ALICIA WILLIAMS: These days, it's
not enough for your applications to be sometimes on.
They need a database that maintains high availability
while handling increasing and seasonal loads.
In today's episode of Spanner Database Unlimited,
we'll show you under the hood how Cloud Spanner provides
five nines.
That's 99.999% uptime for your mission critical applications,
even at Google scale.
[MUSIC PLAYING]
Your customers demand 24/7 access.
Every second your data is unavailable,
you're losing money.
You're not able to process orders, customers can't log in,
or perhaps your operations are ground to a halt. Regulations,
such as ISO 27001 and HIPAA, require
availability guarantees.
For critical infrastructure like health care
or financial services, downtime can
have rippling effects into the economy or public health.
So what are typical causes of downtime for a database?
First, the infrastructure can fail.
Disks die, routers melt down, or memory is corrupted.
Spanner, like other distributed systems,
handles these types of failure by maintaining
separate copies of your data across isolated infrastructure.
The more copies and isolation, the
lower the probability of a complete failure.
Let's dig into how replication works in Spanner.
A regional instance is composed of three
identical read-write replicas.
When you provision one Spanner node,
you actually get three units of storage
and compute that work together.
Each replica contains a full copy of the database
and is hosted in a different physical location or zone.
The zones are organized to reduce the chances
that more than one will fail at the same time,
for example, by having independent power and cooling.
As data changes, Spanner updates each of the replicas.
It uses the Paxos consensus protocol and true time
to ensure these updates are strongly consistent.
We'll dive into Spanner's industry
leading consistency guarantees in the next video.
If one zone becomes unavailable, Spanner automatically
routes queries to the other zones.
This all happens online, meaning in-flight queries won't fail
and the database can continue to handle queries and updates.
Once the zone comes back up, it will
catch up from the other replicas automatically
and resume handling traffic once it's current.
No manual intervention is needed and there's never any downtime.
Regional Spanner configuration support up to four nines,
or 99.99% availability for mission critical applications.
While very unlikely, a region can
be a single point of failure, for example,
in a natural disaster.
So Spanner also offers multi-region configurations.
In this case, it spreads data over
geographically dispersed locations using
Google's dedicated network.
By spreading replicas over multiple independent regions,
a multi-region configuration can achieve up
to five nines of availability.
For the most demanding uptime requirements,
such as in financial services, online gaming and retail,
this is the level of availability you need.
Spanner does a lot of work behind the scenes
to ensure availability, consistency, and performance
at scale.
Google's own applications depend on it today.
However, to your developers, it looks like a single scale
up database.
They don't have to worry about brittle sharding,
eventual consistency, or manual failover,
and can focus on innovation.
Another source of potential downtime
is regular maintenance.
Software gets updated, firmware is
patched, security policies are revised, which in most cases
means bringing down the database.
In a world of always-on access and increasing interdependence
of business processes, finding maintenance windows
across an application set can be impossible.
With Spanner, though, planned database maintenance
is a thing of the past.
Spanner is fully managed.
Google's best in class site reliability engineering
ensures it's always up to date, without having
to bring down the database.
A third source of potential downtime
is changes in applications that rely on the database.
If your application requires a schema change,
like adding a new table or changing a data type,
Spanner's unique schema versioning
allows you to apply changes to a live instance
without missing a beat.
Some schema updates are applied immediately,
such as adding a NOT NULL column.
Others require a validation to avoid violating consistency
constraints or require backfilling,
such as adding an index.
While this backfilling happens automatically
in the background, Spanner continues
to service queries against the previous version of the schema.
Once the changes are completed, it automatically switches over
to the new schema, providing a 100% consistent view
of the data without incurring any downtime.
Another application change that can cause downtime, bugs--
for example, a delete that leaves off aware condition
and deletes too much data, or a calculation error that
corrupts data.
But Spanner provides transactionally consistent
backups, allowing you to roll back to a known good state.
This is possible because every update in Spanner
happens at a time stamp.
Instead of changing the data in place,
Spanner marks the old data as expired
and new data is available at this time.
Using this precise change tracking, backups always
capture a consistent snapshot of the data,
even as data is updated during the time
it takes for the backup to complete.
Restoring a consistent view of the data from a backup
is simple and can be online in minutes,
reducing the recovery time objective during a disaster.
Today, we showed you how Spanner provides availability at scale.
In the next episode, we're diving
into Spanner's consistency at scale.
If you thought you could only have two of the three,
well, stay tuned for next episode's conclusion.
[MUSIC PLAYING]
Thanks for joining us today on Spanner Database Unlimited.