开心学习
当前位置：数据库 > > 正文

mysql双主状态不一致（MySQL GTID主备不一致的修复方案）

时间：2021-10-16 00:18:30类别：数据库

mysql双主状态不一致

MySQL GTID主备不一致的修复方案

 

方案一：重建 Replicas

MySQL 5.6及以上版在复制中引入了新的全局事务ID（GTID）支持。 在启用了GTID模式的情况下执行MySQL和MySQL 5.7的备份时，Percona XtraBackup会自动将GTID值存储在xtrabackup_binlog_info中。 该信息可用于创建新的（或修复损坏的）基于GTID的副本。

 

前提条件

MySQL 机器上需要安装 percona xtrabackup

 

优点

比较安全，操作简单

 

缺点

 

操作步骤

 

Master

在 Master 上使用 xtrabackup 工具对当前的数据库进行备份，执行该命令的用户需要有读取 MySQL data 目录的权限

  • ?
  • 1
    		•
  • innobackupex --default-file=/etc/my.cnf --user=root -H 127.0.0.1 --password=[PASSWORD] /tmp
    		•

    • 将该备份文件拷贝到 Slave 机器上

     

    Slave

    在 Slave 机器上执行该命令，准备备份文件

  • ?
  • 1
    		•
  • innobackupex --default-file=/etc/my.cnf --user=root -H 127.0.0.1 --password=[PASSWORD] --apply-log /tmp/[TIMESTAMP]
    		•

    • 备份并删除 Slave data目录

  • ?
  • 1
  • 2
    		•
  • systemctl stop mysqld
  • mv /data/mysql{,.bak}
    		•

    • 将备份拷贝到目标目录，并赋予相应的权限，然后重启 Slave

  • ?
  • 1
  • 2
  • 3
  • 4
    		•
  • innobackupex --default-file=/etc/my.cnf --user=root -H 127.0.0.1 --password=[PASSWORD] --copy-back /tmp/[TIMESTAMP]
  • chmod 750 /data/mysql
  • chown mysql.mysql -R /data/mysql
  • systemctl start mysqld
    		•

    • 查看当前备份已经执行过的最后一个的GTID，如下示例

  • ?
  • 1
  • 2
    		•
  • $ cat /tmp/[TIMESTAMP]/xtrabackup_binlog_info
  • mysql-bin.000002  1232    c777888a-b6df-11e2-a604-080027635ef5:1-4
    		•

    • 这个GTID也会在 innobackupex 备份完成后打印出来

  • ?
  • 1
    		•
  • innobackupex: MySQL binlog position: filename 'mysql-bin.000002', position 1232, GTID of the last change 'c777888a-b6df-11e2-a604-080027635ef5:1-4'
    		•

    • 使用 root 登录 MySQL，进行如下配置

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
    		•
  • NewSlave > RESET MASTER;
  • NewSlave > SET GLOBAL gtid_purged='c777888a-b6df-11e2-a604-080027635ef5:1-4';
  • NewSlave > CHANGE MASTER TO
  •        MASTER_HOST="$masterip",
  •        MASTER_USER="repl",
  •        MASTER_PASSWORD="$slavepass",
  •        MASTER_AUTO_POSITION = 1;
  • NewSlave > START SLAVE;
    		•

    • 查看 Slave 的复制状态是否正常

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
    		•
  • NewSlave > SHOW SLAVE STATUS\G
  •      [..]
  •      Slave_IO_Running: Yes
  •      Slave_SQL_Running: Yes
  •      [...]
  •      Retrieved_Gtid_Set: c777888a-b6df-11e2-a604-080027635ef5:5
  •      Executed_Gtid_Set: c777888a-b6df-11e2-a604-080027635ef5:1-5
    		•

    • 我们可以看到副本已检索到编号为5的新事务，因此从1到5的事务已在此副本上了。这样我们就完成了一个新 replicas 的搭建。

     

    方案二：使用percona-toolkit进行数据修复

    PT工具包中包含pt-table-checksum和pt-table-sync两个工具，主要用于检测主从是否一致以及修复数据不一致情况。

     

    前提条件

    MySQL 机器上需要安装 percona-toolkit 工具

     

    优点

    修复速度快，不需要停止从库

     

    缺点

    操作复杂，操作前最后先备份数据库
    待修复的表需要具有 unique constraint

     

    操作步骤

     

    背景示例

    IP 关系对应

  • ?
  • 1
  • 2
  • 3
  • 4
    		•
  • | IP | Role |
  • | ---- | ---- |
  • | 192.168.100.132 | Master |
  • | 192.168.100.131 | Slave |
    		•

    • 假设待恢复的表结构如下所示

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
    		•
  • mysql> show create table test.t;
  • +-------+-------------------------------------
  • | Table | Create Table                                                                 |
  • +-------+-------------------------------------
  • | t   | CREATE TABLE `t` (
  •  `id` int(11) NOT NULL,
  •  `content` varchar(20) DEFAULT NULL,
  •  PRIMARY KEY (`id`)
  • ) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
  • +-------+-------------------------------------
    		•

    • 正常主备一致的情况下，Master 和 Slave 的数据均为如下所示

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
    		•
  • mysql> select * from test.t;
  • +----+---------+
  • | id | content |
  • +----+---------+
  • | 1 | a    |
  • | 2 | b    |
  • +----+---------+
  • 2 rows in set (0.00 sec)
    		•

    • 在极端情况下，假如出现了如下主备不一致的情况，情形如下：

    1. Master 新增了一条 id 为 3 的记录，如下所示，但并没有同步到 Slave，同时自动 failover 到了 Slave。
    2. Old Slave 作为 New Master 在服务了一段时间后，表中增加了新的记录。

    重新启动 Old Master 后，Old Master的数据如下所示:

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
    		•
  • old_master> select * from test.t;
  • +----+---------+
  • | id | content |
  • +----+---------+
  • | 1 | a    |
  • | 2 | b    |
  • | 3 | c    |
  • +----+---------+
  • 3 rows in set (0.00 sec)
    		•

    • New Master 的数据如下所示:

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
    		•
  • new_master> select * from test.t;
  • +----+---------+
  • | id | content |
  • +----+---------+
  • | 1 | a    |
  • | 2 | b    |
  • | 3 | cc   |
  • | 4 | dd   |
  • +----+---------+
  • 4 rows in set (0.00 sec)
    		•

    • 此时如果将 old master 配置为 new master 的slave，则会报错，比如出现如下报错

  • ?
  • 1
    		•
  • ...Last_IO_Error: binary log: 'Slave has more GTIDs than the master has, using the master's SERVER_UUID.
    		•

    • 可以看到 Old Master 的 GTID 已到 255

  • ?
  • 1
  • 2
    		•
  • Executed_Gtid_Set: 5b750c75-86c2-11eb-af71-000c2973a2d5:1-10,
  • 60d082ee-86c2-11eb-a9df-000c2988edab:1-255
    		•

    • 而 New Master 的 GTID才到254

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
    		•
  • mysql> show master status\G
  • *************************** 1. row ***************************
  •        File: mysql-bin.000001
  •      Position: 4062
  •    Binlog_Do_DB:
  •  Binlog_Ignore_DB:
  • Executed_Gtid_Set: 5b750c75-86c2-11eb-af71-000c2973a2d5:1-2,
  • 60d082ee-86c2-11eb-a9df-000c2988edab:1-254
  • 1 row in set (0.00 sec)
    		•

    • 此时我们配置 Old Master 跳过错误，将 Old Master 恢复成可以正常从 New Master 复制的状态

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
    		•
  • old_master> stop slave;
  • Query OK, 0 rows affected, 1 warning (0.00 sec)
  •  
  • old_master> set gtid_next='60d082ee-86c2-11eb-a9df-000c2988edab:254'; --Specify the version of the next transaction,the GTID you want to skip
  • Query OK, 0 rows affected (0.00 sec)
  •  
  • old_master> begin;
  • Query OK, 0 rows affected (0.00 sec)
  •  
  • old_master> commit;                          -- Inject an empty transaction
  • Query OK, 0 rows affected (0.00 sec)
  •  
  • old_master> set gtid_next='AUTOMATIC'；  -- Restore to automaic GTID
  • Query OK, 0 rows affected (0.00 sec)
  •  
  • old_master> start slave;
  • Query OK, 0 rows affected (0.13 sec)
    		•

    • 然后我们在 Old Master 上可以看到复制在正常进行

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
    		•
  • mysql> show slave status\G
  •       ...
  •        Slave_IO_Running: Yes
  •       Slave_SQL_Running: Yes
  •       ...
  •       Executed_Gtid_Set: 5b750c75-86c2-11eb-af71-000c2973a2d5:1-10,
  • 60d082ee-86c2-11eb-a9df-000c2988edab:1-255
  •         Auto_Position: 1
  •      Replicate_Rewrite_DB:
  •          Channel_Name:
  •       Master_TLS_Version:
    		•

    • 最后我们在 New Master 上清除 slave_master_info

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
    		•
  • new_master> reset slave all for channel '';
  • Query OK, 0 rows affected (0.00 sec)
  •  
  • new_master> show slave status\G;
  • Empty set (0.01 sec)
    		•

    •  

    校验一致性

    接下来我们要校验主从一致性，在 New Master上执行 pt-table-checksum，ROWS为4，存在一条DIFFS

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
    		•
  • [root@localhost ~]# pt-table-checksum h='127.0.0.1',u='mha',p='[PASSWORD]',P=3306 --no-check-binlog-format --databases test
  • Checking if all tables can be checksummed ...
  • Starting checksum ...
  •       TS ERRORS DIFFS   ROWS DIFF_ROWS CHUNKS SKIPPED  TIME TABLE
  • 03-29T19:24:18   0   1    4     1    1    0  0.322 test.t
    		•

    • 双向同步（同步操作会修改数据，操作前进行数据备份）

    在同步过程中，pt-table-sync 会在 Master 上进行数据修改，pt-table-sync的参数作用如下

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
    		•
  • pt-table-sync --databases test --bidirectional --conflict-column='*' --conflict-comparison 'newest' h='192.168.100.132',u='mha',p='[PASSWORD]',P=3306 h='192.168.100.131' --print
  • --database        指定待执行的数据库
  • --bidirectional      为双向同步
  • --conflict-column     对比该列当冲突发生时
  • --conflict-comparison   冲突对比策略
  • --print          输出对比结果
  • --dry-run         测试运行
  • --execute         执行测试
  •  
  • # 左边的DSN为 Slave
  • # 右边的DSN为 Master
    		•

    • 这里我们指定—conflict-name='content'作为对比列，一般使用业务主键作为该列。可以看到打印出了待执行的语句

  • ?
  • 1
  • 2
  • 3
    		•
  • [root@localhost ~]# pt-table-sync --databases test --bidirectional --conflict-column='content' --conflict-comparison 'newest' h='192.168.100.132',u='mha',p='[PASSWORD]',P=3306 h='192.168.100.131' --print
  • /*192.168.100.132:3306*/ UPDATE `test`.`t` SET `content`='cc' WHERE `id`='3' LIMIT 1;
  • /*192.168.100.132:3306*/ INSERT INTO `test`.`t`(`id`, `content`) VALUES ('4', 'dd');
    		•

    • 接下来执行语句

  • ?
  • 1
    		•
  • [root@localhost ~]# pt-table-sync --databases test --bidirectional --conflict-column='content' --conflict-comparison 'newest' h='192.168.100.132',u='mha',p='[PASSWORD]',P=3306 h='192.168.100.131' --execute
    		•

    • 然后在 Master 上再次执行数据对比，可以看到数据正常了

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
    		•
  • [root@localhost ~]# pt-table-checksum h='127.0.0.1',u='mha',p='[PASSWORD]',P=3306 --no-check-binlog-format --databases test
  • Checking if all tables can be checksummed ...
  • Starting checksum ...
  •       TS ERRORS DIFFS   ROWS DIFF_ROWS CHUNKS SKIPPED  TIME TABLE
  • 03-30T12:09:57   0   0    4     0    1    0  0.330 test.t
    		•

    • 以上就是MySQL GTID主备不一致的修复方案的详细内容，更多关于MySQL GTID主备不一致修复的资料请关注开心学习网其它相关文章！

    原文链接：https://nomansky.top/mysql-gtidzhu-bei-bu-yi-zhi-xiu-fu-fang-an/

    标签：
    mysql GTID 主备
    上一篇下一篇

    猜您喜欢

    热门推荐

    © 2021 开心学习