Berbagi teknologi

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Ekosistem sumber terbuka

Seperti yang kita ketahui bersama, database primer dan sekunder MySQL (dua node) umumnya mencapai ketersediaan data yang tinggi melalui replikasi asinkron dan replikasi semi-sinkron (Semi-Sync). arsitektur primer dan sekunder akan menghadapi masalah serius setelah peralihan HA. Akan ada kemungkinan ketidakkonsistenan data (disebut RPO!=0).Oleh karena itu, selama data bisnis sangat penting, Anda sebaiknya tidak memilih produk database dengan arsitektur primer dan sekunder MySQL (dua node). Disarankan untuk memilih arsitektur multi-salinan dengan RPO=0.

Komunitas MySQL, mengenai evolusi teknologi multi-copy dengan RPO=0:

• MySQL secara resmi bersifat open source dan telah meluncurkan solusi ketersediaan tinggi MySQL Group Replication (MGR) berdasarkan replikasi grup. Protokol Paxos dienkapsulasi secara internal melalui XCOM untuk memastikan konsistensi data.
• Ali Awan PolarDB-X , yang berasal dari pemolesan bisnis dan verifikasi e-commerce Double Eleven Alibaba dan multi-aktivitas di berbagai tempat, ini akan menjadi open source di seluruh inti pada bulan Oktober 2021, sepenuhnya merangkul ekosistem open source MySQL. PolarDB-X diposisikan sebagai database terintegrasi terpusat dan terdistribusi. Node datanya, Data Node (DN), mengadopsi protokol X-Paxos yang dikembangkan sendiri dan sangat kompatibel dengan MySQL 5.7/8.0. Ini tidak hanya menyediakan kemampuan ketersediaan tinggi tingkat finansial , tetapi juga Ini memiliki karakteristik mesin transaksi yang sangat skalabel, operasi yang fleksibel dan pemulihan bencana pemeliharaan, dan penyimpanan data berbiaya rendah.Sumber Terbuka PolarDB-X |. Tiga salinan MySQL berdasarkan Paxos》。

PolarDB-X Konsep integrasi terpusat dan terdistribusi: node data DN dapat digunakan secara independen sebagai bentuk terpusat (versi standar), yang sepenuhnya kompatibel dengan bentuk database yang berdiri sendiri. Ketika bisnis tumbuh ke titik di mana perluasan terdistribusi diperlukan, arsitektur ditingkatkan ke bentuk terdistribusi, dan komponen terdistribusi terhubung dengan mulus ke node data asli. Tidak perlu migrasi atau modifikasi data di sisi aplikasi , dan Anda dapat menikmati distribusinya Kegunaan dan skalabilitas yang dibawa oleh rumus ini, deskripsi arsitektur:"Integrasi Terdistribusi Terpusat"

MGR MySQL dan DN versi standar PolarDB-X keduanya menggunakan protokol Paxos dari prinsip terendah. Jadi apa performa spesifik dan perbedaannya dalam penggunaan sebenarnya? Artikel ini menguraikan aspek perbandingan arsitektur, perbedaan utama, dan perbandingan pengujian.

Deskripsi singkatan MGR/DN: MGR mewakili bentuk teknis MySQL MGR, dan DN mewakili bentuk teknis PolarDB-X DN tunggal terpusat (versi standar).

Singkatnya;

Analisis komparatif secara detailnya relatif panjang, sehingga Anda bisa membaca ringkasan dan kesimpulannya terlebih dahulu. Jika tertarik, Anda bisa mengikuti ringkasannya dan mencari petunjuknya di artikel selanjutnya.

MySQL MGR tidak direkomendasikan untuk bisnis umum dan perusahaan karena memerlukan pengetahuan teknis profesional serta tim operasi dan pemeliharaan untuk menggunakannya dengan baik. Artikel ini juga mereproduksi tiga "perangkap tersembunyi" MySQL MGR yang telah lama beredar di industri :

• Dark Pit 1: Protokol MySQL MGR dan XCOM mengadopsi mode memori penuh. Defaultnya adalah tidak memenuhi jaminan konsistensi data RPO=0 (akan ada masalah data yang hilang dalam kasus uji nanti di artikel ini). menampilkan dan mengkonfigurasi parameter untuk memastikannya. Saat ini Desain MGR tidak dapat mencapai kinerja dan RPO.
• Kesalahan 2: Kinerja MySQL MGR buruk ketika ada penundaan jaringan. Artikel ini menguji perbandingan skenario jaringan 4 menit (termasuk tiga ruang komputer di kota yang sama dan tiga pusat di dua tempat). parameter kinerja kota, hanya 1/5 dari kota yang sama, jika jaminan data RPO=0 diaktifkan, kinerjanya akan lebih buruk.Oleh karena itu, MySQL MGR lebih cocok untuk digunakan dalam skenario ruang komputer yang sama, tetapi tidak cocok untuk pemulihan bencana lintas ruang komputer.
• Kesalahan 3: Dalam arsitektur multi-salinan MySQL MGR, kegagalan node siaga akan menyebabkan lalu lintas node master Leader turun ke 0, yang tidak sesuai dengan akal sehat. Artikel ini berfokus pada upaya mengaktifkan mode pemimpin tunggal MGR (dibandingkan dengan arsitektur replika master-slave MySQL sebelumnya), mensimulasikan dua tindakan downtime dan pemulihan replika budak. Operasi dan operasi pemeliharaan node budak juga akan menyebabkan master node (Pemimpin) muncul. Lalu lintas turun ke 0 (berlangsung sekitar 10 detik), dan pengoperasian dan pemeliharaan secara keseluruhan relatif buruk.Oleh karena itu, MySQL MGR memiliki persyaratan yang relatif tinggi pada pengoperasian dan pemeliharaan host serta memerlukan tim DBA profesional.

Dibandingkan dengan MySQL MGR, PolarDB-X Paxos tidak memiliki kekurangan yang mirip dengan MGR dalam hal konsistensi data, pemulihan bencana lintas ruang komputer, serta pengoperasian dan pemeliharaan node. Namun, PolarDB-X juga memiliki beberapa kekurangan dan kelebihan kecil dalam pemulihan bencana:

• Dalam skenario sederhana di ruang komputer yang sama, kinerja baca-saja dalam konkurensi rendah dan kinerja tulis murni dalam konkurensi tinggi sedikit lebih rendah dibandingkan MySQL MGR sekitar 5%. masih ada ruang untuk optimalisasi kinerja lebih lanjut.
• Keuntungan: 100% kompatibel dengan fitur MySQL 5.7/8.0. Pada saat yang sama, optimasi yang lebih efisien telah dilakukan dalam replikasi database siaga multi-salinan dan jalur failover Skenario pemulihan bencana -menit di industri. Semua berkinerja baik dan dapat menggantikan semi-sinkronisasi (semi-sinkronisasi), MGR, dll.

1. Perbandingan arsitektur

Glosarium

Deskripsi singkatan MGR/DN:

1. MGR: Bentuk teknis dari MySQL MGR, singkatan dari konten selanjutnya: MGR
2. DN: Alibaba Cloud PolarDB-X adalah bentuk teknis terpusat (versi standar). Node data terdistribusi DN dapat digunakan secara independen sebagai bentuk terpusat (versi standar). Ini sepenuhnya kompatibel dengan database yang berdiri sendiri sebagai: DN

MGR

MGR mendukung mode master tunggal dan multi-master, dan sepenuhnya menggunakan kembali sistem replikasi MySQL, termasuk Event, Binlog & Relaylog, Apply, Binlog Apply Recovery, dan GTID. Perbedaan utama dari DN adalah bahwa titik masuk mayoritas log transaksi MGR untuk mencapai konsensus adalah sebelum transaksi database utama dilakukan.

