本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
Amazon Aurora 可靠性
Aurora 的設計目的是要既可靠、耐用且容錯。您可以架構您的 Aurora 資料庫叢集，以透過執行一些動作 (例如新增 Aurora 複本並將其放置在不同的可用區域) 來改善可用性，而 Aurora 也包括數個自動功能，因此是可靠的資料庫解決方案。
儲存體自動修復
因為 Aurora 會在三個可用區域內維持您資料的多個副本，所以，因磁碟故障導致資料遺失的機率會大幅降低。Aurora 會自動偵測在組成叢集磁碟區的磁碟區中所發生的故障。磁碟區的區段失敗時，Aurora 會立即修復該區段。當 Aurora 修復磁碟區段時，它會使用組成叢集磁碟區的其他磁碟區中資料，以確保中修復的區段的資料是最新的。因此，Aurora 可避免資料遺失，並減少執行 point-in-time還原以從磁碟故障中復原的需求。
可存活的頁面快取
在 Aurora 中，每個資料庫執行個體的頁面快取是以與資料庫不同的程序管理，這可讓頁面快取獨立於資料庫存活。（頁面快取也稱為 Aurora MySQL 上的 InnoDB 緩衝區集區，以及 Aurora Postgre 上的緩衝區快取SQL。)
萬一資料庫發生故障，頁面快取仍會保留在記憶體中，這會在資料庫重新啟動時讓目前資料頁面在頁面快取中保持為「暖」的狀態。這會避開需要初始查詢來執行讀取 I/O 操作讓頁面快取「暖機」，進而提供效能增益。
對於 Aurora MySQL，重新啟動和容錯移轉時的頁面快取行為如下：
-
您可以重新啟動寫入器執行個體，而無需重新啟動讀取器執行個體。
-
如果讀取器執行個體在寫入器執行個體重新啟動時未重新啟動，並不會失去其頁面快取。
-
如果讀取器執行個體在寫入器執行個體重新啟動時重新啟動，則確實會失去其頁面快取。
-
-
當讀取器執行個體重新啟動時，寫入器和讀取器執行個體上的頁面快取都會存在。
-
當資料庫叢集容錯移轉時，效果與寫入器執行個體重新啟動時的效果類似。在新的寫入器執行個體 (先前是讀取器執行個體) 上，頁面快取仍會存在，但在讀取器執行個體 (先前是寫入器執行個體) 上，頁面存取不會存在。
對於 Aurora PostgreSQL，您可以使用叢集快取管理來保留在容錯移轉後成為寫入器執行個體的指定讀取器執行個體的頁面快取。如需詳細資訊，請參閱Aurora PostgreSQL 的容錯移轉後使用叢集快取管理快速復原。
從非計劃的重新啟動中復原
Aurora 旨在幾乎立即從非計劃的重新啟動中復原，並在沒有二進位日誌的情況下，繼續為應用程式資料提供服務。Aurora 會在平行執行緒上以非同步的方式復原，以便資料庫在非計劃的重新啟動之後立即開啟並可用。
如需詳細資訊，請參閱 Aurora 資料庫叢集的容錯能力 和 最佳化以減少資料庫重新啟動時間。
以下是 Aurora My 上二進位記錄和意外重新啟動復原的考量SQL：
-
在 Aurora 上啟用二進位日誌會直接影響非計劃重新啟動之後的復原時間，因為它會強迫資料庫執行個體執行二進位日誌復原。
-
使用的二進位日誌類型會影響日誌的大小和效率。針對相同數量的資料庫活動，有些格式會記錄較其他二進位日誌更多的資訊。下列
binlog_format參數的設定會造成不同數量的日誌資料：-
ROW– 最多日誌資料 -
STATEMENT– 最少日誌資料 -
MIXED– 中等數量的日誌資料，通常可提供資料完整性和效能的最佳組合
二進位日誌資料的數量會影響復原時間。如果二進位日誌中記錄了較多資料，資料庫執行個體必須在復原期間處理更多資料，而這會增加復原時間。
-
-
若要透過二進位記錄減少運算額外負荷並改善復原時間，您可以使用增強的 binlog。增強的 binlog 可將資料庫復原時間提升高達 99%。如需詳細資訊，請參閱設定 Aurora MySQL 的增強型 binlog。
-
Aurora 不需要二進位日誌，即可複寫資料庫叢集內的資料或執行 point-in-time還原 (PITR)。
-
如果您不需要二進位日誌用於進行外部複寫 (或外部二進位日誌資料流)，建議您將
binlog_format參數設定為OFF來停用二進位日誌。這麼做可減少復原時間。
如需 Aurora 二進位日誌和複寫的詳細資訊，請參閱 以 Amazon Aurora 進行複寫。如需不同 MySQL 複寫類型影響的詳細資訊，請參閱 MySQL 文件中的陳述式型和資料列型複寫的優點和缺點
