為什麼還原 Amazon RDS for MySQL 資料庫執行個體的快照需要這麼長的時間？

簡短說明

較長的快照還原時間通常是因為長時間的資料庫復原所造成。復原時間取決於擷取快照時執行個體的工作負載。如果來源資料庫執行個體已啟用二進位日誌，則復原可能需要更長的時間。因此，您的快照還原持續時間也可能受到影響。

解決方案

當您還原快照時，Amazon RDS 會執行復原程序，並在新的資料庫執行個體上啟動 MySQL 資料庫引擎。新的資料庫執行個體啟動可能需要幾分鐘的時間，視執行個體啟動期間的復原工作階段長度而定。如需更多資訊，請參閱 MySQL 網站上的 InnoDB 當機復原。

**注意事項：**磁碟區在從 Amazon Simple Storage Service (Amazon S3) 完整充實之前，您會遇到一些延遲 (或延遲載入)。如需延遲載入的詳細資訊，請參閱從快照還原。

若要縮短 Amazon RDS 中的快照還原完成時間，請考慮下列事項：

• 排程備份時段，或在離峰時段建立資料庫執行個體的手動快照。擷取快照時，在來源資料庫執行個體上執行的活動會影響資料庫復原時間和任何快照的還原時間。
• 如果來源執行個體在快照期間使用磁帶儲存類型，則新還原的執行個體將處於修改狀態。例如，當您將資料庫快照還原為一般用途 SSD (GP2) 或佈建 IOPS (PIOPS) 儲存類型時，就會發生基礎磁碟區變更。因此，您的新執行個體會指示「修改」狀態。在此期間，您仍然可以連線至 Amazon RDS 執行個體，不過您可能會遇到一些效能降級的情況。
• 暫時將執行個體還原到較高的資料庫執行個體類別 (例如具有更多記憶體或 RAM 的執行個體類別)。藉由升級資料庫執行個體類別，可以縮短當機復原時間。您暫時獲得更多資源，這有助於加快整體當機復原時間。快照還原完成後，您可以縮減執行個體類別的規模。

若要減少在 Amazon RDS 中啟用二進位日誌的快照還原完成時間，請考慮下列事項：

• 啟用二進位日誌時 (例如，來源執行個體已啟用自動備份)，二進位日誌會直接影響快照還原時間。在當機復原期間，快照還原程序也會執行二進位日誌復原。
• 若要減少 binlog 復原時間，請避免使用大型交易和大型 binlog 檔案。二進位日誌中記錄的資料越多，還原程序在 binlog 復原期間必須處理的資料就越多。因此，復原時間會增加，這也會增加快照還原時間。
• 盡可能使用正確的交易大小。大型交易會一次寫入二進位日誌檔案，且不會在不同的檔案之間分割。因此，二進位日誌檔案最終會變得很大，增加當機復原時間。
• 使用的二進位日誌格式類型也會影響復原的大小和效率。某些格式 (例如以資料列為基礎的記錄) 在二進位日誌中記錄的資訊比其他格式更多。修改資料表中大量資料列的陳述式會導致資料庫引擎針對每個修改的資料列產生 binlog 項目。因此，您會獲得一個較大的 binlog 檔案。如需以資料列為基礎的記錄格式詳細資訊，請參閱 MySQL 網站上以資料列為基礎的記錄和複寫的使用方式。如需有關不同類型二進位記錄格式的詳細資訊，請參閱 MySQL 網站上以陳述式和資料列為基礎的複寫優缺點。