• Pemimpin:

1. 1. Sebelum transaksi dilakukan, fungsi hook before_commit group_replication_trans_before_commit dipanggil untuk memasukkan replikasi mayoritas MGR.
   2. MGR menggunakan protokol Paxos untuk menyinkronkan Acara Binlog yang di-cache di THD ke semua node online
   3. Setelah mendapat tanggapan mayoritas, MGR memutuskan bahwa transaksi dapat diajukan
   4. THD memasuki proses pengiriman grup transaksi dan mulai menulis pembaruan Binlog lokal Ulangi pesan OK klien balasan

• Pengikut:

1. 1. Mesin Paxos MGR terus mendengarkan pesan protokol dari Pemimpin
   2. Setelah proses konsensus Paxos selesai, dipastikan bahwa (batch) Acara ini telah mencapai mayoritas di cluster
   3. Tulis Peristiwa yang diterima ke Log Relai, IO Thread Terapkan Log Relai
   4. Aplikasi Relay Log melewati proses pengiriman grup yang lengkap, dan database siaga pada akhirnya akan menghasilkan file binlognya sendiri.

Alasan mengapa MGR mengadopsi proses di atas adalah karena MGR berada dalam mode multi-master secara default, dan setiap node dapat menulis. Oleh karena itu, node pengikut dalam satu Grup Paxos perlu mengubah log yang diterima menjadi RelayLog terlebih dahulu, lalu menggabungkannya. dengan transaksi tulis yang diterima sebagai pemimpin untuk diserahkan. , file Binlog diproduksi untuk mengirimkan transaksi terakhir dalam proses pengiriman grup dua tahap.

Tanggal

DN menggunakan kembali struktur data dasar dan kode tingkat fungsi MySQL, tetapi mengintegrasikan replikasi log, manajemen log, pemutaran log, dan pemulihan kerusakan dengan protokol X-Paxos untuk membentuk rangkaian replikasi mayoritas dan mekanisme mesin statusnya sendiri. Perbedaan utama dari MGR adalah bahwa titik masuk mayoritas log transaksi DN untuk mencapai konsensus adalah selama proses penyerahan transaksi database utama.

• Pemimpin:

1. 1. Masuk ke proses pengiriman grup transaksi. Dalam fase Flush pengiriman grup, Peristiwa di setiap THD ditulis ke dalam file Binlog, dan kemudian log disiarkan secara asinkron ke semua Pengikut melalui X-Paxos.
   2. Dalam fase Sinkronisasi pengiriman grup, Binlog disimpan terlebih dahulu, lalu lokasi persistensi X-Paxos diperbarui.
   3. Pada fase Komit pengiriman grup, Anda harus menunggu terlebih dahulu hingga X-Paxos menerima respons mayoritas, kemudian mengirimkan grup transaksi, dan terakhir membalas dengan pesan OK dari klien.

• Pengikut:

1. 1. X-Paxos terus mendengarkan pesan protokol dari Leader
   2. Terima Acara (grup), tulis ke Binlog lokal, dan tanggapi
   3. Pesan berikutnya diterima, yang membawa indeks Komit dari posisi dimana mayoritas telah tercapai.
   4. Thread SQL Apply terus menerapkan log Binlog yang diterima di latar belakang, dan paling banyak hanya menerapkannya pada posisi mayoritas.

Alasan desain ini adalah DN saat ini hanya mendukung mode master tunggal, sehingga log pada tingkat protokol X-Paxos adalah Binlog itu sendiri. Follower juga menghilangkan Log Relai, dan konten data log persistennya serta log pemimpin sama dengan harga yang sama.

2. Perbedaan utama

2.1. Efisiensi protokol Paxos

MGR

• Protokol Paxos MGR diimplementasikan berdasarkan protokol Mencius yang termasuk dalam teori Multi-Paxos. Bedanya, Mencius telah melakukan perbaikan optimasi dalam mengurangi beban node master dan meningkatkan throughput.
• Protokol Paxos MGR diimplementasikan oleh komponen XCOM dan mendukung penerapan mode multi-master dan master tunggal. Dalam mode master tunggal, Binlog pada Leader menyiarkan secara atom ke node Follower proses Multi-Paxos standar.
• Untuk memenuhi sebagian besar transaksi, XCOM perlu melalui setidaknya tiga interaksi pesan Accept+AckAccept+Learn, yaitu,Setidaknya 1,5 RTT overhead.Ini memerlukan paling banyak tiga interaksi pesan: Prepare+AckPrepare+Accept+AckAccept+Learn.Artinya, total overhead maksimum adalah 2,5 RTT
• Karena protokol Paxos dilengkapi dengan kohesi tinggi dalam modul XCOM dan tidak mengetahui sistem replikasi MySQL, Pemimpin harus menunggu hingga proses Paxos selesai sebelum melakukan transaksi secara lokal, termasuk persistensi Binlog dan pengiriman grup.
• Setelah Pengikut menyelesaikan sebagian besar pengiriman, Peristiwa tersebut akan disimpan secara asinkron ke Log Relai, lalu aplikasi dan grup SQL Thread akan mengirimkan Binlog produksi.
• Karena log yang disinkronkan oleh Paxos adalah Binlog yang tidak diurutkan sebelum memasuki proses pengiriman grup, maka urutan Acara Binlog di Leader mungkin tidak sama dengan urutan Acara di Log Relay di node Follower.

Tanggal

• Protokol Paxos DN diimplementasikan berdasarkan protokol Raft dan juga termasuk dalam teori Multi-Paoxs. Perbedaannya adalah protokol Raft memiliki jaminan kepemimpinan dan jaminan stabilitas teknik yang lebih kuat.
• Protokol Paxos DN diselesaikan oleh komponen X-Paoxs. Defaultnya adalah mode master tunggal. Dalam mode master tunggal, Binlog pada Leader disiarkan secara atom ke node Follower. Siaran setiap batch pesan adalah proses Raft standar .
• Untuk memenuhi sebagian besar transaksi, X-Paoxs hanya perlu melalui dua interaksi pesan Append+AckAppend, dan hanya1 RTT di atas kepala
• Setelah Leader mengirimkan log ke Follower, selama mayoritas puas, maka Leader akan melakukan transaksi tanpa menunggu siaran Commit Index di tahap kedua.
• Sebelum Follower dapat menyelesaikan pengiriman mayoritas, semua log transaksi harus disimpan. Hal ini sangat berbeda dengan MGR's XCOM yang hanya perlu menerimanya di memori XCOM.
• Indeks Komit dibawa dalam pesan berikutnya dan pesan detak jantung, dan Pengikut melakukan Acara Terapkan setelah Indeks Komit didorong ke atas.
• Isi Binlog Leader dan Follower berada dalam urutan yang sama, log Raft tidak memiliki lubang, dan mekanisme Batching/Pipeline digunakan untuk meningkatkan throughput replikasi log.
• Dibandingkan dengan MGR, Leader selalu hanya mengalami satu kali penundaan bolak-balik saat transaksi dilakukan., sangat penting untuk aplikasi terdistribusi yang sensitif terhadap penundaan

2.2. RPO

Secara teori, baik Paxos maupun Raft dapat memastikan konsistensi data dan log yang telah mencapai mayoritas setelah Crash Recovery tidak akan hilang, namun masih terdapat perbedaan dalam proyek tertentu.

MGR

XCOM sepenuhnya merangkum protokol Paxos, dan semua data protokolnya di-cache di memori terlebih dahulu. Secara default, transaksi yang mencapai mayoritas tidak memerlukan persistensi log. Jika sebagian besar pie gagal dan Pemimpin gagal, akan terjadi masalah serius yaitu RPO != 0.Asumsikan skenario ekstrem:

1. Cluster MGR terdiri dari tiga node ABC, dimana AB adalah ruang komputer independen di kota yang sama dan C adalah node lintas kota. A adalah Pemimpin, BC adalah simpul Pengikut
2. Memulai transaksi 001 pada node Leader A. Leader A menyiarkan log transaksi 001 ke node BC. Jika mayoritas dipenuhi melalui protokol Paxos, transaksi dapat dianggap terkirim. Bagian AB merupakan mayoritas, dan node C tidak menerima log transaksi 001 karena penundaan jaringan lintas kota.
3. Saat berikutnya, Pemimpin A mengirimkan transaksi 001 dan mengembalikan kesuksesan Klien, yang berarti transaksi 001 telah dikirimkan ke database.
4. Saat ini pada Follower node B, log transaksi 001 masih berada di cache XCOM dan belum sempat di-flush ke RelayLog saat ini Follower node C masih belum menerima transaksi 001 log dari pemimpin node A.
5. Pada saat ini, node AB sedang down, node A gagal dan tidak dapat dipulihkan untuk waktu yang lama, node B restart dan pulih dengan cepat, dan node BC terus menyediakan layanan baca dan tulis.
6. Karena log transaksi 001 tidak disimpan ke RelayLog node B selama waktu henti, juga tidak diterima oleh node C, maka pada saat ini, node BC sebenarnya telah kehilangan transaksi 001 dan tidak dapat mengambilnya kembali.
7. Dalam skenario di mana partai mayoritas kalah, RPO!=0

Berdasarkan parameter default komunitas, sebagian besar transaksi tidak memerlukan persistensi log dan tidak menjamin RPO=0. Hal ini dapat dianggap sebagai trade-off untuk kinerja dalam implementasi proyek XCOM. Untuk memastikan RPO=0 absolut, Anda perlu mengonfigurasi parameter group_replication_consistency yang mengontrol konsistensi baca dan tulis ke SETELAH. Namun, dalam kasus ini, selain overhead jaringan 1,5 RTT, transaksi akan memerlukan overhead log IO untuk mencapai mayoritas, dan kinerjanya akan sangat buruk.

Tanggal

PolarDB-X DN menggunakan X-Paxos untuk mengimplementasikan protokol terdistribusi dan sangat terikat dengan proses Komitmen Grup MySQL. Saat transaksi dikirimkan, mayoritas diharuskan untuk mengonfirmasi penempatan dan persistensi sebelum pengiriman sebenarnya diizinkan. Sebagian besar penempatan disk di sini mengacu pada penempatan Binlog dari perpustakaan utama. Thread IO dari perpustakaan siaga menerima log dari perpustakaan utama dan menulisnya ke Binlognya sendiri untuk persistensi. Oleh karena itu, meskipun semua node gagal dalam skenario ekstrem, data tidak akan hilang dan RPO=0 dapat dijamin.

2.3. RTO

Waktu RTO terkait erat dengan waktu overhead dari cold restart sistem itu sendiri, yang tercermin dalam fungsi dasar spesifik:Mekanisme deteksi kesalahan->mekanisme pemulihan kerusakan->mekanisme pemilihan master->penimbangan log

2.3.1

MGR

• Setiap node secara berkala mengirimkan paket detak jantung ke node lain untuk memeriksa apakah node lain dalam keadaan sehat. Periode detak jantung ditetapkan pada 1 detik dan tidak dapat disesuaikan.
• Jika node saat ini menemukan bahwa node lain tidak merespons setelah group_replication_member_expel_timeout (default 5 detik), maka node tersebut akan dianggap sebagai node gagal dan akan dikeluarkan dari cluster.
• Untuk pengecualian seperti gangguan jaringan atau restart yang tidak normal, setelah jaringan dipulihkan, satu node yang gagal akan mencoba bergabung secara otomatis dengan cluster dan kemudian mengikat log.

Tanggal

• Node Leader secara berkala mengirimkan paket detak jantung ke node lain untuk memeriksa apakah node lain dalam keadaan sehat. Periode detak jantung adalah 1/5 dari batas waktu pemilihan. Batas waktu pemilihan dikontrol oleh parameter konsensus_pemilihan_timeout. Defaultnya adalah 5 detik, sehingga periode detak jantung node pemimpin defaultnya adalah 1 detik.
• Jika Pemimpin menemukan bahwa node lain sedang offline, ia akan terus mengirimkan paket detak jantung secara berkala ke semua node lainnya untuk memastikan bahwa node lain dapat mengakses tepat waktu setelah node tersebut mengalami kerusakan dan pulih.Namun, node Leader tidak lagi mengirimkan log transaksi ke node offline.
• Node non-pemimpin tidak mengirimkan paket deteksi detak jantung, tetapi jika node non-pemimpin menemukan bahwa ia belum menerima detak jantung dari node pemimpin setelah konsensus_election_timeout, pemilihan ulang akan dipicu.
• Untuk pengecualian seperti gangguan jaringan atau restart yang tidak normal, setelah jaringan dipulihkan, node yang salah akan secara otomatis bergabung dengan cluster.
• Oleh karena itu, dalam hal deteksi kesalahan, DN menyediakan lebih banyak antarmuka konfigurasi operasi dan pemeliharaan, dan identifikasi kesalahan dalam skenario penerapan lintas kota akan lebih akurat.

2.3.2. Pemulihan kerusakan

MGR

• • Protokol Paxos yang diterapkan oleh XCOM berada dalam status memori. Pencapaian mayoritas tidak memerlukan persistensi.Jika semua node terhenti, protokol tidak dapat dipulihkan. Setelah cluster dimulai ulang, diperlukan intervensi manual untuk memulihkannya.
  • Jika hanya satu node yang crash dan dipulihkan, namun node Follower tertinggal di belakang node Leader dengan lebih banyak log transaksi, dan log transaksi cache XCOM pada Leader telah dihapus, satu-satunya pilihan adalah menggunakan proses Pemulihan Global atau Klon.
  • Ukuran cache XCOM dikontrol oleh group_replication_message_cache_size, defaultnya adalah 1GB
  • Pemulihan Global berarti bahwa ketika sebuah node bergabung kembali dengan cluster, ia memulihkan data dengan memperoleh log transaksi yang hilang (Binary Log) yang diperlukan dari node lain.Proses ini bergantung pada setidaknya satu node di cluster yang menyimpan semua log transaksi yang diperlukan
  • Clone mengandalkan Clone Plugin, yang digunakan untuk pemulihan ketika jumlah data besar atau banyak log yang hilang.Ia bekerja dengan menyalin snapshot dari seluruh database ke node yang rusak, diikuti dengan sinkronisasi akhir dengan log transaksi terbaru
  • Proses Pemulihan Global dan Klon biasanya dilakukan secara otomatis, tetapi dalam beberapa kasus khusus, seperti masalah jaringan atau cache XCOM dari dua node lainnya telah dihapus, diperlukan intervensi manual.

Tanggal

• • Protokol X-Paxos menggunakan persistensi Binlog. Saat memulihkan dari kerusakan, transaksi yang dikirimkan akan dipulihkan sepenuhnya terlebih dahulu. Untuk transaksi yang tertunda, Anda perlu menunggu lapisan protokol XPaxos mencapai kesepakatan untuk menentukan hubungan master-cadangan sebelum melakukan atau mengembalikan transaksi. Seluruh proses sepenuhnya otomatis.Bahkan jika semua node mati, cluster dapat pulih secara otomatis setelah dimulai ulang.
  • Untuk skenario di mana node Follower tertinggal dari node Leader di banyak log transaksi, selama file Binlog di Leader tidak dihapus, node Follower pasti akan menyusul.
  • Oleh karena itu, dalam hal pemulihan kerusakan, DN tidak memerlukan intervensi manual sama sekali.

