MySQL-Beispielcode für bidirektionales Hot-Backup auf zwei Maschinen

1. Beschreibung

MySQL verwendet derzeit nicht die Dual-Machine-Hot-Backup-Strategie. Aufgrund der hohen Verfügbarkeit des Systems ist jedoch nach der Implementierung ein Dual-Machine-Hot-Backup erforderlich Daten-Hot-Backup. Es kann die Trennung von Lesen und Schreiben weiter realisieren und die Leistung des Datenzugriffs in Anwendungen verbessern. Warum habe ich derzeit nicht ein paar inaktive Computer, also habe ich damit begonnen?
Maschine A: (10.0.9.199), Maschine B: (10.0.9.1)

2. Implementierungsschritte

Da es sich zunächst um ein Zwei-Wege-Hot-Backup handelt Richten Sie eine Datenbank (db1) als Master und die Backup-Datenbank (db2) auf B als Slave ein. Dies ist eine Richtung. Konfigurieren Sie dann db2 als Master und db1 als Slave (1) Ändern Sie die Konfigurationsdatei my.cnf von A und B und fügen Sie den folgenden Inhalt hinzu

(2) Starten Sie MySQL auf A und B neu und erstellen Sie einen MySQL-Benutzer auf den beiden Maschinen zur Synchronisierung

log-bin=mysql-0-bin     #设定生成log文件名         #机器A配置
server-id=9199		# 主ID，与从ID不能相同

binlog-do-db=webgps4_0   #设置同步数据库名
binlog-ignore-db=mysql   #避免同步mysql用户配置
replicate-do-db=webgps4_0    // 两处webgps4_0是一致的
replicate-ignore-db=mysql

log-bin=mysql-1-bin     #设定生成log文件名          #以下为机器B配置
server-id=9001		# 主ID，与从ID不能相同

binlog-do-db=webgps4_0   #设置同步数据库名
binlog-ignore-db=mysql   #避免同步mysql用户配置
replicate-do-db=webgps4_0    // 两处webgps4_0是一致的
replicate-ignore-db=mysql

(3) Benutzerberechtigungen festlegen

 CREATE USER 'test'@'10.0.9.1' IDENTIFIED BY '123456';   
 //test为账号，10.0.9.1表示账号只能从指定id也就是B机器访问，最后123456是密码，机器A上执行
 CREATE USER 'test'@'10.0.9.199' IDENTIFIED BY '123456';   
 //机器B上执行

(4) Legen Sie die Master-Slave-Beziehung zwischen A und B und die Master-Slave-Beziehung zwischen B und A fest

grant replication slave,reload,create user, super on *.* to 'test'@'10.0.9.1' IDENTIFIED BY '123456';  //  机器A上执行
grant replication slave,reload,create user, super on *.* to 'test'@'10.0.9.199' IDENTIFIED BY '123456';  // 机器B上执行

Da es sich um eine bidirektionale Sicherung handelt, werden viele Vorgänge in der Konfiguration wiederholt, aber die Master-Slave-Reihenfolge ist inkonsistent, einer ist vorwärts und der andere ist umgekehrt. Hier wurde eine bidirektionale Sicherung implementiert. Jetzt können Sie einige Vorgänge in den beiden Bibliotheken durchführen, um den Effekt zu sehen.

mysql> change master to
    -> master_host = '10.0.9.1',
    -> master_port = 3306,
    -> master_user = 'test',
    -> master_password = '123456';  //机器A上执行，A为slave
mysql> change master to
    -> master_host = '10.0.9.199',
    -> master_port = 3306,
    -> master_user = 'test',
    -> master_password = '123456'; //机器B上执行，B为slave

Derzeit sind nur db1 und sein bidirektionaler Backup-Master-Slave konfiguriert, was bedeutet, dass nur ein Schema als Hot-Standby garantiert ist. In tatsächlichen Anwendungen werden häufig mehrere Schemata verwendet, um den Druck auf einen einzelnen Server zu verringern, z Das Schema von Maschine A in diesem Artikel ist auf B und das Backup von B auf C. Einige Backups sind in einem Ring konfiguriert. Es ist zu beachten, dass bei der Konfiguration von Hot Standby auf Maschine B die Konfiguration von Master oder Slave nicht in der vorherigen Datenbankinstanz durchgeführt werden kann. Eine wiederholte Konfiguration auf derselben Portnummer überschreibt die vorherige. Daher müssen Sie mysqld_multi verwenden, um mehrere Instanzen zu starten Auf einer einzelnen MySQL-Instanz erfolgt die Konfiguration in einer anderen MySQL-Instanz. Informationen zur Konfiguration von mysqld_multi finden Sie im Blogbeitrag: MySQL – Starten mehrerer MySQL-Instanzen auf einer einzelnen Maschine unter Linux (mysqld_multi )

3. Anweisungen zur bidirektionalen Sicherung

Die Hauptbibliothek muss das Bin-Protokoll aktivieren und die Hauptbibliothek und die Slave-Bibliothek müssen eindeutige Server-IDs haben

• Die Slave-Bibliothek muss genau wissen, von welcher Offset-Position welcher Bin-Protokolldatei in der Hauptbibliothek aus mit dem Kopieren begonnen werden soll.

• Die Slave-Bibliothek kann nur aus der Hauptbibliothek kopieren Die angegebene Datenbank oder einige Datentabellen der Datenbank

• Die Datenbanknamen der Master-Datenbank und der Slave-Datenbank können unterschiedlich sein, es wird jedoch dennoch empfohlen um denselben Namen zu verwenden

• Die MySQL-Versionen der Master-Datenbank und der Slave-Datenbank müssen konsistent sein

• Ab MySQL3.23.15, MySQL unterstützt die asynchrone Replikation in eine Richtung. Mit anderen Worten: Ein MySQL-Server fungiert als Master (Hauptdatenbank), ein oder mehrere MySQL-Server fungieren als Slaves (Slave-Datenbanken) und Daten werden asynchron vom Master auf die Slaves repliziert. Beachten Sie, dass diese Replikation asynchron ist und sich von der synchronen Replikationsimplementierung von MySQL unterscheidet (diese Implementierung wird MySQL Cluster genannt).
Wenn die Hauptbibliothek aktualisiert wird, schreibt die Hauptbibliothek die SQL des Aktualisierungsvorgangs in das Binärprotokoll (Bin-Protokoll) und verwaltet einen Index der Binärprotokolldatei, um die Rotation der Protokolldatei zu erleichtern (Rotieren). Wenn die Slave-Bibliothek mit der asynchronen Replikation beginnt, startet die Slave-Bibliothek zwei E/A-Threads, von denen einer eine Verbindung zur Hauptbibliothek herstellt. Dadurch muss die Hauptbibliothek die Änderungen im Binärprotokoll an die Slave-Bibliothek übertragen und das zurückgegebene Protokoll schreiben lokal. Ein anderer Thread ist dafür verantwortlich, das lokal geschriebene Binärprotokoll zu lesen und es lokal auszuführen, um diese Änderung widerzuspiegeln. Die ältere Version ermöglichte beim Kopieren nur einen I/O-Thread, um diese beiden Teile der Funktion zu implementieren.

Das obige ist der detaillierte Inhalt vonMySQL-Beispielcode für bidirektionales Hot-Backup auf zwei Maschinen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!