Analisis senario penggunaan penyegerakan master-slave mysql dan asynchronous

Sebab untuk menjalankan penyelidikan mengenai kandungan ini adalah terutamanya untuk menangani dua keraguan yang tidak terjawab yang dihadapi sebelum ini:

a． Terdapat sistem dalam talian Keadaan separa segerak sering berubah daripada separa segerak kepada tak segerak, dan kemudian kembali kepada separa segerak Sebabnya tidak diketahui.

b． Beberapa ketika dahulu, disebabkan keperluan senario perniagaan, kami menjalankan ujian replikasi tak segerak bilik merentas mesin. Apabila mysql write qps sangat tinggi, didapati bahawa banyak log tidak sempat dihantar ke perpustakaan hamba, iaitu kelajuan penjanaan log binlog di perpustakaan utama adalah lebih tinggi daripada kelajuan penghantaran ke perpustakaan hamba Perbezaan kelajuan ini sentiasa wujud, jadi apabila perpustakaan utama terus tinggi Apabila binlog dijana di bawah tekanan, semakin banyak binlog tidak dihantar ke perpustakaan hamba, tetapi trafik rangkaian pada masa itu hanya kira-kira 18M/S (. satu tuan, satu hamba). Menurut pengetahuan konvensional, kelajuan penghantaran rangkaian Gigabit Ia boleh mencapai 100M, tetapi kelajuan penghantaran binlog semasa antara tuan dan hamba hanya mencapai kira-kira 18M. Adakah ia masalah rangkaian? Atau atas sebab lain.

Prinsip replikasi tuan-hamba Buang benang dan benang io

Apabila hubungan replikasi induk-hamba diwujudkan, terdapat benang dump pada perpustakaan induk, yang digunakan untuk menghantar log binlog yang dijana dalam perpustakaan induk, dan benang io pada perpustakaan hamba digunakan untuk menerima data yang dihantar oleh benang dump ke perpustakaan hamba melalui log binlog, dan bertanggungjawab untuk menulisnya ke dalam log geganti. Ini adalah mekanisme replikasi tuan-hamba Pada masa yang sama, kerana ia adalah replikasi tak segerak, proses penghantaran tidak memerlukan pengesahan ack.

Persoalannya juga di sini - kerana ia adalah penghantaran tak segerak, jika ia hanya difahami sebagai penghantaran rangkaian terus fail binlog, kelajuannya harus sangat cepat, tetapi keadaan sebenar: dalam persekitaran ujian kami, kelajuan penghantaran log binlog adalah hanya 18M/s, iaitu kurang daripada kelajuan kira-kira 22M/s yang dijana oleh log. Mengapa ia hanya pada kelajuan ini dan tidak menggunakan sepenuhnya lebar jalur rangkaian? sebab apa?

Butiran penghantaran log

Dalam struktur replikasi induk-hamba, terdapat satu utas dump pada perpustakaan induk dan satu utas io pada perpustakaan hamba, jadi tiada penghantaran dan penerimaan berbilang rangkaian secara serentak Anda hanya perlu memahami mekanisme kerja binlog buang benang untuk memahami semua butiran.

Dengan menghuraikan fail binlog, kita boleh tahu bahawa transaksi boleh mengandungi berbilang peristiwa Berikut adalah maklumat yang direkodkan dalam binlog perkara paling mudah:

# at 33580

#170531 17:22:53 server id 153443358  end_log_pos 33645 CRC32 0x4ea17869        GTID    last_committed=125      sequence_number=126

SET @@SESSION.GTID_NEXT= ‘e1028e43-4123-11e7-a3c2-005056aa17e6:198’/*!*/;

# at 33645

#170531 17:22:53 server id 153443358  end_log_pos 33717 CRC32 0x66820e00        Query   thread_id=4     exec_time=0     error_code=0

SET TIMESTAMP=1496222573/*!*/;

BEGIN

/*!*/;

# at 33717

#170531 17:22:53 server id 153443358  end_log_pos 33770 CRC32 0x22ddf25e        Table_map: `test`.`xcytest` mapped to number 222

