舊版和目前版本行為差異升級的必要所需的許可升級期間的期望 DynamoDB Streams 行為升級至版本 (目前版本)

將全域表格從舊版 (2017.11.29) 版本升級到目前版本

有兩個版本的 DynamoDB 全域資料表可供使用：全域表版本 2019.11.21 (目前版本) 和. 全域表格版本 (舊版) 客戶應盡可能使用 2019.11.21 版 (目前)，因為相較於 2017.11.29 (舊版)，其提供更大的彈性、更高的效率，且消耗的寫入容量更少。若要判斷您使用的版本，請參閱判斷您正在使用的全域資料表版本。

本節說明如何使用 DynamoDB 主控台將全域資料表升級至 2019.11.21 版 (目前版本)。從版本 2017.11.29 (舊版) 升級至版本 2019.11.21 (目前版本) 是一次性的動作，您無法將其還原。目前，您只能使用主控台升級全域表。

舊版和目前版本之間的行為差異

下列清單說明全域資料表的舊版和目前版本之間的行為差異。

與版本 2017.11.29 (舊版) 相比，版本 2019.11.21 (目前版本) 在數個 DynamoDB 作業上消耗的寫入容量較少，因此對於大多數客戶而言，更具成本效益。這些 DynamoDB 作業的差異如下：

在 2017.11.29 (舊版) 中呼叫PutItem區域中的 1 KB 項目並複製到其他區域需要 2 個 RWRU (舊版)，但 2019.11.21 (目前) 只需要 1 個 RWRU。
呼叫 UpdateItem1KB 料號在 2017.11.29 (舊版) 的來源區域中需要 2 個 RWRU，而在 2017.11.29 (舊版) 的每個目的地區域需要 1 個 RWRU，但 2019.11.21 (目前) 的來源區域與目的地區域只需要 1 個 RWRU。
呼叫 DeleteItem1KB 料號在 2017.11.29 (舊版) 的來源區域中需要 1 個 RWRU 和每個目的地區域 2 RWRU (舊版)，但 2019.11.21 (目前) 的來源或目的地區域只需要 1 個 RWRU。

下表顯示 2017 年 11 月 29 日 (舊版) 和 2019 年 11 月 21 日 (目前) 的註冊資料庫使用量。

在兩個區域中，每個 1 KB 項目的註冊資料耗用量分別為 2015 年 11 月 29 日 (舊版) 和 2019 年 11 月 21 日 (目前)
作業	2017 年 11 月 29 日 (舊版)	2019 年 11 月 21 日（當前）	節省
PutItem	4 RRU	2 RRU	50%
UpdateItem	3 RRU	2 RRU	33%
DeleteItem	3 RRU	2 RRU	33%

版本 2017.11.29 (舊版) 僅提供 11 版。 AWS 區域但是，版本 2019.11.21 (目前版本) 在所有版本中都可以使用。 AWS 區域
您可以建立版本 2017.11.29 (舊版) 全域資料表，方法是先建立一組空白區域資料表，然後叫用 CreateGlobalTableAPI 來形成全域資料表。您可以透過呼叫 UpdateTableAPI 將複本新增至現有地區資料表，來建立版本 2019.11.21 (目前) 全域表格。
版本 2017.11.29 (舊版) 要求您先清空表格中的所有複本，然後才能在新區域中新增複本 (包括建立期間)。版本 2019.11.21（目前版本）支援您在已包含資料的資料表上新增和移除區域的複本。
版本 2017.11.29（舊版）使用以下專用的控制平面 API 集來管理複本：
版本 2019.11.21 (目前版本) 使用DescribeTable和 UpdateTableAPI 來管理複本。
版本 2017.11.29 (舊版) 會針對每次寫入發佈兩筆 DynamoDB Streams 記錄。版本 2019.11.21 (目前版本) 只會針對每次寫入發佈一筆 DynamoDB Streams 記錄。
版本 2017.11.29 (舊版) 會填入並更新aws:rep:deleting、aws:rep:updateregion和屬性。aws:rep:updatetime版本 2019.11.21（目前版本）不會填入或更新這些屬性。
版本 2017.11.29 (舊版) 不會同步處理所有複本的生存時間 (TTL)設定。版本 2019.11.21 (目前版本) 會在各個複本之間同步 TTL 設定。
版本 2017.11.29 (舊版) 不會將 TTL 刪除複寫到其他複本。版本 2019.11.21 (目前版本) 會將 TTL 刪除項目複製到所有複本。
版本 2017.11.29 (舊版) 不會同步處理跨複本的 auto 調整設定。版本 2019.11.21（目前版本）會在各個複本之間同步 auto 調整設定。
版本 2017.11.29 (舊版) 不會同步處理所有複本之間的全域次要索引 (GSI) 設定。版本 2019.11.21 (目前版本) 會在多個複本間同步 GSI 設定。
版本 2017.11.29 (舊版) 不會在複本之間同步處理靜態加密設定。版本 2019.11.21（目前版本）在複本之間同步處理靜態加密設定。
版本 2017.11.29 (舊版) 會發佈量度。PendingReplicationCount版本 2019.11.21 (目前版本) 不會發佈此測量結果。

