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

来源:脚本之家  责任编辑:小易  

方案一:重建 Replicas

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

前提条件

MySQL 机器上需要安装 percona xtrabackup

优点

比较安全,操作简单

缺点

数据量较大的时候备份所需的时间比较久 当数据库有做读写分离的时候,Slave 承担的读请求需要转移到 Master

操作步骤

Master

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

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

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

Slave

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

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

备份并删除 Slave data目录

systemctl stop mysqld
mv /data/mysql{,.bak}

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

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,如下示例

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

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

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

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

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 的复制状态是否正常

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 关系对应

| IP | Role |
| ---- | ---- |
| 192.168.100.132 | Master |
| 192.168.100.131 | Slave |

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

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 的数据均为如下所示

mysql> select * from test.t;
+----+---------+
| id | content |
+----+---------+
| 1 | a    |
| 2 | b    |
+----+---------+
2 rows in set (0.00 sec)

在极端情况下,假如出现了如下主备不一致的情况,情形如下:

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

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

old_master> select * from test.t;
+----+---------+
| id | content |
+----+---------+
| 1 | a    |
| 2 | b    |
| 3 | c    |
+----+---------+
3 rows in set (0.00 sec)

New Master 的数据如下所示:

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,则会报错,比如出现如下报错

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

可以看到 Old Master 的 GTID 已到 255

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

而 New Master 的 GTID才到254

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 复制的状态

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 上可以看到复制在正常进行

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

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

[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的参数作用如下

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'作为对比列,一般使用业务主键作为该列。可以看到打印出了待执行的语句

[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');

接下来执行语句

[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 上再次执行数据对比,可以看到数据正常了

[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主备不一致修复的资料请关注真格学网其它相关文章!

您可能感兴趣的文章:MySQL GTID全面总结MYSQL数据库GTID实现主从复制实现(超级方便)MySQL5.6 GTID模式下同步复制报错不能跳过的解决方法Mysql GTID Mha配置方法MySQL5.7不停业务将传统复制变更为GTID复制的实例详解MySQL主从复制实战 - 基于GTID的复制MySQL 5.6 GTID新特性实践MySQL5.6基于GTID的主从复制在MySQL中使用GTIDs复制协议和中断协议的教程MySQL是如何实现主备同步关于mysql主备切换canal出现的问题解决基于mysql+mycat搭建稳定高可用集群负载均衡主备复制读写分离操作

  • 本文相关:
  • mysql slave 触发 oom-killer解决方法
  • mysql字符编码设置方法
  • mysql实现当前数据表的所有时间都增加或减少指定的时间间隔(推荐
  • mysql like模糊查询通配符使用详细介绍
  • mysql实现不用密码登录的实例方法
  • mysql中的常用工具实例汇总(推荐)
  • 解决mysql与navicat建立连接出现1251错误
  • mysql中多表删除其中id相同记录的方法
  • mysql 关于两个经纬度之间的距离由近及远排序
  • mysql忘记密码修改方式适应5.7以上版本
  • MySQL主从数据不一致,需要重新关联
  • mysql 如果出现主从数据不一致情况怎么弄
  • mysql主主同步,从库不同步应该怎么解决
  • 怎样解决线上MySQL主从不一致问题探讨
  • mysql双机热备份之后从库的数据和主库不一致该怎么办
  • 基于GTID的MySQL Replication的主键冲突
  • mysql的slave报1236的话如何自动修复呢
  • mysql gtid怎么解决master宕机
  • mysql主从错误断开 怎样恢复
  • 详解Mysql自动备份与恢复的几种方法(图文教
  • 网站首页网页制作脚本下载服务器操作系统网站运营平面设计媒体动画电脑基础硬件教程网络安全mssqlmysqlmariadboracledb2mssql2008mssql2005sqlitepostgresqlmongodbredisaccess数据库文摘数据库其它首页mysql gtid全面总结mysql数据库gtid实现主从复制实现(超级方便)mysql5.6 gtid模式下同步复制报错不能跳过的解决方法mysql gtid mha配置方法mysql5.7不停业务将传统复制变更为gtid复制的实例详解mysql主从复制实战 - 基于gtid的复制mysql 5.6 gtid新特性实践mysql5.6基于gtid的主从复制在mysql中使用gtids复制协议和中断协议的教程mysql是如何实现主备同步关于mysql主备切换canal出现的问题解决基于mysql+mycat搭建稳定高可用集群负载均衡主备复制读写分离操作mysql slave 触发 oom-killer解决方法mysql字符编码设置方法mysql实现当前数据表的所有时间都增加或减少指定的时间间隔(推荐mysql like模糊查询通配符使用详细介绍mysql实现不用密码登录的实例方法mysql中的常用工具实例汇总(推荐)解决mysql与navicat建立连接出现1251错误mysql中多表删除其中id相同记录的方法mysql 关于两个经纬度之间的距离由近及远排序mysql忘记密码修改方式适应5.7以上版本mysql安装图解 mysql图文安装教程can""""t connect to mysql servwindows下mysql5.6版本安装及配置mysql字符串截取函数substring的mysql创建用户与授权方法mysql提示:the server quit withmysql——修改root密码的4种方法mysql日期数据类型、时间类型使用mysql之timestamp(时间戳)用法mysql update语句的用法详解mysql中数据库与数据表编码格式的查看、创mysql event scheduler(事件调度器)mysql解压版配置步骤详细教程ubuntu上mysql的安装及使用(通用版)mysql mgr 单主多主模式切换知识点详解mysql开启慢查询(explain sql语句使用介绍mysql创建和删除数据库的命令及相关php脚mysql处理重复数据的方法mysql关于error 1290 (hy000)报错解决方法两大步骤教您开启mysql 数据库远程登陆帐
    免责声明 - 关于我们 - 联系我们 - 广告联系 - 友情链接 - 帮助中心 - 频道导航
    Copyright © 2017 www.zgxue.com All Rights Reserved