Kuasai sepenuhnya penyelesaian kepada kelewatan tuan-hamba MySQL

Artikel ini membawakan anda pengetahuan yang relevan tentang mysql, yang terutamanya mengatur isu-isu yang berkaitan dengan penyelesaian kelewatan tuan-hamba, termasuk apa itu kelewatan tuan-hamba, punca kelewatan tuan-hamba, Jom lihatlah penyelesaian kelewatan tuan-hamba dan seterusnya saya harap ia akan membantu semua orang.

Pembelajaran yang disyorkan: tutorial video mysql

Dalam projek sebelumnya, pemisahan baca-tulis telah dicapai berdasarkan replikasi master-slave MySQL dan AOP , juga menulis blog untuk merekodkan proses pelaksanaan ini. Memandangkan replikasi tuan-hamba MySQL dikonfigurasikan, secara semula jadi akan ada kelewatan tuan-hamba Bagaimana untuk meminimumkan kesan kelewatan tuan-hamba pada sistem aplikasi adalah titik pemikiran yang diperlukan untuk melaksanakan read Write pemisahan, intipati MySQL master-hamba replikasi.

Mengenai topik ini, saya sebenarnya terfikir untuk menulis blog untuk dikongsi sebelum ini, tetapi saya tidak pernah meletakkannya dalam agenda. Baru-baru ini, seorang pembaca meninggalkan mesej menanyakan soalan ini dalam "SpringBoot Implements MySQL Read-Write Separation", yang turut memberi inspirasi kepada saya untuk menulis artikel ini. Mengenai isu ini, saya banyak membaca maklumat dan blog, dan melalui latihan saya sendiri, saya ringkaskan blog ini dengan berdiri di bahu bos.

Apakah kelewatan tuan-hamba

Sebelum membincangkan cara menyelesaikan kelewatan tuan-hamba, mari kita fahami dahulu apa itu kelewatan tuan-hamba.

Untuk melengkapkan replikasi induk-hamba, perpustakaan hamba perlu mendapatkan kandungan binlog yang dibaca oleh utas dump dalam pustaka induk melalui utas I/O dan menulisnya ke dalam log gegantinya sendiri Benang SQL pustaka hamba kemudian Membaca log geganti dan membuat semula log dalam log geganti adalah sama dengan melaksanakan SQL sekali lagi dan mengemas kini pangkalan data anda sendiri untuk mencapai ketekalan data.

Titik masa yang berkaitan dengan penyegerakan data terutamanya termasuk tiga berikut:

1. Pustaka utama selesai melaksanakan transaksi, menulisnya ke binlog dan merekodkan detik ini sebagai T1
2. Selepas itu, ia dihantar ke perpustakaan hamba, dan masa apabila binlog diterima daripada perpustakaan hamba direkodkan sebagai T2; sebagai T3.
3. Apa yang dipanggil kelewatan tuan-hamba ialah perbezaan antara masa pelaksanaan perpustakaan hamba selesai dan masa pelaksanaan perpustakaan utama selesai untuk transaksi yang sama, yang ialah

.

T3 - T1Anda boleh melaksanakan perintah

pada pangkalan data siap sedia, dan hasil pemulangannya akan memaparkan

, yang digunakan untuk menunjukkan berapa saat pangkalan data siap sedia semasa ditangguhkan. Kaedah pengiraan show slave statusseconds_behind_master adalah seperti berikut:
seconds_behind_master

Terdapat medan masa dalam binlog setiap transaksi untuk merekodkan masa yang ditulis pada pangkalan data utama

1. Pangkalan data siap sedia mengeluarkan nilai medan masa transaksi yang sedang dilaksanakan, mengira perbezaan antaranya dan masa sistem semasa dan memperoleh
.
2. seconds_behind_master
Apabila rangkaian normal, masa yang diperlukan untuk log dihantar dari pangkalan data induk ke pangkalan data hamba adalah sangat singkat, iaitu nilai

