mysql8基於gtid方式搭建主從或恢復

對於mysql8基於gtid方式搭建主從或恢復,看到網上寫的太多了,但是效果太差勁,現給出落地步驟(按照我的一步步來保準沒問題,具體操作原因不贅述--請參考官方文檔:https://dev.mysql.com/doc/refman/8.0/en/replication.html
廢話不多說,直接上實踐步驟

前提說明

機器說明:
從庫:10.5.31.9    10.5.31.10
主庫:10.5.31.8
數據庫數據目錄/data/mysql/
數據庫日誌目錄/mysqllog/
該文檔基於已經建立的mysql8安裝模板(已開啓gtid、binlog功能)

以下步驟適用於主從搭建或恢復主從關係

從庫上操作:10.5.31.9    10.5.31.10
    reset master;
    stop slave;
    service mysqld stop
    #刪除從庫上所有的數據
    rm -fr /data/mysql/*
    #清除mysql的所有日誌,尤其是undo日誌
    rm -fr /mysqllog/*
    注意:修改配置文件/etc/my.cnf中的server_id=211,主從不應一樣,從庫的值大於主庫。
主庫上操作(注意開啓binlog日誌和gtid功能,這裏不多說,可以參考華陽的模板中的配置文件):10.5.31.8
    #創建複製賬號並授予replication slave權限
    create user repl@'%' identified by '123456';
    grant replication slave on *.* to repl@'%';
    flush privileges;
    #創建備份目錄
    mkdir /data/backup -p
    #全備
    xtrabackup  -uroot -p1234.Com --socket=/data/mysql/mysql.sock --backup  --target-dir=/data/backup  --defualt-file=/etc/my.cnf
    #拷貝數據到從庫
    scp -r /data/backup [email protected]:/data
    scp -r /data/backup [email protected]:/data
以下步驟是在主庫操作完畢後,在從庫上操作:10.5.31.9    10.5.31.10
    xtrabackup --prepare --target-dir=/data/backup  --default-file=/etc/my.cnf
    xtrabackup --copy-back --target-dir=/data/backup  --default-file=/etc/my.cnf
登錄主庫,查看gtid號:10.5.31.8
    show master status;
登錄從庫:10.5.31.9    10.5.31.10
change master to master_host='10.5.31.8',master_port=3306,master_user='repl',master_password='123456',master_auto_position=1;
    set gtid_next='automatic';
    set global read_only = on;
    start slave;
    show slave status\G;
    顯示兩個yes,同時Retrieved_Gtid_Set和Executed_Gtid_Set正常即可。

主從熱恢復,邏輯備份方式

主庫上操作
mysqldump -uroot -p123456 --single-transaction --master-data=2 --socket=/data/mysql/mysql.sock -A  > all.sql

        --single-transaction  這個參數避免備份時鎖表
        --master-data=2 因爲是基於gtid方案搭建主從,所以採用2,如果是基於binlog日誌方案則使用1(記錄位置點)
    grep GLOBAL.GTID_PURGED all.sql  --例如該結果爲4a81e208-9f0f-11ea-8686-005056a5c812:1-1202,主要是找到事務號(因爲從的事務號和當前備份的肯定是不一樣的--主庫一直在寫數據,需要重新設定從的事務號)
    scp ./all.sql 10.5.31.9:/data/  
    scp ./all.sql 10.5.31.10:/data/
從庫上執行:
    stop slave;
    source /data/all.sql;   
    RESET MASTER;---將事務置爲0,並重新設定事務號 
    set GLOBAL gtid_purged='4a81e208-9f0f-11ea-8686-005056a5c812:1-1202';
    set global read_only = on;
    start slave;
    show slave status\G;
    顯示兩個yes,同時Retrieved_Gtid_Set和Executed_Gtid_Set正常即可。
    查看從庫複製表是否有異常(無結果表示無異常,一般情況是符合預期的):select * from performance_schema.replication_applier_status_by_worker where  LAST_ERROR_NUMBER>0\G;  
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章