騰訊雲數據庫備用-基於GTID複製的mysql作爲CDB的從庫

原因:騰訊雲數據丟失,但是又有業務在騰訊雲上,所以需要對數據庫進行備份(自建從庫,騰訊雲的說法),做騰訊雲數據庫的從庫
基於mysql 5.7實現.
1、首先用戶通過在控制檯創建一個用於複製的賬戶wjqrepl；

2、給wjqrepl用戶賦予相應的權限

需要進入數據庫命令行中，
grant replication slave on *.* to 'xxxxx'@'%' identified by '1234567';
flush privileges;

3、導出雲數據庫中的業務庫數據

4、確認自建從庫是否開啓GTID

show variables like '%gtid%'  查看gtid_mode 的value是否爲on
如果沒有，則修改my.cnf 在[mysqld]中增加如下內容：
gtid-mode=on
enforce-gtid-consistency=on

5、將上述導出的備份文件導入到自建的mysql數據庫中；

帶有 GTID 信息的備份 文件, 要求目標數據庫實例必須開啓 GTID 功能, 且當前數據庫中無其他 GTID 信息. 如果目標數據庫中已經記錄了一條或一條以上的 GTID 信息, 那麼在導入數據庫時會上面類似的錯誤；
解決方法：

1、重新 dump 數據庫, 使用--set-gtid-purged=OFF的參數禁止；
2、在目標數據庫中執行 reset slave all;和 reset master;清空所有 GTID 信息之後就可以導入了；

6、在CVM自建mysql數據庫配置主從同步關係，並啓動slave;

change master to master_host='bj-cdb-d8xcsyv6..com', master_user='re49pl', master_port=63021, master_password='re43sswo@', master_auto_position=1;

7, 出現“The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.”

1、這個應該是由於你在主庫上執行過purge binary logs，然後當從庫change master的時候，卻要執行那些事務。
你可以在主庫上先查找哪些gtid被purge了。

show global variables like 'gtid_purged';

然後拿着這個value，去從庫上依次

stop slave;

set global gtid_purged = '8170836d-8e48-11e0c29b48f84:1-2'; # xxx是你主庫上查到的value。 如果有多個，就一起寫在後面，用，隔開

start slave;

這樣能跳過執行被主庫已經purge的事務了。

附一張從騰訊雲文檔的截圖比較清楚