2.3.3. Memilih pemimpin

Dalam mode master tunggal, XCOM MGR dan DN X-Paxos, mode pemimpin yang kuat, mengikuti prinsip dasar yang sama untuk memilih pemimpin - log yang telah disepakati oleh cluster tidak dapat dibatalkan. Namun jika menyangkut log yang tidak disepakati, terdapat perbedaan

MGR

• Pemilihan Leader lebih pada node mana yang akan dijadikan sebagai layanan Leader selanjutnya.Pemimpin ini belum tentu memiliki log konsensus terbaru saat terpilih, sehingga perlu menyinkronkan log terbaru dari node lain di cluster, dan menyediakan layanan baca dan tulis setelah log diikat.
• Keuntungannya adalah pilihan Leader itu sendiri merupakan produk yang strategis, seperti bobot dan ketertiban. MGR mengontrol bobot setiap node melalui parameter group_replication_member_weight
• Kerugiannya adalah Pemimpin yang baru terpilih itu sendiri mungkin mengalami penundaan replikasi yang besar dan perlu terus mengejar log, atau mungkin mengalami penundaan aplikasi yang besar dan perlu terus mengejar aplikasi log sebelum dapat menyediakan pembacaan dan menulis layanan.Hal ini menghasilkan waktu RTO yang lebih lama

Tanggal

• Pemilihan pemimpin dalam pengertian protokol. Node mana pun yang memiliki log dari semua partai mayoritas di cluster dapat dipilih sebagai pemimpin, jadi node ini mungkin pernah menjadi pengikut atau logger sebelumnya.
• Logger tidak dapat menyediakan layanan membaca dan menulis. Setelah menyinkronkan log ke node lain, Logger akan secara aktif melepaskan peran Leader.
• Untuk memastikan bahwa node yang ditunjuk menjadi pemimpin, DN menggunakan strategi bobot optimis + strategi bobot wajib untuk membatasi urutan menjadi pemimpin, dan menggunakan mekanisme mayoritas strategis untuk memastikan bahwa master baru dapat segera menyediakan baca dan tulis layanan tanpa penundaan.
• Oleh karena itu, dalam hal pemilihan pemimpin, DN tidak hanya mendukung pemilihan strategis yang sama dengan MGR, tetapi juga mendukung strategi bobot wajib.

2.3.4

Pemerataan log berarti ada penundaan replikasi log dalam log antara database primer dan sekunder, dan database sekunder perlu menyamakan log. Untuk node yang dimulai ulang dan dipulihkan, pemulihan biasanya dimulai dengan database siaga, dan penundaan replikasi log telah terjadi dibandingkan dengan database utama, dan log harus diambil dengan database utama. Untuk node yang secara fisik jauh dari Pemimpin, mencapai mayoritas biasanya tidak ada hubungannya dengan node tersebut selalu mengalami penundaan log replikasi dan selalu mengejar log. Situasi ini memerlukan penerapan teknik khusus untuk memastikan penyelesaian penundaan replikasi log secara tepat waktu.

MGR

• Semua log transaksi ada di cache XCOM, dan cache hanya 1G secara default. Oleh karena itu, ketika node pengikut yang jauh tertinggal dalam mereplikasi log permintaan, cache akan mudah dibersihkan.
• Pada saat ini, Follower yang tertinggal akan secara otomatis dikeluarkan dari cluster, dan kemudian menggunakan proses Pemulihan Global atau Klon yang disebutkan di atas untuk pemulihan kerusakan, dan kemudian secara otomatis bergabung dengan cluster setelah mengejar.Jika Anda menemuiMisalnya, masalah jaringan, atau cache XCOM dari dua node lainnya dihapus, dalam hal ini intervensi manual diperlukan untuk menyelesaikan masalah tersebut.
• Mengapa kita harus mengeluarkan cluster terlebih dahulu? Karena node yang salah dalam mode multi-tulis sangat mempengaruhi kinerja, dan cache Leader tidak berpengaruh padanya. Ini harus ditambahkan setelah pengikatan asinkron.
• Mengapa kita tidak bisa langsung membaca file Binlog lokal Leader? Karena protokol XCOM yang disebutkan tadi ada dalam memori penuh, dan tidak ada informasi protokol tentang XCOM di Binlog dan Relay Log.

Tanggal

• Semua data ada di file Binlog. Selama Binlog tidak dibersihkan, maka dapat dikirim sesuai permintaan dan tidak ada kemungkinan dikeluarkan dari cluster.
• Untuk mengurangi jitter IO yang disebabkan oleh perpustakaan utama membaca log transaksi lama dari file Binlog, DN memberikan prioritas untuk membaca log transaksi cache terbaru dari FIFO Cache. Cache FIFO dikontrol oleh parameter konsensus_log_cache_size, dan default adalah 64M
• Jika log transaksi lama di FIFO Cache telah dihilangkan dengan log transaksi yang diperbarui, DN akan mencoba membaca log transaksi yang di-cache sebelumnya dari Prefetch Cache. Prefetch Cache dikontrol oleh parameter konsensus_prefetch_cache_size, dan defaultnya adalah 64M.
• Jika tidak ada log transaksi lama yang diperlukan di Prefetch Cache, DN akan mencoba memulai tugas IO asinkron, membaca beberapa log berturut-turut sebelum dan sesudah log transaksi yang ditentukan dari file Binlog secara batch, menempatkannya di Prefetch Cache, dan menunggu untuk pembacaan ulang DN berikutnya Pilih
• Oleh karena itu, DN tidak memerlukan intervensi manual sama sekali saat menyeimbangkan log.

2.4. Penundaan pemutaran basis data siaga

Penundaan pemutaran basis data siaga adalah penundaan antara waktu penyelesaian transaksi yang sama di basis data utama dan waktu penerapan transaksi di basis data siaga. Yang diuji di sini adalah kinerja log aplikasi Terapkan basis data siaga. Hal ini mempengaruhi berapa lama waktu yang dibutuhkan database siaga untuk menyelesaikan aplikasi datanya dan menyediakan layanan baca dan tulis ketika terjadi pengecualian.

MGR

• Basis data siaga MGR menerima file RelayLog dari basis data utama. Saat menerapkan aplikasi, ia perlu membaca RelayLog lagi, melalui proses pengiriman grup dua tahap yang lengkap, dan menghasilkan data dan file Binlog yang sesuai.
• Efisiensi aplikasi transaksi di sini sama dengan efisiensi pengiriman transaksi pada database utama. Konfigurasi double-one default (innodb_flush_log_at_trx_commit, sync_binlog) akan menyebabkan overhead sumber daya yang sama dari aplikasi database siaga menjadi besar.

Tanggal

• Basis data cadangan DN menerima file Binlog dari basis data utama. Saat mendaftar, Binlog perlu dibaca kembali. Hanya perlu melalui proses pengiriman grup satu tahap dan menghasilkan data yang sesuai.
• Karena DN mendukung Crash Recover lengkap, aplikasi database siaga tidak perlu mengaktifkan innodb_flush_log_at_trx_commit=1, sehingga tidak terpengaruh oleh konfigurasi double-one.
• Oleh karena itu, dalam hal penundaan pemutaran basis data siaga, efisiensi pemutaran basis data siaga DN akan jauh lebih besar daripada MGR.

2.5 Dampak peristiwa besar

Transaksi besar tidak hanya mempengaruhi penyerahan transaksi biasa, tetapi juga mempengaruhi stabilitas seluruh protokol terdistribusi dalam sistem terdistribusi. Dalam kasus yang parah, transaksi besar akan menyebabkan seluruh cluster tidak tersedia untuk waktu yang lama.

MGR

