主備都是全新的恢復，主主搭建步驟

ginni_hua發表於2019-09-29
1.172.17.16.8 tar備份copy到跳板機14:42  16:23  100min
scp 172.17.16.8:/home/mysql/DBbackup/bk_newoa/20190116.tar /data/hua/
2. 從跳板機copy至172.19.53.149&53.150  16:32  15min
scp /data/hua/20190116.tar 172.19.53.149:/data/hua/
scp /data/hua/20190116.tar 172.19.53.150:/data/hua/
3.停例項172.19.53.149&53.150
4.將172.19.53.149&53.150 資料刪除  5min
rm -rf /data/mysql/db_newoa/data/*
5.將172.19.53.149&53.150解壓縮  6min
innobackupex --decompress --parallel=8 /data/hua/20190116/base_20190116
6.在172.19.53.149&53.150上應用資料  2min
innobackupex --apply-log /data/hua/20190116/base_20190116
7.在172.19.53.149&53.150上copy恢復  10min
innobackupex --defaults-file=/data/mysql/db_newoa/newoa.cnf --copy-back /data/hua/20190116/base_20190116
innobackupex --defaults-file=/data/mysql/db_newoa/newoa.cnf --move-back /data/hua/20190116/base_20190116
8.開啟資料庫
sh startup.sh
9.重做主從
172.19.53.149：
reset master;
reset slave all;
change master to master_host='172.19.53.150', MASTER_PORT=23308, master_user='repl', master_password='4%REplic', MASTER_AUTO_POSITION=1;
172.19.53.150：
reset master;
reset slave all;
備份檔案中找到 xtrabackup_slave_info 檔案，根據裡面內容執行，如果主從都為全新的庫，不需要重新設定gtid：
-- SET @@GLOBAL.GTID_PURGED='XXXX';   #執行這個必須gtid為空，先執行reset master
-- set global gtid_executed="7d58ee1a-93a0-11e7-8ff5-f44c7f785650:1-3,d2cf8b03-939f-11e7-99db-407d0f46034d:1-14193879"
change master to master_host='172.19.53.149', MASTER_PORT=23308, master_user='repl', master_password='4%REplic', MASTER_AUTO_POSITION=1;
start slave;
show slave status\G
如果不通，一般是帳號的問題（密碼不對？無訪問許可權...）
select * from mysql.slave_master_info\G;  #檢視帳號密碼資訊repl
show grants for repl@'%';
select user,host from mysql.user; #檢視帳號許可權，如果有限定IP，則需要變更
update mysql.user set host='%' where user='repl';
還是不通，則為防火牆埠沒開啟
[root@mysqltest1 ~]# firewall-cmd --zone=public --add-port=23301/tcp --permanent  #開啟23301
success
[root@mysqltest1 ~]# firewall-cmd --reload #載入
success
[root@mysqltest1 ~]# firewall-cmd --zone=public --query-port=23301/tcp  #檢視
yes
[root@mysqltest1 ~]#  systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2019-01-23 23:10:23 EST; 30min ago
Docs: man:firewalld(1)
Main PID: 4081 (firewalld)
CGroup: /system.slice/firewalld.service
異常ERROR：
1.Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.
這是因為mysql2克隆的mysql1所以，UUID是一樣，我們只需要修改mysql2的UUID，重啟動mysql服務即可。 vi /data/mysql/db_order/data/auto.cnf  不要破壞UUID的格式，字母的地方是字母，數字的地方是數字，只面要變更其中的數字即可。
2.mysql> start slave;
ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository
原因：檢查my.cnf，原來沒指定relay_log，mysql預設產生的relay_log名被該server上的另一個mysql slave佔用了。
修改名稱： relay_log = /db/mysql56/logs/relay_98_3326
10.開啟keepalived
sudo systemctl restart keepalived
11.檢查
備註（reset master/reset slave all）：
reset master刪除所有index file 中記錄的所有binlog 檔案，將日誌索引檔案清空，建立一個新的日誌檔案，這個命令通常僅僅用於第一次用於搭建主從關係的時的主庫.
注意
  reset master 不同於purge binary log的兩處地方
1 reset master 將刪除日誌索引檔案中記錄的所有binlog檔案，建立一個新的日誌檔案 起始值從000001 開始，然而purge binary log 命令並不會修改記錄binlog的順序的數值
2 reset master 不能用於有任何slave 正在執行的主從關係的主庫。因為在slave 執行時刻 reset master 命令不被支援，reset master 將master 的binlog從000001 開始記錄,slave 記錄的master log 則是reset master 時主庫的最新的binlog,從庫會報錯無法找的指定的binlog檔案。
RESET SLAVE
reset slave 將使slave 忘記主從複製關係的位置資訊。該語句將被用於乾淨的啟動, 它刪除master.info檔案和relay-log.info 檔案以及所有的relay log 檔案並重新啟用一個新的relaylog檔案。
使用reset slave之前必須使用stop slave 命令將複製程式停止。
注 所有的relay log將被刪除不管他們是否被SQL thread程式完全應用(這種情況發生於備庫延遲以及在備庫執行了stop slave 命令),儲存複製連結資訊的master.info檔案將被立即清除,如果SQL thread 正在複製臨時表的過程中，執行了stop slave ，並且執行了reset slave，這些被複制的臨時表將被刪除。
RESET SLAVE  ALL
在 5.6 版本中 reset slave 並不會清理儲存於記憶體中的複製資訊比如  master host, master port, master user, or master password,也就是說如果沒有使用change master 命令做重新定向，執行start slave 還是會指向舊的master 上面。
當從庫執行reset slave之後,將mysqld shutdown 複製引數將被重置。
在5.6.3 版本以及以後 使用使用 RESET SLAVE ALL 來完全的 清理複製連線引數資訊。 (Bug #11809016)
RESET SLAVE ALL does not clear the IGNORE_SERVER_IDS list set by CHANGE MASTER TO. This issue is fixed in MySQL 5.7. (Bug #18816897)
In MySQL 5.6.7 and later, RESET SLAVE causes an implicit commit of an ongoing transaction. See Section 13.3.3, “Statements That Cause an Implicit Commit”.


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7836221/viewspace-2658757/，如需轉載，請註明出處，否則將追究法律責任。

相關文章