レガシー (2019.11.21) バージョンからグローバルテーブルを現在の (2017.11.29) バージョンにアップグレードする

DynamoDB グローバルテーブルには、グローバルテーブルバージョン 2019.11.21 (現行) との 2 つのバージョンがありますグローバルテーブルバージョン 2017.11.29 (レガシー）。可能な限り、2019.11.21 (現行) バージョンを使用してください。2017.11.29 (レガシー) よりも柔軟性と効率が高く、消費する書き込みキャパシティーが少ないためです。使用しているバージョンを確認するには、「」を参照してください使用しているグローバルテーブルのバージョンを確認する。

このセクションでは、DynamoDB コンソールを使用してグローバルテーブルをバージョン 2019.11.21 (現行) にアップグレードする方法について説明します。バージョン 2017.11.29 (レガシー) からバージョン 2019.11.21 (現行) へのアップグレードは 1 回限りのアクションであり、元に戻すことはできません。現在、グローバルテーブルはコンソールからのみアップグレードできます。

レガシーバージョンと現行バージョンの動作の違い

次のリストは、グローバルテーブルのレガシーバージョンと最新バージョンの動作の違いを示しています。

バージョン 2019.11.21 (現行) では、バージョン 2017.11.29 (レガシー) と比較して、いくつかの DynamoDB オペレーションの書き込みキャパシティーが減るため、ほとんどのお客様にとってコスト効率が高くなります。これらの DynamoDB オペレーションの違いは次のとおりです。

リージョン内の 1KB 項目PutItemを呼び出し、他のリージョンにレプリケートするには、2017.11.29 (レガシー) ではリージョンごとに 2 つの rWRUs が必要ですが、2019.11.21 (現行) では 1 つの rWRU しか必要ありません。
1KB 項目UpdateItemを呼び出すには、ソースリージョンに 2 つの rWRUs、2017.11.29 (レガシー) には送信先リージョンごとに 1 つの rWRU が必要ですが、2019.11.21 (現行) の送信元リージョンと送信先リージョンの両方で 1 つの rWRU のみが必要です。
1KB 項目DeleteItemを呼び出すには、ソースリージョンに 1 つの rWRU、2017.11.29 (レガシー) の場合は送信先リージョンごとに 2 つの rWRUs が必要ですが、2019.11.21 (現行) の場合は送信元リージョンと送信先リージョンの両方で 1 つの rWRU のみが必要です。

次の表は、2017.11.29 (レガシー) テーブルと 2019.11.21 (現行) テーブルの rWRU 消費量を示しています。

2 つのリージョンの 1KB 項目に対する 2017.11.29 (レガシー) テーブルと 2019.11.21 (現行) テーブルの rWRU 消費
操作	2017.11.29 (レガシー）	2019.11.21 (現行）	削減額
PutItem	4 rWRUs	2 rWRUs	50%
UpdateItem	3 rWRUs	2 rWRUs	33%
DeleteItem	3 rWRUs	2 rWRUs	33%

バージョン 2017.11.29 (レガシー) は 11 でのみ使用できます AWS リージョン。ただし、バージョン 2019.11.21 (現行) はすべてので利用できます AWS リージョン。
バージョン 2017.11.29 (レガシー) グローバルテーブルを作成するには、まず空のリージョンテーブルのセットを作成し、次に CreateGlobalTable API を呼び出してグローバルテーブルを作成します。バージョン 2019.11.21 (現行) グローバルテーブルを作成するには、 UpdateTable API を呼び出して既存のリージョンテーブルにレプリカを追加します。
バージョン 2017.11.29 (レガシー) では、新しいリージョンにレプリカを追加する前に、テーブル内のすべてのレプリカを空にする必要があります (作成時を含む）。バージョン 2019.11.21 (現行) では、すでにデータが含まれているテーブルのリージョンにレプリカを追加および削除できます。
バージョン 2017.11.29 (レガシー) では、レプリカの管理に次の専用コントロールプレーン APIs のセットを使用します。
バージョン 2019.11.21 (現行) では、 DescribeTableおよび UpdateTable APIs を使用してレプリカを管理します。
バージョン 2017.11.29 (レガシー) は、書き込みごとに 2 つの DynamoDB Streams レコードを発行します。バージョン 2019.11.21 (現行) は、書き込みごとに 1 つの DynamoDB Streams レコードのみを発行します。
バージョン 2017.11.29 (レガシー) では、aws:rep:deleting、、および aws:rep:updatetime 属性が入力されaws:rep:updateregion、更新されます。バージョン 2019.11.21 (現行) では、これらの属性は入力または更新されません。
バージョン 2017.11.29 (レガシー) は、レプリカ間で有効期限 (TTL)設定を同期しません。バージョン 2019.11.21 (現行) は、レプリカ間で TTL 設定を同期します。
バージョン 2017.11.29 (レガシー) では、TTL 削除は他のレプリカにレプリケートされません。バージョン 2019.11.21 (現行) は、すべてのレプリカに TTL 削除をレプリケートします。
バージョン 2017.11.29 (レガシー) は、レプリカ間で自動スケーリング設定を同期しません。バージョン 2019.11.21 (現行) は、レプリカ間で自動スケーリング設定を同期します。
バージョン 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 Scaling は、すべてのレプリカで WCUs に対して有効になっているか、すべてのレプリカでオンデマンドキャパシティモードが有効になっています。
アプリケーションでは、テーブル項目に aws:rep:deleting、aws: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 ポリシーは、2 つのリージョンにレプリカがある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"
            ]
        }
    ]
}

