- Hey, this is Kirk from the DynamoDB team.
And today we are talking about global tables.
So let's get going.
Global tables for Amazon DynamoDB
provides your replication with multi-region tables
that are replicated to and active in all regions you select.
It is fully managed, and once enabled,
there is really not much for you to do on an ongoing basis.
Every region's replica is active
as there are no read replicas in global tables.
You'll see this called multi-region, multi-active.
This means your app communicates with the local replica,
but your data is replicated by DynamoDB
to all of the AWS regions
that you have selected for that global table.
If you have an existing single region table,
it can easily be converted
to a global table with no downtime.
In addition, it is just as easy to add
and remove regions to existing global tables.
Your data is secure as all
of your data is encrypted in transit and at rest.
One thing to note is your table must be configured
to use either on-demand capacity mode,
or if you are using provision capacity mode,
auto scaling must be enabled.
Now that you know the basics of global tables in DynamoDB,
let's dive that next level deeper
into how things operate
and what you need to know to be successful with it.
DynamoDB global table replicas are interconnected,
but they are not interdependent.
This means table replicas are connected
and do exchange data,
but their functioning
and maintenance are not dependent upon each other.
If something happens in AWS region A,
it does not affect other global table replicas
in other regions.
Your app should be writing
to the replica in the same region as the app
for the lowest latency and overall performance.
With that,
your data will usually propagate
to other replicas within one second.
Keep in mind these rates are eventually consistent
across global table replicas.
As you might imagine,
this means you could have conflicts
if you are updating the same item
in one or more regions.
In this case,
global tables will use what's called
last writer wins algorithm to reconcile the conflicts.
Last writer wins means that whichever replica
writes the latest version of the item,
that is the one that wins
and will be written to all other replicas.
Along with this, operations such as conditional expressions,
atomic updates, and transactions are on a regional basis.
Therefore, think of it like this.
Data modifications for those local operations will replicate
across the global table, but not the operations themselves.
For example, if you perform a transact write operation
in region A,
those writes will be committed locally
as part of that transaction.
The data changed by those operations
will be replicated to regions B and C,
but not written
as a transactional operation in those other regions.
One thing to note is that with global tables,
writes to your table are priced differently
as they will be replicated
to other replicas in the global table.
Instead of a write capacity unit or write request unit,
it is a replicated write capacity unit
or a replicated write request unit.
Whether it is a capacity unit
or a request unit is determined
by the capacity mode the global table is in.
So why does any of this matter?
When you use global tables for DynamoDB,
it gives your application higher availability,
more durability, and better fault tolerance.
In disaster recovery planning terms,
your database would meet a recovery time objective
of near zero and a recovery point objective
of about one second.
To strengthen that even more,
using global tables means you
get a database uptime service level agreement
from AWS of 99.999%.
There's one other use case
for global tables that you should know about.
And that's when migrating between regions.
Let's say you are currently in region A
and now want to move your entire infrastructure to region B.
You enable global tables by adding a replica in region B.
Once your data is fully replicated over
and your application is moved over as well,
you are now free to make final arrangements
for that now legacy environment in region A.
Now let's talk a little bit about setup and operation.
You can use the AWS console, API, CLI,
CloudFormation, or CDK to operate everything
with global tables.
All right, so now it is demo time.
Right now I am on the global tables tab of my music table.
I'm going to hit create replicas
because I want to create a new global table.
I'm gonna add this one to US west Oregon.
One thing to note here is that because on this table
I do not have DynamoDB streams enabled,
this will enable it for me
because it relies on DynamoDB streams.
And now DynamoDB is in the background creating a replica
in US west 2 and streaming any data that I have.
There's no data in this table right now,
but if there was, it would start streaming that.
So we're going to explore tables.
We're going to create a new item.
Since it's a music table we'll put in here
Radiohead as the artist, and for the sort key,
we have the song title, "Paranoid Android".
All right. And hit create item.
So now when we go over to US west 2,
look in our tables,
we see the music table.
And we look under explore table items.
We see that there is Radiohead and "Paranoid Android".
In summary,
use DynamoDB global tables if you need
better fault tolerance and durability
of your data as part of your overall disaster recovery plan,
for when you need to replicate data
between AWS regions to get data closer to your customers,
and when you need to migrate between AWS regions.
Thanks and be on the lookout
for more core concept videos here
and on our Twitter handle, @DynamoDB.