![Percona-Cluster:备份和恢复过程](https://linux22.com/image/799517/Percona-Cluster%EF%BC%9A%E5%A4%87%E4%BB%BD%E5%92%8C%E6%81%A2%E5%A4%8D%E8%BF%87%E7%A8%8B.png)
我正在尝试恢复从三节点 percona 集群的一个节点获取的完整备份(percona cluster 5.5、galera 2.1、wsrep sst 方法是 rsync、仅 innodb 表)。
备份如下:
rm -rf /tmp/backup/mysqldb
innobackupex --user=bkpuser --password=xxxx --galera-info --no-timestamp /tmp/backup/mysqldb/
innobackupex --apply-log --use-memory=2G /tmp/backup/mysqldb/
我尝试的恢复过程如下:
- 关闭所有三个节点上的 mysql
- 在第一个节点上
- 删除 mysql 数据目录的内容
- 删除 mysql redologs/binlogs、doublewrite 文件等(它们位于单独的文件夹中)
- 复制回我的数据库实例的数据库表空间文件
- 复制回 mysql 数据库的数据库表空间文件
- redologs/binlogs、doublewrite 文件等
- 启动 mysql 来
wsrep_urls = gcomm://
初始化集群
- 在第二和第三个节点上
- 删除 mysql redologs/binlogs、doublewrite 文件等
- 移除
galera.cache
并grastate.dat
- 启动 mysql (
wsrep_urls = gcomm://firstnode:port,gcomm://secondnode:port,gcomm://thirdnode:port
)
- 集群全部同步后,使用完整
wsrep_urls
配置重新启动第一个节点
(我知道 wsrep_urls 已被弃用,但我还没有让 galera 与 wsrep_cluster_address 一起工作。)
我的问题是第二和第三个节点在 SST 之后报告错误。对于每个表,我都会看到此错误:
130225 15:44:43 [ERROR] Cannot find or open table myTestDb/settings from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html
how you can resolve the problem.
Mysqlshow tables
显示表为现有,但是当尝试从中选择时,它会报告错误Table 'myTestDb.settings' does not exist
...
我尝试在启动 mysql 并请求 sst 之前删除本地表空间文件,结果相同。
我应该如何执行恢复?我应该将备份文件复制回所有节点吗?
答案1
您没有说您使用的是哪种 SST 方法。我猜是 xtrabackup?
您描述的第 2 和第 3 个节点的症状听起来像是 ibdata1 文件中的 Innodb 数据字典丢失(并重新初始化)。可能没有从第 1 个节点上的正确位置复制。
您提到了一些内容,例如“单独文件夹”中的 trx 日志和 doublewrite 文件。您的 my.cnf 中的 Innodb 设置是什么?您是否设置了 innodb_data_home_dir(并且它位于您的标准数据目录之外)?
如果是的话,很可能是这个错误:https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1098566或可能是与之类似的。
答案2
我花了很长时间才找到答案。如果你从捐赠节点读取 innobackup.backup.log 并观察添加节点中正在创建的数据,你就会知道为什么会发生这种情况。
我遇到了完全相同的问题。就我的情况而言,注释掉自定义的 innodb_data_home_dir 和 innodb_log_group_home_dir 值将解决问题。
与组同步后,只需启用这些值并复制文件。
希望这可以帮助。