MySQL GTID主备不一致修复方案

最新推荐文章于 2024-12-26 16:58:34 发布

原创

最新推荐文章于 2024-12-26 16:58:34 发布 · 966 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#mysql #数据库 #java #分布式 #面试

本文详细介绍了两种MySQL GTID主备不一致的修复方案：一是通过重建Replicas，包括操作步骤和优缺点；二是利用percona-toolkit进行数据修复，包括工具的使用、优缺点和具体步骤。内容深入且实用，适合数据库管理员参考。

方案一：重建 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]

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，进行如下配置

最低0.47元/天解锁文章