So implementieren Sie die parallele Replikation in der MySQL-Replikation

Traditionelle Single-Thread-Replikationsanweisungen

Wie wir alle wissen, gab es vor MySQL Version 5.6 zwei Threads auf dem Slave-Knoten der Master-Slave-Replikation, nämlich den E/A-Thread und den SQL-Thread.

• Der I/O-Thread ist dafür verantwortlich, Ereignisse aus dem Binärprotokoll zu empfangen und sie in das Relay-Protokoll zu schreiben.

• Der SQL-Thread liest das Relay-Protokoll und spielt es in der Datenbank ab.

Die obige Methode führt gelegentlich zu Verzögerungen. Welche Situationen können also zu Verzögerungen zwischen dem Master- und Slave-Knoten führen?

• 1 Die Hauptdatenbank führt große Transaktionen aus (z. B. große Änderungen an der Tabellenstruktur). .

• 2. Umfangreiche Änderungen an der Hauptdatenbank (z. B. umfangreiche Einfüge-, Aktualisierungs- und Löschvorgänge).

• 3. Im ROW-Synchronisationsmodus verfügt die Hauptdatenbanktabelle über keinen Primärschlüssel, der häufig aktualisiert wird.

• 4. Die Konfiguration der Datenbankparameter ist unangemessen und es liegt ein Engpass bei der Leistung des Slave-Knotens vor (z. B. ist die Einstellung für das Transaktionsprotokoll des Slave-Knotens zu klein, was zu häufigem Festplatten-Flushen führt).

• 5. Die Netzwerkumgebung ist instabil und es kommt zu Verzögerungen und Neuverbindungen beim Lesen des Binlogs aus dem Knoten-IO-Thread.

• 6. Die Master-Slave-Hardwarekonfiguration ist unterschiedlich und die Hardware-Ressourcennutzung des Slave-Knotens erreicht die Obergrenze. (Zum Beispiel: Master-Knoten-SSD-Festplatte, Slave-Knoten-SAS-Festplatte)

Sie können die oben genannten Gründe für Verzögerungen grob klassifizieren.

• 1. Hardwareprobleme (einschließlich Festplatten-IO, Netzwerk-IO usw.)

• 2.

• 3. Probleme beim Datenbankdesign.

• 4. Die Hauptdatenbank wird in großen Mengen geändert und die Single-Threaded-SQL-Verarbeitung des Slave-Knotens ist nicht zeitnah genug.

Zusammenfassung

Nach der Analyse der oben genannten Gründe ist ersichtlich, dass der DBA neben der Verbesserung der Hardwarebedingungen auch auf das Datenbankdesign und die Datenbankkonfiguration achten muss, um die Master-Slave-Verzögerung zu verringern Schließlich ist es notwendig, die gleichzeitigen Verarbeitungsfähigkeiten der Slave-Knoten zu verbessern. Der Wechsel von der Single-Thread-Wiedergabe zur Multi-Thread-Parallel-Wiedergabe ist eine bessere Methode, um das Problem der Datenkonflikte und -bestätigungen zu lösen von Fehlerwiederherstellungsstandortpunkten unter der Prämisse der Multi-Thread-Wiederherstellung.

MySQL5.6 basiert auf paralleler Replikation auf Bibliotheksebene.

Wenn mehrere Datenbanken in der Instanz vorhanden sind, können mehrere Threads gestartet werden, und jeder Thread entspricht einer Datenbank. In diesem Modus startet der Slave-Knoten mehrere Threads. Threads sind in zwei Kategorien unterteilt: Coordinator und WorkThread. Coordinator 和 WorkThread。

• 线程分工执行逻辑

Coordinator线程负责判断事务是否可以并行执行，如果可以并行就把事务分发给WorkThread线程执行，如果判断不能执行，如DDL，跨库操作等，就等待所有的worker线程执行完成之后，再由Coordinator执行。

• 关键配置信息

slave-parallel-type=DATABASE

• 方案不足点

这种并行复制的模式,只有在实例中有多个DB且DB的事务都相对繁忙的情况下才会有较高的并行度，但是日常维护中其实单个实例的的事务处理相对集中在一个DB上。大多数延迟情况都基于热点表的出现而观察得出。如果能够提供基于表的并行度是一个很好方法。

