ApsaraDB RDS：Pengenalan mode MGR

Keandalan data tinggi

Mode MGR menggunakan aturan mayoritas protokol Paxos untuk memastikan keandalan data. Aturan ini menetapkan bahwa suatu transaksi hanya dapat dikomit setelah sebagian besar node dalam kluster RDS menerima log biner dari transaksi tersebut, sehingga mencegah hilangnya data jika sebagian kecil node dalam kluster RDS mengalami kegagalan.

Sebagai contoh, sebuah kluster RDS terdiri dari lima node. Tiga node menerima log biner dari suatu transaksi, dua node tidak menerima log biner, dan dua node mengalami kegagalan.

• Jika node yang gagal menerima log biner, setidaknya satu node yang menerima log biner tetap berfungsi dengan baik.

• Jika node yang gagal tidak menerima log biner, tiga node yang menerima log biner tetap berfungsi dengan baik.

Konsistensi data kuat

Dalam mode MGR, transaksi dikirimkan ke node lain dalam kluster RDS dan kemudian ditulis ke file log biner untuk memastikan konsistensi data. Jika node primer asli mengalami kegagalan dan di-restart, node tersebut secara otomatis ditambahkan kembali ke kluster RDS dan log biner yang hilang disinkronkan secara otomatis ke node yang direstart untuk mendapatkan data terbaru.

Dalam replikasi primer-sekunder tradisional, jika node primer mengalami kegagalan setelah transaksi ditulis ke file log biner tetapi sebelum transaksi dikirimkan ke node sekunder, ketidakkonsistenan data dapat terjadi.

Konsistensi transaksi global

MGR mendukung konsistensi transaksi global yang kuat untuk operasi baca dan tulis. Anda dapat mengonfigurasi parameter group_replication_consistency guna menyesuaikan tingkat konsistensi.

• Konsistensi Baca Kuat Gunakan pengaturan group_replication_consistency=BEFORE pada node sekunder. Pengaturan ini memungkinkan kueri dieksekusi hanya setelah semua transaksi sebelum kueri diselesaikan pada node primer, memastikan konsistensi data.

• Konsistensi Tulis Kuat Gunakan pengaturan group_replication_consistency=AFTER pada node primer. Pengaturan ini memungkinkan transaksi tulis dikomit hanya setelah berhasil diterapkan pada semua node.

Protokol Paxos

Berikut adalah daftar yang menjelaskan fungsionalitas protokol Paxos dalam mode MGR:

• Memastikan bahwa semua node dalam kluster menerima log biner dari transaksi dalam urutan yang sama, yang sangat penting untuk mode pemimpin ganda.

• Memastikan bahwa transaksi hanya dapat dikomit setelah sebagian besar node dalam kluster menerima log biner transaksi, sehingga meningkatkan keandalan data.

Dalam protokol Paxos, kunci digunakan untuk mencapai konsistensi pada urutan pengiriman data antar node. Namun, metode ini kurang efisien dan dapat menyebabkan beban yang tidak seimbang di antara node. Lapisan XCom MySQL menggunakan protokol Mencius, yaitu varian dari protokol berbasis Paxos. Protokol Mencius mengimplementasikan mekanisme polling untuk melakukan load balancing serta meningkatkan efisiensi.

Implementasi mode pemimpin ganda

• Urutan Data: Data dikirim secara serial dalam setiap grup untuk memastikan konsistensi urutan pengiriman data dalam grup. Ketika data dikirim dari beberapa grup Paxos, mekanisme polling digunakan untuk memastikan konsistensi urutan pengiriman data. Sebagai contoh, data dikirim dalam urutan (1,1), (1,2), dan (1,3).

• Mekanisme Noop: Jika data dari node yang terdaftar setelah node diterima oleh sebagian besar node dalam kluster dan tidak ada data pada node yang perlu dikirim, node menyiarkan status noop untuk melewati node itu sendiri. Node dapat mengirim data hanya setelah node yang terdaftar sebelum node mengirim datanya atau menyiarkan status noop.

• Cacat: Ketika jitter atau kegagalan terdeteksi pada node, node tidak dapat mengirim data atau menyiarkan status noop. Dalam kasus ini, node yang terdaftar setelah node tidak dapat mengirim data, dan kluster menjadi tidak tersedia. Ini adalah cacat kritis dari mode pemimpin ganda.

Implementasi mode pemimpin tunggal

Cacat mode pemimpin ganda dapat dioptimalkan, namun tidak dapat dihilangkan sepenuhnya. Oleh karena itu, MySQL menyediakan mode pemimpin tunggal untuk MGR (MySQL Group Replication) guna mencegah kluster menjadi tidak tersedia jika sebagian kecil node dalam kluster mengalami kegagalan.