アップグレード中に想定されること

すべてのグローバルテーブルレプリカは、アップグレード中も引き続き読み取りトラフィックと書き込みトラフィックを処理します。
アップグレードプロセスには、テーブルのサイズとレプリカの数に応じて、数分から数時間かかります。
アップグレードプロセス中、の値はから ACTIVEに変更TableStatusされますUPDATING。DescribeTable API を呼び出すか、DynamoDB コンソールのテーブルビューを使用して、テーブルのステータスを表示できます。
Auto Scaling は、テーブルのアップグレード中に、グローバルテーブルのプロビジョニングされた容量設定を調整しません。アップグレード中にテーブルをオンデマンドキャパシティモードに設定することを強くお勧めします。
アップグレード中に Auto Scaling でプロビジョンドキャパシティモードを使用する場合は、アップグレード中のスロットリングを避けるために、トラフィックの予想される増加に対応するために、ポリシーの最小読み取りおよび書き込みスループットを増やす必要があります。
アップグレードプロセスが完了すると、テーブルのステータスがに変わりますACTIVE。

アップグレード前、アップグレード中、アップグレード後の DynamoDB Streams の動作

バージョン 2019.11.21 (現行) へのアップグレード

を使用して DynamoDB グローバルテーブルのバージョンをアップグレードするには、次の手順を実行します AWS Management Console。

グローバルテーブルをバージョン 2019.11.21 (現行) にアップグレードするには

