疏散程序

若 MRSC 資料表出現此情況，您無需執行額外操作。MRSC 資料表支援復原點目標 (RPO) 為零。對離線區域中 MRSC 資料表的所有成功寫入作業，都會出現在其他區域資料表中，因此即使該區域完全離線，資料仍不會出現落差。業務可持續使用位於其他區域的資料副本。

若發生此情況，區域 A 中尚未傳播的寫入作業會暫存，並在該區域重新上線後傳播。寫操作不會遺失，但它們的傳播會無限期延遲。

在這種情況下如何進行應用程式的決策。對於業務連續性，寫入操作可能需要繼續進行新的主要區域 B。不過，如果區域 B 中的某個項目在區域 A 的寫入操作擱置傳播時收到更新，則會在最後一個寫入獲勝模型下抑制傳播。區域 B 中的任何更新都可能會抑制傳入的寫入請求。

在寫入任何區域模式下，區域 B 可持續執行讀寫作業，並假設區域 A 的項目最終會傳播至區域 B，同時需注意在區域 A 恢復上線前可能出現項目遺失。若可行 (例如針對具冪等性的寫入作業)，建議重新播放近期寫入流量 (如使用上游事件來源)，以填補可能遺失的寫入作業，並透過「最後寫入優先」衝突解決機制抑制傳入寫入的最終傳播。

使用其他寫入模式，您必須考慮工作可以在稍微延時的環境下繼續進行的程度。區域 A 重新上線之前，將丟失一些持續時間較短的寫入操作 (如，ReplicationLatency 追蹤)。業務能夠繼續進行嗎？ 在某些使用案例中，能夠繼續進行，但在其他情況下，如果沒有額外的緩解機制，可能無法繼續進行。

例如，假設即使某個區域完全中斷，您仍必須不中斷地維持可用的信用餘額。您可以將餘額分為兩個獨立項目，一個配置在區域 A，另一個配置在區域 B，並讓每個項目各自擁有一半的可用餘額。這將使用寫入您的區域模式。每個區域中處理的交易更新會針對餘額的本機複本寫入。如果區域 A 完全離線，工作仍然可以在區域 B 中繼續進行交易處理，並且寫入操作將限制為區域 B 中所保留的餘額部分，像這樣拆分餘額會導致複雜性，但即使在不確定的待處理寫入操作下，可以提供一個安全業務復原的範例。

再舉一例，假設您正在擷取 Web 表單資料。您可以使用樂觀並行控制 (OCC)，為資料項目指派版本，並將最新版本嵌入 Web 表單中作為隱藏欄位。每次提交時，只有當資料庫中的版本仍與建置表單的版本相符時，寫入操作才會成功。如果版本不相符，則可以根據資料庫中目前版本重新整理 (或仔細合併) Web 表單，並且使用者可以再次進行操作。OCC 模型通常可以防止其他用戶端覆寫和產生新版本的資料，但也可以在用戶端遇到較舊版本資料的容錯移轉期間提供幫助。假設您是使用時間戳記作為版本。表單最初於 12:00 在區域 A 建置，但在容錯移轉後嘗試寫入區域 B，並發現資料庫中的最新版本時間為 11:59。在此情況中，用戶端可以等候 12:00 版本傳播到區域 B，然後在該版本之上寫入，或是在 11:59 建置並建立新的 12:01 版本 (寫入後，會在區域 A 復原之後抑制傳入版本)。

第三個例子是，某金融服務公司在 DynamoDB 資料庫中儲存客戶帳戶及其財務交易資料。若區域 A 完全中斷，他們希望確保與帳戶相關的所有寫入活動在區域 B 中完全可用；否則，將這些帳戶標示為「部分可用」並予以隔離，直到區域 A 恢復上線。他們沒有暫停所有業務，而是決定只對確定有未傳播交易的一小部分賬戶暫停業務。為了達成此目的，他們使用了第三個區域，我們將呼叫區域 C。在處理區域 A 中的任何寫入操作之前，他們在區域 C 中對那些暫緩操作 (例如，帳戶新的交易計數) 建立摘要彙總。此彙總足以讓區域 B 判斷其檢視是否完全為最新狀態。此動作會有效鎖定帳戶，從寫入區域 C 開始，直到區域 A 接受寫入操作且區域 B 收到為止。除非作為容錯移轉程序的一部分外，不會使用區域 C 中的資料，之後區域 B 可以和區域 C 交叉比對資料，以檢查其帳戶是否已過期。這些帳戶會維持「隔離」狀態，直到區域 A 的復原程序將部分資料同步至區域 B。若區域 C 發生故障，則可啟動新的區域 D 以替代使用。區域 C 中的資料非常短暫，幾分鐘後，區域 D 將擁有最新的使用中寫入操作記錄，以充分發揮作用。如果區域 B 當機，區域 A 可以繼續接受與區域 C 合作的寫入請求。這家公司願意接受更高的延遲寫入 (到兩個區域：C 和 A)，並且很高興擁有資料模型，可以摘要彙總帳戶狀態。