创建或恢复基于GTID复制的从库
2022-03-12 15:18 abce 阅读(576) 评论(0) 编辑 收藏 举报1.创建基于GTID复制的从库
过程概述：
2.在从库还原数据，并将从库的gtid_purged设置成主库的gtid_executed的值
mysqldump可以完成这些任务。来看一个示例，说明如何从 master获取备份并将其恢复到slave以设置新的复制服务器。
master > show global variables like 'gtid_executed';
+---------------+-------------------------------------------+
| Variable_name | Value |
+---------------+-------------------------------------------+
| gtid_executed | 9a565a7b-7059-11e2-9a24-08002762b8af:1-13 |
+---------------+-------------------------------------------+
master > show global variables like 'gtid_purged';
+---------------+------------------------------------------+
| Variable_name | Value |
+---------------+------------------------------------------+
| gtid_purged | 9a565a7b-7059-11e2-9a24-08002762b8af:1-2 |
+---------------+------------------------------------------+
开始备份主库
# mysqldump --all-databases --single-transaction --triggers --routines --host=127.0.0.1 --port=3306 --user=abce --password=abce > dump.sql
备份文件中会包含：
# grep PURGED dump.sql
SET @@GLOBAL.GTID_PURGED='9a565a7b-7059-11e2-9a24-08002762b8af:1-13';
因此，在从库导入备份数据的时候，会将从库的gitd_purged设置成主库的gtid_executed的值。
现在，我只需要将主库的备份数据恢复并启动复制。
slave1 > show global variables like 'gtid_executed';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_executed | |
+---------------+-------+
slave1 > show global variables like 'gtid_purged';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_purged | |
+---------------+-------+
slave1 > source dump.sql;
[...]
slave1 > show global variables like 'gtid_executed';
+---------------+-------------------------------------------+
| Variable_name | Value |
+---------------+-------------------------------------------+
| gtid_executed | 9a565a7b-7059-11e2-9a24-08002762b8af:1-13 |
+---------------+-------------------------------------------+
slave1 > show global variables like 'gtid_purged';
+---------------+-------------------------------------------+
| Variable_name | Value |
+---------------+-------------------------------------------+
| gtid_purged | 9a565a7b-7059-11e2-9a24-08002762b8af:1-13 |
+---------------+-------------------------------------------+
最后一步就是配置从库连接主库，使用gtid。
slave1 > CHANGE MASTER TO MASTER_HOST="127.0.0.1", MASTER_USER="abce", MASTER_PASSWORD="abce", MASTER_PORT=3306, MASTER_AUTO_POSITION = 1;
2.还原坏掉的从库：快速但比较糟糕的方式
假设从库已经宕机了好几天，主库的binlog已经被清理了。会报以下的错误：
Slave_IO_Running: No
Slave_SQL_Running: Yes
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: '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.'
现在如何处理这些呢。首先我们使用糟糕但是比较快速的方法。就是指向主库binlog中其他的gtid的位置。首先，我们获得主库的gtid_executed的值：
master > show global variables like 'GTID_EXECUTED';
+---------------+-------------------------------------------+
| Variable_name | Value |
+---------------+-------------------------------------------+
| gtid_executed | 9a565a7b-7059-11e2-9a24-08002762b8af:1-14 |
+---------------+-------------------------------------------+
在从库上执行：
slave> set global GTID_EXECUTED="9a565a7b-7059-11e2-9a24-08002762b8af:1-14"
ERROR 1238 (HY000): Variable 'gtid_executed' is a read only variable
报错了。要记住，我们是获得主库的gtid_executed的值，然后设置成从库的gtid_puged的值。
slave1 > set global GTID_PURGED="9a565a7b-7059-11e2-9a24-08002762b8af:1-14";
ERROR 1840 (HY000): GTID_PURGED can only be set when GTID_EXECUTED is empty.
又报错了。gtid_executed应该设置为空，在修改gtid_purged之前。但是，我们又没法修改只读变量gtid_executed。唯一的方法就是执行reset master，才能将gtid_executed设置为空(在slave端执行)：
slave1> reset master;
slave1 > show global variables like 'GTID_EXECUTED';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_executed | |
+---------------+-------+
slave1 > set global GTID_PURGED="9a565a7b-7059-11e2-9a24-08002762b8af:1-14";
slave1> start slave io_thread;
slave1> show slave statusG
[...]
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
[...]
现在，如果你没有收到主键、唯一性冲突的报错的话，就可以运行pt-table-checksum、pt-table-sync工具来执行数据检测了。
3.还原坏掉的从库：慢速但比较好的方式
比较好的方式是再次执行mysqldump(详见本文开头部分)，从主库备份一份数据，然后还原到从库：
slave1 [localhost] {abce} ((none)) > source dump.sql;
[...]
ERROR 1840 (HY000): GTID_PURGED can only be set when GTID_EXECUTED is empty.
[...]
值得一提的是，这些类型的错误消息可能会在shell缓冲区中消失，因为dump的恢复将继续进行。 要小心观察。因此，类似的解决方法是：
slave1> reset master;
slave1> source dump.sql;
slave1> start slave;
slave1> show slave statusG
[...]
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
[...]
开启了gtid之后，就应该关注gtid_executed和gtid_purged两个变量了，而不是binlog的名称和位置。
原文地址：