• MGR tidak memiliki optimasi apa pun untuk mendukung transaksi besar, hanya menambahkan parameter group_replication_transaction_size_limit untuk mengontrol batas atas transaksi besar.
• Ketika log transaksi melebihi batas besar transaksi, kesalahan akan langsung dilaporkan dan transaksi tidak dapat dikirimkan.

Tanggal

• Untuk mengatasi masalah ketidakstabilan sistem terdistribusi yang disebabkan oleh transaksi besar, DN mengadopsi solusi pemisahan transaksi besar + pemisahan objek besar untuk menyelesaikan masalah tersebut. DN akan membagi log transaksi dari transaksi besar secara logis + untuk log transaksi blok kecil, setiap blok kecil log transaksi menggunakan jaminan komitmen Paxos penuh
• Berdasarkan solusi pemisahan transaksi besar, DN tidak memberlakukan batasan apa pun pada ukuran transaksi besar. Pengguna dapat menggunakannya sesuka hati dan juga dapat memastikan RPO=0.
• Untuk instruksi rinci, lihat"Teknologi Inti Mesin Penyimpanan PolarDB-X | Optimasi Transaksi Besar"
• Oleh karena itu, DN dapat menangani urusan berskala besar tanpa terpengaruh oleh urusan berskala besar.

2.6.Formulir penempatan

MGR

• MGR mendukung mode penyebaran master tunggal dan multi-master, dalam mode multi-master, setiap node dapat dibaca dan ditulis. Dalam mode master tunggal, database utama dapat dibaca dan ditulis, dan database siaga hanya dapat dibaca. hanya.
• Penyebaran ketersediaan tinggi MGR memerlukan setidaknya tiga penyebaran node, yaitu, setidaknya tiga salinan data dan log. Mode Logger tidak didukung.
• MGR tidak mendukung perluasan node read-only, namun mendukung kombinasi mode replikasi MGR + master-slave untuk mencapai perluasan topologi serupa.

Tanggal

• DN mendukung penerapan mode master tunggal. Dalam mode master tunggal, database utama dapat dibaca dan ditulis, dan database siaga hanya dapat dibaca saja.
• Penyebaran ketersediaan tinggi DN memerlukan setidaknya tiga node, tetapi mendukung salinan log bentuk Logger, yaitu, Pemimpin dan Pengikut adalah salinan berfitur lengkap Dibandingkan dengan Logger, ia hanya memiliki log dan tidak ada data, dan tidak memiliki hak untuk menjadi terpilih. Dalam hal ini, penerapan ketersediaan tinggi tiga node hanya memerlukan overhead penyimpanan sebesar 2 salinan data + 3 salinan log, sehingga penerapannya berbiaya rendah.
• DN mendukung penerapan node baca-saja dan salinan formulir Pelajar hanya-baca. Dibandingkan dengan salinan berfitur lengkap, DN tidak memiliki hak suara. Melalui salinan Pelajar, konsumsi langganan hilir ke perpustakaan utama diwujudkan.

2.7. Ringkasan fitur

3. Uji perbandingan

MGR diperkenalkan di MySQL 5.7.17, tetapi lebih banyak fitur terkait MGR hanya tersedia di MySQL 8.0, dan di MySQL 8.0.22 dan versi yang lebih baru, kinerja keseluruhan akan lebih stabil dan dapat diandalkan. Oleh karena itu, kami memilih versi terbaru 8.0.32 dari kedua belah pihak untuk pengujian perbandingan.

Mengingat terdapat perbedaan dalam lingkungan pengujian, metode kompilasi, metode penerapan, parameter operasi, dan metode pengujian selama pengujian komparatif PolarDB-X DN dan MySQL MGR, yang dapat menyebabkan data perbandingan pengujian tidak akurat, artikel ini akan fokus pada berbagai detail . Lanjutkan sebagai berikut:

Catatan:

• MGR memiliki kontrol aliran yang diaktifkan secara default, sedangkan PolarDB-X DN memiliki kontrol aliran yang dinonaktifkan secara default.Oleh karena itu, group_replication_flow_control_mode MGR dikonfigurasi secara terpisah sehingga kinerja MGR menjadi yang terbaik.
• MGR memiliki hambatan pembacaan yang jelas selama pencacahan, sehingga replication_optimize_for_static_plugin_config MGR dikonfigurasi dan diaktifkan secara terpisah, sehingga kinerja read-only MGR akan menjadi yang terbaik.

3.1

Pengujian kinerja adalah hal pertama yang diperhatikan semua orang saat memilih database. Di sini kami menggunakan alat sysbench resmi untuk membuat 16 tabel, masing-masing berisi 10 juta data, untuk melakukan pengujian kinerja dalam skenario OLTP, dan menguji serta membandingkan kinerja keduanya dalam kondisi konkurensi berbeda dalam skenario OLTP berbeda.Dengan mempertimbangkan berbagai situasi penerapan sebenarnya, kami menyimulasikan empat skenario penerapan berikut:

1. Tiga node dikerahkan di ruang komputer yang sama. Ada penundaan jaringan sebesar 0,1 ms saat mesin saling melakukan ping.
2. Tiga pusat di kota yang sama dan tiga ruang komputer di wilayah yang sama menyebarkan tiga node. Ada penundaan jaringan 1 ms dalam ping antar ruang komputer (misalnya: tiga ruang komputer di Shanghai)
3. Tiga pusat di dua tempat, tiga node ditempatkan di tiga ruang komputer di dua tempat, ping jaringan 1 ms antar ruang komputer di kota yang sama, penundaan jaringan 30 ms antara kota yang sama dan tempat lain (misalnya: Shanghai/Shanghai/Shenzhen)
4. Tiga pusat di tiga tempat, tiga node dikerahkan di tiga ruang komputer di tiga tempat (misalnya: Shanghai/Hangzhou/Shenzhen), penundaan jaringan antara Hangzhou dan Shanghai sekitar 5 ms, dan jarak terjauh dari Hangzhou/Shanghai ke Shenzhen adalah 30 ms .

menjelaskan:

a. Pertimbangkan perbandingan horizontal kinerja empat skenario penerapan. Tiga pusat di dua tempat dan tiga pusat di tiga tempat semuanya mengadopsi mode penerapan 3 salinan.

b. Mengingat pembatasan ketat pada RPO=0 saat menggunakan produk database ketersediaan tinggi, MGR dikonfigurasi dengan RPO<>0 secara default. Di sini, kami akan terus menambahkan pengujian perbandingan antara MGR RPO<>0 dan RPO=0 di masing-masing produk skenario penerapan.

• MGR_0 mewakili data untuk kasus MGR RPO = 0
• MGR_1 mewakili data untuk kasus MGR RPO <> 0
• DN mewakili data untuk kasus DN RPO = 0

3.1.1. Ruang komputer yang sama

Hal ini terlihat dari hasil pengujian:

• Dalam skenario read-only, baik membandingkan MGR_1 (RPO<>0) atau MGR_0 (RPO=0), perbedaan antara DN dan MGR stabil antara -5% dan 10%, yang pada dasarnya dapat dianggap sama. Apakah RPO sama dengan 0 tidak berpengaruh pada transaksi read-only
• Dalam skenario transaksi campuran baca-tulis dan tulis saja, kinerja DN (RPO=0) meningkat sebesar 5% hingga 47% dibandingkan dengan MGR_1 (RPO<>0), dan keunggulan kinerja DN terlihat jelas ketika konkurensinya rendah, dan keuntungannya bila konkurensinya tinggi. Fitur yang tidak jelas. Hal ini karena efisiensi protokol DN lebih tinggi ketika konkurensi rendah, namun hotspot kinerja DN dan MGR dalam konkurensi tinggi semuanya dalam pembersihan.
• Dengan premis yang sama yaitu RPO=0, dalam skenario transaksi campuran baca-tulis dan tulis saja, kinerja DN meningkat 2 kali lipat menjadi 46 kali lipat dibandingkan dengan MGR_0, dan seiring dengan peningkatan konkurensi, keunggulan kinerja DN meningkat. Tidak heran MGR juga mengabaikan RPO=0 untuk kinerja secara default.

