MySQL trong đám mây - Ưu và nhược điểm của Amazon RDS

Di chuyển dữ liệu của bạn sang một dịch vụ đám mây công cộng là một quyết định lớn. Tất cả các nhà cung cấp đám mây lớn đều cung cấp dịch vụ cơ sở dữ liệu đám mây, trong đó Amazon RDS cho MySQL có lẽ là dịch vụ phổ biến nhất.

Trong blog này, chúng ta sẽ xem xét kỹ nó là gì, nó hoạt động như thế nào và so sánh ưu và nhược điểm của nó.

RDS (Dịch vụ Cơ sở dữ liệu Quan hệ) là một dịch vụ cung cấp Dịch vụ Web của Amazon. Tóm lại, nó là Cơ sở dữ liệu như một Dịch vụ, nơi Amazon triển khai và vận hành cơ sở dữ liệu của bạn. Nó đảm nhận các nhiệm vụ như sao lưu và vá phần mềm cơ sở dữ liệu, cũng như tính sẵn sàng cao. Một số cơ sở dữ liệu được hỗ trợ bởi RDS, chúng tôi chủ yếu quan tâm đến MySQL - Amazon hỗ trợ MySQL và MariaDB. Ngoài ra còn có Aurora, là bản sao MySQL của Amazon, được cải thiện, đặc biệt là trong lĩnh vực nhân rộng và tính khả dụng cao.

Triển khai MySQL qua RDS

Hãy cùng xem việc triển khai MySQL qua RDS. Chúng tôi đã chọn MySQL và sau đó chúng tôi được giới thiệu với một số mẫu triển khai để lựa chọn.

Sự lựa chọn chính là - chúng ta có muốn có tính khả dụng cao hay không? Aurora cũng được quảng bá.

Hộp thoại tiếp theo cung cấp cho chúng ta một số tùy chọn để tùy chỉnh. Bạn có thể chọn một trong nhiều phiên bản MySQL - một số phiên bản 5.5, 5.6 và 5.7 có sẵn. Phiên bản cơ sở dữ liệu - bạn có thể chọn từ các kích thước phiên bản điển hình có sẵn trong một khu vực nhất định.

Lựa chọn tiếp theo là một lựa chọn khá quan trọng - bạn có muốn sử dụng triển khai multi-AZ hay không? Đây là tất cả về tính khả dụng cao. Nếu bạn không muốn sử dụng triển khai multi-AZ, một phiên bản duy nhất sẽ được cài đặt. Trong trường hợp không thành công, một cái mới sẽ được tách ra và khối lượng dữ liệu của nó sẽ được tính lại vào nó. Quá trình này mất một thời gian, trong đó cơ sở dữ liệu của bạn sẽ không khả dụng. Tất nhiên, bạn có thể giảm thiểu tác động này bằng cách sử dụng nô lệ và quảng cáo một trong số chúng, nhưng đó không phải là một quy trình tự động. Nếu bạn muốn có tính sẵn sàng cao tự động, bạn nên sử dụng triển khai multi-AZ. Điều gì sẽ xảy ra là hai cá thể cơ sở dữ liệu sẽ được tạo. Một là hiển thị cho bạn. Phiên bản thứ hai, trong một vùng khả dụng riêng biệt, không hiển thị cho người dùng. Nó sẽ hoạt động như một bản sao bóng, sẵn sàng tiếp nhận lưu lượng truy cập khi nút hoạt động bị lỗi. Nó vẫn không phải là một giải pháp hoàn hảo vì lưu lượng truy cập phải được chuyển từ phiên bản bị lỗi sang phiên bản bóng tối. Trong các thử nghiệm của chúng tôi, mất ~ 45 giây để thực hiện chuyển đổi dự phòng nhưng rõ ràng, nó có thể phụ thuộc vào kích thước phiên bản, hiệu suất I / O, v.v. Nhưng tốt hơn nhiều so với chuyển đổi dự phòng không tự động chỉ có nô lệ tham gia.

