前言
本文總結了主從複製的原理及日常運維的坑
1.主從複製簡介
MySQL 複製是指從一個 MySQL 主服務器(master)將數據拷貝到另一臺或多臺 MySQL 從服務器(slaves)的過程，將主數據庫的 DDL 和 DML 操作通過二進制日誌傳到從庫服務器上，然後在從服務器上對這些日誌重新執行，從而使得主從服務器的數據保持同步。
2.主從複製原理
MySQL複製的基本過程如下：
- Slave上面的 IO 線程連接上 Master，並請求從指定日誌文件的指定位置（或者從最開始的日誌）之後的日誌內容；
- Master接收到來自 Slave 的 IO 線程的請求後，通過複製的 IO 線程根據請求信息讀取指定日誌指定位置之後的日誌信息，返回給 Slave端的 IO 線程。
- Slave的 IO 線程接收到信息後， 將接收到的日誌內容依次寫入到 Slave端的 Relay Log 文件(mysql-relay-bin.xxxxxx)的最末端，並將讀取到的 Master 端的 binlog 的文件名和位置記錄到 master-info 文件中.
- Slave 的 SQL 線程檢測到 Relay Log 中新增加了內容後，會馬上解析該 Log 文件中的內容成爲在 Master 端真實執行時候的那些可執行的SQL 語句，並在自身執行這些 SQL。
3.機房掉電主從故障
3.1 故障現象
機房掉電，數據庫非正常關機。
MySQL拉起後，從庫報如下錯誤。
Slave_IO_Running: No
Slave_SQL_Running: Yes
發現從庫的GTID比主庫的GTID要大
--主庫的GTID
mysql> show master status\G
*************************** 1. row ***************************
File: MMK-JEM-Master1-ip31-bin.000002
Position: 195
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: c5833cbf-fa39-11ee-ae67-0242c0a8441f:1-5
1 row in set (0.00 sec)
--從庫執行的GTID
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set: 46081bff-fa3a-11ee-9d8b-0242c0a84420:1-7,
c5833cbf-fa39-11ee-ae67-0242c0a8441f:1-2:6
Auto_Position: 1
3.2 故障處理
1）在從上執行 reset master;
在從庫上執行這個命令的作用是清空從庫的 gtid
2）然後從庫重置即可
mysql> stop slave;
mysql> reset slave;
mysql> start slave;
mysql> show slave status\G
3)查詢從庫被執行過的gtid
mysql> select @@GLOBAL.gtid_executed;
+------------------------------------------+
| @@GLOBAL.gtid_executed |
+------------------------------------------+
| c5833cbf-fa39-11ee-ae67-0242c0a8441f:1-2 |
+------------------------------------------+
此時我們發現有報錯信息，顯示爲同步用戶重複導致，可以跳過
--解決方案，跳過從庫gtid，原來事務最大爲2
mysql> stop slave;
mysql> set gtid_next='c5833cbf-fa39-11ee-ae67-0242c0a8441f:3';
mysql> begin;commit;
mysql> set gtid_next='automatic';
mysql> start slave;
mysql> SHOW SLAVE STATUS\G
--此時發現同步一切OK
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
4.知識點
在MySQL中，sync_binlog參數用於控制二進制日誌(binlog)的同步方式。它決定了事務提交到binlog的時機以及是否需要等待數據同步完成才返回客戶端
根據實際需求，設置sync_binlog參數的值。
0: 表示不進行同步，即異步寫入binlog。
1: 表示在事務提交後立即將binlog同步到磁盤。
n: 表示在事務提交後等待n次fsync操作後將binlog同步到磁盤。
5.故障總結
從二進制日誌讀取數據時，從主機收到致命錯誤1236：“使用主機的SERVER_UUID，從機的GTID比主機多。這可能表示二進制日誌的末尾被截斷，或者最後一個二進制日誌文件丟失，例如，在sync_binlog！=1.主服務器可能已回滾或可能未回滾已複製到從屬服務器的事務。建議將master已從slave回滾到master的任何事務複製到master
轉自
又成長了，異常掉電踩到了MySQL主從同步的坑！
https://mp.weixin.qq.com/s/adeM1rWkMuTeGPHpLs77hQ