主從複製的高階應用
阿新 • • 發佈：2020-10-10
主從複製的高階應用
延時從庫過濾複製半同步gtid複製歡迎來到 來到大浪濤天的部落格 ！
一、主從複製的高階應用
1. 延時從庫
1-1. 延時從庫的介紹說明
- 主從複製主要是為了防止資料庫的物理故障，比如資料損壞，比如主庫例項結點宕機，這樣可以快速的從從庫中匯出故障的庫或者表，也可以直接把從庫應用於生產。但是如果主庫出現邏輯錯誤操作，比如誤刪了資料，或者誤刪了庫，從庫如果不設定延時的話，那也保護不了資料，因為主庫輸入的同時，從庫也同步過來跟著回放了，所以延時從庫主要是用於防止出現邏輯性的誤操作事件。
- SQL執行緒延時:資料已經寫入relaylog中了,SQL執行緒"慢點"執行
- 一般企業建議3-6小時,具體看公司運維人員對於故障的反應時間
1-2.
mysql>stop slave;
這裡的21600是指時間秒
mysql>CHANGE MASTER TO MASTER_DELAY = 21600;
mysql>start slave;
mysql> show slave status \G
SQL_Delay: 21600
SQL_Remaining_Delay: NULL1-3. 延時從庫恢復故障的案例
1-3-1. 延時從庫的恢復思路
1. 監控到資料庫邏輯故障 2. 停從庫SQL執行緒,記錄已經回放的位置點(擷取日誌起點) stop slave sql_thread ; show slave status \G Relay_Log_File: db01-relay-bin.000002 Relay_Log_Pos: 320 3. 擷取relaylog 起點: show slave status \G Relay_Log_File ,Relay_Log_Pos 終點: drop之前的位置點,注意relay_log的events顯示和binlog的events顯示有些區別，左邊的是一致，右邊的pos是顯示的binlog的pos,為了讓relaylog和binlog一一對應，所以我們擷取的時候看左邊的pos位資訊就好了。 show relaylog events in '' 進行擷取 4. 模擬SQL執行緒回訪日誌 從庫 source 5. 恢復業務 情況一: 就一個庫的話 從庫替代主庫工作 情況二: 從庫匯出故障庫,還原到主庫中
1-3-2. 故障恢復演練
1-3-2-1. 資料模擬
- 主庫執行模擬資料
主庫 :
create database delay charset utf8mb4;
use delay;
create table t1 (id int);
insert into t1 values(1),(2),(3);
commit;
drop database delay;- 從庫執行停止 從庫SQL 執行緒,獲取relay的位置點
mysql> stop slave sql_thread;
mysql> show slave status \G
Relay_Log_File: db01-relay-bin.000002
Relay_Log_Pos: 626- 找到relay的擷取終點
mysql> show relaylog events in 'db01-relay-bin.000002';
| db01-relay-bin.000002 | 1299 | Query | 7 | 1228 | drop database delay - 擷取relay
[root@db01 data]# cd /data/3308/data/
[root@db01 data]# mysqlbinlog --start-position=626 --stop-position=1299 db01-relay-bin.000002 >/tmp/relay.sql- 恢復relay到從庫
[root@db01 data]# mysql -uroot -p -S /data/3308/mysql.sock
mysql> set sql_log_bin=0;
mysql> source /tmp/relay.sql- 從從庫匯出被刪除的庫，然後從主庫匯入
mysqldump -uroot -padmin123 -S /data/3307/mysql.sock -B test02 --master-data=2 --single-transaction -R -E --triggers --set-gtid-purged=OFF >test02.sql
source /tmp/test02.sql- 從庫身份解除。
db01 [relay]>stop slave;
db01 [relay]>reset slave all2. 主從過濾複製
2-1. 主從過濾複製的介紹
MySQL主從支援從主庫選擇某些庫進行復制，也可以從從庫選擇某些庫和某些表進行復制，因為大部分的生產場景下，MySQL都是讀比寫繁忙很多，讀的效能也比較低，因此為了緩解主庫的壓力，都是採用主庫寫，多個從庫讀，因此就需要從從庫中選擇需要同步的庫過來，這樣能極大的緩解資料庫的壓力。
2-2. 過濾複製應用
主庫:
show master status ;
從主庫中設定需要複製的庫的白名單
binlog_do_db
從主庫中設定需要複製的庫的黑名單
binlog_ignore_db
從庫:
mysql> show slave status \G
從從庫中設定需要複製的庫的白名單
Replicate_Do_DB:
從從庫中設定需要複製的庫的黑名單
Replicate_Ignore_DB:
從從庫中設定需要複製的表的白名單
Replicate_Do_Table:
從從庫中設定需要複製的表的黑名單
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table: 2-3. 實現過程
mysqldump -S /data/3307/mysql.sock -A --master-data=2 --single-transaction -R --triggers >/backup/full.sql
vim /backup/full.sql
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=154;
[root@db01 ~]# mysql -S /data/3309/mysql.sock
source /backup/full.sql
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000002',
MASTER_LOG_POS=154,
MASTER_CONNECT_RETRY=10;
start slave;
[root@db01 ~]# vim /data/3309/my.cnf
replicate_do_db=ppt
replicate_do_db=word
[root@db01 ~]# systemctl restart mysqld3309
db01 [(none)]>show slave status \G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: DB02
Master_User: repl
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: mysql-bin.000005
Read_Master_Log_Pos: 399
Relay_Log_File: DB02-relay-bin.000008
Relay_Log_Pos: 360
Relay_Master_Log_File: mysql-bin.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: ppt,word
主庫：
Master [(none)]>create database word;
Query OK, 1 row affected (0.00 sec)
Master [(none)]>create database ppt;
Query OK, 1 row affected (0.00 sec)
Master [(none)]>create database excel;
Query OK, 1 row affected (0.01 sec)3. 主從半同步
3-1. 主從半同步的應用場景
1. 解決主從資料一致性問題，在主庫完成了dump執行緒後，二進位制日誌通過IO執行緒快取在從庫的快取中還沒有寫入relaylog中，從庫忽然宕機了，這樣從庫起來後可能和主庫資料不一致。但是需要注意的是當配置了半同步後，主庫效能會急劇降低，因為當從庫沒有返回ACK_receiver執行緒時，主庫就卡在了commit這裡，當達到了超時時間半同步複製也會切換成原始的非同步同步，一樣是無法完全保證主從資料的一致性。
2. ACK ,從庫relay落地,IO執行緒會返回一個ACK,主庫的 ACK_reciver .主庫事務才能提交.如果一直ACK沒收到,超過10秒鐘會切換為非同步複製.3-2. 半同步應用原理
1. 主庫執行新的事務,commit時,更新 show master status\G ,觸發一個訊號給binlog
2. binlog dump 接收到主庫的 show master status\G資訊,通知從庫日誌更新了
3. 從庫IO執行緒請求新的二進位制日誌事件
4. 主庫會通過dump執行緒傳送新的日誌事件,給從庫IO執行緒
5. 從庫IO執行緒接收到binlog日誌,當日志寫入到磁碟上的relaylog檔案時,給主庫ACK_receiver執行緒
6. ACK_receiver執行緒觸發一個事件,告訴主庫commit可以成功了
7. 如果ACK達到了我們預設值的超時時間,半同步複製會切換為原始的非同步複製.3-3. 配置半同步複製
載入外掛
主:
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
從:
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
檢視是否載入成功:
show plugins;
啟動:
主:
SET GLOBAL rpl_semi_sync_master_enabled = 1;
從:
SET GLOBAL rpl_semi_sync_slave_enabled = 1;
重啟從庫上的IO執行緒
STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;
檢視是否在執行
主:
show status like 'Rpl_semi_sync_master_status';
從:
show status like 'Rpl_semi_sync_slave_status';3-4. GTID複製
3-5. GTID複製的介紹
GTID(Global Transaction ID)是對於一個已提交事務的唯一編號，並且是一個全域性(主從複製)唯一的編號。
它的官方定義如下：
GTID = source_id ：transaction_id
7E11FA47-31CA-19E1-9E56-C43AA21293967:29
什麼是sever_uuid，和Server-id 區別？
核心特性: 全域性唯一,具備冪等性3-6. GTID核心引數
重要引數：
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
gtid-mode=on --啟用gtid型別，否則就是普通的複製架構
enforce-gtid-consistency=true --強制GTID的一致性
log-slave-updates=1 --slave更新是否記入日誌3-7. GTID複製配置過程：
- 準備環境
pkill mysqld
\rm -rf /data/mysql/data/*
\rm -rf /data/binlog/*- 準備配置檔案
主庫db01：
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/application/mysql/
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=81
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db01 [\\d]>
EOFslave1(db02)：
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/application/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=82
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db02 [\\d]>
EOFslave2(db03)：
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/application/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=83
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db03 [\\d]>
EOF- 建立使用者
useradd -s /sbin/nologin mysql- 建立必須的目錄
mkdir -p /data/binlog/
mkdir -p /data/mysql/data
chown -R mysql.mysql /data- 初始化資料
mysqld --initialize-insecure --user=mysql --basedir=/application/mysql --datadir=/data/mysql/data - 啟動路徑systemctl啟動
cat >/etc/systemd/system/mysqld.service <<EOF
[Unit]
Description=MySQL Server
Documentation=man:mysqld(8)
Documentation=http://dev.mysql.com/doc/refman/en/using-systemd.html
After=network.target
After=syslog.target
[Install]
WantedBy=multi-user.target
[Service]
User=mysql
Group=mysql
ExecStart=/application/mysql/bin/mysqld --defaults-file=/etc/my.cnf
LimitNOFILE = 5000
EOF- 複製啟動指令碼 /etc/init.d/mysqld start啟動
cp /application/mysql/support-files/mysql.server /etc/init.d/mysqld
修改一下
basedir=/application/mysql
datadir=/data/mysql/data- 啟動資料庫
/etc/init.d/mysqld start- 構建主從：
master:81
slave:82,83
51:
grant replication slave on *.* to repl@'10.0.0.%' identified by '123';
52\53:
change master to
master_host='10.0.0.51',
master_user='repl',
master_password='123' ,
MASTER_AUTO_POSITION=1;
start slave;- GTID 複製和普通複製的區別
（0）在主從複製環境中，主庫發生過的事務，在全域性都是由唯一GTID記錄的，更方便Failover
（1）額外功能引數（3個）
（2）change master to 的時候不再需要binlog 檔名和position號,MASTER_AUTO_POSITION=1;
（3）在複製過程中，從庫不再依賴master.info檔案，而是直接讀取最後一個relaylog的 GTID號
（4） mysqldump備份時，預設會將備份中包含的事務操作，以以下方式
#### SET @@GLOBAL.GTID_PURGED='8c49d7ec-7e78-11e8-9638-000c29ca725d:1-11';
告訴從庫，我的備份中已經有以上事務，你就不用運行了，直接從下一個GTID開始請求binlog就行。3-8. GTID 從庫誤寫入操作處理
檢視監控資訊:
Last_SQL_Error: Error 'Can't create database 'oldboy'; database exists' on query. Default database: 'oldboy'. Query: 'create database oldboy'
Retrieved_Gtid_Set: 71bfa52e-4aae-11e9-ab8c-000c293b577e:1-3
Executed_Gtid_Set: 71bfa52e-4aae-11e9-ab8c-000c293b577e:1-2,
7ca4a2b7-4aae-11e9-859d-000c298720f6:1
注入空事物的方法：
stop slave;
set gtid_next='99279e1e-61b7-11e9-a9fc-000c2928f5dd:3';
begin;commit;
set gtid_next='AUTOMATIC';
這裡的xxxxx:N 也就是你的slave sql thread報錯的GTID，或者說是你想要跳過的GTID。
最好的解決方案：重新構建主從環境