為什麼執行 Amazon RDS for MySQL 執行個體的時間點復原時需要很長的時間？

簡短說明

時間點復原 (PITR) 是將資料庫還原至特定日期和時間狀態的流程。當您啟動 PITR 時，系統會還原最新備份（自動或手動）。然後會套用交易日誌，將 Amazon RDS 資料庫向前復原至 PITR 時間。

解決方法

避免冗長時間點復原的最佳實務

若要避免冗長時間點復原，請遵循下列最佳實務：

• 建立災難復原策略。
• 使用規模較小的交易，然後更頻繁地執行 COMMIT 命令。
• 若要執行大型交易，請在大型交易前後建立快照。但是，大於 max_allowed_packet 參數的交易會造成 PITR 失敗。
• 將快照還原時間降至最低。快照還原的初始化為時間點復原流程的一部分。快照還原的時間較長，時間點復原工作階段就會需要更長的時間。如需詳細資訊，請參閱為什麼還原 Amazon RDS for MySQL 資料庫執行個體的快照需要這麼長的時間？
• 日誌套用流程會需要一些時間，視要套用的日誌數量而定。若要減少要套用的日誌數量，請考慮在自動備份之間建立手動快照。由於時間點復原會自動選擇在 PITR 時間附近建立的自動或手動快照，因此擁有中繼手動快照可減少要套用的日誌數量。如果您正在處理大量變更，請每 3 至 4 小時建立一次手動快照。
• 如果您重新執行任何大型機要，則低的 wait_timeout 值會中斷 Amazon RDS for MySQL 中的時間點復原流程。例如，如果您執行大型資料列型大量更新、插入或刪除，而且重新執行所需時間比 wait_timeout 更長時，即會發生中斷情況。若要防止 PITR 流程中發生任何中斷，請將 wait_timeout 值設為「600」（10 分鐘）以上。如需詳細資訊，請參閱設定 Amazon RDS for MySQL 參數的最佳實務中的 wait_timeout 區段。
• 使用資料列型二進位日誌記錄時，請考慮將 binlog_row_image 參數值設為「MINIMAL」，而不是「FULL」。此更新值會減少二進位日誌的大小，並將 Binlog 復原時間降至最低。
• 除非您需要特定的 Binlog 格式，否則請考慮使用混合的日誌記錄格式。透過混合的日誌記錄，預設會使用陳述式型日誌記錄，但日誌記錄模式會在必要時自動切換至資料列型。此切換有助於減少 Binlog 大小。如需混合日誌記錄的詳細資訊，請參閱 MySQL 網站上的二進位日誌記錄格式。

時間點復原失敗

下列案例會造成時間點復原失敗：

• 處於「儲存空間已滿」狀態的資料庫執行個體。
• 使用 MySQL 中的 MyISAM 資料表。MyISAM 儲存引擎不支援可靠的當機復原流程。MyISAM 資料表會讓時間點復原流程無法正常運作。
• 使用暫時資料表、分散式交易及記憶體資料表。