# at 33770

#170531 17:22:53 server id 153443358  end_log_pos 33817 CRC32 0x61051ea0        Write_rows: table id 222 flags: STMT_END_F

BINLOG ‘

bYsuWRMeXCUJNQAAAOqDAAAAAN4AAAAAAAEABHRlc3QAB3hjeXRlc3QAAgMPAlgCAl7y3SI=

bYsuWR4eXCUJLwAAABmEAAAAAN4AAAAAAAEAAgAC//x9AAAABQBzZGZhc6AeBWE=

‘/*!*/;

### INSERT INTO `test`.`xcytest`

### SET

###   @1=125 /* INT meta=0 nullable=0 is_null=0 */

###   @2=’sdfas’ /* VARSTRING(600) meta=600 nullable=1 is_null=0 */

# at 33817

#170531 17:22:53 server id 153443358  end_log_pos 33848 CRC32 0x630805b4        Xid = 303

COMMIT/*!*/;

Setiap segmen di xxxxx adalah acara.

Fungsi Binlog_sender::send_events ialah fungsi yang menghantar acara acara dalam binlog:

Parameter fungsi:

end_pos, kedudukan akhir fail binlog sedang dibaca.

log_cache, rekod ialah maklumat log yang sedang dihantar, termasuk lokasi log binlog yang telah dihantar, dan fail log binlog.

Analisis logik fungsi:

Jika log_pos kedudukan yang dihantar pada masa ini adalah kurang daripada end_pos kedudukan akhir fail yang diperolehi, ini menunjukkan bahawa masih terdapat log binlog yang belum dihantar dan gelung telah dimasukkan.

Peredaran dalam badan:

a. Mula-mula panggil fungsi read_event untuk mendapatkan acara acara.

b. Log_event_type event_type= (Log_event_type)event_ptr[EVENT_TYPE_OFFSET];

Pernyataan ini digunakan untuk mendapatkan jenis acara dan kemudian melakukan semakan jenis

check_event_type(event_type, log_file, log_pos), jika semakan tidak lulus, 1 akan dikembalikan terus ke fungsi atas.

c. log_pos= my_b_tell(log_cache);

d. Kemudian panggil fungsi send_packet() untuk menghantar binlog.

Ternyata tidak kira berapa banyak binlog yang tidak disegerakkan ke perpustakaan hamba pada masa ini, butiran perpustakaan induk yang menghantar binlog masih menghantar acara satu per satu Sebelum menghantar, jenis acara perlu disemak. Kerana ia dihantar dalam paket kecil, trafik rangkaian tidak besar.

Tetapi kami perlu menjelaskan prasyarat untuk fenomena ini: dalam persekitaran ujian kami, qps tulis pangkalan data pada masa itu mencapai lebih daripada 50,000, jadi terdapat banyak acara yang perlu dihantar Walaupun ia tidak segerak, benang pembuangan berbenang tunggal tidak mempunyai masa untuk menghantar log peristiwa semasa.

Apabila qps yang ditulis besar, memang ada keadaan yang terlambat untuk menghantar log.

Ringkasan

Sekarang, mari kita lihat kembali masalah yang dihadapi dalam talian "Keadaan penyegerakan sering berubah daripada keadaan separa segerak kepada keadaan tak segerak, dan kemudian dipulihkan kepada keadaan separa segerak dalam masa yang ditetapkan." sistem analisis dan kadangkala melakukan kemas kini Kelompok dan import kelompok. Pada masa yang sama, format binlog yang ditetapkan oleh pangkalan data ialah mod baris Untuk transaksi yang mengemas kini berbilang baris, ia mengandungi banyak peristiwa (satu baris ialah peristiwa), jadi penghantaran binlog transaksi ini akan mengambil masa yang lama dan tidak boleh. dihantar dalam masa 1 saat (Tamat masa separa segerak ditetapkan kepada 1), jadi keadaan separa segerak menjadi tak segerak.

Atas ialah kandungan terperinci Analisis senario penggunaan penyegerakan master-slave mysql dan asynchronous. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!