adalah sangat kecil. Dalam erti kata lain, dalam keadaan rangkaian biasa, sumber utama kelewatan induk-hamba ialah perbezaan masa antara perpustakaan hamba yang menerima binlog dan melaksanakan transaksi.

T2 - T1Disebabkan kewujudan kelewatan tuan-hamba, kami mungkin mendapati bahawa data baru sahaja ditulis ke pangkalan data induk, tetapi hasilnya tidak dapat ditemui kerana ia mungkin belum disegerakkan ke pangkalan data hamba lagi. Semakin serius kelewatan tuan-hamba, semakin jelas masalah ini.

Punca kelewatan tuan-hamba

Terdapat masalah perbezaan masa antara pangkalan data induk dan pangkalan data hamba apabila melaksanakan transaksi yang sama Alasan utama termasuk tetapi tidak terhad kepada situasi berikut :

Di bawah beberapa syarat penggunaan,

prestasi mesin di mana pangkalan data hamba terletak lebih buruk daripada prestasi pangkalan data utama
• .
Pangkalan data hamba berada di bawah tekanan yang lebih besar
• , iaitu pangkalan data hamba tertakluk kepada sejumlah besar permintaan.
Laksanakan perkara besar
• . Kerana pangkalan data utama mesti menunggu pelaksanaan transaksi selesai sebelum ia ditulis ke binlog dan kemudian dihantar ke pangkalan data siap sedia. Jika kenyataan mengambil masa 10 minit untuk dilaksanakan pada pangkalan data induk, maka transaksi ini boleh menyebabkan kelewatan 10 minit dalam pangkalan data hamba.
Keupayaan salinan selari daripada pustaka
• .
Penyelesaian untuk kelewatan tuan-hamba

Terdapat terutamanya penyelesaian berikut untuk menyelesaikan kelewatan tuan-hamba:

Bekerja dengan separuh- segerakkan replikasi separa segerak
1. ;
Satu tuan dan berbilang hamba
2. untuk berkongsi tekanan daripada pangkalan data hamba
Paksa penyelesaian pangkalan data induk
3. (konsistensi kuat); penyelesaian tidur: Selepas perpustakaan induk dikemas kini, tidur sebelum membaca daripada perpustakaan hamba; nilai sama ada parameter
sudah sama dengan 0 dan bandingkan kedudukan);
5. Replikasi selariseconds_behind_master — menyelesaikan masalah kelewatan replikasi daripada pustaka; 🎜>Di sini kami terutamanya memperkenalkan beberapa penyelesaian yang saya gunakan dalam projek, iaitu
replikasi separuh segerak, operasi masa nyata, akses paksa kepada pangkalan data utama, replikasi selari
6. .
replikasi separa segerak separa segera

MySQL mempunyai tiga mod penyegerakan, iaitu:

"Replikasi tak segerak": Replikasi lalai MySQL adalah tak segerak Pangkalan data induk akan segera mengembalikan keputusan kepada klien selepas melaksanakan transaksi yang diserahkan oleh pelanggan, dan tidak peduli sama ada pangkalan data hamba telah pun. Terima dan proses. Akan ada masalah apabila pangkalan data utama turun, transaksi yang telah diserahkan pada pangkalan data utama mungkin tidak dihantar ke pangkalan data hamba kerana sebab rangkaian Jika failover dilakukan pada masa ini dan hamba dinaikkan secara paksa kepada tuan, ia boleh menyebabkan Data pada tuan baharu tidak lengkap.

"Replikasi segerak penuh" : Ini bermakna apabila perpustakaan utama menyelesaikan transaksi dan semua perpustakaan hamba telah melaksanakan transaksi, perpustakaan utama akan menyerahkan transaksi dan mengembalikan hasilnya kepada pelanggan. Kerana anda perlu menunggu semua perpustakaan hamba menyelesaikan transaksi sebelum kembali, prestasi replikasi segerak sepenuhnya pasti akan terjejas teruk.

