Bagaimana mereka bentuk seni bina sistem storan MySQL Binlog

1. Pengenalan kepada kingbus

1.1 Apakah kingbus?

Kingbus ialah sistem penyimpanan binlog MySQL yang diedarkan berdasarkan protokol ketekalan kuat rakit. Ia boleh bertindak sebagai Hamba MySQL untuk menyegerakkan binlog daripada Master sebenar dan menyimpannya dalam kelompok yang diedarkan. Pada masa yang sama, ia juga bertindak sebagai Master MySQL untuk menyegerakkan binlog dalam kelompok kepada hamba lain. kingbus mempunyai ciri-ciri berikut:

Serasi dengan protokol replikasi MySQL, menyegerakkan binlog pada Master melalui Gtid dan menyokong hamba untuk menarik binlog dari kingbus melalui Gtid.

Replikasi data merentas wilayah, Kingbus menyokong replikasi data merentas wilayah melalui protokol rakit. Data binlog yang ditulis kepada kluster dijamin sangat konsisten merentas berbilang nod, dan susunan binlog benar-benar konsisten dengan yang ada pada induk.

Ketersediaan tinggi, kerana Kingbus dibina di atas protokol konsensus kukuh Raft, ia boleh mencapai ketersediaan tinggi bagi keseluruhan perkhidmatan tarik dan tolak binlog apabila lebih separuh daripada nod dalam kluster bertahan.

1.2 Apakah masalah yang boleh diselesaikan oleh kingbus?

Kingbus boleh mengurangkan trafik penghantaran rangkaian Master. Dalam topologi replikasi dengan satu tuan dan berbilang hamba, tuan perlu menghantar binlog kepada setiap hamba Jika terdapat terlalu banyak hamba, trafik rangkaian berkemungkinan mencapai had atas kad rangkaian tuan. Sebagai contoh, apabila induk melakukan operasi seperti memadam jadual besar atau DDL dalam talian, sejumlah besar peristiwa binlog boleh dijana serta-merta Jika 10 hamba disambungkan kepada induk, trafik kad rangkaian pada induk akan dikuatkan sebanyak 10 kali . Jika induk menggunakan kad rangkaian Gigabit, kad rangkaian mungkin penuh jika lebih daripada 10MB/S trafik dijana. Dengan menyambung kepada master melalui kingbus, hamba boleh diedarkan kepada berbilang mesin untuk mengimbangi trafik penghantaran.

Untuk memudahkan proses Master Failover, anda hanya perlu mempromosikan hamba yang disambungkan ke kingbus untuk dikuasai, dan ubah hala kingbus ke master baharu, hamba lain masih disambungkan ke kingbus, dan topologi replikasi kekal tidak berubah.

Simpan ruang yang digunakan oleh Master untuk menyimpan fail binlog. Secara amnya, MySQL menggunakan SSD yang lebih mahal Jika fail binlog mengambil banyak ruang, data yang disimpan dalam MySQL perlu dikurangkan. Anda boleh mengurangkan bilangan fail binlog yang disimpan pada Master dengan menyimpan semua binlog dalam kingbus

Menyokong replikasi heterogen. Sambung ke kingbus melalui saluran sumber terbuka Alibaba secara berterusan menolak binlog ke terusan menerima binlog dan kemudian menolaknya ke baris gilir mesej kafka, dan akhirnya menyimpannya dalam HBase analisis perniagaan.

2. Seni bina keseluruhan Kingbus

Struktur keseluruhan kingbus ditunjukkan dalam rajah di bawah:

Storan bertanggungjawab untuk menyimpan entri log rakit dan Metadata Dalam Kingbus, log rakit dan mysql binlog dibezakan oleh maklumat pengepala yang berbeza Bahagian data log rakit adalah peristiwa binlog daripada log secara berasingan , menjimatkan ruang simpanan. Kerana kingbus perlu menyimpan beberapa maklumat meta, seperti maklumat undian nod rakit dan kandungan khusus beberapa acara binlog khas (FORMAT_DESCRIPTION_EVENT).

Raft mereplikasi pemilihan utama, replikasi log dan fungsi lain kluster kingbus, menggunakan perpustakaan rakit etcd.

Penyegerak Binlog hanya berjalan pada nod utama gugusan Raft Hanya terdapat satu penyegerak dalam keseluruhan gugusan. Penyegerak berpura-pura menjadi hamba dan mewujudkan sambungan replikasi induk-hamba kepada Master Master akan menapis peristiwa binlog yang telah diterima oleh penyegerak berdasarkan set executed_gtid_set yang dihantar oleh penyegerak dan hanya menghantar peristiwa binlog yang tidak dimiliki oleh penyegerak. diterima Protokol replikasi ini serasi sepenuhnya dengan mekanisme replikasi tuan-hamba MySQL. Selepas penyegerak menerima acara binlog, ia akan melakukan beberapa pemprosesan mengikut jenis acara binlog, dan kemudian merangkum acara binlog ke dalam mesej dan menyerahkannya kepada kelompok rakit. Melalui algoritma rakit, acara binlog ini boleh disimpan pada berbilang nod dan mencapai konsistensi yang kukuh.

