Bagaimana untuk melaksanakan replikasi selari dalam Replikasi MySQL-tutorial mysql-php.cn

Arahan untuk replikasi berbenang tunggal tradisional

Seperti yang kita sedia maklum, sebelum MySQL versi 5.6, terdapat dua utas pada nod hamba replikasi tuan-hamba, masing-masing ialah benang I/O dan benang SQL.

Benang I/O bertanggungjawab untuk menerima peristiwa daripada log binari dan menulisnya ke Log Geganti.
Benang SQL membaca Log Geganti dan memainkannya semula dalam pangkalan data.

Kaedah di atas kadangkala boleh menyebabkan kelewatan, jadi apakah situasi yang boleh menyebabkan kelewatan antara nod induk dan hamba?

1 .Pangkalan data utama melakukan transaksi besar (seperti perubahan struktur jadual besar).
2. Perubahan besar-besaran pada pangkalan data utama (seperti operasi sisipan, kemas kini dan pemadaman berskala besar).
3 Dalam mod penyegerakan ROW, kunci utama jadual besar dalam pangkalan data utama tidak dikemas kini dengan kerap.
4. Konfigurasi parameter pangkalan data adalah tidak munasabah dan terdapat kesesakan dalam prestasi nod hamba (contohnya: tetapan log transaksi nod hamba terlalu kecil, mengakibatkan pemadaman cakera yang kerap).
5 Persekitaran rangkaian tidak stabil, dan terdapat kelewatan dan sambungan semula dalam membaca binlog daripada benang IO nod.
6 Konfigurasi perkakasan induk-hamba adalah berbeza, dan penggunaan sumber perkakasan nod hamba mencapai had atas. (Contohnya: cakera SSD nod induk, cakera SAS nod hamba)

secara kasar boleh mengklasifikasikan sebab kelewatan di atas.

1 Isu perkakasan (termasuk IO cakera, IO rangkaian, dll.)
2.
Isu reka bentuk pangkalan data.
4. Pangkalan data utama berubah dalam kuantiti yang banyak, dan pemprosesan satu benang SQL nod hamba tidak cukup tepat pada masanya.

Ringkasan

Menganalisis sebab-sebab di atas, dapat dilihat bahawa untuk mengurangkan kelewatan tuan-hamba, di samping menambah baik keadaan perkakasan, DBA juga perlu memberi perhatian kepada reka bentuk pangkalan data dan isu konfigurasi Akhir sekali, adalah perlu untuk meningkatkan keupayaan pemprosesan serentak nod hamba Menukar daripada main balik berbenang tunggal kepada main balik selari berbilang adalah kaedah yang lebih baik titik adalah bagaimana untuk menyelesaikan konflik data dan lokasi pemulihan kesalahan di bawah premis pemulihan berbilang benang Klik untuk mengesahkan soalan.

Replikasi selari peringkat perpustakaan MySQL5.6

Apabila terdapat berbilang pangkalan data dalam contoh, berbilang urutan boleh dimulakan dan setiap urutan sepadan dengan satu pangkalan data. Dalam mod ini, nod hamba akan memulakan berbilang benang. Benang dibahagikan kepada dua kategori Coordinator dan WorkThread.

Pembahagian benang logik pelaksanaan buruh

CoordinatorBenang bertanggungjawab untuk menentukan sama ada urus niaga boleh dilaksanakan secara selari , dan jika ya, edarkan transaksi Laksanakan untuk WorkThread urutan Jika dinilai bahawa ia tidak boleh dilaksanakan, seperti DDL, 跨库操作, dsb., tunggu semua urutan pekerja menyelesaikan pelaksanaan, dan kemudian laksanakan. ia oleh Coordinator.

Maklumat konfigurasi utama

slave-parallel-type=DATABASE

Salin selepas log masuk

Kekurangan cadangan

Model replikasi selari ini hanya akan mempunyai tahap keselarian yang tinggi apabila terdapat berbilang DB dalam contoh dan urus niaga DB agak sibuk Walau bagaimanapun, dalam penyelenggaraan harian, pemprosesan urus niaga satu kejadian adalah agak tertumpu pada a DB. Kebanyakan kelewatan diperhatikan berdasarkan kehadiran jadual hotspot. Adalah idea yang baik untuk menyediakan keselarian berasaskan jadual.

Replikasi selari MySQL5.7 berdasarkan penyerahan kumpulan

Arahan penyerahan kumpulan

Ringkasnya, di bawah tetapan double 1, selepas transaksi diserahkan Iaitu, operasi memberus cakera ditukar untuk menggabungkan berbilang transaksi ke dalam kumpulan transaksi dan kemudian melakukan pembersihan cakera bersatu Pemprosesan ini mengurangkan tekanan cakera IO. Untuk butiran, sila rujuk 老叶茶馆 tweet penjelasan tentang penyerahan kumpulan https://mp.weixin.qq.com/s/rcPkrutiLc93aTblEZ7sFg

Sekumpulan transaksi diserahkan pada masa yang sama, yang bermaksud bahawa tiada konflik dalam transaksi dalam kumpulan, jadi urus niaga dalam kumpulan berada pada nod hamba Ia boleh dilaksanakan secara serentak Masalahnya ialah bagaimana untuk membezakan sama ada transaksi berada dalam kumpulan yang sama, jadi dua maklumat parameter baharu last_committed dan sequence_number

<🎜. >

muncul dalam binlog Bagaimana untuk menilai Adakah transaksi dalam kumpulan

Menghuraikan binlog menunjukkan bahawa terdapat dua lagi maklumat parameter, <. 🎜> dan
, antaranya last_committed diduplikasi. sequence_numberlast_committed

# Nilai ini merujuk kepada nombor urutan penyerahan transaksi, meningkat secara monoton.
sequence_number

# Nilai ini mempunyai dua makna 1. Nilai yang sama bermakna transaksi ini berada dalam kumpulan yang sama, 2. Nilai ini juga mewakili kumpulan transaksi sebelumnya nombor.

last_committed

[root@mgr2 GreatSQL]# mysqlbinlog mysql-bin.0000002 | grep last_committed
GTID last_committed=0 sequence_number=1
GTID last_committed=0 sequence_number=2
GTID last_committed=2 sequence_number=3
GTID last_committed=2 sequence_number=4
GTID last_committed=2 sequence_number=5
GTID last_committed=2 sequence_number=6
GTID last_committed=6 sequence_number=7
GTID last_committed=6 sequence_number=8

Salin selepas log masuk

```
slave-parallel-type=LOGICAL_CLOCK
```
Salin selepas log masuk

基于组提交的同步有个不足点，就是当主节点的事务繁忙度较低的时候，导致时间段内组提交fsync刷盘的事务量较少，于是导致从库回放的并行度并不高，甚至可能一组里面只有一个事务，这样从节点的多线程就基本用不到，可以通过设置下面两个参数，让主节点延迟提交。

binlog_group_commit_sync_delay # 等待延迟提交的时间，binlog提交后等待一段时间再 fsync。让每个 group 的事务更多，人为提高并行度。
binlog_group_commit_sync_no_delay_count # 待提交的最大事务数，如果等待时间没到，而事务数达到了，就立即 fsync。达到期望的并行度后立即提交，尽量缩小等待延迟。

MySQL8.0基于writeset的并行复制

writeset 基于事务结果冲突进行判断事务是否可以进行并行回放的方法，他由binlog-transaction-dependency-tracking参数进行控制，默认采用WRITESET方法。

关键参数查看

Command-Line Format	--binlog-transaction-dependency-tracking=value
System Variable	binlog_transaction_dependency_tracking
Scope	Global
Dynamic	Yes
SET_VAR Hint Applies	No
Type	Enumeration
Default Value	COMMIT_ORDER
Valid Values	COMMIT_ORDER WRITESET WRITESET_SESSION

参数配置项说明

COMMIT_ORDER # 使用 5.7 Group commit 的方式决定事务依赖。
WRITESET # 使用写集合的方式决定事务依赖。
WRITESET_SESSION # 使用写集合，但是同一个session中的事务不会有相同的last_committed。

writeset 是一个HASH类型的数组，里面记录着事务的更新信息，通过transaction_write_set_extraction判断当前事务更新的记录与历史事务更新的记录是否存在冲突，判断过后再采取对应处理方法。writeset储存的最大存储值由binlog-transaction-dependency-history-size控制。

需要注意的是，当设置成WRITESET或WRITESET_SESSION的时候，事务提交是无序状态的，可以通过设置 slave_preserve_commit_order=1 强制按顺序提交。

binlog_transaction_dependency_history_size

设定一个上限，限制在内存中缓存之前事务修改的行信息时所使用的行哈希数。一旦达到这个哈希数，就会清除历史记录。

Command-Line Format	--binlog-transaction-dependency-history-size=#
System Variable	binlog_transaction_dependency_history_size
Scope	Global
Dynamic	Yes
SET_VAR Hint Applies	No
Type	Integer
Default Value	25000
Minimum Value	1
Minimum Value	1000000

transaction_write_set_extraction

该模式支持三种算法，默认采用XXHASH64，当从节点配置writeset复制的时候，该配置不能配置为OFF。在MySQL 8.0.26中，该参数已被标记为已弃用，将来将被删除。

Command-Line Format	--transaction-write-set-extraction[=value]
Deprecated	8.0.26
System Variable	binlog_transaction_dependency_history_size
Scope	Global, Session
Dynamic	Yes
SET_VAR Hint Applies	No
Type	Enumeration
Default Value	XXHASH64
Valid Values	OFF MURMUR32 XXHASH64

数据库配置

slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 8
binlog_transaction_dependency_tracking = WRITESET
slave_preserve_commit_order = 1

Salin selepas log masuk

Atas ialah kandungan terperinci Bagaimana untuk melaksanakan replikasi selari dalam Replikasi MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!