全域資料表和常見問題的就緒性檢查清單 - Amazon DynamoDB
常見問答集

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

全域資料表和常見問題的就緒性檢查清單

部署全域資料表時，請使用下列檢查清單來制定決策和執行任務。

  • 決定有多少以及哪些區域應參與全域資料表。

  • 決定應用程式的寫入模式。如需詳細資訊，請參閱 全域資料表的寫入模式。

  • 根據您的寫入模式計畫 使用全域資料表的請求路由 策略。

  • 根據您的寫入模式和路由策略來定義疏散計畫。

  • 擷取每個區域的運作狀態、延遲和錯誤的指標。如需 DynamoDB 指標的清單，請參閱監控 Amazon DynamoDB 的操作感知 AWS 部落格文章，以取得要觀察的指標清單。您還應該使用 Synthetic Canaries (旨在檢測故障的人工請求，以煤礦中的金絲雀命名)，以及即時觀察客戶流量。並非所有問題都會出現在 DynamoDB 指標中。

  • 為 ReplicationLatency 中任何持續增加設定警示。增加可能表示意外設定錯誤，而全域資料表在不同區域中有不同的寫入設定，這會導致複寫請求失敗並增加延遲。這也可能表示存在區域中斷。一個很好的例子是如果最近的平均值超過 180,000 毫秒，則發出警示。您也可能會看到 ReplicationLatency 降到 0，這表示停止複寫。

  • 為每個全域資料表指派充足的最大讀取和寫入設定值。

  • 事先確定疏散區域的原因。如果決定涉及人為判斷，請記錄所有考量因素。這項工作應提前仔細完成，而不是在壓力下進行。

  • 為每個動作維護執行手冊，作為當疏散區域時必須採取的措施。通常，全域資料表涉及的工作很少，但移動堆疊的其餘部分可能很複雜。

    注意

    最佳實務是僅依賴資料平面操作，而非控制平面操作，因為在區域故障期間，某些控制平面操作可能會遭到降級。

    如需詳細資訊，請參閱部 AWS 落格文章使用 Amazon DynamoDB 全域表建置彈性應用程式：第 4 部分。

  • 定期測試執行手冊的各個方面，包括區域疏散。未經測試的執行手冊是不可靠的執行手冊。

  • 請考慮使用 Resilience Hub 來評估整個應用程式 (包括全域資料表) 的彈性。它透過儀表板提供整體應用程式產品組合彈性狀態的全面檢視。

  • 請考慮使用 Route 53 ARC 整備檢查來評估應用程式目前的組態，並追蹤與最佳實務之間的任何差異。

  • 撰寫用於 Route 53 或 Global Accelerator 使用的運作狀態檢查時，僅通過延時來確定 DynamoDB 端點是否已啟動是不夠的。這無法涵蓋許多故障模式，例如 IAM 組態錯誤、程式碼部署問題、DynamoDB 外部堆疊中的故障、高於平均讀取或寫入延遲等等。最好執行一組執行完整資料庫流程的呼叫。

部署全域資料表的常見問答集 (FAQ)

DynamoDB 全域資料表的整體使用方式有哪些實用原則？

DynamoDB 全域資料表的控制項很少，但仍需要考慮很多因素。您必須決定寫入模式、路由模型和疏散程序。您必須在每個區域檢測您的應用程式，並準備好調整路由或執行疏散以維護全域狀況。獲得的好處是擁有全球分佈式的資料集，具有低延遲讀取和寫入，以及 99.999% 的服務等級協議。

全域資料表的定價為何？

傳統 DynamoDB 資料表的寫入是以寫入容量單位 (WCU，適用於佈建資料表) 或寫入請求單位 (WRU，適用於隨需資料表) 定價。如果您寫入一個 5 KB 的項目，則會產生 5 個單位的費用。全域資料表的寫入是以複寫寫入容量單位 (rWCU，適用於佈建資料表) 或複寫寫入請求單位 (rWRU，適用於隨需資料表) 定價。

rWCU 和 rWRU 包括管理複寫所需的串流媒體基礎設施成本。因此，它們的價格比 WCU 和 WRU 高出 50%。需支付跨區域資料傳輸費用。

直接寫入或複寫寫入項目的每個區域都會產生複寫寫入單位費用。

寫入全域次要索引 (GSI) 會視為本機寫入，並使用一般的寫入單位。

