DynamoDB 全域資料表部署前檢查清單
部署全域資料表時,請使用下列檢查清單來制定決策和執行任務。
-
判斷您的使用案例更適合 MRSC 或 MREC 一致性模式。您是否需要高度一致性,即使必須承擔更高延遲與其他取捨?
決定有多少以及哪些區域應參與全域資料表。若您計劃使用 MRSC,請決定第三個區域要作為複本區域或見證區域。
決定應用程式的寫入模式。這與一致性模式並非相同概念。如需更多詳細資訊,請參閱 使用 DynamoDB 全域資料表的寫入模式。
根據您的寫入模式計畫 DynamoDB 的路由策略 策略。
根據一致性模式、寫入模式與路由策略定義您的 疏散程序。
擷取每個區域的運作狀態、延遲和錯誤的指標。如需 DynamoDB 指標的列表,請參閱監控 Amazon DynamoDB 以提高操作意識 AWS 部落格文章
,以取得要觀察的指標列表。您還應該使用 Synthetic Canaries (旨在檢測故障的人工請求,以煤礦中的金絲雀命名),以及即時觀察客戶流量。並非所有問題都會出現在 DynamoDB 指標中。 若您使用 MREC,請針對
ReplicationLatency的持續增加設定警示。增加可能表示意外設定錯誤,而全域資料表在不同區域中有不同的寫入設定,這會導致複寫請求失敗並增加延遲。這也可能表示存在區域中斷。一個很好的例子是如果最近的平均值超過 180,000 毫秒,則發出警示。您也應監控 ReplicationLatency是否降為 0,此狀況表示複寫程序已停滯。為每個全域資料表指派充足的最大讀取和寫入設定值。
事先確定疏散區域的原因。如果決定涉及人為判斷,請記錄所有考量因素。這項工作應提前仔細完成,而不是在壓力下進行。
為每個動作維護執行手冊,作為當疏散區域時必須採取的措施。通常,全域資料表涉及的工作很少,但移動堆疊的其餘部分可能很複雜。
注意
在容錯移轉程序中,最佳實務是僅依賴資料平面操作,而非控制平面操作,因為在區域故障期間,部分控制平面操作可能會降級。
如需詳細資訊,請參閱 AWS 部落格文章使用 Amazon DynamoDB 全域資料表建置彈性應用程式:第 4 部分
。 定期測試執行手冊的各個方面,包括區域疏散。未經測試的執行手冊是不可靠的執行手冊。
請考慮使用 AWS Resilience Hub 來評估整個應用程式 (包含全域資料表) 的韌性。它透過儀表板提供整體應用程式產品組合彈性狀態的全面檢視。
請考慮使用 ARC 的整備檢查來評估應用程式的目前組態,並追蹤與最佳實務的偏差。
當您為 Route 53 或 Global Accelerator 撰寫運作狀態檢查時,請設計一組涵蓋完整資料庫流程的呼叫。若您的檢查僅確認 DynamoDB 端點可用,將無法涵蓋多種失敗模式,例如 AWS Identity and Access Management (IAM) 組態錯誤、程式碼部署問題、DynamoDB 外部堆疊故障、或高於平均的讀取/寫入延遲等。
部署全域資料表的常見問答集 (FAQ)
全域資料表的定價為何?
-
傳統的 DynamoDB 資料表寫入作業會依照佈建資料表的寫入容量單位 (WCU) 或隨需資料表的寫入請求單位 (WRU) 收費。如果您寫入一個 5 KB 的項目,則會產生 5 個單位的費用。全域資料表的寫入依複寫寫入容量單位 (rWCU,適用於佈建資料表) 或複寫寫入請求單位 (rWRU,適用於隨需資料表) 收費;rWCU 與 rWRU 的收費與 WCU、WRU 相同。
-
無論項目是直接寫入或透過複寫寫入,每個區域都會產生 rWCU 與 rWRU 費用。需支付跨區域資料傳輸費用。
-
寫入全域次要索引 (GSI) 會視為本機寫入作業,並使用常規寫入單位。
-
目前 rWCU 與 rWRU 均無可用的預留容量。若資料表中的 GSI 消耗大量寫入單位,購買 WCU 預留容量可能有助於節省成本。
-
當您將新區域加入全域資料表時,DynamoDB 會自動啟動新區域,並根據資料表的 GB 大小向您收費,就像是資料表還原一樣。此外,需支付跨區域資料傳輸費用。
全域資料表支援哪些區域?
全域資料表 2019.11.21 版 (目前) 支援所有適用於 MREC 資料表的 AWS 區域 功能,以及適用於 MRSC 資料表的下列區域集:
-
美國區域集:美國東部 (維吉尼亞北部)、美國東部 (俄亥俄)、美國西部 (奧勒岡)
-
歐洲區域集:歐洲 (愛爾蘭)、歐洲 (倫敦)、歐洲 (巴黎)、歐洲 (法蘭克福)
-
亞太區域集:亞太地區 (東京)、亞太地區 (首爾) 和亞太地區 (大阪)
全域資料表如何處理 GSI?
在全域資料表 2019.11.21 版 (目前)中,當您在某個區域建立 GSI 時,系統會在其他參與區域自動建立並回填。
如何停止全域資料表的複寫?
-
刪除複本資料表的方式,與刪除其他資料表相同。刪除全域資料表將停止複寫到該區域,並刪除保留在該區域中的資料表複本。不過,您無法在保留資料表複本為獨立實體的同時停止複寫,也無法暫停複寫。
-
MRSC 資料表必須部署於三個區域中。若要刪除副本,您必須同時刪除所有副本與見證,使 MRSC 資料表轉為本機資料表。
DynamoDB 串流如何與全域資料表互動?
-
每個全域資料表都會根據其所有的寫入作業產生獨立串流,無論從何處開始皆然。您可以選擇在一個區域或所有區域中 (獨立) 使用此 DynamoDB 串流。如果您想要處理本機寫入,而不是複寫的寫入操作,可以將自己的區域屬性新增至每個項目。然後,您可以使用 Lambda 事件篩選條件,呼叫 Lambda 函式在本機區域中進行寫入。這有助於插入和更新操作,但不能用於刪除操作。
-
設定為多區域最終一致性 (MREC 資料表) 的全域資料表會透過從複本資料表上的 DynamoDB 串流讀取變更,並將其套用至其他所有複本資料表,以進行變更複寫。因此,MREC 全域資料表的所有副本預設均啟用 DynamoDB,且無法停用。MREC 複寫程序可在短時間內將多項變更整合為單一複寫寫入作業。因此,各複本的串流可能會包含略有差異的記錄。在 MREC 副本上,DynamoDB Streams 記錄一律依每個項目排序,但不同副本之間的項目順序可能會有所不同。
-
為多區域強式一致性 (MRSC 資料表) 設定的全域資料表不使用 DynamoDB Streams 進行複寫,因此 MRSC 副本預設不啟用此功能。您可以在 MRSC 複本上啟用 DynamoDB Streams。MRSC 副本上的 DynamoDB Streams 記錄在所有副本間完全相同,並一律依項目排序,但不同副本間的項目順序可能仍有差異。
全域資料表如何處理交易?
-
在 MRSC 資料表上執行交易作業會產生錯誤。
-
MREC 資料表上的交易作業僅在最初執行寫入的區域內,提供原子性、一致性、隔離性與持久性 (ACID) 保證。全域資料表不支援跨區域交易。例如,若您擁有在美國東部 (俄亥俄) 與美國西部 (奧勒岡) 區域皆有副本的 MREC 全域資料表,並於美國東部 (俄亥俄) 區域執行
TransactWriteItems操作,當變更複寫後,您可能會在美國西部 (奧勒岡) 區域觀察到部分完成的交易。當變更已在來源區域遞交後,這些變更才會複寫至其他區域。
全域資料表如何與 DynamoDB Accelerator (DAX) 快取互動?
全域資料表會透過直接更新 DynamoDB 來略過 DAX,因此 DAX 不會察覺其持有過時資料。當快取的 TTL 到期時,才會重新整理 DAX 快取。
是否會傳播資料表上的標籤?
否,標籤不會自動傳播。
我應該備份所有區域中的資料表還是只備份一個?
答案是取決於備份的目的。
-
如果您想要確保資料耐久性,則 DynamoDB 已適當提供該保護。該服務確保的就是耐久性。
-
如果您想要保留歷史記錄的快照 (例如,為了符合法規要求),則在一個區域中進行備份應該就足夠了。您可以使用 AWS Backup 將備份複製到其他區域。
-
如果您想要復原錯誤刪除或修改的資料,請在一個區域中使用 DynamoDB 時間點復原 (PITR)。
如何使用CloudFormation部署全域資料表?
-
CloudFormation 將 DynamoDB 資料表和一個全域資料表顯示為兩個獨立的資源:
AWS::DynamoDB::Table和AWS::DynamoDB::GlobalTable。一種做法是使用GlobalTable建構方式,先建立為獨立資料表,若有需要再新增其他區域。 -
在 CloudFormation 中,無論複本數目多少,每個全域資料表都在單一區域中由單一堆疊控制。當您部署範本時,CloudFormation 會將所有複本建立和更新為單一堆疊操作的一部分。您不應該在多個區域中部署相同的 AWS::DynamoDB::GlobalTable 資源。這會導致錯誤且不支援。如果您在多個區域中部署應用程式範本,則可以使用條件在單一區域中建立
AWS::DynamoDB::GlobalTable資源。您也可以選擇在與應用程式分開的堆疊中定義AWS::DynamoDB::GlobalTable資源,並確保其部署到單一區域。 -
若您希望在維持 CloudFormation 管理的情況下,將一般資料表轉換為全域資料表,請將刪除原則設定為
Retain,自堆疊移除該資料表後,於主控台將其轉換為全域資料表,再將該全域資料表作為新資源匯入堆疊。如需更多資訊,請參閱 AWSGitHub 儲存庫。 -
目前不支援跨帳戶複寫。