Cuối cùng, chúng tôi có cài đặt lưu trữ - loại, kích thước, PIOPS (nếu có) và cài đặt cơ sở dữ liệu - số nhận dạng, người dùng và mật khẩu.

Trong bước tiếp theo, một số tùy chọn khác đang chờ người dùng nhập.

Chúng ta có thể chọn nơi mà phiên bản sẽ được tạo:VPC, mạng con, nó có công khai hay không (như trong - nếu IP công cộng được chỉ định cho cá thể RDS), vùng khả dụng và Nhóm bảo mật VPC. Sau đó, chúng tôi có các tùy chọn cơ sở dữ liệu:lược đồ đầu tiên sẽ được tạo, cổng, tham số và nhóm tùy chọn, thẻ siêu dữ liệu có nên được đưa vào ảnh chụp nhanh hay không, cài đặt mã hóa.

Tiếp theo, các tùy chọn sao lưu - bạn muốn giữ các bản sao lưu của mình trong bao lâu? Bạn muốn chúng chụp khi nào? Thiết lập tương tự liên quan đến việc bảo trì - đôi khi quản trị viên Amazon phải thực hiện bảo trì trên phiên bản RDS của bạn - nó sẽ xảy ra trong một cửa sổ xác định trước mà bạn có thể đặt tại đây. Xin lưu ý, không có tùy chọn nào là không chọn ít nhất 30 phút cho thời hạn bảo trì, đó là lý do tại sao việc sản xuất phiên bản multi-AZ thực sự quan trọng. Việc bảo trì có thể dẫn đến việc khởi động lại nút hoặc thiếu tính khả dụng trong một thời gian. Nếu không có multi-AZ, bạn cần chấp nhận thời gian chết đó. Với việc triển khai nhiều AZ, chuyển đổi dự phòng sẽ xảy ra.

Cuối cùng, chúng tôi có các cài đặt liên quan đến giám sát bổ sung - chúng tôi có muốn bật tính năng này hay không?

Quản lý RDS

Trong chương này, chúng ta sẽ xem xét kỹ hơn cách quản lý MySQL RDS. Chúng tôi sẽ không xem xét mọi tùy chọn hiện có, nhưng chúng tôi muốn làm nổi bật một số tính năng mà Amazon cung cấp.

Ảnh chụp nhanh

MySQL RDS sử dụng khối lượng EBS làm bộ lưu trữ, vì vậy nó có thể sử dụng ảnh chụp nhanh EBS cho các mục đích khác nhau. Sao lưu, nô lệ - tất cả đều dựa trên ảnh chụp nhanh. Bạn có thể tạo ảnh chụp nhanh theo cách thủ công hoặc chúng có thể được chụp tự động khi có nhu cầu. Điều quan trọng cần lưu ý là ảnh chụp nhanh EBS, nói chung (không chỉ trên các phiên bản RDS), thêm một số chi phí cho các hoạt động I / O. Nếu bạn muốn chụp nhanh, hãy mong đợi hiệu suất I / O của bạn giảm xuống. Đó là trừ khi bạn sử dụng triển khai đa AZ. Trong trường hợp đó, phiên bản "bóng" sẽ được sử dụng làm nguồn ảnh chụp nhanh và sẽ không có tác động nào hiển thị trên phiên bản sản xuất.

Bản sao lưu

Sao lưu dựa trên ảnh chụp nhanh. Như đã đề cập ở trên, bạn có thể xác định lịch trình sao lưu và lưu giữ khi bạn tạo một phiên bản mới. Tất nhiên, bạn có thể chỉnh sửa các cài đặt đó sau đó, thông qua tùy chọn "sửa đổi phiên bản".