rWCU 目前沒有可用的預留容量。對於具有消耗寫入單元的 GSI 的資料表來說，購買預留容量可能仍然有所幫助。

將新區域新增至全域資料表時，初始啟動程序的費用如同每 GB 還原的資料一樣，再加上跨區域資料傳輸費用。

全域資料表支援哪些區域？

全域表版本 2019.11.21 (目前版本) 在大多數地區都有提供。當您新增複本時，您可以在 DynamoDB 主控台的區域下拉式清單中看到最新的清單。

GSI 如何處理全域資料表？

在全域表版本 2019.11.21（目前）中，當您在一個區域中建立 GSI 時，它會在其他參與的區域中自動建立並自動回填。

如何停止全域資料表的複寫？

刪除複本資料表的方式，與刪除其他資料表相同。刪除全域資料表將停止複寫到該區域，並刪除保留在該區域中的資料表複本。不過，您不能在將表的複本作為獨立實體保留的同時停止複制，也無法暫停複寫。

DynamoDB 串流如何與全域資料表互動？

每個全域資料表都會根據其寫入資料表產生獨立串流，無論是從哪裡開始。您可以選擇在一個區域或所有區域中 (獨立) 使用此 DynamoDB 串流。如果您想要處理本機寫入，而不是複寫的寫入操作，可以將自己的區域屬性新增至每個項目。然後，您可以使用 Lambda 事件篩選條件，呼叫 Lambda 函數在本機區域中進行寫入。這有助於插入和更新操作，可惜不能用於刪除操作。

全域資料表如何處理交易？

交易操作僅在最初寫入發生的區域內提供原子性、一致性、隔離性和耐久性 (ACID) 保證。全域資料表不支援跨區域交易。例如，如果您有一個全域資料表，其在美國東部 (俄亥俄) 和美國西部 (奧勒岡) 區域有複本，並且在美國東部 (俄亥俄) 區域執行 TransactWriteItems 操作，在這些變更進行複寫之後，您可能會在美國西部 (奧勒岡) 區域看到部分完成的交易。當變更已在來源區域遞交後，這些變更才會複寫至其他區域。

全域資料表如何與 DynamoDB Accelerator (DAX) 快取互動？

全域資料表會透過直接更新 DynamoDB 來略過 DAX，因此 DAX 不會察覺其持有過時資料。當快取的 TTL 到期時，才會重新整理 DAX 快取。

是否會傳播資料表上的標籤？

否，標籤不會自動傳播。

我應該備份所有區域中的資料表還是只備份一個？

答案是取決於備份的目的。如果您想要確保資料耐久性，則 DynamoDB 已適當提供該保護。該服務確保的就是耐久性。如果您想要保留歷史記錄的快照 (例如，為了符合法規要求)，則在一個區域中進行備份應該就足夠了。您可以使用將備份複製到其他區域 AWS Backup。如果您想要復原錯誤刪除或修改的資料，請在一個區域中使用 DynamoDB 時間點復原 (PITR)。

如何使用部署全域資料表 AWS CloudFormation？

CloudFormation 將 DynamoDB 資料表和全域資料表代表為兩個獨立的資源：AWS::DynamoDB::Table和。AWS::DynamoDB::GlobalTable其中一種方法是使用 GlobalTable 建構模組來建立可能是全域資料表的所有資料表。然後，您可以將它們保留為獨立資料表來啟動，並在稍後視需要新增至區域。

在中 CloudFormation，無論複本數目為何，每個全域表都由單一區域中的單一堆疊控制。部署範本時， CloudFormation 會建立並更新所有複本，做為單一堆疊作業的一部分。您不應該在多個區域中部署相同的 AWS::DynamoDB::GlobalTable 資源。這會導致錯誤且不支援。如果您在多個區域中部署應用程式範本，則可以使用條件在單一區域中建立 AWS::DynamoDB::GlobalTable 資源。您也可以選擇在與應用程式分開的堆疊中定義 AWS::DynamoDB::GlobalTable 資源，並確保其部署到單一區域。

如果您有一般資料表，且想要將其轉換為全域資料表，同時保持管理， CloudFormation 則將刪除原則設定為 Retain、從堆疊中移除資料表、將資料表轉換為主控台中的全域資料表，然後將全域資料表作為新資源匯入堆疊。

目前不支援跨帳戶複寫。