GTID atau Pengidentifikasi Transaksi Global diperkenalkan di MySQL 5.6.5. GTID adalah id unik global yang diberikan untuk semua transaksi yang dijalankan di server hosting MySQL berkemampuan GTID. GTID adalah kombinasi dari UUID server tempat transaksi tertentu telah dilakukan, dan nomor urut transaksi tersebut pada server tertentu. Hal ini membuat GTID unik secara global.
Replikasi MySQL
Replikasi berbasis GTID jauh lebih fleksibel dibandingkan dengan replikasi berbasis binlog yang lebih lama. Dalam pengaturan berbasis GTID, slave tidak memerlukan file binlog master dan posisi untuk memulai replikasi. Baca selengkapnya tentang replikasi berbasis GTID. Dalam posting blog ini kita akan membahas beberapa masalah umum replikasi MySQL yang disebabkan saat menerapkan kumpulan replika berbasis GTID.
Transaksi salah adalah transaksi yang diterapkan ke satu atau lebih slave yang tidak perlu direplikasi pada node lain. Ini bisa berupa perbaikan intermiten yang diterapkan pada slave, atau penulisan yang tidak disengaja ke slave oleh aplikasi.
Masalah dengan transaksi yang salah ini muncul ketika budak yang berisi transaksi yang salah dipromosikan menjadi master. Dalam kasus replikasi berbasis GTID, ini akan menyebabkan masalah. Master baru sekarang menyadari bahwa budak belum mengeksekusi transaksi yang salah. Salah satu dari dua hal dapat terjadi:
(1) Transaksi yang salah masih ada di binlog master dan akan mengirimkannya ke budak, ini dapat merusak data atau menyebabkan kesalahan.
(2) Transaksi tidak ada di binlog, dan karenanya tidak dapat dikirim ke slave, yang menyebabkan kesalahan replikasi.
Pencegahan
Transaksi yang salah dapat dicegah secara aktif dengan mengikuti langkah-langkah ini. Jika Anda harus menerapkan perbaikan pada slave, salah satu cara untuk mengurangi transaksi yang salah adalah dengan mematikan sementara logging biner pada slave. Mengeksekusi sql_bin_log =0 sebelum mengeksekusi kueri yang salah harus berhasil. Nanti Anda dapat mengaktifkan binlog dengan menjalankan sql_bin_log =1.Untuk mencegah aplikasi menulis ke slave, Read-Only harus diaktifkan di server saat dikonfigurasi sebagai slave.
Deteksi
Mendeteksi transaksi yang salah dalam kumpulan replika MySQL berbasis GTID itu mudah. MySQL menyimpan semua GTID yang dieksekusi dalam tabel Skema Kinerja/Skema Informasi berdasarkan versi MySQL yang Anda gunakan. Mengambil GTID yang dijalankan slave saat ini dan mengurangkannya dari GTID yang dieksekusi pada master saat ini akan memberi Anda semua transaksi yang salah pada slave tersebut. Utilitas seperti mysqlfailover atau mysqlrpladmin juga dapat membantu dalam mendeteksi transaksi yang salah.
Solusi
Setelah transaksi yang salah terdeteksi, ada dua cara Anda dapat memperbaiki kesalahan replikasi yang disebabkan setelah failover. Salah satu caranya adalah dengan menghapus GTID dari transaksi yang salah dari riwayat yang dieksekusi GTID budak. Dengan cara ini, ketika budak dipromosikan menjadi master, transaksi yang salah tidak akan direplikasi ke semua node. Cara lain untuk menangani transaksi yang salah adalah dengan memberi tahu semua budak lain untuk melewati transaksi yang salah. Itu termasuk memasukkan transaksi kosong dengan GTID yang sama dengan transaksi yang salah ke semua node lain di set replika. Ini akan membuat semua node lain berpikir bahwa mereka telah menerapkan transaksi ini dan karenanya akan melewatinya. MySQL memiliki utilitas bernama Mysqlslavetrx yang didedikasikan untuk melakukan ini. Utilitas ini dapat digunakan untuk memasukkan transaksi kosong dengan GTID yang diberikan. Menambahkan transaksi kosong juga dapat memiliki kegunaan lain , seperti yang dibahas di sini.