Bất kỳ lúc nào bạn cũng có thể khôi phục ảnh chụp nhanh - bạn cần đi tới phần ảnh chụp nhanh, chọn ảnh chụp nhanh bạn muốn khôi phục và bạn sẽ thấy một hộp thoại tương tự như hộp thoại bạn đã thấy khi tạo một phiên bản mới. Đây không phải là điều ngạc nhiên vì bạn chỉ có thể khôi phục ảnh chụp nhanh thành một phiên bản mới - không có cách nào để khôi phục nó trên một trong các phiên bản RDS hiện có. Điều này có thể gây ngạc nhiên, nhưng ngay cả trong môi trường đám mây, việc sử dụng lại phần cứng (và các phiên bản bạn đã có) có thể có ý nghĩa. Trong môi trường chia sẻ, hiệu suất của một phiên bản ảo duy nhất có thể khác nhau - bạn có thể thích gắn bó với cấu hình hiệu suất mà bạn đã quen thuộc. Rất tiếc, điều này không thể thực hiện được trong RDS.

Một tùy chọn khác trong RDS là khôi phục theo thời gian - tính năng rất quan trọng, là yêu cầu đối với bất kỳ ai cần chăm sóc tốt dữ liệu của mình. Ở đây mọi thứ phức tạp hơn và kém tươi sáng hơn. Đối với người mới bắt đầu, điều quan trọng cần lưu ý là MySQL RDS ẩn nhật ký nhị phân khỏi người dùng. Bạn có thể thay đổi một số cài đặt và liệt kê các binlog đã tạo, nhưng bạn không có quyền truy cập trực tiếp vào chúng - để thực hiện bất kỳ thao tác nào, kể cả sử dụng chúng để khôi phục, bạn chỉ có thể sử dụng UI hoặc CLI. Điều này giới hạn các tùy chọn của bạn trong phạm vi những gì Amazon cho phép bạn làm và nó cho phép bạn khôi phục bản sao lưu của mình tới “thời gian khôi phục” mới nhất được tính trong khoảng thời gian 5 phút. Vì vậy, nếu dữ liệu của bạn đã bị xóa lúc 9 giờ 33a, bạn chỉ có thể khôi phục dữ liệu đó về trạng thái lúc 9 giờ 30a. Khôi phục theo thời gian hoạt động giống như khôi phục ảnh chụp nhanh - một phiên bản mới được tạo.

Mở rộng quy mô, nhân rộng

MySQL RDS cho phép mở rộng quy mô thông qua việc thêm các nô lệ mới. Khi một máy chủ được tạo, một ảnh chụp nhanh của máy chủ sẽ được chụp và nó được sử dụng để tạo một máy chủ mới. Phần này hoạt động khá tốt. Thật không may, bạn không thể tạo bất kỳ cấu trúc liên kết sao chép phức tạp hơn như cấu trúc liên quan đến các bậc thầy trung gian. Bạn không thể tạo thiết lập tổng thể - tổng thể, thiết lập này sẽ để lại bất kỳ HA nào trong tay Amazon (và các triển khai đa AZ). Từ những gì chúng tôi có thể nói, không có cách nào để kích hoạt GTID (không phải bạn có thể hưởng lợi từ nó vì bạn không có bất kỳ quyền kiểm soát nào đối với việc sao chép, không có THAY ĐỔI MASTER trong RDS), chỉ có các vị trí binlog kiểu cũ.

Thiếu GTID làm cho việc sử dụng sao chép đa luồng không khả thi - trong khi có thể thiết lập một số công nhân sử dụng nhóm tham số RDS, nếu không có GTID thì không sử dụng được. Vấn đề chính là không có cách nào để xác định vị trí nhật ký nhị phân duy nhất trong trường hợp xảy ra sự cố - một số công nhân có thể đã đứng sau, một số có thể tiến bộ hơn. Nếu bạn sử dụng sự kiện được áp dụng mới nhất, bạn sẽ mất dữ liệu chưa được áp dụng bởi những người lao động "chậm trễ" đó. Nếu bạn sử dụng sự kiện cũ nhất, rất có thể bạn sẽ gặp phải lỗi "khóa trùng lặp" do các sự kiện được áp dụng bởi những nhân viên cao cấp hơn. Tất nhiên, có một cách để giải quyết vấn đề này nhưng nó không hề nhỏ và tốn nhiều thời gian - chắc chắn không phải là thứ bạn có thể dễ dàng tự động hóa.