Gambar sebelumnya mengilustrasikan arsitektur XCom dalam mode pemimpin tunggal, di mana hanya satu node yang dapat memproses permintaan tulis. Dengan demikian, Anda hanya perlu mengaktifkan satu grup Paxos. Penerima secara otomatis akan mengabaikan grup Paxos lainnya saat data dipolling. Dengan pendekatan ini, protokol Paxos dapat digunakan untuk mengirim data tanpa memengaruhi ketersediaan kluster, selama sebagian besar node dalam kluster tetap tersedia.

Dalam mode pemimpin tunggal, node sekunder di kluster tidak mengirimkan transaksi, melainkan informasi terkait manajemen kluster. Sebelum mengirimkan data, node sekunder harus meminta lokasi pengiriman data dari node primer, kemudian mengirimkan data tersebut ke semua node dalam kluster. Sebagai contoh, <3,1> pada gambar sebelumnya menunjukkan lokasi untuk pengiriman data. Meskipun pengiriman data memiliki latensi tinggi dan efisiensi rendah dalam mode ini, performa kluster tetap tidak terpengaruh karena informasi manajemen kluster dikirim dengan frekuensi yang relatif rendah.

Lapisan logika replikasi grup

Lapisan logika replikasi grup mengirim dan menerima transaksi ke dan dari kluster, serta memainkan kembali transaksi tersebut. Berikut ini adalah penjelasan cara kerja lapisan logika replikasi grup pada node primer dan sekunder:

• Node Primer: Sebelum transaksi dikomit pada node primer, lapisan logika replikasi grup mengirim log biner dari transaksi ke lapisan XCom dan kemudian ke node lain dalam kluster. Setelah sebagian besar node dalam kluster menerima transaksi, deteksi konflik dilakukan.

  • Jika transaksi lolos deteksi konflik, transaksi ditulis ke file log biner dan dikomit pada node primer.

  • Jika transaksi gagal deteksi konflik, transaksi dibatalkan.

• Node Sekunder: Setelah sebagian besar node dalam kluster menerima transaksi, lapisan XCom mengirim transaksi ke lapisan logika replikasi grup untuk melakukan deteksi konflik.

  • Jika transaksi lolos deteksi konflik, transaksi ditulis ke file log relay dan kemudian diterapkan oleh thread applier.

  • Jika transaksi gagal deteksi konflik, data dari transaksi dibuang.

Deteksi konflik

• Skenario

  Skenario: Dalam mode MGR, deteksi konflik harus dilakukan dalam skenario berikut:

  • Mode Pemimpin Ganda: Deteksi konflik diperlukan untuk semua operasi tulis.

  • Mode Pemimpin Tunggal: Jika pergantian primer/sekunder dilakukan dan transaksi tulis dieksekusi sebelum log relay dari node primer asli diterapkan pada node primer baru, deteksi konflik diperlukan.

• Implementasi

  Dalam mode MGR, deteksi konflik tingkat baris dilakukan berdasarkan nilai hash dari kunci utama baris data. Setiap node memelihara array informasi autentikasi transaksi, yaitu array hash, yang terdiri dari elemen-elemen berikut:

  • Kunci: Nilai hash dari baris data.

  • Nilai: Gabungan dari pengenal transaksi global (GTID) dari transaksi saat ini yang memodifikasi baris data dan gtid_executed yang diperoleh sebelum transaksi saat ini dikomit pada node sumber. gtid_executed menentukan set GTID dari semua transaksi yang telah dikomit pada node sumber.

  Sebelum transaksi dikomit, perhatikan hal-hal berikut:

  • Node sumber mengirim data yang dimodifikasi oleh transaksi dan set komitmen yang berisi transaksi yang dikomit sebelum transaksi saat ini dikomit.

  • Semua node dalam kluster menggunakan nilai hash dari semua baris data yang dimodifikasi oleh transaksi saat ini untuk membaca nilai yang diperlukan dari array informasi autentikasi, dan memasukkan nilai-nilai ini ke dalam set dependensi. Set dependensi menunjukkan transaksi yang harus diselesaikan sebelum transaksi saat ini dikomit.

  Sebelum transaksi saat ini dikomit atau ditulis ke log relay, sistem membandingkan set komitmen dan set dependensi dari aspek-aspek berikut:

  • Jika set komitmen berisi set dependensi, transaksi saat ini lolos deteksi konflik. Dalam hal ini, sistem menulis transaksi saat ini ke file log biner dan mengkomit transaksi pada node sumber, dan menulis transaksi saat ini ke file log relay pada node lain.

  • Jika set komitmen tidak berisi set dependensi, transaksi saat ini gagal dalam deteksi konflik. Dalam kasus ini, sistem melakukan rollback transaksi saat ini pada node sumber dan membuang relay log pada node lainnya.

  Mekanisme Penghapusan:

  Mekanisme Penghapusan: Untuk mengurangi penggunaan memori, data redundan dalam array informasi autentikasi dihapus secara berkala.

  • Ketika transaksi dieksekusi pada semua node dalam kluster, semua baris data yang dimodifikasi oleh transaksi dapat dihapus dari array informasi autentikasi.

  • Dalam mode MGR, data dari transaksi yang dieksekusi dihapus setiap 60 detik.