Tôi là một fan hâm mộ AWS lớn nói chung ... nhưng RDS, không nhiều lắm.
@RolandoMySQLDBA đã chỉ ra một số điểm khá tốt chống lại nó.
Ưu điểm duy nhất tôi thấy trong RDS so với MySQL trên EC2 là khả năng thực hiện các điểm chụp nhanh và nhấp chuột, nhân bản và phục hồi tại thời điểm, nhưng những điều này gần như không đủ để bù cho sự mất kiểm soát và tính linh hoạt và chúng chắc chắn là không biện minh cho giá cao hơn. RDS là gợi cảm theo một số cách, nhưng cuối cùng bạn không thể tin tưởng vào những gì cuối cùng bạn không thể sửa chữa, bởi vì bạn không thể có được tất cả các bộ phận chuyển động.
Tôi không thích không có SUPERđặc quyền. Tôi không thích không thể theo dõi nhật ký lỗi. Tôi không thích không thể chạy "top" hoặc "iuler" trên máy chủ cơ sở dữ liệu của mình để xem các lõi và ổ đĩa đang tận hưởng tải như thế nào. Tôi không thích không có quyền truy cập vào công cụ lưu trữ được liên kết. Tôi không thích nghĩ đến việc trả tiền cho một máy chủ dự phòng nóng (multi-AZ) nóng mà tôi thậm chí không thể tận dụng như một bản sao đọc. Chắc chắn, có những giải thích hoàn toàn hợp lý tại sao tất cả các ràng buộc này phải được đặt ra để MySQL được đóng gói và bán thành công dưới dạng RDBMS-in-a-box. Điều duy nhất là, RDBMS-in-a-box "giải quyết" cả loạt vấn đề tôi không gặp phải ... và cản trở tôi, gây ra những vấn đề mới.
Nhưng công cụ giảm giá tuyệt đối với tôi với RDS là thiếu hoàn toàn quyền truy cập vào nhật ký nhị phân và sao chép. Binlog, đặc biệt là dựa trên hàng, là một công cụ khôi phục tuyệt vời cho các thảm họa nhỏ, nhưng chúng không giúp ích gì cho bạn nếu bạn không thể truy cập chúng. Bạn muốn định cấu hình máy chủ tại chỗ tại văn phòng của bạn dưới dạng bản sao đọc của cơ sở dữ liệu sản xuất của bạn trong RDS? Một cái gì đó để sao lưu cục bộ từ, làm báo cáo, có sẵn để khắc phục thảm họa nếu điều gì đó không thể tưởng tượng được xảy ra với dữ liệu của bạn sống trong RDS? Đó là một ý tưởng đồng thời rõ ràng và xuất sắc.
Rất tiếc, xin lỗi, truy cập trực tiếp để nhân rộng không có sẵn. Chắc chắn, bạn có thể trả tiền để đọc bản sao ... nhưng chỉ như các trường hợp RDS khác. Không phải là một đề xuất giá trị trong cuốn sách của tôi.
Cập nhật: Một thay đổi đáng kể trong RDS cho MySQL 5.6
Tôi vẫn thích chạy máy chủ của riêng tôi (ngay cả trong EC2) như trái ngược với chạy RDS cho một số lý do, trong đó có việc thiếu hỗ trợ cho User-Defined Functions , không có khả năng sử dụng Federated Storage Engine , và không có khả năng để có một kết nối bổ sung có sẵn để truy cập khẩn cấp ... tuy nhiên ...
Amazon đã thực hiện một thay đổi đáng kể trong MySQL 5.6 cho RDS, loại bỏ một trong những phản đối chính của tôi - có lẽ là sự phản đối lớn nhất của tôi: nhật ký nhị phân hiện có thể truy cập và bạn có thể chạy một phiên bản không phải RDS làm nô lệ hoặc kết nối các tiện ích khác với máy chủ đọc luồng binlog.
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MyQuery.Procedural.Exporting.NonRDSRepl.html
Chính thức, tài liệu chỉ ra rằng họ đang phơi bày điều này để bạn có thể thiết lập nô lệ cho mục đích di chuyển trực tiếp - bạn đồng bộ hóa máy chủ chính tương lai nước ngoài từ phiên bản RDS hiện tại bằng cách sử dụng mysqldump, sau đó kết nối nó với RDS làm nô lệ để nhận nguồn cấp dữ liệu cập nhật trực tiếp qua luồng sao chép cho đến khi ứng dụng của bạn được chuyển sang chủ mới - nhưng không chính thức, bạn có thể thực hiện việc này trên cơ sở liên tục miễn là bạn không mong đợi chúng hỗ trợ bạn ... mà, với tôi, có vẻ hợp lý
Điều này đã được xác nhận trong một Hội thảo trên web gần đây , trong một cuộc trò chuyện bắt đầu vào khoảng 56:45:
"Bạn có thể giữ nó ở trạng thái sao chép vô thời hạn ...
"... miễn là bạn có trách nhiệm duy trì việc nhân rộng ..."
"Chúng tôi không ngăn cản bạn thực hiện sao chép liên tục nếu đó là những gì bạn muốn."
Khả năng mới này đủ để tôi bỏ qua sự phản đối trong việc sử dụng RDS trong các phiên bản MySQL hỗ trợ trang web công khai của chúng tôi, nơi chúng tôi không sử dụng FEDERATEDhoặc một số thứ khác nhiều hoặc nhiều.
Vì vậy, tôi vẫn không ủng hộ nó, nhưng tôi không còn chống lại nó nữa, vì việc phát trực tiếp nhật ký nhị phân khiến tôi cuối cùng phải kiểm soát dữ liệu theo thời gian thực và trách nhiệm đảm bảo rằng không có giao dịch nào bị mất trong một lần mất điện thảm khốc đã trở lại với tôi, bởi vì tôi, với tư cách là DBA, đã trở lại trong tầm kiểm soát - đó chính xác là cách tôi muốn. Có một nhà cung cấp bên thứ ba chỉ tay hoặc nộp đơn kiện, hoặc bất cứ điều gì, sẽ không lấy lại được dữ liệu bị mất của bạn nếu nó biến mất xuống một lỗ đen bên trong hộp đen.
Ban quản lý dường như thích "ý tưởng" của RDS và không phản đối sự khác biệt về chi phí, vì vậy chúng tôi hiện đang tung ra tất cả các trang web mới có RDS phía sau chúng.
Tôi thừa nhận, phục hồi điểm và nhấp vào thời điểm, là một tính năng hay trong RDS ... nó không làm thay đổi hoặc phá vỡ máy hiện tại của bạn - thay vào đó, nó kích hoạt một phiên bản hoàn toàn mới, sử dụng bản sao lưu đó là gần nhất với thời điểm đã chọn, sau đó áp dụng các binlog cần thiết để đưa máy mới đó tiến về điểm mà bạn đã chỉ định.
Liên quan đến vấn đề này, nhưng theo một hướng khác, hiện tại cũng có thể sử dụng một chiến lược tương tự để di chuyển cơ sở dữ liệu MySQL trực tiếp vào RDS ... bạn có thể kết nối một chủ RDS (có lẽ, thông thường, đây sẽ là một triển khai mới được triển khai dụ) như một nô lệ của một hệ thống hiện có để cá thể RDS có phiên bản dữ liệu trực tiếp tại thời điểm bạn di chuyển vào nó. Không giống như truy cập vào các binlog RDS để sao chép ra bên ngoài, chỉ hoạt động trong 5.6, sao chép bên trong được hỗ trợ trong RDS bắt đầu với 5.5.33 và 5.6.13.