Người dùng được tạo trên MySQL RDS không có đặc quyền SUPER nên các hoạt động, vốn đơn giản trong MySQL độc lập, không hề tầm thường trong RDS. Amazon đã quyết định sử dụng các quy trình được lưu trữ để trao quyền cho người dùng thực hiện một số hoạt động đó. Từ những gì chúng tôi có thể cho biết, một số vấn đề tiềm ẩn được đề cập mặc dù không phải lúc nào cũng vậy - chúng tôi nhớ khi bạn không thể xoay sang nhật ký nhị phân tiếp theo trên bản chính. Lỗi chính + hỏng binlog có thể làm cho tất cả các nô lệ bị hỏng - bây giờ có một quy trình cho điều đó: rds_next_master_log .

Một nô lệ có thể được thăng cấp theo cách thủ công thành chủ. Điều này sẽ cho phép bạn tạo một số loại HA trên cơ chế đa AZ (hoặc bỏ qua nó) nhưng nó đã trở nên vô nghĩa bởi thực tế là bạn không thể reslave bất kỳ nô lệ nào hiện có cho chủ mới. Hãy nhớ rằng bạn không có bất kỳ quyền kiểm soát nào đối với việc sao chép. Điều này làm cho toàn bộ bài tập trở nên vô ích - trừ khi chủ của bạn có thể đáp ứng tất cả lưu lượng truy cập của bạn. Sau khi thăng cấp một chủ mới, bạn không thể chuyển đổi dự phòng cho nó vì nó không có bất kỳ nô lệ nào để xử lý tải của bạn. Việc quay vòng các nô lệ mới sẽ mất thời gian vì ảnh chụp nhanh EBS phải được tạo trước và quá trình này có thể mất hàng giờ. Sau đó, bạn cần làm nóng cơ sở hạ tầng trước khi có thể tải nó.

Thiếu đặc quyền siêu cấp

Như chúng tôi đã nói trước đó, RDS không cấp cho người dùng đặc quyền SUPER và điều này trở nên khó chịu đối với những người đã quen sử dụng nó trên MySQL. Hãy nghi ngờ rằng, trong những tuần đầu tiên, bạn sẽ học được mức độ thường xuyên phải làm những việc mà bạn thường làm - chẳng hạn như hủy truy vấn hoặc vận hành lược đồ hiệu suất. Trong RDS, bạn sẽ phải tuân theo danh sách các thủ tục được lưu trữ được xác định trước và sử dụng chúng thay vì thực hiện mọi việc trực tiếp. Bạn có thể liệt kê tất cả chúng bằng cách sử dụng truy vấn sau:

SELECT specific_name FROM information_schema.routines;

Đối với nhân rộng, một số nhiệm vụ được đề cập nhưng nếu bạn rơi vào tình huống chưa được đề cập, thì bạn đã gặp may.

Khả năng tương tác và Thiết lập đám mây kết hợp

Đây là một lĩnh vực khác mà RDS thiếu tính linh hoạt. Giả sử bạn muốn xây dựng một thiết lập đám mây / tại chỗ hỗn hợp - bạn có cơ sở hạ tầng RDS và bạn muốn tạo một vài nô lệ tại chỗ. Vấn đề chính mà bạn sẽ gặp phải là không có cách nào để di chuyển dữ liệu ra khỏi RDS ngoại trừ việc thực hiện một kết xuất hợp lý. Bạn có thể chụp nhanh dữ liệu RDS nhưng bạn không có quyền truy cập vào chúng và bạn không thể di chuyển chúng khỏi AWS. Bạn cũng không có quyền truy cập thực tế vào phiên bản để sử dụng xtrabackup, rsync hoặc thậm chí cp. Lựa chọn duy nhất cho bạn là sử dụng mysqldump, mydumper hoặc các công cụ tương tự. Điều này làm tăng thêm độ phức tạp (cài đặt bộ ký tự và đối chiếu có khả năng gây ra sự cố) và tốn thời gian (mất nhiều thời gian để kết xuất và tải dữ liệu bằng các công cụ sao lưu hợp lý).

