RDS MySQL物理备份文件恢复到自建数据库

• Q：为什么下载数据文件会报错？

  A：使用wget -c 'https://****.bak.rds.aliyuncs.com/****_xb.qp?****' -O test_xb.qp命令下载时请用2个英文单引号（'）将下载地址包裹起来，便于程序识别具体的地址，防止出错。

tar -izxvf test.tar.gz -C /var/mysql_bkdata/

### MySQL 8.0
gzip -d -c test.xb.gz | /u01/xtrabackup80/bin/xbstream -x -v -C /var/mysql_bkdata/

### MySQL 5.5/5.6/5.7
gzip -d -c test.xb.gz | xbstream -x -v -C /var/mysql_bkdata/

## 步骤一：解包
cat test_qp.xb | xbstream -x -v -C /var/mysql_bkdata/

## 步骤二：解压
### MySQL 5.5/5.6/5.7
innobackupex --decompress --remove-original /var/mysql_bkdata/

### MySQL 8.0
/u01/xtrabackup80/bin/xtrabackup --decompress --remove-original --target-dir=/var/mysql_bkdata/

• Q：下载的备份文件解压缩报错怎么办？

  A：请根据如下步骤检查或处理报错：

  确认您下载的文件是否为物理备份文件。

  请确认压缩文件保存的名称后缀是否正确（使用URL中包含的文件名后缀xb.qp、.tar.gz、.xb.gz或_qp.xb）。

  针对不同格式的压缩文件，请使用本步骤提供的解压命令。

  常见的报错如下：

  • 执行解压命令出现sh: qpress: command not found报错。

    解决方法：请参考本文前提条件确认您自建库所在服务器中是否已安装解压工具qpress。

  • 备份文件类型为xbstream文件包（_qp.xb 后缀），执行解压命令出现innobackupex未找到。

    解决方法：请参考本文前提条件确认您自建库所在服务器中是否已安装Percona XtraBackup。

  • 出现报错：备份文件类型为xbstream文件包（_qp.xb 后缀），执行cat解包命令出现can't change to dir to xx( errorcode:no such file or directory)报错。

    解决方法：报错原因可能是命令中文件名或路径错误引起，请确认文件名和路径是否正确。

• Q：系统返回报错xtrabackup: Unknown error 3613，如何处理？

  A：请将Percona XtraBackup更新到最新版本后再次尝试。

• Q：系统返回报错Original data directory /var/mysql_newdata is not empty!，如何处理？

  A：使用sudo rm -rf /var/mysql_newdata/*命令清空文件夹内文件，然后在重新执行恢复操作。

• Q：系统返回报错InnodDB: Encryption information in datafile: ./xxx.ibd can't be decrypted, please check if a keyring plugin is loaded and initialized successfully.，如何处理？

  请检查实例是否开启了TDE加密：

  • 如果开启了TDE加密，请确认是否存在加密过的表，请参见本文前提条件，先对已加密的表执行设置透明数据加密TDE，然后重新根据本文操作指引进行恢复。

  • 如果未开启TDE加密，请确保您的Percona XtraBackup版本正确，请参见准备工作安装。

• Q：已下载的备份文件发现存在TDE加密的数据，导致恢复数据出错，有什么解决办法？

  A：该情况下无法基于已下载的加密的备份文件进行恢复。RDS实例中如果存在加密过的表，会导致恢复过程出错。请参见本文前提条件，先对已加密的表执行设置透明数据加密TDE，然后重新根据本文操作指引进行恢复。

• Q：恢复时报错innobackupex: File 'undo001' not found (Errcode: 2 - No Such file or directory)如何处理？

  A：undo文件为系统文件，不同版本数据库间存在差异，请检查本地自建数据库的版本是否与RDS MySQL数据库版本一致。

• Q：Ubuntu操作系统报错mysqld: [ERROR] Failed to open required defaults file: /etc/my.cnf，是为什么，怎么处理？

  A：该报错是由Ubuntu自带安全程序AppArmor导致的，请使用apt install -y apparmor-utils和aa-complain /usr/sbin/mysqld命令修改AppArmor设置。

• Q：恢复完成后，无法启动自建库或在使用自建库的过程中遇到error 1105 Unknown error错误怎么办？

  A：执行如下SQL语句转换数据库存储引擎即可：

  USE mysql;
  ALTER TABLE proc engine=myisam;
  ALTER TABLE event engine=myisam;
  ALTER TABLE func engine=myisam;

  说明

  如果执行上述语句报错ERROR 1067 (42000): Invalid default value for 'modified'，请先执行SET SQL_MODE='ALLOW_INVALID_DATES';语句。

• Q：数据库恢复后，root密码是多少？

  A：根据版本不同，root密码获取方法如下：

  • 如果您的实例版本为MySQL 5.7或8.0，则root密码即自建库的root密码。

  • 如果您的实例版本为MySQL 5.5或5.6，需要重置root密码方可正常使用。更多信息，请参见官方文档。

• Q：启动时报错InnodDB: Assertion failure in thread 140xxx in file page0zip.icne xxx，如何处理？

  A：造成该报错的原因可能是系统磁盘空间不足，您可以尝试扩容自建数据库所在服务器的磁盘后，再进行尝试。

• Q：启动时报错[ERROR] Failed to open the relay log xxx、[ERROR] Slave: Failed to initialize the master info xxx、[ERROR] Failed to create or recover replication info repositories.，如何处理？

  A：该报错是由于RDS实例为高可用，而本地自建数据库不涉及主备节点而导致的，不影响数据库启动，无需关注。

• Q：为什么阿里云物理备份还原到自建MySQL上以后，数据的时间字段和本地时间不一致？怎样才能保持时间一致？

  A：如果自建库的时区与RDS实例的时区不一致，则需要修改自建库的time_zone参数，使其与RDS实例的time_zone参数一致。如果RDS实例的time_zone参数值为system，则需查看RDS实例所在的地域，并将自建库的time_zone设置为该地域的时区。

• Q：连接自建数据库时报错Access denied for user 'XXX'，如何处理？

  A：请检查RDS MySQL实例账号或密码是否正确，使用的账号和密码为RDS中创建的账号和密码。

• Q：连接自建数据库时，忘记密码了怎么办？

  A：若忘记账号或密码，请在执行启动MySQL进程命令时，传入--skip-grant-tables参数，进程启动后会忽略权限检查，从而此步骤无需账户密码就可登录数据库。您可在登录成功后重新再修改账号和密码。

• Q：连接自建数据库后，只看到系统库或部分数据库怎么处理？

  A：请重启数据库后，使用root账号或原RDS实例中的高权限账号连接数据库查看。