"Replikasi separa segerak" : Ia adalah jenis antara replikasi segerak sepenuhnya dan replikasi tak segerak sepenuhnya Pustaka induk hanya perlu menunggu sekurang-kurangnya satu perpustakaan hamba menerima dan menulis kepadanya fail Relay Log Just, perpustakaan utama tidak perlu menunggu semua perpustakaan hamba mengembalikan ACK ke perpustakaan utama. Hanya selepas perpustakaan utama menerima ACK ini, ia boleh mengembalikan pengesahan "urus niaga selesai" kepada pelanggan.

Replikasi lalai MySQL adalah tak segerak, jadi akan berlaku kelewatan tertentu dalam data antara pangkalan data induk dan pangkalan data hamba Lebih penting lagi, replikasi tak segerak boleh menyebabkan kehilangan data. Walau bagaimanapun, replikasi segerak sepenuhnya akan memanjangkan masa untuk menyelesaikan transaksi dan mengurangkan prestasi. Jadi saya mengalihkan perhatian saya kepada replikasi separa segerak. Bermula dari MySQL 5.5, MySQL menyokong replikasi separa segerak dalam bentuk pemalam.

Berbanding dengan replikasi tak segerak, replikasi separa segerak meningkatkan keselamatan data dan mengurangkan kelewatan master-slave Sudah tentu, kelewatan ini adalah sekurang-kurangnya satu masa perjalanan pergi balik TCP/IP. Oleh itu, replikasi separa segerak paling baik digunakan dalam rangkaian kependaman rendah.

Perlu diingatkan bahawa:

• Kedua-dua pustaka induk dan pustaka hamba mesti mendayakan replikasi separa segerak sebelum replikasi separa segerak boleh dilakukan, jika tidak, induk perpustakaan akan dipulihkan kepada replikasi Asynchronous lalai.
• Jika semasa proses menunggu, masa menunggu telah melebihi tamat masa yang dikonfigurasikan dan tiada ACK diterima daripada mana-mana pustaka hamba, maka perpustakaan utama secara automatik akan menukar kepada replikasi tak segerak pada masa ini. Apabila sekurang-kurangnya satu nod hamba separa segerak mengejar, pangkalan data induk akan secara automatik menukar kepada replikasi separa segerak.

Isu berpotensi dengan replikasi separa segerak

Dalam replikasi separa segerak tradisional (diperkenalkan dalam MySQL 5.5), pangkalan data utama menulis data ke binlog dan melaksanakan komit selepas melakukan transaksi. , akan sentiasa menunggu ACK dari perpustakaan hamba, iaitu selepas perpustakaan hamba menulis Log Geganti, menulis data ke cakera, dan kemudian mengembalikan ACK ke perpustakaan utama Hanya selepas perpustakaan utama menerima ACK ini boleh mengembalikan mesej "transaksi selesai" kepada pelanggan.

Masalah akan timbul, iaitu perpustakaan utama sebenarnya telah melakukan transaksi ke lapisan enjin storan, dan aplikasi sudah dapat melihat bahawa data telah berubah, dan hanya menunggu kepulangan Itu sahaja. Jika pangkalan data induk turun pada masa ini, pangkalan data hamba mungkin tidak menulis Log Geganti dan ketidakkonsistenan data antara pangkalan data induk dan hamba akan berlaku.

Untuk menyelesaikan masalah di atas, MySQL 5.7 memperkenalkan replikasi separa segerak dipertingkatkan. Untuk gambar di atas, "Waiting Slave dump" dilaraskan kepada sebelum "Storage Commit", iaitu, selepas perpustakaan induk menulis data ke binlog, ia mula menunggu respons ACK dari perpustakaan hamba sehingga sekurang-kurangnya satu perpustakaan hamba menulis ke Log Geganti, dan kemudian Data ditulis pada cakera, dan kemudian ACK dikembalikan ke perpustakaan utama, memberitahu perpustakaan utama bahawa ia boleh melaksanakan operasi komit, dan kemudian perpustakaan utama menyerahkan transaksi kepada lapisan enjin transaksi Barulah aplikasi dapat melihat perubahan data.