Có thể thiết lập sao chép giữa RDS và một phiên bản bên ngoài (theo cả hai cách, vì vậy việc di chuyển dữ liệu vào RDS cũng có thể thực hiện được), nhưng nó có thể là một quá trình rất tốn thời gian.

Mặt khác, nếu bạn muốn ở trong môi trường RDS và mở rộng cơ sở hạ tầng của mình qua Đại Tây Dương hoặc từ bờ đông sang bờ Tây Hoa Kỳ, RDS cho phép bạn làm điều đó - bạn có thể dễ dàng chọn một khu vực khi tạo nô lệ mới.

Thật không may, nếu bạn muốn di chuyển cái chính của mình từ vùng này sang vùng khác, điều này hầu như không thể thực hiện được nếu không có thời gian ngừng hoạt động - trừ khi một nút duy nhất của bạn có thể xử lý tất cả lưu lượng truy cập của bạn.

Bảo mật

Mặc dù MySQL RDS là một dịch vụ được quản lý, nhưng không phải mọi khía cạnh liên quan đến bảo mật đều được các kỹ sư của Amazon đảm nhận. Amazon gọi nó là “Mô hình trách nhiệm chung”. Nói tóm lại, Amazon đảm nhận bảo mật của mạng và lớp lưu trữ (để dữ liệu được truyền một cách an toàn), hệ điều hành (các bản vá lỗi, sửa lỗi bảo mật). Mặt khác, người dùng phải quan tâm đến phần còn lại của mô hình bảo mật. Đảm bảo lưu lượng truy cập đến và đi từ phiên bản RDS được giới hạn trong VPC, đảm bảo rằng xác thực cấp cơ sở dữ liệu được thực hiện đúng (không có tài khoản người dùng MySQL không có mật khẩu), xác minh rằng bảo mật API được đảm bảo (AMI được đặt chính xác và với các đặc quyền bắt buộc tối thiểu). Người dùng cũng nên quan tâm đến các cài đặt tường lửa (nhóm bảo mật) để giảm thiểu việc RDS và VPC có trong mạng bên ngoài. Người dùng cũng có trách nhiệm triển khai dữ liệu ở chế độ mã hóa còn lại - ở cấp ứng dụng hoặc cấp cơ sở dữ liệu, bằng cách tạo phiên bản RDS được mã hóa ngay từ đầu.

Mã hóa cấp độ cơ sở dữ liệu chỉ có thể được bật khi tạo phiên bản, bạn không thể mã hóa cơ sở dữ liệu hiện có, đã chạy.

Giới hạn RDS

Nếu bạn định sử dụng RDS hoặc nếu bạn đã sử dụng nó, bạn cần lưu ý những hạn chế đi kèm với MySQL RDS.

Thiếu đặc quyền SUPER có thể, như chúng tôi đã đề cập, rất khó chịu. Trong khi các thủ tục được lưu trữ xử lý một số hoạt động, nó là một đường cong học tập vì bạn cần học cách làm mọi thứ theo một cách khác. Thiếu đặc quyền SUPER cũng có thể gây ra vấn đề trong việc sử dụng các công cụ theo dõi và xu hướng bên ngoài - vẫn có một số công cụ có thể yêu cầu đặc quyền này cho một số phần chức năng của nó.

Thiếu quyền truy cập trực tiếp vào nhật ký và thư mục dữ liệu MySQL khiến việc thực hiện các tác vụ trở nên khó khăn hơn liên quan đến chúng. Thỉnh thoảng, nó xảy ra khi một DBA cần phân tích cú pháp các bản ghi nhị phân hoặc lỗi đuôi, truy vấn chậm hoặc nhật ký chung. Mặc dù có thể truy cập các nhật ký đó trên RDS, nhưng nó cồng kềnh hơn là làm bất cứ điều gì bạn cần bằng cách đăng nhập vào shell trên máy chủ MySQL. Việc tải chúng xuống cục bộ cũng mất một chút thời gian và thêm độ trễ cho bất cứ việc gì bạn làm.

