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

# DynamoDB 全域資料表部署前檢查清單
<a name="bp-global-table-design.prescriptive-guidance.checklist-and-faq"></a>

部署全域資料表時，請使用下列檢查清單來制定決策和執行任務。
+ 判斷您的使用案例更適合 MRSC 或 MREC 一致性模式。您是否需要高度一致性，即使必須承擔更高延遲與其他取捨？
+ 決定有多少以及哪些區域應參與全域資料表。若您計劃使用 MRSC，請決定第三個區域要作為複本區域或見證區域。
+ 決定應用程式的寫入模式。這與一致性模式並非相同概念。如需詳細資訊，請參閱[使用 DynamoDB 全域資料表的寫入模式](bp-global-table-design.prescriptive-guidance.writemodes.md)。
+ 根據您的寫入模式計畫 [DynamoDB 的路由策略](bp-global-table-design.prescriptive-guidance.request-routing.md) 策略。
+ 根據一致性模式、寫入模式與路由策略定義您的 [ 疏散程序  使用全域資料表疏散區域   區域疏散指的是將作業活動 (通常為讀取與寫入活動) 從該區域移轉出去的過程。  疏散即時區域即時區域  疏散即時區域   您可能會因多種原因決定疏散運作中的區域：例如作為日常業務流程的一部分 (如採用「追日式」或「寫入單一區域」模式)、因業務決策變更作用中區域、回應 DynamoDB 以外軟體堆疊的故障，或因遇到一般性問題 (例如區域延遲高於平常)。 通過*寫入任何區域*模式，疏散即時區域非常簡單。您可以使用任意路由系統將流量導向其他區域，並讓疏散區域中的寫入操作照常複製。 「寫入單一區域」與「寫入您區域」模式通常搭配 MREC 資料表使用。因此，在新作用中區域開始寫入作業前，您必須確保舊作用中區域的所有寫入已完整記錄、串流處理並全域傳播，以確保後續寫入作業基於最新資料版本。 假設區域 A 處於作用中狀態，而區域 B 是被動的 (無論是針對全域資料表或區域 A 中的項目來說)。執行疏散的典型機制是暫停寫入 A、等待充分的時間讓這些操作完全傳播到 B、更新架構堆疊以辨識 B 為使用中，然後繼續寫入操作至 B。沒有指標能夠保證區域 A 的資料已完全複製到區域 B。如果區域 A 狀況良好，請暫停寫入操作至區域 A，然後等待 10 倍 `ReplicationLatency` 最近指標的最大值，判斷複製是否完成。如果區域 A 狀況不佳並顯示延遲增加的其他區域，則您可以選擇較大的倍數作為等待時間。   疏散離線區域離線區域  疏散離線區域   有一種特殊情況需考量：若區域 A 在未預警的情況下完全離線，該怎麼處理？ 此情況極少發生，但仍應納入考量。  

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

疏散離線 MREC 資料表  
若發生此情況，區域 A 中尚未傳播的寫入作業會暫存，並在該區域重新上線後傳播。寫操作不會遺失，但它們的傳播會無限期延遲。  
在這種情況下如何進行應用程式的決策。對於業務連續性，寫入操作可能需要繼續進行新的主要區域 B。不過，如果區域 B 中的某個項目在區域 A 的寫入操作擱置傳播時收到更新，則會在*最後一個寫入獲勝*模型下抑制傳播。區域 B 中的任何更新都可能會抑制傳入的寫入請求。  
在*寫入任何區域*模式下，區域 B 可持續執行讀寫作業，並假設區域 A 的項目最終會傳播至區域 B，同時需注意在區域 A 恢復上線前可能出現項目遺失。若可行 (例如針對具冪等性的寫入作業)，建議重新播放近期寫入流量 (如使用上游事件來源)，以填補可能遺失的寫入作業，並透過「最後寫入優先」衝突解決機制抑制傳入寫入的最終傳播。  
使用其他寫入模式，您必須考慮工作可以在稍微延時的環境下繼續進行的程度。區域 A 重新上線之前，將丟失一些持續時間較短的寫入操作 (如，`ReplicationLatency` 追蹤)。業務能夠繼續進行嗎？ 在某些使用案例中，能夠繼續進行，但在其他情況下，如果沒有額外的緩解機制，可能無法繼續進行。  
例如，假設即使某個區域完全中斷，您仍必須不中斷地維持可用的信用餘額。您可以將餘額分為兩個獨立項目，一個配置在區域 A，另一個配置在區域 B，並讓每個項目各自擁有一半的可用餘額。這將使用*寫入您的區域*模式。每個區域中處理的交易更新會針對餘額的本機複本寫入。如果區域 A 完全離線，工作仍然可以在區域 B 中繼續進行交易處理，並且寫入操作將限制為區域 B 中所保留的餘額部分，像這樣拆分餘額會導致複雜性，但即使在不確定的待處理寫入操作下，可以提供一個安全業務復原的範例。  
再舉一例，假設您正在擷取 Web 表單資料。您可以使用[樂觀並行控制 (OCC)](DynamoDBMapper.OptimisticLocking.md)，為資料項目指派版本，並將最新版本嵌入 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)，並且很高興擁有資料模型，可以摘要彙總帳戶狀態。   ](bp-global-table-design.prescriptive-guidance.evacuation.md#bp-global-table-design.prescriptive-guidance.evacuation.title) [疏散程序](bp-global-table-design.prescriptive-guidance.evacuation.md)。
+ 擷取每個區域的運作狀態、延遲和錯誤的指標。如需 DynamoDB 指標清單，請參閱 AWS 部落格文章[監控 Amazon DynamoDB 的操作意識](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/)，以取得要觀察的指標清單。您還應該使用 [Synthetic Canaries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (旨在檢測故障的人工請求，以煤礦中的金絲雀命名)，以及即時觀察客戶流量。並非所有問題都會出現在 DynamoDB 指標中。
+ 若您使用 MREC，請針對 `ReplicationLatency` 的持續增加設定警示。增加可能表示意外設定錯誤，而全域資料表在不同區域中有不同的寫入設定，這會導致複寫請求失敗並增加延遲。這也可能表示存在區域中斷。一個[很好的例子](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/)是如果最近的平均值超過 180,000 毫秒，則發出警示。您也應監控 `ReplicationLatency` 是否降為 0，此狀況表示複寫程序已停滯。
+ 為每個全域資料表指派充足的最大讀取和寫入設定值。
+ 事先確定疏散區域的原因。如果決定涉及人為判斷，請記錄所有考量因素。這項工作應提前仔細完成，而不是在壓力下進行。
+ 為每個動作維護執行手冊，作為當疏散區域時必須採取的措施。通常，全域資料表涉及的工作很少，但移動堆疊的其餘部分可能很複雜。
**注意**  
在容錯移轉程序中，最佳實務是僅依賴資料平面操作，而非控制平面操作，因為在區域故障期間，部分控制平面操作可能會降級。

   如需詳細資訊，請參閱 AWS 部落格文章[使用 Amazon DynamoDB 全域資料表建置彈性應用程式：第 4 部分](https://aws.amazon.com/blogs/database/part-4-build-resilient-applications-with-amazon-dynamodb-global-tables/)。
+ 定期測試執行手冊的各個方面，包括區域疏散。未經測試的執行手冊是不可靠的執行手冊。
+ 請考慮使用 [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) 來評估整個應用程式 (包含全域資料表) 的韌性。它透過儀表板提供整體應用程式產品組合彈性狀態的全面檢視。
+ 請考慮使用 ARC 的整備檢查來評估應用程式的目前組態，並追蹤與最佳實務的偏差。
+ 當您為 Route 53 或 Global Accelerator 撰寫運作狀態檢查時，請設計一組涵蓋完整資料庫流程的呼叫。如果您限制檢查以確認 DynamoDB 端點已啟動，您將無法涵蓋許多失敗模式，例如 AWS Identity and Access Management (IAM) 組態錯誤、程式碼部署問題、DynamoDB 外部堆疊中的失敗、高於平均讀取或寫入延遲等。

## 部署全域資料表的常見問答集 (FAQ)
<a name="bp-global-table-design.prescriptive-guidance.faq"></a>

**全域資料表的定價為何？**
+ 傳統的 DynamoDB 資料表寫入作業會依照佈建資料表的寫入容量單位 (WCU) 或隨需資料表的寫入請求單位 (WRU) 收費。如果您寫入一個 5 KB 的項目，則會產生 5 個單位的費用。全域資料表的寫入依複寫寫入容量單位 (rWCU，適用於佈建資料表) 或複寫寫入請求單位 (rWRU，適用於隨需資料表) 收費；rWCU 與 rWRU 的收費與 WCU、WRU 相同。
+ 無論項目是直接寫入或透過複寫寫入，每個區域都會產生 rWCU 與 rWRU 費用。需支付跨區域資料傳輸費用。
+ 寫入全域次要索引 (GSI) 會視為本機寫入作業，並使用常規寫入單位。
+ 目前 rWCU 與 rWRU 均無可用的預留容量。若資料表中的 GSI 消耗大量寫入單位，購買 WCU 預留容量可能有助於節省成本。
+ 當您將新區域加入全域資料表時，DynamoDB 會自動啟動新區域，並根據資料表的 GB 大小向您收費，就像是資料表還原一樣。此外，需支付跨區域資料傳輸費用。

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

[Global Tables 2019.11.21 版 （目前）](GlobalTables.md) 支援 AWS 區域 MREC 資料表的所有 ，以及 MRSC 資料表的下列區域集：
+ 美國區域集：美國東部 (維吉尼亞北部)、美國東部 (俄亥俄)、美國西部 (奧勒岡)
+ 歐洲區域集：歐洲 (愛爾蘭)、歐洲 (倫敦)、歐洲 (巴黎)、歐洲 (法蘭克福)
+ AP 區域集：亞太區域 （東京）、亞太區域 （首爾） 和亞太區域 （大阪）

**全域資料表如何處理 GSI？**

在[全域資料表 2019.11.21 版 (目前)](GlobalTables.md)中，當您在某個區域建立 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)](PointInTimeRecovery_Howitworks.md)。

**如何使用 部署全域資料表 CloudFormation？**
+ CloudFormation 將 DynamoDB 資料表和一個全域資料表顯示為兩個獨立的資源：`AWS::DynamoDB::Table` 和 `AWS::DynamoDB::GlobalTable`。一種做法是使用 `GlobalTable` 建構方式，先建立為獨立資料表，若有需要再新增其他區域。
+ 在 CloudFormation 中，無論複本數目多少，每個全域資料表都在單一區域中由單一堆疊控制。當您部署範本時，CloudFormation 會將所有複本建立和更新為單一堆疊操作的一部分。您不應該在多個區域中部署相同的 [AWS::DynamoDB::GlobalTable](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html) 資源。這會導致錯誤且不支援。如果您在多個區域中部署應用程式範本，則可以使用條件在單一區域中建立 `AWS::DynamoDB::GlobalTable` 資源。您也可以選擇在與應用程式分開的堆疊中定義 `AWS::DynamoDB::GlobalTable` 資源，並確保其部署到單一區域。
+ 若您希望在維持 CloudFormation 管理的情況下，將一般資料表轉換為全域資料表，請將刪除原則設定為 `Retain`，自堆疊移除該資料表後，於主控台將其轉換為全域資料表，再將該全域資料表作為新資源匯入堆疊。如需更多資訊，請參閱 [AWS GitHub 儲存庫](https://github.com/aws-samples/amazon-dynamodb-table-to-global-table-cdk)。
+ 目前不支援跨帳戶複寫。