3.1.2. Tiga pusat di kota yang sama

Hal ini terlihat dari hasil pengujian:

• Dalam skenario read-only, baik membandingkan MGR_1 (RPO<>0) atau MGR_0 (RPO=0), perbedaan antara DN dan MGR stabil antara -7% dan 5%, yang pada dasarnya dapat dianggap sama. Apakah RPO sama dengan 0 tidak berpengaruh pada transaksi read-only
• Dalam skenario transaksi campuran baca-tulis dan tulis-saja, kinerja DN (RPO=0) meningkat sebesar 30% hingga 120% dibandingkan dengan MGR_1 (RPO<>0), dan keunggulan kinerja DN terlihat jelas ketika konkurensi rendah, dan ketika konkurensi tinggi, kinerjanya lebih baik. Fitur yang tidak jelas. Hal ini karena efisiensi protokol DN lebih tinggi ketika konkurensi rendah, namun hotspot kinerja DN dan MGR dalam konkurensi tinggi semuanya dalam keadaan bersih.
• Dengan premis yang sama yaitu RPO=0, dalam skenario transaksi campuran baca-tulis dan tulis saja, kinerja DN meningkat 1 hingga 14 kali lipat dibandingkan dengan MGR_0, dan seiring dengan peningkatan konkurensi, keunggulan kinerja DN meningkat. Tidak heran MGR juga mengabaikan RPO=0 untuk kinerja secara default.

3.1.3. Dua tempat dan tiga pusat

Hal ini terlihat dari hasil pengujian:

• Dalam skenario read-only, baik membandingkan MGR_1 (RPO<>0) atau MGR_0 (RPO=0), perbedaan antara DN dan MGR stabil antara -4% dan 7%, yang pada dasarnya dapat dianggap sama. Apakah RPO sama dengan 0 tidak berpengaruh pada transaksi read-only
• Dalam skenario transaksi campuran baca-tulis dan tulis-saja, kinerja DN (RPO=0) meningkat 2 kali lipat menjadi 16 kali lipat dibandingkan dengan MGR_1 (RPO<>0), dan keunggulan kinerja DN terlihat jelas ketika konkurensi rendah, dan keuntungan ketika konkurensi tinggi. Fitur yang tidak jelas. Hal ini karena efisiensi protokol DN lebih tinggi ketika konkurensi rendah, namun hotspot kinerja DN dan MGR dalam konkurensi tinggi semuanya dalam pembersihan.
• Dengan premis yang sama yaitu RPO=0, dalam skenario transaksi campuran baca-tulis dan tulis saja, kinerja DN meningkat 8 kali hingga 29 kali dibandingkan dengan MGR_0, dan seiring dengan peningkatan konkurensi, keunggulan kinerja DN meningkat. Tidak heran MGR juga mengabaikan RPO=0 untuk kinerja secara default.

3.1.4. Tiga tempat dan tiga pusat

Hal ini terlihat dari hasil pengujian:

• Dalam skenario read-only, baik membandingkan MGR_1 (RPO<>0) atau MGR_0 (RPO=0), perbedaan antara DN dan MGR stabil antara -5% dan 0%, yang pada dasarnya dapat dianggap sama. Apakah RPO sama dengan 0 tidak berpengaruh pada transaksi read-only
• Dalam skenario transaksi campuran baca-tulis dan tulis-saja, kinerja DN (RPO=0) meningkat 2 kali hingga 5 kali lipat dibandingkan dengan MGR_1 (RPO<>0), dan keunggulan kinerja DN terlihat jelas ketika konkurensi rendah, dan keuntungan ketika konkurensi tinggi. Fitur yang tidak jelas. Hal ini karena efisiensi protokol DN lebih tinggi ketika konkurensi rendah, namun hotspot kinerja DN dan MGR dalam konkurensi tinggi semuanya dalam pembersihan.
• Dengan premis yang sama yaitu RPO=0, dalam skenario transaksi campuran baca-tulis dan tulis saja, kinerja DN meningkat 2 kali lipat hingga 17 kali lipat dibandingkan dengan MGR_0, dan seiring dengan peningkatan konkurensi, keunggulan kinerja DN meningkat. Tidak heran MGR juga mengabaikan RPO=0 untuk kinerja secara default.

3.1.5. Perbandingan penerapan

Untuk membandingkan dengan jelas perubahan kinerja dalam metode penerapan yang berbeda, kami memilih data TPS MGR dan DN dalam metode penerapan yang berbeda berdasarkan konkurensi skenario oltp_write_only 256 dalam pengujian di atas membandingkan data TPS dari metode penerapan yang berbeda. Rasio dibandingkan dengan data dasar untuk mengetahui perbedaan perubahan kinerja selama penerapan lintas kota

Hal ini terlihat dari hasil pengujian:

• Dengan perluasan metode penerapan, TPS MGR_1 (RPO<>0) turun secara signifikan. Dibandingkan dengan penerapan di ruang komputer yang sama, kinerja penerapan lintas ruang komputer di kota yang sama turun sebesar 27,5%. penyebaran lintas kota (tiga pusat di dua tempat, tiga pusat di tiga tempat) Penurunan sebesar 77%~82%, hal ini disebabkan oleh peningkatan penyebaran RT lintas kota.
• DN (RTO=0) relatif stabil. Dibandingkan dengan penerapan di ruang komputer yang sama, kinerja penerapan ruang komputer lintas-komputer di kota yang sama dan penerapan tiga pusat di dua tempat turun sebesar 4% menjadi 12%. . Kinerja penerapan tiga pusat di tiga tempat turun sebesar 37% karena latensi jaringan yang tinggi. Hal ini juga disebabkan oleh peningkatan penerapan RT di seluruh kota.Namun, berkat mekanisme Batch&Pipeline DN, dampak lintas kota dapat diatasi dengan meningkatkan konkurensi, misalnya, dalam arsitektur tiga tempat dan tiga pusat, dengan konkurensi >=512, throughput kinerja di kota yang sama dan dua. tempat dan tiga pusat pada dasarnya dapat disejajarkan.
• Terlihat penyebaran lintas kota berdampak besar terhadap MGR_1 (RPO<>0)

3.1.6. Kegelisahan Kinerja

Dalam penggunaan sebenarnya, kita tidak hanya memperhatikan data performa saja, tetapi juga perlu memperhatikan jitter performa. Lagi pula, jika jitternya seperti roller coaster, pengalaman pengguna sebenarnya akan sangat buruk. Kami memantau dan menampilkan data keluaran TPS secara real-time. Mengingat alat sysbenc itu sendiri tidak mendukung data pemantauan keluaran jitter kinerja, kami menggunakan koefisien variasi matematis sebagai indikator perbandingan:

• Koefisien Variasi (CV): Koefisien variasi adalah simpangan baku dibagi rata-rata. Koefisien ini biasanya digunakan untuk membandingkan fluktuasi kumpulan data yang berbeda, terutama jika perbedaan rata-ratanya besar. Semakin besar CV, semakin besar pula fluktuasi data relatif terhadap mean.

Mengambil 256 skenario oltp_read_write secara bersamaan sebagai contoh, kami menganalisis secara statistik TPS MGR_1 (RPO<>0) dan DN (RPO=0) di ruang komputer yang sama, tiga pusat di kota yang sama, tiga pusat di dua tempat, dan tiga pusat di tiga tempat. Grafik jitter sebenarnya adalah sebagai berikut, dan data indikator jitter sebenarnya untuk setiap skenario adalah sebagai berikut:

Hal ini terlihat dari hasil pengujian:

• TPS MGR berada dalam keadaan tidak stabil dalam skenario oltp_read_write, dan tiba-tiba turun tajam tanpa alasan. Fenomena ini ditemukan dalam beberapa pengujian di beberapa skenario penerapan. Sebagai perbandingan, DN sangat stabil.
• Menghitung koefisien variasi CV, CV MGR sangat besar, 6% hingga 10%, bahkan mencapai nilai maksimum 10% ketika penundaan di ruang komputer yang sama minimal, sedangkan CV DN relatif stabil, 2% hingga 4 %, dan kinerja DN lebih stabil daripada MGR. Seks pada dasarnya dua kali lebih tinggi
• Terlihat bahwa jitter kinerja MGR_1 (RPO<>0) relatif besar

3.2. Informasi RTO

Fitur inti dari database terdistribusi adalah ketersediaan tinggi. Kegagalan node mana pun di cluster tidak akan mempengaruhi ketersediaan secara keseluruhan. Untuk bentuk penerapan tipikal 3 node dengan satu master dan dua cadangan yang diterapkan di ruang komputer yang sama, kami mencoba melakukan uji kegunaan dalam tiga skenario berikut:

• Interupsi database utama, lalu mulai ulang, dan amati waktu RTO bagi klaster untuk memulihkan ketersediaan selama proses.
• Interupsi database siaga apa pun lalu mulai ulang untuk mengamati kinerja ketersediaan database utama selama proses.

3.2.1. Waktu henti basis data utama + mulai ulang

Ketika tidak ada beban, matikan pemimpin dan pantau perubahan status setiap node di cluster dan apakah node tersebut dapat ditulis.

Dari hasil pengujian terlihat bahwa pada kondisi tanpa tekanan :

• RTO DN adalah 8-15 detik, dibutuhkan 8 detik untuk mengurangi menjadi 2 node, dan 15 detik untuk memulihkan 3 node;
• RTO MGR adalah 23-37 detik. Dibutuhkan 23 detik untuk menurunkan versi menjadi 2 node dan 37 detik untuk memulihkan 3 node.
• Kinerja RTO DN secara keseluruhan lebih baik daripada MGR

3.2.2. Waktu henti basis data siaga + mulai ulang

Gunakan sysbench untuk melakukan stress test secara bersamaan terhadap 16 thread dalam skenario oltp_read_write. Pada detik ke-10 pada gambar, matikan node siaga secara manual dan amati data TPS output real-time dari sysbench.

Dapat dilihat dari grafik hasil pengujian:

• Setelah database siaga terganggu, TPS database utama MGR turun secara signifikan, dan itu berlangsung sekitar 20 detik sebelum kembali ke level normal. Menurut analisis log, ada dua proses di sini: mendeteksi bahwa node yang salah menjadi tidak dapat dijangkau dan mengeluarkan node yang salah dari cluster MGR. Tes ini mengkonfirmasi kelemahan yang telah lama beredar di komunitas MGR. Meskipun hanya 1 node di antara 3 node yang tidak tersedia.Seluruh cluster mengalami kegelisahan yang parah selama jangka waktu tertentu dan menjadi tidak tersedia.
• Untuk mengatasi masalah MGR master tunggal yang mengalami kegagalan node tunggal dan seluruh instans tidak tersedia, komunitas memperkenalkan fungsi pemimpin tunggal MGR paxos dari 8.0.27 untuk menyelesaikan masalah, tetapi fungsi tersebut dinonaktifkan secara default. Di sini kita mengaktifkan group_replication_paxos_single_leader dan melanjutkan verifikasi. Setelah mengganggu database siaga kali ini, kinerja database utama tetap stabil dan sedikit meningkat.
• Untuk DN, setelah database siaga terganggu, TPS database utama segera meningkat sekitar 20%, lalu tetap stabil, dan cluster selalu tersedia.Ini kebalikan dari MGR. Alasannya adalah setelah mengganggu database siaga, database utama hanya perlu mengirim log ke database siaga yang tersisa setiap kali, dan proses pengiriman dan penerimaan paket jaringan menjadi lebih efisien.

Melanjutkan pengujian, kami memulai ulang dan memulihkan database siaga dan mengamati perubahan pada data TPS dari database utama.

Dapat dilihat dari grafik hasil pengujian:

• MGR pulih dari 2 node menjadi 3 node dalam 5 detik.Namun ada juga situasi dimana perpustakaan utama tidak tersedia, yang berlangsung sekitar 12 detik.Meskipun node standby akhirnya bergabung dengan cluster, status MEMBER_STATE selalu RECOVERING, menandakan bahwa data sedang dikejar saat ini.
• Dalam skenario setelah group_replication_paxos_single_leader diaktifkan, restart database siaga juga diverifikasi. Hasilnya, MGR pulih dari 2 node menjadi 3 node dalam 10 detik.Namun masih ada waktu tidak tersedia yang berlangsung sekitar 7 detik.Tampaknya parameter ini tidak dapat sepenuhnya menyelesaikan masalah MGR master tunggal yang mengalami kegagalan node tunggal dan seluruh instance tidak tersedia.
• Untuk DN, database siaga pulih dari 2 node menjadi 3 node dalam 10 detik, dan database utama tetap tersedia. Akan ada fluktuasi jangka pendek pada TPS di sini. Hal ini karena penundaan replikasi log dari database siaga yang dimulai ulang lebih lambat, dan log yang tertinggal perlu ditarik dari database utama database utama. Setelah peninjauan log, kinerja keseluruhan akan stabil.

3.3. RPO

Untuk membangun skenario RPO<>0 kegagalan mayoritas MGR, kami menggunakan metode Kasus MTR milik komunitas untuk melakukan pengujian injeksi kesalahan pada MGR. Kasus yang dirancang adalah sebagai berikut:

--echo
--echo ############################################################
--echo # 1. Deploy a 3 members group in single primary mode.
--source include/have_debug.inc
--source include/have_group_replication_plugin.inc
--let $group_replication_group_name= aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
--let $rpl_group_replication_single_primary_mode=1
--let $rpl_skip_group_replication_start= 1
--let $rpl_server_count= 3
--source include/group_replication.inc
 
--let $rpl_connection_name= server1
--source include/rpl_connection.inc
--let $server1_uuid= `SELECT @@server_uuid`
--source include/start_and_bootstrap_group_replication.inc
 
--let $rpl_connection_name= server2
--source include/rpl_connection.inc
--source include/start_group_replication.inc
 
--let $rpl_connection_name= server3
--source include/rpl_connection.inc
--source include/start_group_replication.inc
 
--echo
--echo ############################################################
--echo # 2. Init data
--let $rpl_connection_name = server1
--source include/rpl_connection.inc
CREATE TABLE t1 (c1 INT PRIMARY KEY);
INSERT INTO t1 VALUES(1);
 
--source include/rpl_sync.inc
SELECT * FROM t1;
 
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SELECT * FROM t1;
 
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SELECT * FROM t1;
 
--echo
--echo ############################################################
--echo # 3. Mock crash majority members
 
--echo # server 2 wait before write relay log
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
 
--echo # server 3 wait before write relay log
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
 
 
--echo # server 1 commit new transaction
--let $rpl_connection_name = server1
--source include/rpl_connection.inc
INSERT INTO t1 VALUES(2);
# server 1 commit t1(c1=2) record
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 1 crash
--source include/kill_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo 
--echo # server 3 check
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 3 crash and restart
--source include/kill_and_restart_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo 
--echo # server 2 check
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 2 crash and restart
--source include/kill_and_restart_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo
--echo ############################################################
--echo # 4. Check alive members, lost t1(c1=2) record
 
