Cara Mengatur Replikasi Asinkron dari Galera Cluster ke server MySQL Standalone dengan GTID

Replikasi hybrid, yaitu menggabungkan Galera dan replikasi MySQL asinkron dalam pengaturan yang sama, menjadi jauh lebih mudah sejak GTID diperkenalkan di MySQL 5.6. Meskipun cukup mudah untuk mereplikasi dari server MySQL mandiri ke Galera Cluster, melakukannya sebaliknya (Galera → standalone MySQL) sedikit lebih menantang. Setidaknya sampai kedatangan GTID.

Ada beberapa alasan bagus untuk memasang slave asinkron ke Galera Cluster. Pertama, kueri pelaporan/jenis OLAP yang berjalan lama pada node Galera mungkin memperlambat seluruh cluster, jika beban pelaporan sangat intensif sehingga node harus mengeluarkan banyak upaya untuk mengatasinya. Jadi kueri pelaporan dapat dikirim ke server mandiri, yang secara efektif mengisolasi Galera dari beban pelaporan. Dalam pendekatan belt dan suspender, slave asinkron juga dapat berfungsi sebagai cadangan langsung jarak jauh.

Dalam posting blog ini, kami akan menunjukkan cara mereplikasi Galera Cluster ke server MySQL dengan GTID, dan cara melakukan failover replikasi jika node master gagal.

Replikasi Hibrida di MySQL 5.5

Di MySQL 5.5, melanjutkan replikasi yang rusak mengharuskan Anda menentukan file dan posisi log biner terakhir, yang berbeda di semua node Galera jika log biner diaktifkan. Kita dapat menggambarkan situasi ini dengan gambar berikut:

Jika master MySQL gagal, replikasi terputus dan slave perlu beralih ke master lain. Anda perlu memilih node Galera baru, dan secara manual menentukan file log biner baru dan posisi transaksi terakhir yang dijalankan oleh slave. Pilihan lain adalah membuang data dari node master baru, mengembalikannya ke slave dan memulai replikasi dengan node master baru. Opsi ini tentu saja dapat dilakukan, tetapi tidak terlalu praktis dalam produksi.

Bagaimana GTID Memecahkan Masalah

GTID (Global Transaction Identifier) ​​menyediakan pemetaan transaksi yang lebih baik di seluruh node, dan didukung di MySQL 5.6. Di Galera Cluster, semua node akan menghasilkan file binlog yang berbeda. Peristiwa binlog sama dan dalam urutan yang sama, tetapi nama file binlog dan offsetnya mungkin berbeda. Dengan GTID, slave dapat melihat transaksi unik yang masuk dari beberapa master dan ini dapat dengan mudah dipetakan ke dalam daftar eksekusi slave jika perlu memulai ulang atau melanjutkan replikasi.

Semua informasi yang diperlukan untuk sinkronisasi dengan master diperoleh langsung dari aliran replikasi. Ini berarti bahwa saat Anda menggunakan GTID untuk replikasi, Anda tidak perlu menyertakan opsi MASTER_LOG_FILE atau MASTER_LOG_POS dalam pernyataan CHANGE MASTER TO. Alih-alih, Anda hanya perlu mengaktifkan opsi MASTER_AUTO_POSITION. Anda dapat menemukan detail lebih lanjut tentang GTID di halaman Dokumentasi MySQL.

Menyiapkan Replikasi Hibrida dengan Tangan

Pastikan node Galera (master) dan slave berjalan di MySQL 5.6 sebelum melanjutkan dengan pengaturan ini. Kami memiliki database bernama sbtest di Galera, yang akan kami replikasi ke node slave.

1. Aktifkan opsi replikasi yang diperlukan dengan menentukan baris berikut di dalam my.cnf setiap node DB (termasuk node slave):

Untuk node master (Galera):

gtid_mode=ON
log_bin=binlog
log_slave_updates=1
enforce_gtid_consistency
expire_logs_days=7
server_id=1         # 1 for master1, 2 for master2, 3 for master3
binlog_format=ROW

Untuk simpul budak:

gtid_mode=ON
log_bin=binlog
log_slave_updates=1
enforce_gtid_consistency
expire_logs_days=7
server_id=101         # 101 for slave
binlog_format=ROW
replicate_do_db=sbtest
slave_net_timeout=60

2. Lakukan rolling restart cluster dari Galera Cluster (dari ClusterControl UI> Manage> Upgrade> Rolling Restart). Ini akan memuat ulang setiap node dengan konfigurasi baru, dan mengaktifkan GTID. Mulai ulang budak juga.

3. Buat pengguna replikasi budak dan jalankan pernyataan berikut di salah satu node Galera:

mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave'@'%' IDENTIFIED BY 'slavepassword';

4. Masuk ke database slave dan dump sbtest dari salah satu node Galera:

$ mysqldump -uroot -p -h192.168.0.201 --single-transaction --skip-add-locks --triggers --routines --events sbtest > sbtest.sql

5. Kembalikan file dump ke server slave:

$ mysql -uroot -p < sbtest.sql

6. Mulai replikasi pada node slave:

mysql> STOP SLAVE;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.201', MASTER_PORT = 3306, MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

Untuk memverifikasi bahwa replikasi berjalan dengan benar, periksa keluaran status budak:

mysql> SHOW SLAVE STATUS\G
       ...
       Slave_IO_Running: Yes
       Slave_SQL_Running: Yes
       ...

Menyiapkan Replikasi Hibrida Menggunakan ClusterControl

Pada paragraf sebelumnya, kami menjelaskan semua langkah yang diperlukan untuk mengaktifkan log biner, memulai ulang node cluster demi node, menyalin data, dan kemudian mengatur replikasi. Prosedurnya adalah tugas yang membosankan dan Anda dapat dengan mudah membuat kesalahan di salah satu langkah ini. Di ClusterControl kami telah mengotomatiskan semua langkah yang diperlukan.

1. Untuk pengguna ClusterControl, Anda dapat membuka node di halaman Nodes dan mengaktifkan logging biner.

Ini akan membuka dialog yang memungkinkan Anda menyetel masa berlaku log biner, mengaktifkan GTID, dan memulai ulang otomatis.

Ini memulai pekerjaan, yang akan dengan aman menulis perubahan ini ke konfigurasi, membuat pengguna replikasi dengan hibah yang tepat, dan memulai ulang node dengan aman.

Ulangi proses ini untuk setiap node Galera dalam cluster, hingga semua node menunjukkan bahwa mereka adalah master.

2. Tambahkan slave replikasi asinkron ke cluster

Dan ini semua yang harus Anda lakukan. Seluruh proses yang dijelaskan dalam paragraf sebelumnya telah diotomatisasi oleh ClusterControl.

Mengganti Guru

Jika master yang ditunjuk turun, budak akan mencoba untuk menyambung kembali lagi dalam nilai slave_net_timeout (setup kami adalah 60 detik - default adalah 1 jam). Anda akan melihat kesalahan berikut pada status budak:

       Last_IO_Errno: 2003
       Last_IO_Error: error reconnecting to master '[email protected]:3306' - retry-time: 60  retries: 1

Karena kami menggunakan Galera dengan GTID diaktifkan, master failover didukung melalui ClusterControl saat Pemulihan Otomatis Cluster dan Node telah diaktifkan. Apakah master akan gagal karena konektivitas jaringan atau alasan lain, ClusterControl akan secara otomatis gagal ke node master lain yang paling cocok di cluster.

Jika Anda ingin melakukan failover secara manual, cukup ubah master node sebagai berikut:

mysql> STOP SLAVE;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.202', MASTER_PORT = 3306, MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

Dalam beberapa kasus, Anda mungkin mengalami kesalahan “Entri duplikat .. untuk kunci” setelah node master diubah:

       Last_Errno: 1062
       Last_Error: Could not execute Write_rows event on table sbtest.sbtest; Duplicate entry '1089775' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysqld-bin.000009, end_log_pos 85789000

Di versi MySQL yang lebih lama, Anda cukup menggunakan SET GLOBAL SQL_SLAVE_SKIP_COUNTER =n untuk melewati pernyataan, tetapi tidak berfungsi dengan GTID. Miguel dari Percona menulis posting blog yang bagus tentang cara memperbaikinya dengan menyuntikkan transaksi kosong.

Pendekatan lain, untuk database yang lebih kecil, juga bisa dengan hanya mendapatkan dump baru dari salah satu node Galera yang tersedia, memulihkannya dan menggunakan pernyataan RESET MASTER:

mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> DROP SCHEMA sbtest; CREATE SCHEMA sbtest; USE sbtest;
mysql> SOURCE /root/sbtest_from_galera2.sql; -- repeat step #4 above to get this dump
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.202', MASTER_PORT = 3306, MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

Anda juga dapat menggunakan pt-table-checksum untuk memverifikasi integritas replikasi, informasi lebih lanjut di entri blog ini.

Catatan:Karena dalam replikasi MySQL, slave applier secara default masih single-threaded, jangan berharap kinerja replikasi async sama dengan replikasi paralel Galera. Untuk MySQL 5.6 dan 5.7 ada opsi untuk membuat replikasi asinkron dijalankan secara paralel pada node slave, tetapi pada prinsipnya replikasi ini masih tergantung pada urutan transaksi yang benar di dalam skema yang sama untuk terjadi. Jika beban replikasi intensif dan berkelanjutan, lag budak akan terus bertambah. Kami telah melihat kasus di mana budak tidak pernah bisa mengejar tuannya.