全域資料表撤離程序 - AWS 規定指引

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

全域資料表撤離程序

撤離區域是將活動(通常是寫入活動,可能讀取活動)遠離該區域的過程。

疏散即時區域

您可能基於多種原因決定撤離即時區域:作為一般業務活動的一部分 (例如,如果您使用的是寫入一個 Region 模式)、因為商業決定變更目前作用中的區域、以回應 DynamoDB 外部軟體堆疊的故障,或是因為您遇到一般問題,例如區域內一般延遲高。follow-the-sun

通過寫入任何區域模式,疏散即時區域非常簡單。您可以使用任何路由系統將流量路由到替代區域,並讓已撤離區域中已發生的寫入作業如常複寫。

透過寫入至一個區域寫入您的區域模式,您必須確定在新的使用中區域中開始寫入作業之前,已完整記錄、串流處理和全域傳播至作用中區域的所有寫入作業,以確保 future 的寫入作業會根據最新版本的資料處理。

假設區域 A 處於作用中狀態,而區域 B 是被動的 (無論是針對全域資料表或區域 A 中的項目來說)。執行疏散的典型機制是暫停寫入 A、等待充分的時間讓這些操作完全傳播到 B、更新架構堆疊以辨識 B 為使用中,然後繼續寫入操作至 B。沒有指標能夠保證區域 A 的資料已完全複製到區域 B。如果區域 A 狀況良好,請暫停寫入操作至區域 A,然後等待 10 倍 ReplicationLatency 最近指標的最大值,判斷複製是否完成。如果區域 A 狀況不佳並顯示延遲增加的其他區域,則您可以選擇較大的倍數作為等待時間。

疏散離線區域

有一個特殊情況需要考慮:如果 A 區域在沒有通知的情況下完全離線怎麼辦? 這是極不可能的,但仍應考慮。如果發生這種情況,區域 A 中尚未傳輸的任何寫入操作都會在區域 A 重新上線後保留和傳播。寫操作不會遺失,但它們的傳播會無限期延遲。

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

透過寫入任何區域模式,區域 B 中的讀取和寫入作業可以繼續進行,相信區域 A 中的項目最終會傳播到區域 B,並識別遺失項目的可能性,直到區域 A 重新連線為止。如果可能的話,例如使用冪等寫入作業,您應該考慮重新播放最近的寫入流量 (例如,使用上游事件來源),以填補任何可能遺失寫入作業的空白,並讓最後一個寫入器 wins 衝突解決方案抑制傳入寫入作業的最終傳播。

使用其他寫入模式,您必須考慮工作可以稍微out-of-date觀察世界的程度。區域 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 就會有足夠的執行中寫入作業up-to-date記錄,以便完全有用。如果區域 B 當機,區域 A 可以繼續接受與區域 C 合作的寫入請求。這家公司願意接受更高的延遲寫入 (到兩個區域:C 和 A),並且很高興擁有資料模型,可以摘要彙總帳戶狀態。