Vollständige Beherrschung der MySQL-Replikationsarchitektur

Dieser Artikel vermittelt Ihnen relevantes Wissen über MySQL und stellt hauptsächlich verwandte Themen zur Replikationsarchitektur vor, einschließlich Master-Slave-Replikationsarchitektur, Kaskaden-Replikationsarchitektur, Multi-Master-Slave-Replikationsarchitektur usw. Ich hoffe, es hilft allen.

Empfohlenes Lernen: MySQL-Video-Tutorial

Replikationsarchitektur mit einem Master und mehreren Slaves

In tatsächlichen Anwendungsszenarien handelt es sich bei mehr als 90 % der MySQL-Replikation um ein Architekturmuster, bei dem ein Master auf einen oder mehrere Slaves repliziert .

In einem Szenario, in dem der Leseanforderungsdruck der Hauptbibliothek sehr hoch ist, können Sie die Ein-Master-Mehrfach-Slave-Replikationsarchitektur konfigurieren, um eine Lese- und Schreibtrennung zu erreichen und eine große Anzahl von Leseanforderungen zu verteilen, die keinen besonders hohen Realwert erfordern -Zeitleistung für die Datenbank durch Lastausgleich bei mehreren Slave-Bibliotheken (Leseanforderungen mit hohen Echtzeitanforderungen können aus der Master-Bibliothek gelesen werden), um den Lesedruck auf die Master-Bibliothek zu reduzieren, wie in der folgenden Abbildung dargestellt.

Nachteile:

• Der Master kann nicht heruntergefahren werden.
• Es kommt zu Verzögerungen, wenn zu viele Slaves vorhanden sind zur routinemäßigen Wartung heruntergefahren werden muss, muss ein Slave zum Master umgewandelt werden. Wählen Sie Welches ist ein Problem?

Wenn ein Slave zum Master wird, kommt es zu Inkonsistenzen zwischen den Daten des aktuellen Masters und des vorherigen Masters, und der vorherige Master hat die Binlog-Datei und den POS-Standort des aktuellen Masterknotens nicht gespeichert.

Multi-Master-Replikationsarchitektur

Die Multi-Master-Replikationsarchitektur löst das Single-Point-of-Failure-Problem des Masters in der Single-Master-Multi-Slave-Replikationsarchitektur.

Sie können ein Drittanbieter-Tool wie Keepalived verwenden, um eine IP-Drift einfach zu erreichen, sodass Ausfallzeiten und Wartungsarbeiten des Masters den Schreibvorgang nicht beeinträchtigen.

Kaskadierende Replikationsarchitektur

Ein Master und viele Slaves, der E/A-Druck und der Netzwerkdruck der Hauptbibliothek nehmen mit der Anzahl der Slave-Bibliotheken zu, da jede Slave-Bibliothek über ein unabhängiges BINLOG verfügt Zum Senden von Ereignissen wird ein Dump-Thread verwendet, und die „Kaskaden-Replikationsarchitektur“ löst den zusätzlichen E/A- und Netzwerkdruck auf die Hauptbibliothek im Master-Multi-Slave-Szenario.

Wie im Bild unten gezeigt.

Im Vergleich zur Ein-Master-Mehrfach-Slave-Architektur kopiert die Kaskadenreplikation nur Daten aus der Master-Datenbank in eine kleine Anzahl von Slave-Datenbanken, und andere Slave-Datenbanken kopieren dann Daten aus dieser kleinen Anzahl von Slave-Datenbanken Erleichterung der Arbeitsbelastung der Master-Datenbank.

Natürlich gibt es auch Nachteile: Die traditionelle Replikation von MySQL ist asynchron. Im Kaskadenreplikationsszenario müssen die Daten in der Master-Datenbank zweimal repliziert werden, bevor sie andere Slave-Datenbanken erreichen Ein-Master- und mehrere-Slave-Replikationsszenario. Die Kopie ist sogar noch größer.

