mysql GTID主從複製故障後不停機恢復同步流程

時間 2020-11-30

標籤 node mysql sql 數據庫 vim 安全 bash 服務器 session 架構欄目 MySQL 简体版

原文原文鏈接

GTID實現主從複製數據同步node

GTID是一個基於原始mysql服務器生成的一個已經被成功執行的全局事務ID，它由服務器ID以及事務ID組成，這個全局事務ID不只僅在原始服務器上惟一，在全部主從關係的mysql服務器上也是惟一的。正式由於這樣一個特性使得mysql主從複製變得更加簡單，以及數據庫一致性更可靠。mysql

介紹sql

GTID的概念數據庫

全局事務標識：global transaction identifiers
GTID是一個事務一一對應，而且全局惟一ID
一個GTID在一個服務器上只執行一次，避免重複執行致使數據混亂不一致
再也不使用傳統的MASTER_LOG_FILE+MASTER_LOG_POS開啓複製，而是採用MASTER_AUTO_POSTION=1的方式開啓複製。
從MYSQL-5.6.5及後續版本開始支持

GTID的組成vim

GTID = server_uuid:transaction_id安全

server_uuid：mysql服務器的惟一標識，查看方法mysql客戶端內：show variables like '%server_uuid%';bash

transaction_id：此id是當前服務器中提交事務的一個序列號，從1開始自增加，一個數值對應一個事務服務器

GTID號示例：c9fba9e2-db3b-11eb-81d4-000c298d8da1:1-5session

GTID的優點架構

實現主從更簡單，不用像之前同樣尋找log_file和log_pos
比傳統的主從更加安全
GTID是連續沒有空洞的，保證數據一致性，零丟失。

GTID工做原理

master更新數據時，會在事務前產生GTID，一同記錄到binlog日誌中
slave端的I/O線程將變動的binlog，寫入到本地的relay log中
SQL線程從relay log中獲取GTID，而後對比slave端的binlog是否有記錄（因此MySQL5.6 slave端必須開啓binlog）
若是有記錄，說明該GTID的事務已經執行，slave會忽略
若是沒有記錄，slave就會從relay log中執行該GTID的事務，並記錄到binlog
在解析過程當中會判斷是否有主鍵，若是沒有就用二級索引，若是沒有就用所有掃描

開始配置GTID複製

主：192.168.152.253 Centos7

從：192.168.152.252 Centos8

測試數據庫：vfan

測試表：student

一、修改mysql服務配置文件，添加如下參數，隨後重啓：

server-id=100    #server id log-bin=/var/lib/mysql/mysql-bin #開啓binlog並指定存儲位置 expire_logs_days=10 #日誌保存時間爲10天 gtid_mode=on #gtid模塊開關 enforce_gtid_consistency=on #啓動GTID強一致性，開啓gtid模塊必須開啓此功能。 binlog_format=row #bin_log日誌格式，共有三種STATEMENT、ROW、MIXED；默認爲STATEMENT skip_slave_start=1  #防止複製隨着mysql啓動而自動啓動

主服務器和從服務器的配置一致便可，server-id更改一下

二、在主服務器中建立從服務器鏈接的用戶

CREATE USER 'copy'@'192.168.152.252' IDENTIFIED BY 'copy'; GRANT REPLICATION SLAVE ON *.* TO 'copy'@'192.168.152.252'; flush privileges;

建立完畢記得要測試下slave機是否能登陸成功

三、使用mysqldump使兩數據庫數據同步

主mysql執行： mysqldump -uroot -proot1 vfan > dump2.sql scp dump2.sql 192.168.152.252:/data/ 從mysql執行： mysql> source /data/dump2.sql

當前主、從服務器數據內容一致，都是如下數據：

mysql> select * from student; +----+------+-----+
| id | name | age |
+----+------+-----+
|  1 | Tony |  18 |
|  2 | Any  |  17 |
|  3 | Goy  |  20 |
|  4 | Baly |  18 |
|  5 | Heg  |  19 |
|  6 | hhh  | 100 |
|  7 | lll  |  99 |
+----+------+-----+
7 rows in set (0.01 sec)

四、開啓主從複製

mysql> CHANGE MASTER TO MASTER_HOST='192.168.152.253',MASTER_USER='copy',MASTER_PASSWORD='copy',MASTER_PORT=3306,MASTER_AUTO_POSITION=1; Query OK, 0 rows affected, 2 warnings (0.04 sec) mysql> start slave; Query OK, 0 rows affected (0.01 sec) ## 查看slave狀態 mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.152.253 Master_User: copy Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000014 Read_Master_Log_Pos: 897 Relay_Log_File: kubenode2-relay-bin.000002 Relay_Log_Pos: 416 Relay_Master_Log_File: mysql-bin.000014 Slave_IO_Running: Yes Slave_SQL_Running: Yes