Sudah tentu, skim separa penyegerakan sebelumnya turut disokong, dan MySQL 5.7.2 memperkenalkan parameter baharu rpl_semi_sync_master_wait_point untuk kawalan. Parameter ini mempunyai dua nilai:

1. AFTER_SYNC: Ini ialah skim separa penyegerakan baharu, Longgokan Hamba Menunggu sebelum Komit Storan.
2. AFTER_COMMIT: Ini ialah penyelesaian separa segerak lama.

Dalam mod after_commit yang digunakan dalam MySQL 5.5 - 5.6, selepas transaksi pelanggan diserahkan pada lapisan enjin storan, pangkalan data utama berada di bawah sementara pangkalan data utama menunggu pengesahan daripada pangkalan data hamba. Pada masa ini, walaupun keputusan tidak dikembalikan kepada pelanggan semasa, transaksi telah diserahkan dan pelanggan lain akan membaca transaksi yang diserahkan. Jika pangkalan data hamba tidak menerima transaksi atau tidak menulisnya ke log geganti, dan pangkalan data induk tidak berfungsi, dan kemudian beralih ke pangkalan data siap sedia, transaksi yang dibaca sebelum ini akan hilang, dan bacaan hantu akan berlaku, yang bermaksud data akan hilang.

Nilai lalai MySQL 5.7 ialah after_sync Pangkalan data induk menulis setiap transaksi ke binlog, menghantarnya ke pangkalan data hamba dan mengalirkannya ke cakera (log geganti). Pustaka utama menunggu sehingga perpustakaan hamba mengembalikan ack, kemudian melakukan transaksi dan mengembalikan hasil komit OK kepada pelanggan. Walaupun perpustakaan utama ranap, semua transaksi yang telah dilakukan pada perpustakaan utama boleh dijamin disegerakkan ke log geganti perpustakaan hamba, menyelesaikan masalah pembacaan hantu dan kehilangan data yang disebabkan oleh mod after_commit Ketekalan data semasa failover Akan dinaikkan pangkat . Kerana jika pangkalan data hamba tidak berjaya menulis, pangkalan data induk tidak akan melakukan transaksi. Di samping itu, menunggu ACK daripada pangkalan data sebelum melakukan juga boleh mengumpul transaksi, yang bermanfaat untuk penyerahan kumpulan komit kumpulan dan meningkatkan prestasi.

Tetapi ini juga akan menghadapi masalah dengan mengandaikan bahawa perpustakaan utama digantung sebelum enjin storan diserahkan, maka jelas sekali bahawa transaksi ini tidak berjaya, memandangkan Binlog yang sepadan telah melakukan a Operasi penyegerakan, mulai sekarang Perpustakaan telah menerima Binlog ini dan melaksanakannya dengan jayanya, yang setara dengan mempunyai data tambahan pada perpustakaan hamba (pustaka hamba mempunyai data ini tetapi perpustakaan utama tidak), yang boleh dianggap sebagai masalah, tetapi data tambahan biasanya bukan masalah yang serius. Apa yang boleh dijamin ialah tiada data yang hilang Mempunyai lebih banyak data adalah lebih baik daripada kehilangan data.

Satu tuan dan berbilang hamba

Jika pangkalan data hamba melaksanakan sejumlah besar permintaan pertanyaan, operasi pertanyaan pada pangkalan data hamba akan menggunakan banyak sumber CPU, sekali gus menjejaskan kelajuan penyegerakan dan menyebabkan induk daripada kelewatan. Kemudian kita boleh menyambung beberapa lagi perpustakaan hamba dan biarkan perpustakaan hamba ini berkongsi tekanan membaca.

Ringkasnya, ia adalah untuk menambah mesin Caranya mudah dan kasar, tetapi ia juga akan membawa kos tertentu.

Paksa penyelesaian pangkalan data utama

