為什麼我的 Amazon Aurora 資料庫叢集的複製、快照還原或時間點還原需要這麼長時間？

簡短說明

Amazon Aurora 的持續備份和還原技術經過最佳化，可避免還原時間出現變化。這些技術還可協助叢集的儲存磁碟區在叢集可供使用時立即達到完整效能。還原時間較長通常是由於進行備份時，來源資料庫中長時間執行的交易所造成。

解決方案

**注意事項：**如果您在執行 AWS Command Line Interface (AWS CLI) 命令時收到錯誤訊息，請確認您使用的是最新的 AWS CLI 版本。

Amazon Aurora 會自動且持續地備份叢集磁碟區的變更。備份的保留時間長度為備份保留期。這種持續備份可讓您將資料還原到新叢集，並還原到指定保留期內的任何時間點。這可避免需要執行冗長的二進位日誌向前復原程序。由於您建立了新叢集，因此不會影響原始資料庫的效能或造成中斷。

當您啟動複製、快照或時間點還原時，Amazon Relational Database Service (Amazon RDS) 會代表您呼叫下列 API：

• RestoreDBClusterFromSnapshot 或 RestoreDBClusterToPointInTime。這些 API 會建立新叢集，並從 Amazon Simple Storage Service (Amazon S3) 還原磁碟區。此作業最多可能需要幾個小時才能完成。當您將資料還原到 Aurora 叢集時，所有資料都會從 Amazon S3 平行傳輸到三個可用區域上的六個副本。
• 叢集儲存磁碟區複製是 RestoreDBClusterToPointInTime 的變體。其使用寫入時複製通訊協定，通常可在幾分鐘內完成。

完成此步驟時，叢集會變更為「可用」狀態。您可以透過重新整理主控台或使用 AWS CLI 來檢查叢集狀態。

只有在叢集可用時，執行個體建立程序才會啟動。這種情況分為兩個階段：設定執行個體組態和資料庫損毀復原。

您可以透過尋找 MySQL 錯誤日誌檔來檢查 API 是否已完成執行個體的設定。即使執行個體處於「正在建立」狀態，也可以執行這項操作。如果錯誤日誌檔可供下載，則表示執行個體已設定，而引擎目前正在執行損毀復原。錯誤日誌檔也是檢查資料庫損毀復原進度以及 Amazon CloudWatch 指標的最佳資源。

**注意事項：**如果您使用 AWS CLI 或 API 執行還原作業，則必須叫用 CreateDBInstance 呼叫，因為該呼叫不是自動的。

檢查來源資料庫上是否有長時間執行的寫入作業

最佳實務是確認在快照、時間點或複製時，來源資料庫上沒有長時間執行的寫入作業。任何長時間執行的 DCL、DDL 或 DML (開放式寫入交易) 都可能會延長還原資料庫變成可用狀態所需的時間。

例如，若為 Aurora 叢集啟用二進位日誌，則會增加執行復原所需的時間。這是因為 InnoDB 會自動檢查日誌，並將資料庫向前復原到當前。然後，它會回復復原時存在的任何未認可交易。如需 InnoDB 損毀復原的相關資訊，請參閱 Innodb 復原。

執行個體完成建立和復原程序後，叢集和執行個體就可以接受傳入連線。

注意事項： Aurora 不需要二進位日誌。除非必要，否則最佳實務就是停用該功能。對於跨區域複寫，您可以改為評估 Aurora 全域資料庫。Aurora 全域資料庫也不需要二進位日誌。

---

相關資訊

Amazon Aurora 儲存體和可靠性

從資料庫叢集快照還原