☰

XtraBackup 恢复会在从属上产生重复吗？

tag-icon • tag-icon mysql-replication percona master-slave xtrabackup mysql5.6
XtraBackup 恢复会在从属上产生重复吗？

我们最近将 MySQL 5.0 主主设置升级到 Percona 5.6。由于我们这边的一些故障，从属服务器中断了，但我们认为我们可以通过使用 xtrabackup 从正在运行的服务器创建备份并将其导入到从属服务器来简单地修复它。整个周末我都在尝试这样做（部分原因是它是一个拥有大量数据库和表的庞大数据库），但无济于事。有人能解释一下我在这里可能做错了什么吗？

首先，我在当前生产主机上运行以下命令：

ulimit -n 409600 innobackupex --defaults-file=/etc/mysql/debian.cnf /mnt

完成后，我将结果目录复制到另一台服务器并运行：

innobackupex --use-memory=4G --apply-log /srv/restore

它最终会退出并显示 OK 消息。现在我使用以下命令将其恢复到数据库：

innobackupex --move-back /srv/restore

一切顺利，我可以再次启动 MySQL（在我 chown /srv/mysql 目录之后，这是我们的数据目录）。数据在那里，数据库运行良好。现在我开始在这个数据库上执行从属操作：

/usr/bin/mysql --defaults-file=/etc/mysql/debian.cnf -e "CHANGE MASTER TO MASTER_HOST='10.x.x.x', MASTER_USER='replication', MASTER_PASSWORD='verysecret', MASTER_AUTO_POSITION=1; START SLAVE"

从属启动，但由于 1062 错误立即停止。经过调查，我发现它试图应用的条目是在我开始备份后立即添加到主数据库上的。我可以修复它，但我立即收到一个新错误。

在我看来，备份似乎不包含所有最新的 GTID，只包含备份开始时可用的 GTID？我认为这正是 XtraBackup 应该修复的问题？我现在没有其他办法来确保在备份期间不对数据库进行任何写入。我在这里做错了什么吗？这应该发生吗？

在 Debian Wheezy 上运行并安装所有最新补丁。

Server version: 5.6.25-73.1-log Percona Server (GPL), Release 73.1, Revision 07b797f $ innobackupex --version InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy and Percona LLC and/or its affiliates 2009-2013. All Rights Reserved. $ xtrabackup --version xtrabackup version 2.2.11 based on MySQL server 5.6.24 Linux (x86_64) (revision id: )

答案1

您必须告诉从属服务器在备份时在主服务器上执行的最后一个 GTID 是什么。

NewSlave > SET GLOBAL gtid_purged="XXXX";
NewSlave > CHANGE MASTER TO
           MASTER_HOST="10.x.x.x",
           MASTER_USER="replication",
           MASTER_PASSWORD="verysecret",
           MASTER_AUTO_POSITION = 1;
NewSlave > START SLAVE;
NewSlave > SHOW SLAVE STATUS \G;

来源：https://www.percona.com/doc/percona-xtrabackup/2.1/howtos/recipes_ibkx_gtid.html

相关内容