MySQL-16-主從複製進階
阿新 • • 發佈：2021-07-22
延時從庫
介紹
延時從庫: 是我們人為配置的一種特殊從庫，人為配置從庫和主庫延時N小時
為什麼要有延時從庫
資料庫故障
物理損壞，普通的主從複製非常擅長解決物理損壞
邏輯損壞，普通主從複製沒辦法解決邏輯損壞
配置延時從庫
SQL執行緒延時:資料已經寫入relaylog中了,SQL執行緒"慢點"執行 一般企業建議3-6小時,具體看公司運維人員對於故障的反應時間 ## 配置方法，在配置普通主從複製後，在從庫執行以下操作，即可配置延時從庫 mysql> stop slave; mysql> CHANGE MASTER TO MASTER_DELAY = 300; # 這裡的單位是秒 mysql> start slave; mysql> show slave status \G SQL_Delay: 300 # 延時時間為300秒 SQL_Remaining_Delay: NULL # 距離執行第一個事務還剩多少時間
延時從庫應用
故障恢復思路
1主1從,從庫延時5分鐘,主庫誤刪除1個庫
1. 5分鐘之內 偵測到誤刪除操作
2. 停從庫SQL執行緒
3. 擷取relaylog
起點:停止SQL執行緒時,relay最後應用位置
終點:誤刪除之前的position(GTID)
4. 恢復擷取的日誌到從庫
5. 從庫身份解除,替代主庫工作
故障模擬及恢復
主庫資料操作
db01 [(none)]>create database relay charset utf8mb4; db01 [(none)]>use relay db01 [relay]>create table t1 (id int); db01 [relay]>insert into t1 values(1); db01 [relay]>drop database relay;
停止從庫SQL執行緒
mysql> stop slave sql_thread;
找relaylog的擷取起點和終點
起點:
mysql> show slave status\G;
Relay_Log_File: db01-relay-bin.000002
Relay_Log_Pos: 320
終點:這裡是1233
mysql> show relaylog events in 'db01-relay-bin.000002';
擷取relaylog日誌檔案
[root@db01 data]# mysqlbinlog --start-position=320 --stop-position=1233 /data/3308/data/db01-relay-bin.000002>/tmp/relay.sql
從庫恢復relaylog
source /tmp/relay.sql
從庫身份解除
db01 [relay]>stop slave;
db01 [relay]>reset slave all
恢復情況
第一種：如果主庫只有一個庫，那麼可以考慮從庫直接替代主庫進行工作
第二種：從庫匯出被誤刪除的庫恢復到主庫，然後在建立主從關係
半同步（瞭解）
解決主從資料不一致的問題
半同步複製工作原理的變化
1. 主庫執行新的事務,commit時,更新 show master status\G ,觸發一個訊號
2. binlog dump 接收到主庫的 show master status\G資訊,通知從庫日誌更新了
3. 從庫IO執行緒請求新的二進位制日誌事件
4. 主庫會通過dump執行緒傳送新的日誌事件,給從庫IO執行緒
5. 從庫IO執行緒接收到binlog日誌,當日志寫入到磁碟上的relaylog檔案時,給主庫ACK_receiver執行緒
6. ACK_receiver執行緒觸發一個事件,告訴主庫commit可以成功了
7. 如果ACK達到了我們預設值的超時時間,半同步複製會切換為原始的非同步複製
配置半同步複製
載入外掛
主:
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';
過濾複製
環境準備
從庫 :
mysql -S /data/3308/mysql.sock
drop database relay ;
stop slave;
reset slave all;
主庫:
mysql -S /data/33078/mysql.sock
reset master;
從庫:
[root@db01 ~]# mysql -S /data/3308/mysql.sock
mysql >
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154,
MASTER_CONNECT_RETRY=10;
start slave;
配置過濾複製
主庫：
直接配置需要複製的庫才寫binlog日誌，這樣，從庫就只能複製到寫了binlog日誌的庫，但是這樣太暴力，不建議這樣使用
主庫配置檔案加入如下引數，注意只要這兩個引數中的一個即可
[root@db01 data]# vim /data/3307/my.cnf
binlog_do_db="aa" # 表示只有aa庫才寫binlog日誌
binlog_ignore_db="bb" # 表示除了bb庫都寫binlog日誌
[root@db01 data]# systemctl restart mysqld3307
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000004 | 154 | aa | | |
+------------------+----------+--------------+------------------+-------------------+
從庫：
配置檔案加入只回放哪些庫，主庫的binlog日誌還是要全部取過來的
[root@db01 data]# vim /data/3308/my.cnf
replicate_do_db=mydb
[root@db01 data]# systemctl restart mysqld3308
mysql> show slave status\G
Replicate_Do_DB: repl
Replicate_Ignore_DB:
GTID主從複製*****
GTID介紹
GTID(Global Transaction ID)是對於一個已提交事務的唯一編號，並且是一個全域性(主從複製)唯一的編號。
它的官方定義如下：
GTID = source_id ：transaction_id
7E11FA47-31CA-19E1-9E56-C43AA21293967:29
什麼是sever_uuid，和Server-id 區別？
核心特性: 全域性唯一,具備冪等性
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更新是否記入日誌
GTID複製配置過程
1 清理環境(實驗環境)
pkill mysqld
rm -rf /data/mysql/data/*
rm -rf /data/binlog/*
2 準備配置檔案
準備3臺虛擬機器伺服器 10.0.0.51（db01主庫）、10.0.0.52（db02從庫）、10.0.0.53（db03從庫）
主庫db01：
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/application/mysql/
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=51
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]>
EOF
slave1(db02)：
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/application/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=52
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]>
EOF
slave2(db03)：
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/application/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=53
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
3 初始化資料（三臺主機都要執行）
mysqld --initialize-insecure --user=mysql --basedir=/data/mysql --datadir=/data/mysql/data
4 啟動資料庫（三臺主機都要執行）
systemctl start mysqld
5 構建主從
master:51
slave:52,53
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 從庫誤寫入操作處理
檢視監控資訊:
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。
最好的解決方案：重新構建主從環境
GTID 複製和普通複製的區別
普通複製：
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=444,
MASTER_CONNECT_RETRY=10;
GTID複製：
change master to
master_host='10.0.0.51',
master_user='repl',
master_password='123' ,
MASTER_AUTO_POSITION=1;
start slave;
（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';
告訴從庫，我的備份中已經有以上事務，你就不用運行了，直接從下一個GTID開始請求binlog就行
轉載請註明出處喲~ https://www.cnblogs.com/lichengguo