--echo # server 3 check
--let $rpl_connection_name= server3
--source include/rpl_connection.inc
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 3 lost t1(c1=2) record
SELECT * FROM t1;
 
--echo 
--echo # server 2 check
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 2 lost t1(c1=2) record
SELECT * FROM t1;

!include ../my.cnf
 
[mysqld.1]
loose-group_replication_member_weight=100
 
[mysqld.2]
loose-group_replication_member_weight=90
 
[mysqld.3]
loose-group_replication_member_weight=80
 
[ENV]
SERVER_MYPORT_3=		@mysqld.3.port
SERVER_MYSOCK_3=		@mysqld.3.socket

Hasil kasus yang berjalan adalah sebagai berikut:

 
############################################################
# 1. Deploy a 3 members group in single primary mode.
include/group_replication.inc [rpl_server_count=3]
Warnings:
Note	####	Sending passwords in plain text without SSL/TLS is extremely insecure.
Note	####	Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
[connection server1]
[connection server1]
include/start_and_bootstrap_group_replication.inc
[connection server2]
include/start_group_replication.inc
[connection server3]
include/start_group_replication.inc
 
############################################################
# 2. Init data
[connection server1]
CREATE TABLE t1 (c1 INT PRIMARY KEY);
INSERT INTO t1 VALUES(1);
include/rpl_sync.inc
SELECT * FROM t1;
c1
1
[connection server2]
SELECT * FROM t1;
c1
1
[connection server3]
SELECT * FROM t1;
c1
1
 
############################################################
# 3. Mock crash majority members
# server 2 wait before write relay log
[connection server2]
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
# server 3 wait before write relay log
[connection server3]
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
# server 1 commit new transaction
[connection server1]
INSERT INTO t1 VALUES(2);
SELECT * FROM t1;
c1
1
2
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13000	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13002	ONLINE	SECONDARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	ONLINE	SECONDARY	8.0.32	XCom
# server 1 crash
# Kill the server
# sleep enough time for electing new leader
 
# server 3 check
[connection server3]
SELECT * FROM t1;
c1
1
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13002	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	ONLINE	SECONDARY	8.0.32	XCom
# server 3 crash and restart
# Kill and restart
# sleep enough time for electing new leader
 
# server 2 check
[connection server2]
SELECT * FROM t1;
c1
1
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13002	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	UNREACHABLE	SECONDARY	8.0.32	XCom
# server 2 crash and restart
# Kill and restart
# sleep enough time for electing new leader
 
############################################################
# 4. Check alive members, lost t1(c1=2) record
# server 3 check
[connection server3]
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier		NULL	OFFLINE			
# server 3 lost t1(c1=2) record
SELECT * FROM t1;
c1
1
 
# server 2 check
[connection server2]
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier		NULL	OFFLINE			
# server 2 lost t1(c1=2) record
SELECT * FROM t1;
c1
1

Perkiraan logika kasus yang mereproduksi angka yang hilang adalah sebagai berikut:

1. MGR terdiri dari 3 node dalam mode single-master, Server 1/2/3, dimana Server 1 sebagai database utama dan menginisialisasi 1 record c1=1
2. Server injeksi kesalahan 2/3 akan hang saat menulis Relay Log
3. Terhubung ke node Server 1, menulis catatan c1=2, dan transaksi yang dilakukan juga mengembalikan kesuksesan.
4. Kemudian Mock server1 crash secara tidak normal (mesin rusak, tidak dapat dipulihkan, dan tidak dapat diakses). Saat ini, Server 2/3 dibiarkan menjadi mayoritas.
5. Mulai ulang Server 2/3 secara normal (pemulihan cepat), tetapi Server 2/3 tidak dapat memulihkan cluster ke kondisi yang dapat digunakan.
6. Hubungkan ke node Server 2/3 dan tanyakan catatan database. Hanya catatan c1=1 yang terlihat (Server 2/3 telah kehilangan c1=2)

Berdasarkan kasus di atas, untuk MGR, ketika sebagian besar server mati dan database utama tidak tersedia, setelah database siaga dipulihkan, akan ada kehilangan data sebesar RPO<>0, dan catatan komit yang berhasil adalah awalnya dikembalikan ke klien hilang.

Untuk DN, pencapaian mayoritas mengharuskan log tetap berada di mayoritas, sehingga bahkan dalam skenario di atas, data tidak akan hilang dan RPO=0 dapat dijamin.

3.4. Penundaan pemutaran basis data siaga

Dalam mode siaga aktif tradisional MySQL, basis data siaga umumnya berisi utas IO dan utas Terapkan. Setelah pengenalan protokol Paxos, utas IO menyinkronkan binlog dari basis data aktif dan siaga tergantung pada overhead Terapkan pemutaran database siaga, di sini kita menjadi penundaan pemutaran database siaga.

Kami menggunakan sysbench untuk menguji skenario oltp_write_only, dan menguji durasi penundaan dalam pemutaran database siaga di bawah 100 konkurensi dan jumlah kejadian yang berbeda.Waktu tunda pemutaran database siaga dapat ditentukan dengan memantau kolom APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP tabel performance_schema.replication_applier_status_by_worker untuk melihat apakah setiap pekerja bekerja secara real-time untuk menentukan apakah replikasi telah berakhir.
 

Dapat dilihat dari grafik hasil pengujian:

• Dengan jumlah data tertulis yang sama, waktu penyelesaian pemutaran semua log database siaga DN jauh lebih baik dibandingkan dengan konsumsi waktu MGR yang hanya 3% hingga 4% dari MGR. Hal ini penting untuk ketepatan waktu peralihan aktif/siaga.
• Seiring dengan meningkatnya jumlah penulisan, keunggulan latensi pemutaran basis data siaga DN dibandingkan MGR terus dipertahankan dan sangat stabil.
• Menganalisis alasan penundaan pemutaran database siaga, strategi pemutaran database siaga MGR mengadopsi group_replication_consistency dengan nilai default EVENTUAL, yaitu transaksi RO dan RW tidak menunggu penerapan transaksi sebelumnya sebelum dieksekusi. Hal ini dapat memastikan kinerja penulisan maksimum dari basis data utama, namun penundaan basis data siaga akan relatif besar (dengan mengorbankan penundaan basis data siaga dan RPO=0 sebagai imbalan atas penulisan kinerja tinggi dari basis data utama, mengaktifkan fungsi pembatas saat ini MGR dapat menyeimbangkan kinerja dan database siaga tertunda, namun kinerja database utama akan terganggu)

3.5.Ringkasan tes

4. Ringkasan

Setelah analisis teknis mendalam dan perbandingan kinerja,PolarDB-X Dengan protokol X-Paxos yang dikembangkan sendiri dan serangkaian desain yang dioptimalkan, DN telah menunjukkan banyak keunggulan dibandingkan MySQL MGR dalam hal kinerja, kebenaran, ketersediaan, dan overhead sumber daya. Namun, MGR juga menempati posisi penting dalam ekosistem MySQL , berbagai situasi seperti jitter pemadaman basis data siaga, fluktuasi kinerja pemulihan bencana ruang mesin lintas, dan stabilitas perlu dipertimbangkan. Oleh karena itu, jika Anda ingin memanfaatkan MGR dengan baik, Anda harus dilengkapi dengan tim teknis, operasi, dan pemeliharaan yang profesional mendukung.

Ketika dihadapkan dengan persyaratan skala besar, konkurensi tinggi, dan ketersediaan tinggi, mesin penyimpanan PolarDB-X memiliki keunggulan teknis yang unik dan kinerja yang sangat baik dibandingkan dengan MGR dalam skenario siap pakai.PolarDB-XTerpusat berbasis DN (versi standar) memiliki keseimbangan yang baik antara fungsi dan kinerja, menjadikannya solusi database yang sangat kompetitif.