升級的必要

開始升級至版本 2019.11.21 (目前) 全域表格之前，您必須符合下列先決條件：

生存時間 (TTL)複本上的設定在各個區域之間是一致的。
複本上的全域次要索引 (GSI) 定義在各個區域之間是一致的。
複本上的靜態加密設定在各個區域之間是一致的。
DynamoDB auto 調整功能已針對所有複本啟用 WCU，或針對所有複本啟用隨需容量模式。
應用程式不需要表格項目中的aws:rep:deletingaws:rep:updateregion、和aws:rep:updatetime屬性。

全域表升級所需的權限

若要升級至版本 2019.11.21 (目前版本)，您必須在所有具有複本的區域中擁有dynamodb:UpdateGlobalTableVersion權限。除了存取 DynamoDB 主控台和檢視表格所需的權限外，還需要這些權限。

下列 IAM 政策授予將任何全域資料表升級至 2019.11.21 版 (目前版本) 的許可。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "dynamodb:UpdateGlobalTableVersion",
            "Resource": "*"
        }
    ]
}

下列 IAM 政策授予許可，只將兩個區域中具有複本的Music全域資料表升級為 2019.11.21 版 (目前版本)。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "dynamodb:UpdateGlobalTableVersion",
            "Resource": [
                "arn:aws:dynamodb::123456789012:global-table/Music",
                "arn:aws:dynamodb:ap-southeast-1:123456789012:table/Music",
                "arn:aws:dynamodb:us-east-2:123456789012:table/Music"
            ]
        }
    ]
}

升級期間的期望

升級時，所有全域表格複本都會繼續處理讀取和寫入流量。
升級程序需要幾分鐘到數小時的時間，具體取決於資料表大小和複本數目。
在升級程序期間，的值TableStatus會從變更ACTIVE為UPDATING。您可以透過叫用 DescribeTableAPI 或 Dynam oDB 主控台中的「表格」檢視來檢視表格的狀態。
在升級表格時，Auto Scaling 不會調整全域表的佈建容量設定。強烈建議您在升級期間將表格設定為隨需容量模式。
如果您選擇在升級期間使用佈建的容量模式搭配 auto 擴展，則必須增加原則的最小讀取和寫入輸送量，以適應任何預期的流量增加，以避免升級期間的限制。
升級程序完成後，您的表格狀態將變更為ACTIVE。

DynamoDB 在升級之前、期間和升級後串流行為

