本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Amazon Aurora 可靠性
<a name="Aurora.Overview.Reliability"></a>

 Aurora 的設計目的是要既可靠、耐用且容錯。您可以架構您的 Aurora 資料庫叢集，以透過執行一些動作 (例如新增 Aurora 複本並將其放置在不同的可用區域) 來改善可用性，而 Aurora 也包括數個自動功能，因此是可靠的資料庫解決方案。

**Topics**
+ [儲存體自動修復](#Aurora.Overview.AutoRepair)
+ [可存活的頁面快取](#Aurora.Overview.CacheWarming)
+ [從非計劃的重新啟動中復原](#Aurora.Overview.RestartRecovery)

## 儲存體自動修復
<a name="Aurora.Overview.AutoRepair"></a>

 因為 Aurora 會在三個可用區域內維持您資料的多個副本，所以，因磁碟故障導致資料遺失的機率會大幅降低。Aurora 會自動偵測在組成叢集磁碟區的磁碟區中所發生的故障。磁碟區的區段失敗時，Aurora 會立即修復該區段。當 Aurora 修復磁碟區段時，它會使用組成叢集磁碟區的其他磁碟區中資料，以確保中修復的區段的資料是最新的。因此，Aurora 可避免資料遺失並減少執行時間點還原以從磁碟失敗復原的需求。

## 可存活的頁面快取
<a name="Aurora.Overview.CacheWarming"></a>

在 Aurora 中，每個資料庫執行個體的頁面快取是以與資料庫不同的程序管理，這可讓頁面快取獨立於資料庫存活。(頁面快取在 Aurora MySQL 上也稱為 InnoDB *緩衝集區*，在 Aurora PostgreSQL 上則稱為*緩衝快取*。)

萬一資料庫發生故障，頁面快取仍會保留在記憶體中，這會在資料庫重新啟動時讓目前資料頁面在頁面快取中保持為「暖」的狀態。這會避開需要初始查詢來執行讀取 I/O 操作讓頁面快取「暖機」，進而提供效能增益。

對於 Aurora MySQL，當重新啟動和容錯移轉時的頁面快取行為如下：
+ 您可以重新啟動寫入器執行個體，無需重新啟動讀取器執行個體。
  + 如果讀取器執行個體在寫入器執行個體重新啟動時未重新啟動，並不會失去其頁面快取。
  + 如果讀取器執行個體在寫入器執行個體重新啟動時重新啟動，則確實會失去其頁面快取。
+ 當讀取器執行個體重新啟動時，寫入器和讀取器執行個體上的頁面快取都會存在。
+ 當資料庫叢集容錯移轉時，效果與寫入器執行個體重新啟動時的效果類似。在新的寫入器執行個體 (先前是讀取器執行個體) 上，頁面快取仍會存在，但在讀取器執行個體 (先前是寫入器執行個體) 上，頁面存取不會存在。

對於 Aurora PostgreSQL，您可以使用叢集快取管理來保留在容錯移轉後，成為寫入器執行個體的所指定讀取器執行個體其頁面快取。如需更多詳細資訊，請參閱 [Aurora PostgreSQL 的容錯移轉後使用叢集快取管理快速復原](AuroraPostgreSQL.cluster-cache-mgmt.md)。

## 從非計劃的重新啟動中復原
<a name="Aurora.Overview.RestartRecovery"></a>

Aurora 旨在幾乎立即從非計劃的重新啟動中復原，並在沒有二進位日誌的情況下，繼續為應用程式資料提供服務。Aurora 會在平行執行緒上以非同步的方式復原，以便資料庫在非計劃的重新啟動之後立即開啟並可用。

如需詳細資訊，請參閱[Aurora 資料庫叢集的容錯能力](Concepts.AuroraHighAvailability.md#Aurora.Managing.FaultTolerance)及[最佳化以減少資料庫重新啟動時間](AuroraMySQL.MySQL80.md#ReducedRestartTime)。

下列是 Aurora MySQL 上二進位日誌和非計劃重新啟動復原的考量：
+ 在 Aurora 上啟用二進位日誌會直接影響非計劃重新啟動之後的復原時間，因為它會強迫資料庫執行個體執行二進位日誌復原。
+ 使用的二進位日誌類型會影響日誌的大小和效率。針對相同數量的資料庫活動，有些格式會記錄較其他二進位日誌更多的資訊。下列 `binlog_format` 參數的設定會造成不同數量的日誌資料：
  + `ROW` – 最多日誌資料
  + `STATEMENT` – 最少日誌資料
  + `MIXED` – 中等數量的日誌資料，通常可提供資料完整性和效能的最佳組合

  二進位日誌資料的數量會影響復原時間。如果二進位日誌中記錄了較多資料，資料庫執行個體必須在復原期間處理更多資料，而這會增加復原時間。
+ 若要透過二進位記錄減少運算額外負荷並改善復原時間，您可以使用增強型 binlog。增強型 binlog 可改善資料庫復原時間高達 99%。如需更多詳細資訊，請參閱 [設定 Aurora MySQL 的增強型 binlog](AuroraMySQL.Enhanced.binlog.md)。
+ Aurora 不需要二進位日誌，即可在資料庫叢集內複寫資料或是執行時間點還原 (PITR)。
+ 如果您不需要二進位日誌用於進行外部複寫 (或外部二進位日誌資料流)，建議您將 `binlog_format` 參數設定為 `OFF` 來停用二進位日誌。這麼做可減少復原時間。

如需 Aurora 二進位日誌和複寫的詳細資訊，請參閱 [以 Amazon Aurora 進行複寫](Aurora.Replication.md)。如需不同的 MySQL 複寫類型隱含意義的詳細資訊，請參閱 MySQL 文件中的[陳述式和資料列式複寫的優缺點](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html)。