Heim  >  Artikel  >  Datenbank  >  Verstehen Sie den GTID-basierten Replikationsmodus von MySQL

Verstehen Sie den GTID-basierten Replikationsmodus von MySQL

coldplay.xixi
coldplay.xixinach vorne
2020-12-28 10:12:212341Durchsuche

MySQL-Tutorial In der Spalte „MySQL-Tutorial“ wird der GTID-basierte Replikationsmodus von MySQL vorgestellt

GTID-Definition

Verstehen Sie den GTID-basierten Replikationsmodus von MySQLGTID (Global Transaction Identifier) ​​​​Globale Transaktionskennung. GTID ist eine wesentliche Verbesserung der Master-Slave-Replikation, die in Version 5.6 eingeführt wurde. Im Vergleich zur vorherigen Version der Master-Slave-Replikation basierend auf Binlog-Dateien + Position weist die GTID-basierte Master-Slave-Replikation eine höhere Datenkonsistenz und robustere Master-Slave-Daten auf Replikation und Failover sind weniger fehleranfällig und erfordern selten menschliches Eingreifen.

Darstellungsmethode

GTID = server_uuid:transaction_id

Die GTID wird normalerweise in der MySQL-Systemvariablen @@GLOBAL.gtid_executed und der Systemtabelle mysql.gtid_executed aufgezeichnet. Code > befindet sich die Systemvariable <code>@@GLOBAL.gtid_executed im Speicher und gehört zum nicht-persistenten Speicher, während die Systemtabelle mysql.gtid_executed zum persistenten Speicher gehört. Die Vorteile von GTID gegenüber der herkömmlichen Replikation Wie zuvor sind /code> und log_posGTID kontinuierlich und ohne Lücken, was Datenkonsistenz und Nullverlust gewährleistet. Der Replikationscluster verfügt über eine einheitliche Methode zur Identifizierung des Replikationsstandorts, was die Clusterverwaltung vereinfacht

GTID-Einschränkungen

    Das Mischen von Engines wie Innodb und Myisam in einer Transaktion führt zu mehreren GTIDS


    CREATE TABLE…..SELECT kann nicht verwendet werden@@GLOBAL.gtid_executed 以及系统表mysql.gtid_executed中,系统变量@@GLOBAL.gtid_executed 在内存中,属于非持久化存储,而系统表mysql.gtid_executed属于持久化存储。

    GTID比传统复制的优势

    1. 更简单的搭建主从复制
    2. 更简单的实现failover (主从切换),不用以前那样一步一步的去找log_filelog_pos
    3. GTID是连续的没有空洞的,保证数据的一致性,零丢失。
    4. 复制集群有一个统一的方式识别复制位置,给集群管理带来了便利

    GTID的限制

    1. 在一个事务里面混合使用引擎如Innodb,myisam,造成多个GTIDS
    2. CREATE TABLE…..SELECT 不能使用
    3. CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE 不能在事务内使用

    主从复制流程图


    GTID生命周期

    1. 当一个事务在一个主库上被执行和提交,那么这个事务就会被分配一个和该主库uuid相关联的gtid,这个gtid被写入到主库的binlog文件中。
    2. 当这个binlog文件达到最大值发生轮转,或者MySQL Server关闭时,上一个binlog文件中的事务GTID将会被写入到mysql.gtid_executed表中。
    3. 事务提交时,该事务的gtid会很快的添加到系统变量@@GLOBAL.gtid_executed,但是系统表 mysql.gtid_executed 则不会,应为有部分gtid还在binlog中,需要等到binlog轮转或者mysqlServer关闭时才会写入到mysql。gtid_executed表中.
    4. 主库上的binlog通过主从复制协议传送到从库,并写入到从库的relay log(中继日志), 从库读取relay log中的gtid和对应的事务信息,把gtid_next设置为该gtid值,使得从库使用该gtid值应用其对应的事务
    5. 如果多个线程并发应用同一个事务,比如多个线程设置gtid_next为同一个值,MySQL Server 只允许其中一个线程执行,gtid_owned系统变量记录着谁拥有该GTID.

    传统更换GTID复制模式

    1. 配置GTID
    2. 所有服务器设置global.read_only
    3. CREATE TEMPORARY TABLE und DROP TEMPORARY TABLE können nicht innerhalb einer Transaktion verwendet werden
    🎜Master-Slave-Replikationsfluss Diagramm 🎜🎜🎜🎜🎜🎜🎜🎜🎜GTID-Lebenszyklus🎜🎜
      🎜Wenn eine Transaktion auf einem Main erfolgt Wenn die Bibliothek ausgeführt und festgeschrieben wird, wird dieser Transaktion eine GTID zugewiesen, die mit der UUID der Hauptbibliothek verknüpft ist, und diese GTID wird in die Binlog-Datei der Hauptbibliothek geschrieben. 🎜🎜Wenn diese Binlog-Datei die maximale Größe erreicht und rotiert wird oder MySQL Server heruntergefahren wird, wird die Transaktions-GTID in der vorherigen Binlog-Datei in die Tabelle mysql.gtid_executed geschrieben. 🎜🎜Wenn eine Transaktion übermittelt wird, wird die GTID der Transaktion schnell zur Systemvariablen @@GLOBAL.gtid_executed hinzugefügt, die Systemtabelle mysql.gtid_executed jedoch nicht, da noch einige GTID vorhanden sind Beim binlog müssen Sie warten, bis die binlog-Rotation oder der mysqlServer heruntergefahren ist, bevor Sie in mysql schreiben. gtid_executed-Tabelle 🎜🎜Das Binlog der Hauptbibliothek wird über das Master-Slave-Replikationsprotokoll an die Slave-Bibliothek übertragen und in das Relay-Protokoll der Slave-Bibliothek (Relay-Log) und des Slaves geschrieben Die Bibliothek liest die GTID des Relay-Protokolls und die entsprechenden Transaktionsinformationen und setzt gtid_next auf den GTID-Wert, sodass die Slave-Bibliothek den GTID-Wert verwendet, um ihre entsprechende Transaktion anzuwenden🎜🎜Wenn mehrere Threads gleichzeitig dieselbe Transaktion anwenden, B. mehrere Threads, die gtid_next auf denselben Wert setzen. Die Systemvariable gtid_owned zeichnet auf, wer die GTID besitzt.🎜🎜🎜🎜🎜🎜Traditioneller Ersatz-GTID-Replikationsmodus 🎜🎜
        🎜GTID konfigurieren🎜🎜Stellen Sie den Parameter global.read_only auf allen Servern ein und warten Sie, bis der Master-Slave-Server synchronisiert ist;
        mysql> SET @@global.read_only = ON;
        🎜🎜Starten Sie den Master-Slave-Server nacheinander neu; 🎜🎜Verwenden Sie Change Master, um die Master-Slave-Konfiguration zu aktualisieren.
        mysql> CHANGE MASTER TO
        MASTER_HOST = host,
        MASTER_PORT = port,
        MASTER_USER = user,
        MASTER_PASSWORD = password,
        MASTER_AUTO_POSITION = 1;
        5. Überprüfen Sie die Master-Slave-Replikation

Das obige ist der detaillierte Inhalt vonVerstehen Sie den GTID-basierten Replikationsmodus von MySQL. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Dieser Artikel ist reproduziert unter:learnku.com. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen