Detaillierte Erläuterung des Beispielcode-Sharings der Master-Slave-Replikation von MySQL5.6 unter Centos7

In diesem Artikel wird hauptsächlich die detaillierte Erklärung der Master-Slave-Replikation von MySQL5.6 unter Centos7 vorgestellt. Der Herausgeber findet es ziemlich gut, daher werde ich es jetzt mit Ihnen teilen und als Referenz geben. Folgen wir dem Editor und werfen wir einen Blick darauf.

1. Einführung in die MySQL-Master-Slave-Replikation

Die Master-Slave-Replikation von MySQL ist nicht aktiviert Die Datenbankfestplatte Die Datei wird direkt kopiert, aber zur Synchronisierung über das logische Binlog-Protokoll auf den lokalen Server kopiert. Anschließend liest der lokale Thread die SQL-Anweisung im Protokoll und wendet sie erneut auf die MySQL-Datenbank .

MySQL-Datenbank unterstützt die Replikation in verschiedenen Geschäftsszenarien wie unidirektional, bidirektional, Kettenkaskade und Ring. Ein Server fungiert als Hauptserver-Master und empfängt Aktualisierungen von Benutzern, während ein oder mehrere andere Server fungieren als Der Slave-Server empfängt den Protokollinhalt aus der Binlog-Datei des Master-Servers, analysiert die SQL und aktualisiert sie auf dem Slave-Server.

Ein Master und ein Slave (A -> B, A ist der Master, B ist der Slave)

Ein Master und mehrere Slaves (A -> B, A -> C, A ist der Slave-Master, B und C sind Slaves)

Bidirektionale Dual-Master-Synchronisation (A -> B, B -> A, A und B sind beide Master und sichern sich gegenseitig)

Lineare Kaskade (A -> B -> C, A und B sind Master und Slaves und C ist Slave)

Ringkaskade (A -> B -> C -> ;A, A, B und C sind beide Master und jeder Knoten kann Daten schreiben)

2. Die Lösung zur Realisierung der Trennung von MySQL-Master-Slave-Lesen und -Schreiben

1. Erzielen Sie eine Lese- und Schreibtrennung durch Programme (

Urteilsaussage Schlüsselwort zur Verbindung der Master-Slave-Datenbank)

2. Erzielen Sie eine Lese- und Schreibtrennung durch Offenheit Quellsoftware (MySQL-Proxy, Amoeba, Stable Die Leistung und Funktionen sind durchschnittlich, nicht für den Produktionseinsatz empfohlen)

3. Unabhängige Entwicklung von DAL-Layer-Software

3 . Einführung in das Prinzip der MySQL-Master-Slave-Replikation

MySQL-Master-Slave-Replikation ist ein asynchroner Replikationsprozess, der eine Master-Bibliothek in eine Slave-Bibliothek kopiert zwischen Master und Slave wird durch drei Threads vervollständigt. Der SQL-Thread und der E/A-Thread befinden sich auf der Slave-Seite und der andere E/A-Thread befindet sich auf der Master-Seite.

Replikationsprinzip und -prozess

1. Führen Sie den Start-Slave-Befehl auf dem Slave aus, schalten Sie den Master-Slave-Replikationsschalter ein und starten Sie die Master-Slave-Replikation.

2. Der E/A-Thread des Slaves fordert den Master über den autorisierten Replikationsbenutzer auf dem Master an und fordert den angegebenen Speicherort des angegebenen Binlog-Protokolls an.

3. Nachdem der Master die Anfrage vom E/A-Thread des Slaves erhalten hat, liest sein eigener E/A-Thread, der für das Kopieren verantwortlich ist, die Protokollinformationen nach der angegebenen Position des angegebenen Binlog-Protokolls stapelweise Die Anforderungsinformationen des Slaves werden dann an den E/A-Thread des Slaves zurückgegeben. Zusätzlich zum Binlog-Protokoll enthalten die zurückgegebenen Informationen auch den neuen Binlog-Dateinamen des Masters und die nächste angegebene Aktualisierungsposition im neuen Binlog.

4. Der Slave erhält den Binlog-Protokollinhalt, der vom E/A-Thread auf dem Master gesendet wird. Nach der Protokolldatei und dem Standortpunkt wird der Binlog-Inhalt an das Ende des eigenen Relay-Protokolls geschrieben (Relay-Protokoll)-Datei nacheinander und zeichnen Sie den Namen und den Speicherort der neuen Binlog-Datei in der Master-Info-Datei auf, sodass der Master beim nächsten Lesen des neuen Binlog-Protokolls angewiesen werden kann, vom neuen Speicherort zu lesen des neuen Binlogs.

5. Der SQL-Thread des Slaves erkennt den neu hinzugefügten Protokollinhalt des E/A-Threads im lokalen Relay-Protokoll in Echtzeit und analysiert den Inhalt in der Relay-Protokolldatei zeitnah in SQL-Anweisungen. und analysieren Sie die SQL-Anweisungen in der Reihenfolge ihrer Positionen. Führen Sie diese SQL-Anweisungen aus. Relay-log.info zeichnet den Dateinamen und den Speicherort des aktuellen Anwendungs-Relay-Protokolls auf.

4. MySQL-Master-Slave-Replikationsvorgang

Ich habe hier mehrere Instanzen von MySQL auf einer einzelnen Maschine, 3306, 3308 , 3309

Die Master-Datenbank ist 3306 und die Slave-Datenbank ist 3308,3309

(1), in der Master-Datenbank

1. Legen Sie den Server-ID-Wert fest und öffnen Sie die Binlog-Funktion

