RDS không cho phép ngay cả người dùng chính SUPER đặc quyền và điều này là bắt buộc để thực thi FLUSH TABLES WITH READ LOCK . (Đây là một hạn chế đáng tiếc của RDS).
Câu lệnh không thành công đang được tạo bởi --master-data , tất nhiên là cần thiết nếu bạn muốn có thể tìm hiểu tọa độ binlog chính xác nơi bắt đầu sao lưu. FLUSH TABLES WITH READ LOCK có được khóa đọc toàn cục trên tất cả các bảng, cho phép mysqldump START TRANSACTION WITH CONSISTENT SNAPSHOT (như với --single-transaction ) và sau đó SHOW MASTER STATUS để lấy tọa độ nhật ký nhị phân, sau đó nó giải phóng khóa đọc toàn cục vì nó có một giao dịch sẽ giữ cho dữ liệu hiển thị ở trạng thái nhất quán với vị trí nhật ký đó.
RDS phá vỡ cơ chế này bằng cách từ chối SUPER đặc quyền và không cung cấp cách giải quyết rõ ràng nào.
Có một số tùy chọn hacky có sẵn để giải quyết vấn đề này một cách chính xác, không có tùy chọn nào trong số đó có thể đặc biệt hấp dẫn:
-
thực hiện sao lưu trong khoảng thời gian lưu lượng truy cập thấp. Nếu tọa độ binlog không thay đổi giữa thời điểm bạn bắt đầu sao lưu và sau khi sao lưu bắt đầu ghi dữ liệu vào tệp đầu ra hoặc máy chủ đích (giả sử bạn đã sử dụng
--single-transaction) thì điều này sẽ hoạt động vì bạn biết tọa độ không thay đổi trong khi quá trình đang chạy. -
quan sát vị trí binlog trên trang cái ngay trước khi bắt đầu sao lưu và sử dụng các tọa độ này với
CHANGE MASTER TO. Nếubinlog_formatcủa chủ bạn được đặt thànhROWthì điều này sẽ hoạt động, mặc dù bạn có thể sẽ phải bỏ qua một vài lỗi ban đầu, nhưng sau đó sẽ không có bất kỳ lỗi nào. Điều này hoạt động vì sao chép dựa trên hàng rất xác định và sẽ dừng lại nếu nó cố gắng chèn một cái gì đó đã có ở đó hoặc xóa một cái gì đó đã biến mất. Sau khi vượt qua các lỗi, bạn sẽ ở tọa độ binlog thực nơi ảnh chụp nhanh nhất quán thực sự bắt đầu. -
như trong mục trước, nhưng sau khi khôi phục bản sao lưu, hãy thử xác định vị trí chính xác bằng cách sử dụng
mysqlbinlog --base64-output=decode-rows --verboseđể đọc binlog của master tại các tọa độ mà bạn thu được, kiểm tra nô lệ mới của bạn để xem các sự kiện nào phải đã được thực thi trước khi thực sự bắt đầu chụp nhanh và sử dụng các tọa độ được xác định theo cách này đểCHANGE MASTER TO. -
sử dụng một quy trình bên ngoài để có được khóa đọc trên mỗi và mọi bảng trên máy chủ, quy trình này sẽ dừng tất cả quá trình ghi; quan sát rằng vị trí binlog từ
SHOW MASTER STATUSđã ngừng tăng, bắt đầu sao lưu và giải phóng các khóa đó.
Nếu bạn sử dụng bất kỳ phương pháp nào trong số này ngoài cách tiếp cận cuối cùng, điều đặc biệt quan trọng là bạn phải thực hiện so sánh bảng để chắc chắn rằng nô lệ của bạn giống hệt với phương pháp chính khi nó đang chạy. Nếu bạn gặp lỗi sao chép tiếp theo ... thì không phải vậy.
Có lẽ là lựa chọn an toàn nhất - nhưng cũng có thể là khó chịu nhất vì có vẻ như nó không cần thiết - bắt đầu bằng cách tạo một bản sao đọc RDS của bản sao RDS của bạn. Sau khi nó được thiết lập và đồng bộ hóa với bản chính, bạn có thể dừng sao chép trên bản sao đọc RDS bằng cách thực hiện một thủ tục được lưu trữ do RDS cung cấp, CALL mysql.rds_stop_replication được giới thiệu trong RDS 5.6.13 và 5.5.33 không yêu cầu SUPER đặc ân.
Khi nô lệ bản sao RDS đã dừng, hãy lấy mysqldump của bạn từ bản sao đọc RDS, bây giờ sẽ có một tập dữ liệu không thay đổi trên đó như một tập tọa độ chính cụ thể. Khôi phục bản sao lưu này vào máy nô lệ ngoài trang web của bạn và sau đó sử dụng tọa độ chính của bản sao đọc RDS từ SHOW SLAVE STATUS Exec_Master_Log_Pos và Relay_Master_Log_File với tư cách là CHANGE MASTER TO của bạn tọa độ.
Giá trị được hiển thị trong Exec_Master_Log_Pos trên nô lệ là thời điểm bắt đầu giao dịch tiếp theo hoặc sự kiện được xử lý
và đó chính xác là nơi nô lệ mới của bạn cần bắt đầu đọc trên bản chính.
Sau đó, bạn có thể ngừng truyền bản sao đọc RDS sau khi nô lệ bên ngoài của bạn đã hoạt động.