Sie können die Latenz der Kaskadenreplikation reduzieren, indem Sie die Tabellen-Engine auf dem sekundären Slave als BLACKHOLE auswählen. Wie der Name schon sagt, handelt es sich bei der BLACKHOLE-Engine um eine „Black-Hole“-Engine. Die in die BLACKHOLE-Tabelle geschriebenen Daten werden nicht auf die Festplatte geschrieben. Die BLACKHOLE-Tabelle ist immer eine leere Tabelle, die nur Ereignisse aufzeichnet im BINLOG.

Das Folgende demonstriert die BLACKHOLE-Engine:

mysql> CREATE TABLE `user` (
    -> `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY,
    -> `name` varchar(255) NOT NULL DEFAULT '',
    -> `age` tinyint unsigned NOT NULL DEFAULT 0
    -> )ENGINE=BLACKHOLE charset=utf8mb4;Query OK, 0 rows affected (0.00 sec)mysql> INSERT INTO `user` (`name`,`age`) values("itbsl", "26");Query OK, 1 row affected (0.00 sec)mysql> select * from user;Empty set (0.00 sec)

Sie können sehen, dass in der Benutzertabelle keine Daten vorhanden sind, deren Speicher-Engine BLACKHOLE ist.

Kombinierte Multi-Master- und Kaskaden-Replikationsarchitektur

Kombiniert Multi-Master- und Kaskaden-Replikationsarchitektur, die das Problem des Single-Point-Masters und das Problem der Slave-Kaskadenverzögerung löst.

Aufbau einer Multi-Master-Replikationsarchitektur

Hostplanung:

Master1: Docker, Port 3314

Master2: Docker, Port 3315

• Master1-Konfiguration
• Konfigurationsdatei. my.cn f:

$ cat /home/mysql/docker-data/3315/conf/my.cnf
[mysqld]
character_set_server=utf8
init_connect='SET NAMES utf8'

symbolic-links=0

lower_case_table_names=1
server-id=1403314
log-bin=mysql-bin
binlog-format=ROW
auto_increment_increment=2 # 几个主库，这里就配几
auto_increment_offset=1 # 每个主库的偏移量需要不一致
gtid_mode=ON
enforce-gtid-consistency=true
binlog-do-db=order      # 要同步的数据库

Starten Sie Docker:

$ docker run --name mysql3314 -p 3314:3306 --privileged=true -ti -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=order -e MYSQL_USER=user -e MYSQL_PASSWORD=pass -v /home/mysql/docker-data/3314/conf:/etc/mysql/conf.d -v /home/mysql/docker-data/3314/data/:/var/lib/mysql -v /home/mysql/docker-data/3314/logs/:/var/log/mysql -d mysql:5.7

Fügen Sie einen Benutzer für die Replikation hinzu und autorisieren Sie:

mysql> GRANT REPLICATION SLAVE,FILE,REPLICATION CLIENT ON *.* TO 'repluser'@'%' IDENTIFIED BY '123456';
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)

Starten Sie die Synchronisierung von Master1 (der Benutzer kommt hier von Master2):

mysql> change master to master_host='172.23.252.98',master_port=3315,master_user='repluser',master_password='123456',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.03 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

Konfiguration von Master2

Die Konfiguration von Master2 ähnelt der von Master1.

Der Hauptunterschied besteht darin, dass es in my.cnf ein Attribut gibt, das inkonsistent sein muss:

auto_increment_offset=2 # 每个主库的偏移量需要不一致

Test:

Erstellen Sie eine Tabelle in Master2 und fügen Sie Daten hinzu:

mysql> create table t_order(id int primary key auto_increment, name varchar(20));
Query OK, 0 rows affected (0.01 sec)

mysql> insert into t_order(name) values("A");
Query OK, 1 row affected (0.01 sec)

mysql> insert into t_order(name) values("B");
Query OK, 1 row affected (0.00 sec)

mysql> select * from t_order;
+----+------+
| id | name |
+----+------+
|  2 | A    |
|  4 | B    |
+----+------+
2 rows in set (0.00 sec)

Sie finden die Schrittgröße von id in Master2 ist 2 und beginnt mit einer Erhöhung um 2.

Fragen Sie dann die Daten in Master1 ab und fügen Sie hinzu:

mysql> select * from t_order;
+----+------+
| id | name |
+----+------+
|  2 | A    |
|  4 | B    |
+----+------+
2 rows in set (0.00 sec)

mysql> insert into t_order(name) values("E");
Query OK, 1 row affected (0.00 sec)

mysql> select * from t_order;
+----+------+
| id | name |
+----+------+
|  2 | A    |
|  4 | B    |
|  5 | E    |
+----+------+
3 rows in set (0.00 sec)

Sie können feststellen, dass die Schrittgröße der ID in Master1 2 beträgt und von 1 an zunimmt. Fragen Sie dann die Daten in Master2 ab und Sie können die Daten mit finden ID 5 gibt die Master-Master-Replikationskonfiguration an. Kein Problem.

Warum sind die Offsets des ID-Inkrements in den beiden Mastern inkonsistent? Wenn die beiden Master gleichzeitig die Einfügeanforderung empfangen, kann sichergestellt werden, dass die ID nicht in Konflikt gerät. Dies kann tatsächlich nur sicherstellen, dass die eingefügten Daten nicht in Konflikt geraten, kann jedoch nicht die durch Löschen und Ändern verursachte Dateninkonsistenz garantieren.

In tatsächlichen Anwendungsszenarien kann dem Client also nur ein Master zur Verfügung gestellt werden, um die Datenkonsistenz sicherzustellen.

MySQL高可用的搭建

这里借助keepalived来对上面的多主复制架构改造来实现MySQL的高可用。

keepalived的安装：

$ sudo apt-get install -y keepalived

keepalived.conf

$ cat /etc/keepalived/keepalived3314.conf! Configuration File for keepalived#简单的头部，这里主要可以做邮件通知报警等的设置，此处就暂不配置了；global_defs {
        #notificationd LVS_DEVEL}#预先定义一个脚本，方便后面调用，也可以定义多个，方便选择；vrrp_script chk_haproxy {
    script "/etc/keepalived/chkmysql.sh"  #具体脚本路径
    interval 2  #脚本循环运行间隔}#VRRP虚拟路由冗余协议配置vrrp_instance VI_1 {   #VI_1 是自定义的名称；
    state BACKUP    #MASTER表示是一台主设备，BACKUP表示为备用设备【我们这里因为设置为开启不抢占，所以都设置为备用】
    nopreempt      #开启不抢占
    interface eth0   #指定VIP需要绑定的物理网卡
    virtual_router_id 11   #VRID虚拟路由标识，也叫做分组名称，该组内的设备需要相同
    priority 130   #定义这台设备的优先级 1-254；开启了不抢占，所以此处优先级必须高于另一台

    advert_int 1   #生存检测时的组播信息发送间隔，组内一致
    authentication {    #设置验证信息，组内一致
        auth_type PASS   #有PASS 和 AH 两种，常用 PASS
        auth_pass asd    #密码
    }
    virtual_ipaddress {
        172.23.252.200    #指定VIP地址，组内一致，可以设置多个IP
    }
    track_script {    #使用在这个域中使用预先定义的脚本，上面定义的
        chk_haproxy    }

    #notify_backup "/etc/init.d/haproxy restart"   #表示当切换到backup状态时,要执行的脚本
    #notify_fault "/etc/init.d/haproxy stop"     #故障时执行的脚本}

/etc/keepalived/chkmysql.sh

$ cat /etc/keepalived/chkmysql.s.sh#!/bin/bashmysql -uroot -proot -P 3314 -e "show status;" > /dev/null 2>&1if [ $? == 0 ];then
        echo "$host mysql login successfully"
        exit 0else
        echo "$host login failed"
        killall keepalived        exit 2fi

推荐学习：mysql视频教程

Das obige ist der detaillierte Inhalt vonVollständige Beherrschung der MySQL-Replikationsarchitektur. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!