作業	複本區域	升級前的行為	升級期間的行為	升級後的行為
放置或更新	來源	時間戳記人口發生使用 UpdateItem.	時間戳人口發生使用 PutItem.	不會產生客戶可見的時間戳記。
		會產生兩個串流記錄。第一條記錄包含客戶寫入的屬性。第二條記錄包含`aws:rep:*`屬性。	會產生兩個串流記錄。第一條記錄包含客戶寫入的屬性。第二條記錄包含`aws:rep:*`屬性。	系統會產生包含客戶寫入屬性的單一「串流」記錄。
		每個客戶寫入時會使用兩個 RWCU。	每個客戶寫入時會使用兩個 RWCU。	每個客戶寫入時會使用一個 RWCU。
		`ReplicationLatency`和`PendingReplicationCount`量度在中發佈 CloudWatch。	`ReplicationLatency`和`PendingReplicationCount`量度在中發佈 CloudWatch。	`ReplicationLatency`量度發佈於 CloudWatch。
	目的地	複寫發生使用 PutItem.	複寫發生使用 PutItem.	複寫發生使用 PutItem.
		系統會產生單一「串流」記錄，其中包含客戶撰寫的屬性和`aws:rep:*`屬性。	系統會產生單一「串流」記錄，其中包含客戶撰寫的屬性和`aws:rep:*`屬性。	系統會產生單一「串流」記錄，其中僅包含客戶撰寫的屬性，且不包含複製屬性。
		如果料號存在於目的地區域中，則會耗用一個 RWCU。如果目的地區域中不存在該項目，則會使用兩個 RWCU。	如果料號存在於目的地區域中，則會耗用一個 RWCU。如果目的地區域中不存在該項目，則會使用兩個 RWCU。	每個客戶寫入時會使用一個 RWCU。
		`ReplicationLatency`和`PendingReplicationCount`量度在中發佈 CloudWatch。	`ReplicationLatency`和`PendingReplicationCount`量度在中發佈 CloudWatch。	`ReplicationLatency`量度發佈於 CloudWatch。
刪除	來源	使用刪除具有較小時間戳的任何項目DeleteItem。	使用刪除具有較小時間戳的任何項目 DeleteItem。	使用刪除具有較小時間戳的任何項目 DeleteItem。
		系統會產生單一「串流」記錄，其中包含客戶撰寫的屬性和`aws:rep:*`屬性。	系統會產生單一「串流」記錄，其中包含客戶撰寫的屬性和`aws:rep:*`屬性。	系統會產生單一「串流」記錄，其中包含客戶撰寫的屬性。
		每個客戶刪除都會使用一個 RWCU。	每個客戶刪除都會使用一個 RWCU。	每個客戶刪除都會使用一個 RWCU。
		`ReplicationLatency`和`PendingReplicationCount`量度在中發佈 CloudWatch。	`ReplicationLatency`和`PendingReplicationCount`量度在中發佈 CloudWatch。	`ReplicationLatency`量度發佈於 CloudWatch。
	目的地	兩階段刪除發生：在階段 1 中， UpdateItem 設定刪除旗標。在階段 2 中， DeleteItem 刪除項目。	使用刪除項目 DeleteItem。	使用刪除項目 DeleteItem。
		會產生兩個串流記錄。第一筆記錄包含對`aws:rep:deleting`欄位的變更。第二個記錄包含客戶寫入的屬性和`aws:rep:*`屬性。	系統會產生單一資料流記錄，其中包含客戶撰寫的屬性。	系統會產生單一資料流記錄，其中包含客戶撰寫的屬性。
		每個客戶刪除時會使用兩個 RWCU。	每個客戶刪除都會使用一個 RWCU。	每個客戶刪除都會使用一個 RWCU。
		`ReplicationLatency`和`PendingReplicationCount`量度在中發佈 CloudWatch。	`ReplicationLatency`量度發佈於 CloudWatch。	`ReplicationLatency`量度發佈於 CloudWatch。

升級至版本 (目前版本)

執行下列步驟，以使用升級您的 DynamoDB 全域表版本。 AWS Management Console

若要將全域表格升級至版本 2019.11.21 (目前版本)

在 https://console.aws.amazon.com/dynamodb/home 開啟 DynamoDB 主控台。
在主控台左側的導覽窗格中，選擇 [表格]，然後選取要升級至版本 2019.11.21 (目前) 的全域資料表。
選擇 Global Tables (全域資料表) 標籤。
選擇 Update version (更新版本)。
閱讀並同意新的要求，然後選擇 Continue (繼續)。
升級程序完成後，顯示在主控台上的全域表格版本會變更為 2019.11. 21。

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

判斷版本

使用讀取和寫入操作