Thiếu sự kiểm soát đối với cấu trúc liên kết sao chép, tính khả dụng cao chỉ trong các triển khai đa AZ. Do bạn không có quyền kiểm soát việc sao chép, bạn không thể triển khai bất kỳ loại cơ chế sẵn sàng cao nào vào lớp cơ sở dữ liệu của mình. Không quan trọng là bạn có nhiều nô lệ, bạn không thể sử dụng một số nô lệ trong số họ làm ứng cử viên chính vì ngay cả khi bạn thăng cấp nô lệ cho chủ nhân, không có cách nào để khôi phục nô lệ còn lại khỏi chủ nhân mới này. Điều này buộc người dùng phải sử dụng triển khai nhiều AZ và tăng chi phí (bản sao "bóng tối" không miễn phí, người dùng phải trả tiền cho nó).

Tính khả dụng giảm do thời gian ngừng hoạt động theo kế hoạch. Khi triển khai một phiên bản RDS, bạn buộc phải chọn khoảng thời gian hàng tuần là 30 phút trong đó các hoạt động bảo trì có thể được thực hiện trên phiên bản RDS của bạn. Mặt khác, điều này có thể hiểu được vì RDS là Cơ sở dữ liệu dưới dạng Dịch vụ nên việc nâng cấp phần cứng và phần mềm cho các phiên bản RDS của bạn được các kỹ sư AWS quản lý. Mặt khác, điều này làm giảm tính khả dụng của bạn vì bạn không thể ngăn cơ sở dữ liệu chính của mình ngừng hoạt động trong suốt thời gian bảo trì. Một lần nữa, trong trường hợp này, việc sử dụng thiết lập multi-AZ sẽ làm tăng tính khả dụng vì các thay đổi xảy ra đầu tiên trên phiên bản bóng và sau đó chuyển đổi dự phòng được thực hiện. Tuy nhiên, bản thân dự phòng không minh bạch, vì vậy, bằng cách này hay cách khác, bạn sẽ mất thời gian hoạt động. Điều này buộc bạn phải thiết kế ứng dụng của mình với những lỗi chính MySQL không mong muốn. Không phải đó là một mẫu thiết kế tồi - cơ sở dữ liệu có thể gặp sự cố bất cứ lúc nào và ứng dụng của bạn phải được xây dựng theo cách có thể chống chọi được với cả tình huống thảm khốc nhất. Chỉ là với RDS, bạn có các tùy chọn hạn chế để có tính khả dụng cao.

Giảm tùy chọn để triển khai tính khả dụng cao. Do sự thiếu linh hoạt trong quản lý cấu trúc liên kết sao chép, phương pháp khả thi cao duy nhất là triển khai đa AZ. Phương pháp này là tốt nhưng có những công cụ để sao chép MySQL sẽ giảm thiểu thời gian chết hơn nữa. Ví dụ:MHA hoặc ClusterControl khi được sử dụng kết nối với ProxySQL có thể cung cấp (trong một số điều kiện như thiếu các giao dịch chạy dài) quá trình chuyển đổi dự phòng minh bạch cho ứng dụng. Trong khi sử dụng RDS, bạn sẽ không thể sử dụng phương pháp này.

