AWS recently released a new version of Global Tables for DynamoDB which changes how the the global table is defined. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/globaltables.V2.html
There is an updated synchronization protocol that decreases the needed write capacity and a simplified definition of how to create a cross region replication (i.e. a global table).
Where as before to set-up cross region replication the individual tables needed to be created and a seperate globabl table to keep those tables in sync (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/globaltables.tutorial.html#creategt_console) the new version API (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/V2globaltables.tutorial.html#V2creategt_cli) requires an update to the original table to tell it to replicate to separate regions rather than having separately managed tables connected through a global table. This means the current method of defining a global table (aws_dynamodb_global_table) is outdated in modeling how global tables are defined with this new API.
Unsure
Existing single-region DynamoDB tables can now be converted to global tables:
Note that the workflow for creating and managing the v2019 tables is completely different than v2017, and that the list of available features is different. Some critical differences I've noticed include the following:
Given the differences listed above, there may be an argument here for implementing this new feature as a completely separate resource type, aws_dynamodb_table_v2019
or something along those lines.
This tutorial is a good reference for the new workflow: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/V2globaltables.tutorial.html#V2creategt_cli
Existing single-region DynamoDB tables can now be converted to global tables:
NOTE: this describes the behavior of the new v2019 tables, but I'm fairly certain it does not imply that existing v2017 single-region tables can be converted (please correct me if you find documentation to the contrary). One thing that I am sure about is that existing v2017 multi-region tables cannot be converted to v2019.
@crawforde I took a stab at implementing the new version based on your suggestions (we have a need for this functionality). I'm not sure it should be a separate resource, though, as it's my understanding if you have a DynamoDB table that is not currently being replicated as a global table (V2017) you can start replicating it using V2019 (AFAIK, non-global tables don't have a V2017/V2019 version).
Let me know what you think.
I'm doing some testing on your PR now. The only issue I've seen is that it's wanting to recreate all of my GSIs on two of my tables.... This appears separate from the other issue of recreating GSIs, as some of them don't have any non_key_attributes.
@stolfi hmm...is it related to billing_mode
?
@stolfi hmm...is it related to
billing_mode
?
I'm currently PPR, let me move that table to provisioned to see if it makes a difference. I have 17 tables, so it's odd that only two have this issue.
Sorry for the delay... It does appear to be billing mode related. I moved to PROVISIONED on one of two tables and am able to get the plan
to come back with no changes.
Let me see if I can hunt that down and put in a fix.
@stolfi awesome. Thanks for testing!
Initial support for this functionality (a new replica
configuration block in the aws_dynamodb_table
resource) has been merged and will release with version 2.58.0 of the Terraform AWS Provider, later this week. Thanks to @cmonty for the implementation. 👍
This has been released in version 2.58.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.
For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks!
I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.
If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!
Most helpful comment
Note that the workflow for creating and managing the v2019 tables is completely different than v2017, and that the list of available features is different. Some critical differences I've noticed include the following:
Given the differences listed above, there may be an argument here for implementing this new feature as a completely separate resource type,
aws_dynamodb_table_v2019
or something along those lines.This tutorial is a good reference for the new workflow: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/V2globaltables.tutorial.html#V2creategt_cli