ApsaraDB RDS：RDS MySQL物理備份檔案恢複到自建資料庫

• Q：為什麼下載資料檔案會報錯？

  A：使用wget -c 'https://****.bak.rds.aliyuncs.com/****_xb.qp?****' -O test_xb.qp命令下載時請用2個英文單引號（'）將下載地址包裹起來，便於程式識別具體的地址，防止出錯。

執行以下解壓命令時，將test_xb.qp替換為您另存新檔的備份檔案名，/var/mysql_bkdata/替換為您建立的備份解壓路徑。

### MySQL 8.0
qpress -do  test_xb.qp | /u01/xtrabackup80/bin/xbstream -x -v -C /var/mysql_bkdata/

### MySQL 5.5/5.6/5.7
qpress -do  test_xb.qp | xbstream -x -v -C /var/mysql_bkdata/

執行以下解壓命令時，請將test_qp.xb替換為您另存新檔的備份檔案名，/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/

執行以下解壓命令時，請將test.tar.gz替換為您另存新檔的備份檔案名，/var/mysql_bkdata/替換為您建立的備份解壓路徑。

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

執行以下解壓命令時，請將test.xb.gz替換為您另存新檔的備份檔案名，/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/

• 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：啟動時報錯[ERROR] Data Dictionary initialization failed如何處理？

  A：該報錯可能由作業系統不相容導致，RDS底層作業系統為Linux，建議使用Linux作業系統恢複資料庫，不同作業系統恢複可能會有版本相容問題。

• Q：使用sudo systemctl start mysqld啟動本地MySQL失敗，如何處理？

  A：可能由於Linux系統的SELinux為強制模式（Enforcing mode）引起。通過getenforce命令可以查看SELinux的目前狀態。

  • 如果是開發或測試環境，建議將SELinux模式修改為許可模式（Permissive mode）後，再嘗試使用sudo systemctl start mysqld啟動MySQL。

  • 如果是生產環境，建議詳細檢查 SELinux日誌確認MySQL無法啟動的具體原因，並根據這些資訊修複SELinux策略。

• 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參數，進程啟動後會忽略許可權檢查，允許無需賬戶密碼登入資料庫。請注意，使用--skip-grant-tables參數存在安全風險，建議在登入成功後立即修改帳號和密碼。

• Q：串連自建資料庫後，只看到系統庫或部分資料庫怎麼處理？

  A：請重啟資料庫後，使用root帳號或原RDS執行個體中的高許可權帳號串連資料庫查看。