Jika sesetengah operasi mempunyai keperluan ketat pada data masa nyata, mereka perlu mencerminkan data masa nyata terkini, seperti hal kewangan melibatkan sistem wang, sistem masa nyata dalam talian, atau perniagaan yang membaca serta-merta selepas menulis, maka kita perlu melepaskan pemisahan membaca dan menulis, dan membiarkan permintaan membaca seperti itu juga melalui perpustakaan utama, jadi tidak ada masalah kelewatan. .

Sudah tentu, ini juga kehilangan peningkatan prestasi yang dibawa kepada kami oleh pemisahan membaca dan menulis, jadi pertukaran yang sesuai diperlukan.

Replikasi selari

Secara amnya, replikasi induk-hamba MySQL melibatkan tiga utas, yang kesemuanya merupakan utas tunggal: Benang Binlog Dump, benang IO dan benang SQL. Kelewatan replikasi biasanya berlaku di dua tempat:

Benang SQL terlalu sibuk (sebab utama
• Kegelisahan rangkaian menyebabkan kelewatan replikasi benang IO (sebab kedua).

Pelaksanaan log pada pangkalan data siap sedia ialah logik benang SQL pada pangkalan data siap sedia yang melaksanakan log geganti (log geganti) untuk mengemas kini data.

Sebelum MySQL versi 5.6, MySQL hanya menyokong replikasi satu benang Akibatnya, masalah kelewatan tuan-hamba yang serius akan berlaku apabila konkurensi pangkalan data utama dan TPS tinggi.

Bermula dari MySQL 5.6, terdapat konsep berbilang benang SQL, yang boleh memulihkan data secara serentak, iaitu teknologi replikasi selari . Ini boleh menyelesaikan masalah kelewatan tuan-hamba MySQL dengan baik.

Daripada replikasi satu benang kepada versi terbaharu replikasi berbilang benang, evolusi telah melalui beberapa versi. Malah, dalam analisis akhir, semua mekanisme replikasi berbilang benang adalah untuk membahagikan sql_thread dengan hanya satu benang kepada berbilang benang, yang bermaksud semuanya mematuhi model berbilang benang berikut:

penyelaras ialah sql_thread asal, tetapi kini ia tidak lagi mengemas kini data secara langsung, ia hanya bertanggungjawab untuk membaca log transit dan mengedarkan transaksi. Perkara yang sebenarnya mengemas kini log menjadi benang pekerja . Bilangan benang pekerja ditentukan oleh parameter . slave_parallel_workers

Memandangkan rangkaian pekerja berjalan serentak, untuk memastikan pengasingan transaksi dan mengelakkan masalah liputan kemas kini, penyelaras perlu memenuhi dua keperluan asas berikut semasa mengedar:

1. Dua transaksi yang mengemas kini baris yang sama mesti diedarkan kepada pekerja yang sama (untuk mengelakkan liputan kemas kini) .
2. Urus niaga yang sama tidak boleh dipisahkan dan mesti diletakkan dalam pekerja yang sama (untuk memastikan pengasingan transaksi) .

Semua versi replikasi berbilang benang mengikut dua prinsip asas ini.

Berikut ialah strategi pengedaran jadual demi jadual dan strategi pengedaran baris demi baris, yang boleh membantu memahami lelaran versi rasmi MySQL bagi strategi replikasi selari:

• Pengagihan mengikut strategi jadual: Dua urus niaga boleh dijalankan secara selari jika ia mengemas kini jadual yang berbeza. Oleh kerana data disimpan dalam jadual, pengedaran mengikut jadual memastikan bahawa dua pekerja tidak akan mengemas kini baris yang sama.
  • Skim pengedaran berasaskan jadual berfungsi dengan baik dalam senario di mana berbilang jadual mempunyai beban genap, tetapi kelemahannya ialah: jika anda menemui jadual hotspot, contohnya, apabila semua transaksi kemas kini melibatkan jadual tertentu, Semua urus niaga akan ditugaskan kepada pekerja yang sama, yang menjadi replikasi berbenang tunggal.
• Strategi pengedaran baris demi baris: Jika dua transaksi tidak mengemas kini baris yang sama, ia boleh selari pada pangkalan data siap sedia. Jelas sekali, mod ini memerlukan format binlog mestilah baris.
  • Penyelesaian replikasi selari baris demi baris menyelesaikan masalah jadual hotspot dan mempunyai tahap selari yang lebih tinggi Walau bagaimanapun, kelemahannya ialah: berbanding dengan strategi pengedaran selari jadual demi jadual, baris-. strategi selari oleh baris memerlukan penggunaan apabila memutuskan lebih banyak sumber pengkomputeran.

Strategi replikasi selari versi MySQL 5.6

Versi MySQL 5.6 menyokong replikasi selari, tetapi butiran yang disokong adalah selari dengan pangkalan data (berdasarkan Skema ) .

Idea teras ialah : data apabila jadual di bawah skema berbeza diserahkan serentak tidak akan menjejaskan satu sama lain, iaitu perpustakaan hamba boleh memperuntukkan fungsi seperti benang SQL kepada skema yang berbeza dalam log geganti untuk memainkan semula transaksi yang diserahkan oleh perpustakaan utama dalam log geganti untuk memastikan data konsisten dengan perpustakaan utama.

Jika terdapat berbilang DB pada pangkalan data utama, menggunakan strategi ini boleh meningkatkan kelajuan replikasi daripada pangkalan data hamba. Tetapi biasanya terdapat berbilang jadual dalam satu pangkalan data, jadi konkurensi berasaskan pangkalan data tidak mempunyai kesan, dan main semula selari tidak boleh dilakukan sama sekali, jadi strategi ini tidak banyak digunakan.

Strategi replikasi selari MySQL 5.7

MySQL 5.7 memperkenalkan replikasi selari berasaskan penyerahan kumpulan, parameter slave_parallel_workers menetapkan bilangan utas selari, ditentukan oleh parameter slave-parallel-type Kawal strategi replikasi selari:

• dikonfigurasikan sebagai PANGKALAN DATA, yang bermaksud menggunakan strategi selari pangkalan data demi pangkalan data versi MySQL 5.6
• dikonfigurasikan sebagai LOGICAL_CLOCK, yang bermaksud menggunakan strategi replikasi selari berdasarkan komitmen kumpulan; >Urus niaga yang boleh diserahkan dalam kumpulan yang sama mestilah Baris yang sama tidak akan diubah suai (disebabkan mekanisme penguncian MySQL) kerana transaksi telah melepasi ujian konflik kunci
.

Proses khusus replikasi selari berdasarkan penyerahan kumpulan adalah seperti berikut:

Transaksi yang diserahkan bersama dalam kumpulan mempunyai commit_id yang sama, dan kumpulan seterusnya adalah commit_id 1; commit_id ditulis terus ke dalam binlog; kumpulan selesai, penyelaras Pergi dan dapatkan kumpulan seterusnya untuk pelaksanaan.

1. Semua transaksi dalam status persediaan dan komitmen boleh dilaksanakan selari pada pangkalan data siap sedia
.
2. Dua parameter berkaitan diserahkan oleh kumpulan binlog:

parameter binlog_group_commit_sync_delay, yang menunjukkan bilangan mikrosaat untuk ditangguhkan sebelum memanggil fsync flush

binlog_group_commit_count_parameter; menunjukkan Berapa kali terkumpul sebelum fsync dipanggil.

Kedua-dua parameter ini digunakan untuk memanjangkan masa secara sengaja daripada binlog tulis kepada fsync, dengan itu mengurangkan bilangan binlog menulis ke cakera. Dalam strategi replikasi selari MySQL 5.7, ia boleh digunakan untuk mencipta lebih banyak "urus niaga dalam fasa penyediaan pada masa yang sama". Anda boleh mempertimbangkan untuk melaraskan nilai kedua-dua parameter ini untuk mencapai tujuan menambah baik keselarasan replikasi pangkalan data siap sedia.

Pembelajaran yang disyorkan:
• tutorial video mysql

Atas ialah kandungan terperinci Kuasai sepenuhnya penyelesaian kepada kelewatan tuan-hamba MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!