Giảm thông tin chi tiết về hiệu suất của cơ sở dữ liệu của bạn. Mặc dù bạn có thể nhận được các số liệu từ chính MySQL, nhưng đôi khi chỉ là không đủ để có được cái nhìn đầy đủ về tình hình. Tại một số thời điểm, phần lớn người dùng sẽ phải đối mặt với những vấn đề thực sự kỳ lạ do phần cứng bị lỗi hoặc cơ sở hạ tầng bị lỗi - mất gói mạng, kết nối bị ngắt đột ngột hoặc sử dụng CPU cao bất ngờ. Khi bạn có quyền truy cập vào máy chủ MySQL của mình, bạn có thể tận dụng rất nhiều công cụ giúp bạn chẩn đoán trạng thái của máy chủ Linux. Khi sử dụng RDS, bạn bị giới hạn ở những chỉ số nào có sẵn trong Cloudwatch, công cụ theo dõi và xu hướng của Amazon. Mọi chẩn đoán chi tiết hơn yêu cầu liên hệ với bộ phận hỗ trợ và yêu cầu họ kiểm tra và khắc phục sự cố. Quá trình này có thể nhanh chóng nhưng cũng có thể là một quá trình rất dài với rất nhiều email liên lạc qua lại.

Nhà cung cấp bị khóa do quy trình phức tạp và tốn thời gian để lấy dữ liệu ra khỏi MySQL RDS. RDS không cấp quyền truy cập vào thư mục dữ liệu MySQL nên không có cách nào sử dụng các công cụ tiêu chuẩn của ngành như xtrabackup để di chuyển dữ liệu theo cách nhị phân. Mặt khác, RDS ẩn là một MySQL do Amazon duy trì, rất khó để biết liệu nó có tương thích 100% với ngược dòng hay không. RDS chỉ khả dụng trên AWS, vì vậy bạn sẽ không thể thực hiện thiết lập kết hợp.

Tóm tắt

MySQL RDS có cả điểm mạnh và điểm yếu. Đây là một công cụ rất tốt cho những ai muốn tập trung vào ứng dụng mà không phải lo lắng về việc vận hành cơ sở dữ liệu. Bạn triển khai một cơ sở dữ liệu và bắt đầu đưa ra các truy vấn. Không cần xây dựng tập lệnh sao lưu hoặc thiết lập giải pháp giám sát vì nó đã được thực hiện bởi các kỹ sư AWS - tất cả những gì bạn cần làm là sử dụng nó.

Ngoài ra còn có một mặt tối của MySQL RDS. Thiếu các tùy chọn để xây dựng các thiết lập phức tạp hơn và mở rộng quy mô bên ngoài chỉ thêm nhiều nô lệ. Thiếu hỗ trợ để có tính khả dụng cao tốt hơn so với những gì được đề xuất trong triển khai nhiều AZ. Truy cập rườm rà vào nhật ký MySQL. Thiếu quyền truy cập trực tiếp vào thư mục dữ liệu MySQL và thiếu hỗ trợ sao lưu vật lý, điều này khiến cho việc di chuyển dữ liệu ra khỏi phiên bản RDS trở nên khó khăn.

Tóm lại, RDS có thể phù hợp với bạn nếu bạn coi trọng việc dễ sử dụng hơn là kiểm soát chi tiết cơ sở dữ liệu. Bạn cần lưu ý rằng, tại một số thời điểm trong tương lai, bạn có thể phát triển nhanh hơn MySQL RDS. Chúng tôi không nhất thiết chỉ nói về hiệu suất ở đây. Đó là về nhu cầu của tổ chức bạn đối với cấu trúc liên kết sao chép phức tạp hơn hoặc nhu cầu có cái nhìn sâu sắc hơn về hoạt động cơ sở dữ liệu để giải quyết nhanh chóng các vấn đề khác nhau phát sinh theo thời gian. Trong trường hợp đó, nếu tập dữ liệu của bạn đã tăng kích thước, bạn có thể thấy khó khăn khi chuyển ra khỏi RDS. Trước khi đưa ra bất kỳ quyết định nào để chuyển dữ liệu của bạn vào RDS, người quản lý thông tin phải xem xét các yêu cầu và ràng buộc của tổ chức họ trong các lĩnh vực cụ thể.

Trong một vài bài đăng trên blog tiếp theo, chúng tôi sẽ hướng dẫn bạn cách lấy dữ liệu của bạn ra khỏi RDS vào một vị trí riêng biệt. Chúng tôi sẽ thảo luận về cả việc chuyển đổi sang EC2 và sang cơ sở hạ tầng tại chỗ.