[MUSIC].
>> Hello, welcome to the Azure Cosmos DB liftoff series.
My name is Nik Larin.
I'm an Azure Cosmos DB for Postgres product manager.
Today we're going to talk about
scaling our distributed Postgres database in Azure,
scaling reads across multiple Azure regions and
using positives class their read replicas for disaster recovery.
Before we begin, let me quickly go through
the key terminology we use in our distributed Postgres.
Postgres cluster may have two types of nodes,
coordinator and worker node.
Each node is a managed Postgres server with
Citus extension lying on its own virtual machine,
coordinator stores cluster metadata and is the cluster node that
your application connects to as it would
to any other Postgres database.
Coordinator acts as a dispatcher for distributed queries
and writes directing them to the right nodes in the cluster.
I'll going to gauge in,
read results coming from
individual nodes before sending it back to the application.
Worker node stores actual data in the formal shards.
Shard is a Postgres table on the worker node that
contains sub-set of rows for a given Postgres table.
We talk about sharding when we need to
distribute Postgres database or in other words,
divide data Amanda notes by putting it in individual shards.
Distribution column, also called distribution key,
is used to assign table rows to specific shards.
Choosing the distribution column for each table in
your database is one of
the most important data modeling decisions.
It determines how data is spread across the nodes in the cluster,
enhance performance of the distributed Postgres.
Now that we've reviewed the key terms for distributed Postgres,
lets take a look at the scale-out capabilities.
The most fundamental ability of
Azure Cosmos DB for Postgres is scale-out.
You can start with a single node Postgres and shard
your Postgres database by adding
more nodes to the cluster in future.
Let's take a closer look at what defined
single and multi node Postgres.
Single-node Postgres, is what we offer in as
a part of the Azure Cosmos DB is a
robust and full-featured managed Postgres.
It is built using native open source Postgres.
We support all major Postgres versions
that are maintained by Postgres community.
The major benefit of using native Postgres,
that is not a Postgres fork in our managed service,
is how fast we can deliver innovation in Postgres database engine
and compatibility with reach
Postgres ecosystems including extensions.
Then our single node Postgres,
offers a broad range of features that you
may expect in a managed relational database service,
from compute and storage scaling to
high availability to network security options and clean
public and private access
to cross-region read replicas and that we're
going to talk more in this presentation and more.
One of the distinctive features of
our single node Postgres is ability to
define data distribution model even
before you need all power of multi-node cluster.
To do that, you would need to select
the column to be used as a distribution key and create
distributed tables that would define shards
and rules for possible future multi-node cluster.
Doing that is easy before you
ingest significant amount of data into
your Postgres database and makes
your workload to ready for future scale-out.
How exactly transition from single node to multi-node works
when you outgrow single node
or simply need power of distributed Postgres,
you can transition to multi-node Postgres
in two steps without downtime.
First, you need to add worker nodes.
Once added worker nodes are empty,
so you need to move some data to these nodes.
For that, you need to do
so-called sharp rebalancing that would move
chunks of data to the worker nodes with zero database downtime.
Your application continue to work as before,
as connection strings stays the same and
all features that you configured before falls
your single-node Postgres will continue
to be there in the multi-node configuration.
Once data is moved to worker nodes,
your transition from single node or multi-node Postgres cluster is
completed and you can enjoy
the benefits of multi-node Postgres performance.
Here's how transition works.
On this slide,
we're starting with a single node on
the left that combines coordinator worker node roles.
We talked about data modeling on single node by choosing
distribution column and creating distributed tables.
Once done, it is just about adding worker nodes to
your single node with few clicks in
Azure portal and rebalancing shards.
The data is moved to the newly added nodes.
On the left side, you can see
a single node configuration that is transitioning to
Multi-node 1 on the right
with one coordinator and three worker nodes.
After transition to multi-node cluster,
your application continues to connect to coordinator node for
reads and writes with
elevated performance delivered by multiple nodes.
When your data and performance needs grow even further,
you can keep adding worker nodes to
your multi-node configuration with zero downtime.
Let's take a look at the live Postgres cluster that has
outgrown single-node Postgres and needs to become a Multi-node 1.
While scale-out helps to
keep growing your cluster with zero downtime,
it is happening on one cluster.
What if you have a very demanding read consumer,
such as hundreds and thousands of
users refreshing their analytical dashboards.
Cluster read replicas may help in this case,
you would create a read replica cluster
in the same or another Azure region and point
those readers to debt replica to
offload reads from your primary Postgres cluster.
You can create read replicas for
single node or multi-node clusters.
Let's take a look at what defines read replica clusters.
First of all, it is a synchronous replication.
It means that transaction can be committed on
the primary postgres cluster
before it's replicated to all replicas.
That improves performance on the primary cluster,
but also means that you have
so-called replication [inaudible] replicas that you
would want to monitor using Azure monitor metrics.
Each read replica has its own connection string,
as well as certain configuration settings,
such as compute configuration.
It means that you can have
a more or less powerful read replicas
compared to your primary cluster,
depending on the actual compute needs on these replicas.
You can create up to five replicas in any supported Azure region.
Last but not least,
you can create read replicas for a read write cluster,
but you can't create a replica for
a replica or so-called nested replicas.
In addition to read scalability,
read replicas can be used for
cross-region disaster recovery when you need to switch
from your primary cluster to
another one in case of region unavailability.
Read replicas can also be used to move
your Postgres cluster from one Azure region to another.
Let's take a closer look at disaster recovery with read replicas.
A read replica in Azure Cosmos DB for Postgres can be promoted
to an independent cluster available for reads and writes.
You can break replication relationship between
a read replica in its primary cluster at anytime.
As replication between primary cluster and
its replicas is a synchronous,
there is often replication lag
that can vary across nodes in a cluster.
To decide on whether you would like to
promote specific replica to an independent cluster,
you may check replication lag on all nodes and
the replica cluster using Azure Monitor Metrics.
Once read replica promotion is initiated,
it cannot be reversed and would take a few minutes to complete.
Now let's take a look at what we discussed today.
We talked about single node and
multi-node Postgres clusters and how to
transition from a single node to multi-node clusters.
How to set up read replicas of
distributed Postgres database in different Azure regions.
Finally, we talked about how to
use read replicas for disaster recovery.
If you would like to learn more about
Azure Cosmos DB for Postgres,
use this short link.
Thank you very much for your time. [MUSIC]