> vi /etc/my.cnf

 [mysqld]
 #用于同步的每台机器server-id都不能相同

server-id = 10

log-bin = /data/mysql56/data/mysql-bin

2. Starten Sie die Hauptdatenbank neu

> service mysqld restart

3 -id

> mysql -uroot -p

> show variables like 'server_id';

4. Erstellen Sie ein Konto in der Bibliothek zum Kopieren aus der Bibliothek

> grant replication slave on *.* to "rep"@"%" identified by "123456";

> flush privileges;

> select user,host from mysql.user;

> show grants for rep@"%";

5. Schreibgeschützte Sperrtabelle der Hauptbibliotheksdatenbank (nicht schließen). das aktuelle Fenster)

> flush table with read lock;

Hauptbibliothek anzeigen

Status

> show master status;

6. Sichern Sie alle Datendateien in der Hauptdatenbank

> mysqldump -uroot -p -A -B | gzip > /data/mysql_bak.$(date +%F).sql.gz

7. Entsperren Sie nach dem Sichern der Hauptdatenbankdaten

> unlock tables;

8. Migrieren Sie die aus der Hauptbibliothek exportierten Daten in die Slave-Bibliothek

(2) auf dem Slave Bibliothek

1. Legen Sie den Server-ID-Wert fest und deaktivieren Sie die Binlog-Funktion

①Es gibt zwei Situationen, in denen Binlog in der Mitte geöffnet werden muss

②B der Kaskadensynchronisation A->B->C muss binlog öffnen

③Tun Sie es von der Slave-Bibliothek aus. Die Datenbanksicherung erfordert eine vollständige Sicherung und das Binlog-Protokoll muss eine vollständige Sicherung sein.

> vi /mysql-instance/3308/my.cnf 

[mysqld]

server-id = 11

relay-log = /mysql-instance/3308/relay-bin

relay-log-info-file = /mysql-instance/3308/relay-log.info

2. Starten Sie die Slave-Datenbank neu

> /mysql-instance/3308/mysql restart

3. Melden Sie sich bei der Slave-Datenbank an, um die Parameter zu überprüfen

> mysql -uroot -p -S /mysql-instance/3308/mysql.sock

> show variables like 'log_bin';

> show variables like 'server_id';

von mysqldump aus der Hauptdatenbank exportiert nach Aus der Datenbank

> gzip -d /data/mysql_bak.2017-01-15.sql.gz

Stellen Sie die Master-Datenbankdaten in der Slave-Datenbank wieder her

> mysql -uroot -p -S /mysql-instance/3308/mysql.sock < /data/mysql_bak.2017-01-15.sql

5. Melden Sie sich bei der Slave-Datenbank an und konfigurieren Sie die Replikation Parameter

CHANGE MASTER TO

MASTER_HOST='127.0.0.1',

MASTER_PORT=3306,

MASTER_USER='rep',

MASTER_PASSWORD='123456',

MASTER_LOG_FILE='mysql-bin.000001',

MASTER_LOG_POS=396;

Achten Sie auf MASTER_LOG_FILE oben und MASTER_LOG_POS. Dies sind die Informationen, die mit „Show Master Status“ in der Hauptbibliothek angezeigt werden können.

Sehen Sie sich die Datei „master.info“ an

> cat /mysql-instance/3308/data/master.info

6. Starten Sie den Slave-Datenbanksynchronisierungsschalter und testen Sie die Master-Slave-Replikation

> mysql -uroot -p -S /mysql-instance/3308/mysql.sock -e "start slave;"

> mysql -uroot -p -S /mysql-instance/3308/mysql.sock -e "show slave status\G;"

> mysql -uroot -p -S /mysql-instance/3308/mysql.sock -e "show slave status\G" | egrep "IO_Running|SQL_Running|_Behind_Master"

Testen Sie den Master -Slave-Replikation

> mysql -uroot -p -e "create database wohehe;"

> mysql -uroot -p -S /mysql-instance/3308/mysql.sock -e "show databases;"

五、mysql主从复制线程状态说明及用途

1、主库线程的同步状态

> show processlist\G; 


*************************** 1. row ***************************

   Id: 5

  User: rep

  Host: localhost:47605

   db: NULL

Command: Binlog Dump

  Time: 4728

 State: Master has sent all binlog to slave; waiting for binlog to be updated

  Info: NULL

说明主库线程已从binlog读取更新，发送到了从库，线程处理空闲状态，等待binlog的事件更新。

2、从库线程的同频状态

> show processlist\G; 

*************************** 2. row ***************************

   Id: 6

  User: system user

  Host:

   db: NULL

Command: Connect

  Time: 5305

 State: Slave has read all relay log; waiting for the slave I/O thread to update it

  Info: NULL

说明从库已读取所有中继日志，等待从库I/O线程的更新。

六、主从复制故障

如果我在从库上创建了一个库，然后去主库创建同名的库，那么这就会冲突了。

> show slave status; 

Slave_IO_Running: Yes

Slave_SQL_Running: No

Seconds_Behind_Master: NULL

Last_Error: Error 'Can't create database 'xxxxx'; database exists' on query. Default database: 'xxxxx'. Query: 'create database xxxxx'

对于该冲突解决方法

方法一

> stop slave;

#将同步指针移动下一个，如果多次不同步，可重复操作

> set global sql_slave_skip_counter = 1;

> start slave;

方法二

> vi /mysql-instance/3308/my.cnf 

#把可以忽略的错误号事先在配置文件中配置

slave-skip-errors = 1002,1007,1032

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung des Beispielcode-Sharings der Master-Slave-Replikation von MySQL5.6 unter Centos7. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!