五、檢查是否同步

主服務器中插入數據： mysql> INSERT INTO student(name,age) VALUES('gogoo',50),('zhazha',25); Query OK, 2 rows affected (0.03 sec) Records: 2  Duplicates: 0  Warnings: 0 從服務器中讀取： mysql> select * from student; +----+--------+-----+
| id | name   | age |
+----+--------+-----+
|  1 | Tony   |  18 |
|  2 | Any    |  17 |
|  3 | Goy    |  20 |
|  4 | Baly   |  18 |
|  5 | Heg    |  19 |
|  6 | hhh    | 100 |
|  7 | lll    |  99 |
|  8 | gogoo  |  50 |
|  9 | zhazha |  25 |
+----+--------+-----+
9 rows in set (0.00 sec)

數據已經同步，基礎的主從複製已經搭建完成

如今模擬一個主從複製架構中，從服務器中途複製失敗，再也不同步主服務器的場景，並要求不停業務進行數據同步修復，恢復一致。

一、首先先模擬一個數據插入的場景

vim insert.sh

#!/usr/bin/env bash values=(`find /usr/ -type d | awk -F '/' '{print $NF}' | sort -u`) while true
do age=$(( $RANDOM%100 )) name=${values[$(( $RANDOM%6 ))]} mysql -h127.1 -P3306 -uroot -proot1 -e "INSERT INTO vfan.student(name,age) VALUES('"${name}"',${age});" &> /dev/null 
sleep $(( $RANDOM%5 )) done

運行腳本，數據在隨機插入（插入時間間隔 < 5s）

目前主mysql數據：

mysql> select * from student; +----+---------------------+-----+
| id | name                | age | ...... |  97 | _                   |   2 |
|  98 | 00bash              |  15 |
|  99 | 00bash              |  52 |
| 100 | 00bash              |  43 |
| 101 | _                   |  65 |
| 102 | 00                  |  67 |
+-----+---------------------+-----+
102 rows in set (0.01 sec)

二、數據還在陸續插入，此時模擬slave節點宕機或異常(在此就直接stop slave;)

mysql> stop slave; Query OK, 0 rows affected (0.01 sec)

三、此時主庫數據還在增長，而從庫已經不一樣步，如下是從庫數據：

mysql> select * from student; +----+---------------------+-----+
| id | name                | age | ...... | 82 | 00bash              |  50 |
| 83 | 00systemd-bootchart |  36 |
| 84 | 00bash              |  48 |
| 85 | 00systemd-bootchart |  41 |
| 86 | 00                  |  72 |
+----+---------------------+-----+
86 rows in set (0.00 sec)

四、開始從庫恢復數據

思路：

先經過mysqldump全量備份當前的數據，因爲不能影響業務，因此在mysqldump數據時不能形成鎖表。要保持數據寫入

因爲mysqldump時數據還在寫入，因此有一部分數據仍是會同步不全，因此導入mysqldump的數據後，跳過dump中包含的GTID事務，再從新創建一次主從配置，開啓slave線程，恢復數據並同步。

（1）mysqldump不鎖表備份數據

mysqldump -uroot -proot1 --single-transaction --master-data=2 -R vfan | gzip > dump4.sql

主要起做用參數：--single-transaction

（2）查看當前mysqldump導出數據的GTID號

[root@TestCentos7 data]# grep GLOBAL.GTID_PURGED dump4.sql SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ 'c9fba9e2-db3b-11eb-81d4-000c298d8da1:1-228';

以上的 c9fba9e2-db3b-11eb-81d4-000c298d8da1:1-228 表示MASTER機執行到的GTID事務號

（3）去從數據庫導入

scp dump4.sql 192.168.152.252:/data mysql客戶端內： mysql> source /data/dump4.sql 此時從庫數據： mysql> select * from student; | 230 | 00                  |  53 |
| 231 | 00bash              |  66 |
| 232 | _                   |  18 |
| 233 | 0.33.0              |  98 |
| 234 | 00bash              |  14 |
+-----+---------------------+-----+
234 rows in set (0.00 sec) 主庫數據： | 454 | _                   |  46 |
| 455 | 03modsign           |  59 |
| 456 | 00systemd-bootchart |  77 |
| 457 | 03modsign           |   6 |
| 458 | 0.33.0              |  88 |
+-----+---------------------+-----+
458 rows in set (0.00 sec)

從庫數據恢復一部分到234行，主庫數據依然在增長，已是458條

（4）因爲咱們mysqldump的數據已經包含了在MASTER執行的 1-228 個事務，因此咱們在SLAVE進行同步的時候，要忽略這些事務再也不進行同步，否則會出現相似於這種報錯：

mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.152.253 Master_User: copy Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000002 Read_Master_Log_Pos: 137827 Relay_Log_File: kubenode2-relay-bin.000002 Relay_Log_Pos: 417 Relay_Master_Log_File: mysql-bin.000002 Slave_IO_Running: Yes Slave_SQL_Running: No Last_Errno: 1062 Last_Error: Could not execute Write_rows event on table vfan.student; Duplicate entry '87' for key 'student.PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000002, end_log_pos 10588

要想跳過某些GTID，SLAVE必須保證 gtid_purged 參數爲空才能正確跳過，查看當前的gtid_purged：

mysql> show global variables like '%gtid%'; +----------------------------------+-------------------------------------------------------------------------------------+
| Variable_name                    | Value                                                                               |
+----------------------------------+-------------------------------------------------------------------------------------+
| binlog_gtid_simple_recovery      | ON                                                                                  |
| enforce_gtid_consistency         | ON                                                                                  |
| gtid_executed                    | b30cb2ff-32d4-11eb-a447-000c292826bc:1-2, c9fba9e2-db3b-11eb-81d4-000c298d8da1:1-80 |
| gtid_executed_compression_period | 1000                                                                                |
| gtid_mode                        | ON                                                                                  |
| gtid_owned                       |                                                                                     |
| gtid_purged                      | c9fba9e2-db3b-11eb-81d4-000c298d8da1:1-70                                           |
| session_track_gtids              | OFF                                                                                 |
+----------------------------------+-------------------------------------------------------------------------------------+
8 rows in set (0.02 sec)

當前gtid_purged不爲空，因此咱們要先設置它爲空，執行：

mysql> reset master; Query OK, 0 rows affected (0.05 sec) mysql> show global variables like '%gtid%'; +----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| binlog_gtid_simple_recovery      | ON    |
| enforce_gtid_consistency         | ON    |
| gtid_executed                    |       |
| gtid_executed_compression_period | 1000  |
| gtid_mode                        | ON    |
| gtid_owned                       |       |
| gtid_purged                      |       |
| session_track_gtids              | OFF   |
+----------------------------------+-------+
8 rows in set (0.00 sec)

（5）gtid_purged爲空後，開始重置SLAVE

mysql> stop slave; Query OK, 0 rows affected (0.00 sec) mysql> reset slave all; Query OK, 0 rows affected (0.02 sec)

（6）重置後，設置跳過的GTID，並從新同步MASTER

mysql> SET @@GLOBAL.GTID_PURGED='c9fba9e2-db3b-11eb-81d4-000c298d8da1:1-228'; Query OK, 0 rows affected (0.01 sec) mysql> CHANGE MASTER TO MASTER_HOST='192.168.152.253',MASTER_USER='copy',MASTER_PASSWORD='copy',MASTER_PORT=3306,MASTER_AUTO_POSITION=1; Query OK, 0 rows affected, 2 warnings (0.04 sec)

（7）開啓SLAVE進程，查看同步狀態

mysql> start slave; Query OK, 0 rows affected (0.01 sec) mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.152.253 Master_User: copy Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000002 Read_Master_Log_Pos: 137827 Relay_Log_File: kubenode2-relay-bin.000002 Relay_Log_Pos: 84993 Relay_Master_Log_File: mysql-bin.000002 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 137827 Relay_Log_Space: 85206 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 100 Master_UUID: c9fba9e2-db3b-11eb-81d4-000c298d8da1 Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: c9fba9e2-db3b-11eb-81d4-000c298d8da1:229-519 Executed_Gtid_Set: c9fba9e2-db3b-11eb-81d4-000c298d8da1:1-519 Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: Master_public_key_path: Get_master_public_key: 0 Network_Namespace: 1 row in set (0.00 sec)

能夠看到，同步正常！

（8）最後，查看master與slave數據是否一致

MASTER數據：SELECT * FROM student; | 520 | 00systemd-bootchart |  18 |
| 521 | 00systemd-bootchart |  44 |
| 522 | 03modsign           |  98 |
| 523 | 00systemd-bootchart |  45 |
| 524 | 00                  |  90 |
| 525 | 03modsign           |  21 |
+-----+---------------------+-----+
525 rows in set (0.00 sec) SLAVE數據：SELECT * FROM student; | 519 | 0.33.0              |  99 |
| 520 | 00systemd-bootchart |  18 |
| 521 | 00systemd-bootchart |  44 |
| 522 | 03modsign           |  98 |
| 523 | 00systemd-bootchart |  45 |
| 524 | 00                  |  90 |
| 525 | 03modsign           |  21 |
+-----+---------------------+-----+
525 rows in set (0.00 sec)