MySQL5.7基于组提交的并行复制

组提交说明

简单来说就是在双1的设置下，事务提交后即刷盘的操作改为多个事务合并成一组事务再进行统一刷盘，这样处理就降低了磁盘IO的压力。详细资料参考老叶茶馆关于组提交的说明推文https://mp.weixin.qq.com/s/rcPkrutiLc93aTblEZ7sFg

一组事务同时提交也就意味着组内事务不存在冲突，故组内的事务在从节点上就可以并发执行，问题在于如何区分事务是否在同一组中的，于是在binlog中出现了两个新的参数信息last_committed 和 sequence_number

• 如何判断事务在一个组内呢?

解析binlog可以发现里面多了last_committed和sequence_number两个参数信息，其中last_committed存在重复的情况。

• sequence_number # 这个值指的是事务提交的序号，单调递增。

• last_committed

Thread-Arbeitsteilungsausführungslogik
Koordinator Der Thread ist dafür verantwortlich, zu bestimmen, ob die Transaktion parallel ausgeführt werden kann. Wenn sie parallel ausgeführt werden kann, wird die Transaktion verteilt an den WorkThread-Thread zur Ausführung, wenn festgestellt wird, dass er nicht ausgeführt werden kann, z. B. DDL, bibliotheksübergreifende Operation usw. , warten Sie, bis alle Arbeitsthreads die Ausführung abgeschlossen haben, und führen Sie sie dann durch Coordinator aus. Wichtige Konfigurationsinformationen: Bei der täglichen Wartung konzentriert sich die Transaktionsverarbeitung einer einzelnen Instanz jedoch relativ auf eine Datenbank. Die meisten Verzögerungen werden aufgrund des Vorhandenseins von Hotspot-Tabellen beobachtet. Es wäre eine gute Idee, eine tabellenbasierte Parallelität bereitzustellen.

Parallele Replikation von MySQL5.7 basierend auf der Gruppenübermittlung

Anweisungen zur Gruppenübermittlung

• Einfach ausgedrückt, unter der Einstellung „Double 1“ ist der Vorgang des Leerens der Festplatte nach der Transaktion Gesendet wird geändert. Führen Sie mehrere Transaktionen zu einer Gruppe von Transaktionen zusammen und führen Sie dann ein einheitliches Festplatten-Flushing durch, wodurch der Druck auf die Festplatten-E/A verringert wird. Ausführliche Informationen finden Sie im Erklärungs-Tweet von Laoye Teahouse zur Gruppeneinreichung https://mp.weixin.qq.com/s/rcPkrutiLc93aTblEZ7sFg

  🎜🎜Eine Gruppe Anzahl der Transaktionen werden gleichzeitig übermittelt. Dies bedeutet, dass es keinen Konflikt zwischen den Transaktionen innerhalb der Gruppe gibt, sodass die Transaktionen in der Gruppe gleichzeitig auf dem Slave-Knoten ausgeführt werden können. Das Problem besteht darin, zu unterscheiden, ob die Transaktionen gleich sind Gruppe, sodass zwei neue Parameterinformationen im Binlog last_committed und sequence_number angezeigt werden Wenn Sie das Binlog analysieren, können Sie feststellen, dass es mehr last_committed und sequence_number gibt. Zwei Parameterinformationen, von denen last_committed dupliziert wird. 🎜🎜🎜🎜🎜sequence_number # Dieser Wert bezieht sich auf die Sequenznummer der Transaktionseinreichung, die monoton ansteigt. 🎜🎜🎜🎜last_committed # Dieser Wert hat zwei Bedeutungen: 1. Der gleiche Wert bedeutet, dass sich diese Transaktionen in derselben Gruppe befinden, 2. Dieser Wert stellt auch die maximale Anzahl der vorherigen Gruppe von Transaktionen dar. 🎜🎜🎜

  [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

  🎜🎜🎜Datenbankkonfiguration🎜🎜🎜

  slave-parallel-type=LOGICAL_CLOCK

  🎜🎜🎜Schemamängel🎜

基于组提交的同步有个不足点，就是当主节点的事务繁忙度较低的时候，导致时间段内组提交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

Das obige ist der detaillierte Inhalt vonSo implementieren Sie die parallele Replikation in der MySQL-Replikation. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!