DynamoDB コンソール (https://console.aws.amazon.com/dynamodb/home) を開きます。
コンソールの左側のナビゲーションペインで、テーブル を選択し、バージョン 2019.11.21 (現行) にアップグレードするグローバルテーブルを選択します。
[グローバルテーブル] タブを選択します。
[Update version (バージョンの更新)] を選択します。
新しい要件を読んで同意してから、[バージョンを更新] を選択します。
アップグレードプロセスが完了すると、コンソールに表示されるグローバルテーブルのバージョンが 2019.11.21 に変わります。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

バージョンを確認する

読み込み操作と書き込み操作の使用

操作	レプリカリージョン	アップグレード前の動作	アップグレード中の動作	アップグレード後の動作
入力または更新	ソース	タイムスタンプ母集団はを使用して行われますUpdateItem。	タイムスタンプ母集団はを使用して行われますPutItem。	顧客に表示されるタイムスタンプは生成されません。
		2 つのストリームレコードが生成されます。最初のレコードには、顧客が書き込んだ属性が含まれます。2 番目のレコードには、 `aws:rep:*` 属性が含まれています。	2 つのストリームレコードが生成されます。最初のレコードには、顧客が書き込んだ属性が含まれます。2 番目のレコードには、 `aws:rep:*` 属性が含まれています。	カスタマー書き込み属性を含む単一の Streams レコードが生成されます。
		顧客の書き込みごとに 2 つの rWCUs が消費されます。	顧客の書き込みごとに 2 つの rWCUs が消費されます。	顧客の書き込みごとに 1 つの rWCU が消費されます。
		`ReplicationLatency` および `PendingReplicationCount`メトリクスはで公開されます CloudWatch。	`ReplicationLatency` および `PendingReplicationCount`メトリクスはで公開されます CloudWatch。	`ReplicationLatency` メトリクスはで公開されます CloudWatch。
	送信先	レプリケーションはを使用して行われます PutItem。	レプリケーションはを使用して行われます PutItem。	レプリケーションはを使用して行われます PutItem。
		単一の Streams レコードが生成されます。このレコードには、お客様が作成した属性と `aws:rep:*` 属性の両方が含まれます。	単一の Streams レコードが生成されます。このレコードには、お客様が作成した属性と `aws:rep:*` 属性の両方が含まれます。	単一の Streams レコードが生成されます。このレコードには、お客様が作成した属性のみが含まれ、レプリケーション属性は含まれません。
		項目が送信先リージョンに存在する場合、1 つの rWCU が消費されます。項目が送信先リージョンに存在しない場合、2 つの rWCUs が消費されます。	項目が送信先リージョンに存在する場合、1 つの rWCU が消費されます。項目が送信先リージョンに存在しない場合、2 つの rWCUs が消費されます。	顧客の書き込みごとに 1 つの rWCU が消費されます。
		`ReplicationLatency` および `PendingReplicationCount`メトリクスはで公開されます CloudWatch。	`ReplicationLatency` および `PendingReplicationCount`メトリクスはで公開されます CloudWatch。	`ReplicationLatency` メトリクスはで公開されます CloudWatch。
[Delete] (削除)	ソース	を使用して、タイムスタンプの小さい項目をすべて削除しますDeleteItem。	を使用して、タイムスタンプの小さい項目をすべて削除します DeleteItem。	を使用して、タイムスタンプの小さい項目をすべて削除します DeleteItem。
		単一の Streams レコードが生成されます。このレコードには、お客様が作成した属性と `aws:rep:*` 属性の両方が含まれます。	単一の Streams レコードが生成されます。このレコードには、お客様が作成した属性と `aws:rep:*` 属性の両方が含まれます。	顧客が作成した属性を含む 1 つの Streams レコードが生成されます。
		カスタマーの削除ごとに 1 つの rWCU が消費されます。	カスタマーの削除ごとに 1 つの rWCU が消費されます。	カスタマーの削除ごとに 1 つの rWCU が消費されます。
		`ReplicationLatency` および `PendingReplicationCount`メトリクスはで公開されます CloudWatch。	`ReplicationLatency` および `PendingReplicationCount`メトリクスはで公開されます CloudWatch。	`ReplicationLatency` メトリクスはで公開されます CloudWatch。
	送信先	2 フェーズの削除が行われます。フェーズ 1 では、は削除フラグ UpdateItem を設定します。フェーズ 2 では、は項目 DeleteItem を削除します。	を使用して項目を削除します DeleteItem。	を使用して項目を削除します DeleteItem。
		2 つのストリームレコードが生成されます。最初のレコードには、 `aws:rep:deleting`フィールドへの変更が含まれています。2 番目のレコードには、お客様が作成した属性と `aws:rep:*` 属性が含まれています。	単一のストリームレコードが生成されます。このレコードには、お客様が作成した属性が含まれます。	単一のストリームレコードが生成されます。このレコードには、お客様が作成した属性が含まれます。
		カスタマー削除ごとに 2 つの rWCUs が消費されます。	カスタマーの削除ごとに 1 つの rWCU が消費されます。	カスタマーの削除ごとに 1 つの rWCU が消費されます。
		`ReplicationLatency` および `PendingReplicationCount`メトリクスはで公開されます CloudWatch。	`ReplicationLatency` メトリクスはで公開されます CloudWatch。	`ReplicationLatency` メトリクスはで公開されます CloudWatch。