RDS bahkan tidak mengizinkan pengguna master SUPER hak istimewa, dan ini diperlukan untuk menjalankan FLUSH TABLES WITH READ LOCK . (Ini adalah keterbatasan RDS yang disayangkan).
Pernyataan gagal dihasilkan oleh --master-data opsi, yang tentu saja diperlukan jika Anda ingin dapat mempelajari koordinat binlog yang tepat di mana pencadangan dimulai. FLUSH TABLES WITH READ LOCK memperoleh kunci baca global pada semua tabel, yang memungkinkan mysqldump untuk START TRANSACTION WITH CONSISTENT SNAPSHOT (seperti halnya dengan --single-transaction ) lalu SHOW MASTER STATUS untuk mendapatkan koordinat log biner, setelah itu melepaskan kunci baca global karena memiliki transaksi yang akan menjaga data yang terlihat dalam keadaan konsisten dengan posisi log tersebut.
RDS merusak mekanisme ini dengan menolak SUPER hak istimewa dan tidak memberikan solusi yang jelas.
Ada beberapa opsi peretasan yang tersedia untuk mengatasi ini dengan benar, tidak ada yang menarik:
-
melakukan backup selama periode lalu lintas rendah. Jika koordinat binlog tidak berubah antara saat Anda memulai pencadangan dan setelah pencadangan mulai menulis data ke file keluaran atau server tujuan (dengan asumsi Anda menggunakan
--single-transaction) maka ini akan berhasil karena Anda tahu koordinatnya tidak berubah saat proses sedang berjalan. -
amati posisi binlog pada master tepat sebelum memulai pencadangan, dan gunakan koordinat ini dengan
CHANGE MASTER TO. Jikabinlog_formatmaster Anda diatur keROWmaka ini akan berfungsi, meskipun Anda mungkin harus melewati beberapa kesalahan awal, tetapi tidak harus memiliki kesalahan selanjutnya. Ini berfungsi karena replikasi berbasis baris sangat deterministik dan akan berhenti jika mencoba memasukkan sesuatu yang sudah ada atau menghapus sesuatu yang sudah hilang. Setelah melewati kesalahan, Anda akan berada di koordinat binlog yang sebenarnya di mana snapshot yang konsisten sebenarnya dimulai. -
seperti pada item sebelumnya, tetapi, setelah memulihkan cadangan, coba tentukan posisi yang benar dengan menggunakan
mysqlbinlog --base64-output=decode-rows --verboseuntuk membaca binlog master pada koordinat yang Anda peroleh, memeriksa slave baru Anda untuk melihat peristiwa mana yang harus telah dieksekusi sebelum snapshot benar-benar dimulai, dan menggunakan koordinat yang ditentukan dengan cara ini untukCHANGE MASTER TO. -
gunakan proses eksternal untuk mendapatkan kunci baca pada setiap tabel di server, yang akan menghentikan semua penulisan; perhatikan bahwa posisi binlog dari
SHOW MASTER STATUStelah berhenti bertambah, mulai pencadangan, dan lepaskan kunci tersebut.
Jika Anda menggunakan salah satu dari pendekatan ini selain mungkin yang terakhir, sangat penting bagi Anda untuk melakukan perbandingan tabel untuk memastikan bahwa slave Anda identik dengan master setelah dijalankan. Jika Anda menemukan kesalahan replikasi berikutnya... maka itu tidak terjadi.
Mungkin opsi teraman -- tetapi juga mungkin yang paling menjengkelkan karena sepertinya itu tidak perlu -- adalah memulai dengan membuat replika baca RDS dari master RDS Anda. Setelah selesai dan disinkronkan ke master, Anda dapat menghentikan replikasi pada replika baca RDS dengan menjalankan prosedur tersimpan yang disediakan RDS, CALL mysql.rds_stop_replication yang diperkenalkan di RDS 5.6.13 dan 5.5.33 yang tidak memerlukan SUPER hak istimewa.
Dengan slave replika RDS dihentikan, ambil mysqldump Anda dari replika baca RDS, yang sekarang akan memiliki kumpulan data yang tidak berubah sebagai kumpulan koordinat master tertentu. Pulihkan cadangan ini ke slave off-site Anda lalu gunakan koordinat master replika baca RDS dari SHOW SLAVE STATUS Exec_Master_Log_Pos dan Relay_Master_Log_File sebagai CHANGE MASTER TO . Anda koordinat.
Nilai yang ditampilkan di Exec_Master_Log_Pos pada budak adalah awal dari transaksi berikutnya atau acara untuk diproses
, dan di situlah budak baru Anda perlu mulai membaca master.
Kemudian Anda dapat menonaktifkan replika baca RDS setelah slave eksternal Anda aktif dan berjalan.