Pelayan Binlog ialah Master yang melaksanakan protokol replikasi Hamba sebenar boleh menyambung ke port yang dipantau oleh pelayan binlog Pelayan binlog akan menghantar acara binlog kepada hamba Protokol replikasi MySQL. Apabila tiada acara binlog dihantar kepada hamba, pelayan binlog akan menghantar peristiwa degupan jantung secara berkala kepada hamba untuk memastikan sambungan replikasi hidup.

Pelayan API bertanggungjawab untuk pengurusan keseluruhan kluster kingbus, termasuk yang berikut:

Operasi keahlian kluster rakit, lihat status kluster, tambah nod, keluarkan nod, kemas kini maklumat nod, dsb.

Operasi berkaitan penyegerak binlog: mulakan penyegerak binlog, hentikan penyegerak binlog dan semak status penyegerak binlog.

Operasi berkaitan pelayan Binlog, mulakan pelayan binlog, hentikan pelayan binlog, dan semak status pelayan binlog. Pelbagai kelainan pada lapisan pelayan tidak akan menjejaskan lapisan rakit Pelayan boleh difahami sebagai pemalam, yang boleh dimulakan dan dihentikan apabila diminta. Apabila melanjutkan Kingbus pada masa hadapan, anda hanya perlu melaksanakan pelayan dengan logik yang berkaitan. Contohnya, jika anda melaksanakan pelayan protokol kafka, anda boleh menggunakan mesej dalam kingbus melalui klien kafka.

3.pelaksanaan teras kingbus

3.1 Pelaksanaan teras storan

Terdapat dua bentuk log dalam simpanan, satu ialah log rakit (selepas ini dirujuk sebagai log rakit), yang dihasilkan dan digunakan oleh algoritma rakit, dan satu lagi ialah Log bentuk pengguna (iaitu, acara mysql binlog) . Dalam reka bentuk Storan, dua borang Log digabungkan menjadi satu Kemasukan Log. Ia hanya dibezakan oleh maklumat pengepala yang berbeza. Storan terdiri daripada fail data dan fail indeks, seperti yang ditunjukkan dalam rajah di bawah:

Segmen mempunyai saiz tetap (1GB) dan hanya boleh ditulis sebagai tambahan Namanya ialah indeks_rakit_rakit-akhir_rakit, yang menunjukkan julat indeks rakit bagi segmen.

Hanya segmen terakhir boleh ditulis dan nama failnya ialah first_raft_index-inprogress Segmen lain adalah baca sahaja.

Segmen baca sahaja dan fail indeks yang sepadan ditulis dan dibaca melalui mmap.

Kandungan indeks segmen terakhir disimpan dalam kedua-dua cakera dan memori. Membaca indeks hanya memerlukan bacaan dari ingatan.

3.2 Penggunaan perpustakaan rakit etcd

Pustaka rakit Etcd adalah satu benang apabila memproses log yang digunakan, entri komited, dsb. Sila rujuk pautan untuk fungsi tertentu Masa pemprosesan fungsi ini mestilah sesingkat mungkin Jika masa pemprosesan melebihi masa pemilihan rakit, kluster akan dipilih semula. Perkara ini memerlukan perhatian khusus.

3.3 Pelaksanaan teras penyegerak binlog

Tugas utama penyegerak binlog ialah:

Acara tarik binlog

Menghuraikan dan memproses acara binlog

Serahkan acara binlog kepada kelompok rakit. Jelas sekali, mekanisme saluran paip boleh digunakan untuk meningkatkan kelajuan pemprosesan keseluruhan proses Kingbus menggunakan goroutine yang berasingan untuk memproses setiap peringkat, dan menghubungkan peringkat yang berbeza melalui saluran paip. Memandangkan penyegerak binlog menerima peristiwa binlog satu demi satu, penyegerak tidak dapat menjamin integriti transaksi Ada kemungkinan bahawa selepas penyegerak digantung, induk perlu disambungkan semula pada masa ini, penyegerak Binlog mungkin tidak lengkap lengkap. Dengan keupayaan unik, kingbus melaksanakan fungsi analisis integriti transaksi, yang dilaksanakan sepenuhnya dengan merujuk kepada kod sumber MySQL.

3.4 Pelaksanaan teras pelayan binlog

Pelayan Binlog melaksanakan fungsi induk Apabila hamba mewujudkan sambungan replikasi dengan pelayan binlog, hamba akan menghantar arahan yang berkaitan, dan pelayan binlog perlu bertindak balas kepada arahan ini. Akhirnya hantar acara binlog kepada hamba. Untuk setiap hamba, pelayan binlog akan memulakan goroutine untuk membaca log rakit secara berterusan, mengalih keluar maklumat pengepala yang berkaitan, dan mengubahnya menjadi acara binlog, yang kemudiannya akan dihantar kepada hamba.

Atas ialah kandungan terperinci Bagaimana mereka bentuk seni bina sistem storan MySQL Binlog. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!