Mari kita bincangkan tentang penyelesaian untuk kelewatan tuan-hamba MySQL

Artikel ini membawakan anda pengetahuan yang berkaitan tentang penyelesaian pemprosesan kelewatan master-slave dalam MySQL master-slave replication dan read-write separation adalah seni bina pangkalan data yang biasa di Internet di mana jumlah data adalah besar dan jumlah konkurensi adalah besar, kelewatan tuan-hamba akan menjadi serius. Semoga ia membantu semua orang.

Mengapa kelewatan tuan-hamba begitu besar?

Jawapan: MySQL menggunakan replay RelayLog satu benang.

Bagaimana untuk mengoptimumkan dan memendekkan masa main semula?

Jawapan: Main semula selari berbilang benang bagi RelayLog boleh memendekkan masa.

Apakah masalah dengan ulangan selari berbilang benang bagi RelayLog?

Jawapan: Anda perlu mempertimbangkan cara membahagikan RelayLog supaya berbilang kejadian pangkalan data dan berbilang benang boleh memainkan semula RelayLog secara selari tanpa ketidakkonsistenan.

Mengapa terdapat ketidakkonsistenan?

Jawapan: Jika RelayLog diperuntukkan secara rawak kepada urutan ulang tayang yang berbeza, anggap bahawa terdapat tiga rekod pengubahsuaian bersiri dalam RelayLog:

kemas kini wang set akaun=100 di mana uid=58;

kemas kini set akaun wang=150 di mana uid=58;

kemas kini set akaun wang=200 di mana uid=58;

jika utas tunggal Main semula: Ia boleh memastikan bahawa urutan pelaksanaan semua perpustakaan hamba dan perpustakaan induk adalah konsisten.

Suara Suara: Akhirnya, wang akan menjadi 200.

Jika berbilang rangkaian ditugaskan secara rawak untuk dimainkan semula: berbilang utas ulangan melaksanakan ketiga-tiga penyataan ini secara serentak, adalah tidak pasti siapa yang melaksanakannya terakhir dan data pangkalan data hamba akhir mungkin berbeza daripada pangkalan data utama.

Suara Suara: Berbilang perpustakaan hamba mungkin mempunyai wang sebanyak 100, 150, 200, tidak pasti.

Bagaimana untuk memperuntukkan, memainkan semula berbilang hamba dan benang serta mendapatkan data yang konsisten?

Jawapan: Untuk operasi tulis pada pustaka yang sama, gunakan utas yang sama untuk memainkan semula RelayLog untuk operasi tulis pada pustaka yang berbeza, beberapa utas boleh digunakan untuk memainkan semula RelayLog secara serentak.

Bagaimana untuk melakukannya?

Jawapan: Reka bentuk algoritma hash, hash(db-name) % thread-num, cincang nama perpustakaan dan kemudian memodulasi bilangan utas, anda boleh melakukannya dengan mudah, sama Operasi tulis pada pustaka dilaksanakan secara bersiri oleh benang ulang tayang yang sama.

Suara Suara: Main semula pada pustaka berbeza adalah selari, yang mempercepatkan main balik.

Apakah kekurangan rancangan ini?

Jawapan: Banyak syarikat menggunakan "pangkalan data tunggal dengan berbilang jadual" untuk MySQL Jika ini berlaku, masih terdapat hanya satu pangkalan data dan kelajuan main semula RelayLog tidak boleh dipertingkatkan.

Pencerahan: Naik taraf model seni bina DB "pangkalan data tunggal dan berbilang jadual" kepada model seni bina DB "berbilang pangkalan data dan berbilang jadual".

Suara Suara: Dalam senario perniagaan Internet dengan jumlah data yang besar dan konkurensi yang besar, model "berbilang pangkalan data" juga mempunyai banyak kelebihan lain, seperti:

(1) Pengembangan contoh yang sangat mudah : DBA sangat Mudah untuk memanjangkan perpustakaan yang berbeza kepada keadaan yang berbeza;

(2) Mengasingkan perpustakaan mengikut perniagaan: penyahgandingan perniagaan, pengasingan perniagaan, mengurangkan gandingan dan pengaruh bersama

(3 ) Sangat mudah untuk memisahkan perkhidmatan mikro: adalah mudah bagi setiap perkhidmatan untuk mempunyai contoh sendiri; main semula RelayLog dioptimumkan?

Jawapan: Walaupun hanya terdapat satu pangkalan data, urus niaga dilaksanakan serentak pada pangkalan data utama Memandangkan ia boleh dilaksanakan secara selari pada pangkalan data utama, ia juga sepatutnya boleh dilaksanakan secara selari pada pangkalan data hamba? Idea baharu: Bahagikan urus niaga yang dilaksanakan secara selari pada pangkalan data utama ke dalam kumpulan dan nomborkannya Main semula transaksi ini pada pangkalan data hamba boleh dilaksanakan secara selari (pelaksanaan urus niaga pada pangkalan data utama. semua memasuki fasa penyediaan, menunjukkan bahawa tidak ada konflik antara transaksi, jika tidak, mustahil untuk diserahkan), ya, MySQL melakukan ini dengan tepat.

Penyelesaian: replikasi selari berasaskan GTID.

Bermula dari MySQL 5.7, maklumat yang dihantar oleh kumpulan disimpan dalam GTID Menggunakan alat mysqlbinlog, anda boleh melihat maklumat yang diserahkan oleh kumpulan:

.

20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=1
20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=2
20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=3
20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=4

Berbanding dengan log asal, terdapat lebih banyak last_committed dan sequence_number.

Apa yang last_commited?

Jawapan: Ia adalah nombor transaksi terakhir yang diserahkan apabila transaksi diserahkan Jika mereka mempunyai komitmen terakhir yang sama, ini bermakna mereka berada dalam kumpulan dan boleh dimainkan semula dan dilaksanakan secara serentak. . Ringkasan

Replikasi selari MySQL, kaedah memendekkan kelewatan penyegerakan tuan-hamba, merangkumi beberapa idea seni bina berikut:

Berbilang benang ialah cara biasa untuk memendekkan kaedah masa pelaksanaan;

Suara Suara: Contohnya, banyak crontab boleh menggunakan berbilang benang untuk memisahkan data dan melaksanakan secara selari.

Apabila multi-thread menghantar tugasan secara serentak, idempoten mesti dipastikan: MySQL menyediakan dua kaedah: "idempoten mengikut perpustakaan" dan "idempoten mengikut commit_id", yang bernilai

; Voiceover : Sebagai contoh, mesej kumpulan boleh menjadi idempoten mengikut group_id mesej pengguna boleh menjadi idempoten mengikut user_id.

Khusus untuk kelewatan penyegerakan master-slave MySQL:

mysql5.5: Replikasi selari tidak disokong, semua orang harus meningkatkan versi MySQL

mysql5.6: Selari replikasi mengikut perpustakaan , adalah disyorkan untuk menggunakan seni bina "multi-library";

mysql5.7: replikasi selari mengikut GTID;

Atas ialah kandungan terperinci Mari kita bincangkan tentang penyelesaian untuk kelewatan tuan-hamba MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!