我们最近升级了一个MySQL 5.0 master-master安装到Percona 5.6。 因为我们的一些故障，从属于b0rken，但我们认为我们可以通过使用xtrabackup从正在运行的服务器创build备份并将其导入从服务器来简单地修复它。 我整个周末都试图这样做（部分原因是因为这是一个庞大的数据库和表），但无济于事。 有人能说出我在这里做错了什么吗？
首先，我在生产大师当前运行以下内容：
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（在我浏览/ srv / mysql目录之后，这是我们的数据库）。 数据在那里，数据库运行正常。 现在我开始从事这个数据库：
/usr/bin/mysql --defaults-file=/etc/mysql/debian.cnf -e "CHANGE MASTER TO MASTER_HOST='10.xxx', 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: )
您必须告诉从服务器在备份时，主服务器上执行的最后一个GTID是什么。
NewSlave > SET GLOBAL gtid_purged="XXXX"; NewSlave > CHANGE MASTER TO MASTER_HOST="10.xxx", 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