You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
High availability (HA) minimizes database downtime by maintaining standby replicas
17
-
of every node in a cluster. If a node goes down, Azure Cosmos DB for PostgreSQL
18
-
switches incoming connections from the failed node to its standby. Failover
19
-
happens within a few minutes, and promoted nodes always have fresh data through
20
-
PostgreSQL synchronous streaming replication.
16
+
High availability (HA) minimizes database downtime by maintaining standby replicas of every node in a cluster. If a node goes down, Azure Cosmos DB for PostgreSQL switches incoming connections from the failed node to its standby. Failover happens within a few minutes, and promoted nodes always have fresh data through PostgreSQL synchronous streaming replication.
21
17
22
-
All primary nodes in a cluster are provisioned into one [availability zone](./concepts-availability-zones.md)
23
-
for better latency between the nodes. The preferred availability zone allows you to put all cluster nodes in the same availability zone where the application is deployed. This proximity could improve performance further by decreasing app-database latency. The standby nodes are provisioned into
24
-
another availability zone. The Azure portal
25
-
[displays](concepts-cluster.md#node-availability-zone) the availability
26
-
zone of each primary node in a cluster. You can also check availability zone of each node in a cluster using one of the programmatic methods such as [REST APIs](/rest/api/postgresqlhsc/servers/get).
18
+
All primary nodes in a cluster are provisioned into one [availability zone](./concepts-availability-zones.md) for better latency between the nodes. The preferred availability zone allows you to put all cluster nodes in the same availability zone where the application is deployed. This proximity could improve performance further by decreasing app-database latency. The standby nodes are provisioned into another availability zone. The Azure portal
19
+
[displays](concepts-cluster.md#node-availability-zone) the availability zone of each primary node in a cluster. You can also check availability zone of each node in a cluster using one of the programmatic methods such as [REST APIs](/rest/api/postgresqlhsc/servers/get).
27
20
28
-
Even without HA enabled, each node has its own locally
29
-
redundant storage (LRS) with three synchronous replicas maintained by Azure
30
-
Storage service. If there's a single replica failure, it’s detected by Azure
31
-
Storage service and is transparently re-created. For LRS storage durability,
Even without HA enabled, each node has its own locally redundant storage (LRS) with three synchronous replicas maintained by Azure Storage service. If there's a single replica failure, it’s detected by Azure Storage service and is transparently re-created. For LRS storage durability, see metrics [on this page](../../storage/common/storage-redundancy.md#summary-of-redundancy-options).
34
22
35
-
When HA *is* enabled, Azure Cosmos DB for PostgreSQL runs one standby node for each primary
36
-
node in the cluster. The primary and its standby use synchronous
37
-
PostgreSQL replication. This replication allows customers to have predictable
38
-
downtime if a primary node fails. In a nutshell, our service detects a failure
39
-
on primary nodes, and fails over to standby nodes with zero data loss.
23
+
When HA *is* enabled, Azure Cosmos DB for PostgreSQL runs one standby node for each primary node in the cluster. The primary and its standby use synchronous PostgreSQL replication. This replication allows customers to have predictable downtime if a primary node fails. In a nutshell, our service detects a failure on primary nodes, and fails over to standby nodes with zero data loss.
40
24
41
-
To take advantage of HA on the coordinator node, database applications need to
42
-
detect and retry dropped connections and failed transactions. The newly
43
-
promoted coordinator is accessible with the same connection string.
25
+
To take advantage of HA on the coordinator node, database applications need to detect and retry dropped connections and failed transactions. The newly promoted coordinator is accessible with the same connection string.
44
26
45
27
## High availability states
46
28
47
-
Recovery can be broken into three stages: detection, failover, and full
48
-
recovery. Azure Cosmos DB for PostgreSQL runs periodic health checks on every node, and
49
-
after four failed checks it determines that a node is down. Azure Cosmos DB for PostgreSQL
50
-
then promotes a standby to primary node status (failover), and creates a new
51
-
standby-to-be. Streaming replication begins, bringing the new node up to date.
29
+
Recovery can be broken into three stages: detection, failover, and full recovery. Azure Cosmos DB for PostgreSQL runs periodic health checks on every node, and after four failed checks it determines that a node is down. Azure Cosmos DB for PostgreSQL then promotes a standby to primary node status (failover), and creates a new standby-to-be. Streaming replication begins, bringing the new node up to date.
52
30
When all data has been replicated, the node has reached full recovery.
53
31
54
-
Azure Cosmos DB for PostgreSQL displays its failover progress state on the Overview page
55
-
for clusters in the Azure portal.
32
+
Azure Cosmos DB for PostgreSQL displays its failover progress state on the Overview page for clusters in the Azure portal.
56
33
57
34
***Healthy**: HA is enabled and the node is fully replicated to its standby.
58
-
***Failover in progress**: A failure was detected on the primary node and
59
-
a failover to standby was initiated. This state transitions into
60
-
**Creating standby** once failover to the standby node is completed, and the
61
-
standby becomes the new primary.
62
-
***Creating standby**: The previous standby was promoted to primary, and a
63
-
new standby is being created for it. When the new secondary is ready, this
64
-
state transitions into **Replication in progress**.
65
-
***Replication in progress**: The new standby node is provisioned and data
66
-
synchronization is in progress. Once all data is replicated to the new
67
-
standby, synchronous replication is enabled between the primary and
68
-
standby nodes, and the nodes' state transitions back to **Healthy**.
35
+
***Failover in progress**: A failure was detected on the primary node and a failover to standby was initiated. This state transitions into **Creating standby** once failover to the standby node is completed, and the standby becomes the new primary.
36
+
***Creating standby**: The previous standby was promoted to primary, and a new standby is being created for it. When the new secondary is ready, this state transitions into **Replication in progress**.
37
+
***Replication in progress**: The new standby node is provisioned and data synchronization is in progress. Once all data is replicated to the new standby, synchronous replication is enabled between the primary and standby nodes, and the nodes' state transitions back to **Healthy**.
Copy file name to clipboardExpand all lines: articles/cosmos-db/postgresql/concepts-private-access.md
+31-85Lines changed: 31 additions & 85 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,78 +20,37 @@ This page describes the private access option. For public access, see
20
20
21
21
## Definitions
22
22
23
-
**Virtual network**. An Azure Virtual Network (VNet) is the fundamental
24
-
building block for private networking in Azure. Virtual networks enable many
25
-
types of Azure resources, such as database servers and Azure Virtual Machines
26
-
(VM), to securely communicate with each other. Virtual networks support on-premises
27
-
connections, allow hosts in multiple virtual networks to interact with each
28
-
other through peering, and provide added benefits of scale, security options,
29
-
and isolation. Each private endpoint for a cluster
30
-
requires an associated virtual network.
23
+
**Virtual network**. An Azure Virtual Network (VNet) is the fundamental building block for private networking in Azure. Virtual networks enable many types of Azure resources, such as database servers and Azure Virtual Machines (VM), to securely communicate with each other. Virtual networks support on-premises connections, allow hosts in multiple virtual networks to interact with each other through peering, and provide added benefits of scale, security options, and isolation. Each private endpoint for a cluster requires an associated virtual network.
31
24
32
25
**Subnet**. Subnets segment a virtual network into one or more subnetworks.
33
-
Each subnetwork gets a portion of the address space, improving address
34
-
allocation efficiency. You can secure resources within subnets using Network
35
-
Security Groups. For more information, see Network security groups.
36
-
37
-
When you select a subnet for a cluster’s private endpoint, make sure
38
-
enough private IP addresses are available in that subnet for your current and
39
-
future needs.
40
-
41
-
**Private endpoint**. A private endpoint is a network interface that uses a
42
-
private IP address from a virtual network. This network interface connects
43
-
privately and securely to a service powered by Azure Private Link. Private
44
-
endpoints bring the services into your virtual network.
45
-
46
-
Enabling private access for Azure Cosmos DB for PostgreSQL creates a private endpoint for
47
-
the cluster’s coordinator node. The endpoint allows hosts in the selected
48
-
virtual network to access the coordinator. You can optionally create private
49
-
endpoints for worker nodes too.
50
-
51
-
**Private DNS zone**. An Azure private DNS zone resolves hostnames within a
52
-
linked virtual network, and within any peered virtual network. Domain records
53
-
for nodes are created in a private DNS zone selected for
54
-
their cluster. Be sure to use fully qualified domain names (FQDN) for
55
-
nodes' PostgreSQL connection strings.
26
+
Each subnetwork gets a portion of the address space, improving address allocation efficiency. You can secure resources within subnets using Network Security Groups. For more information, see Network security groups.
27
+
28
+
When you select a subnet for a cluster’s private endpoint, make sure enough private IP addresses are available in that subnet for your current and future needs.
29
+
30
+
**Private endpoint**. A private endpoint is a network interface that uses a private IP address from a virtual network. This network interface connects privately and securely to a service powered by Azure Private Link. Private endpoints bring the services into your virtual network.
31
+
32
+
Enabling private access for Azure Cosmos DB for PostgreSQL creates a private endpoint for the cluster’s coordinator node. The endpoint allows hosts in the selected virtual network to access the coordinator. You can optionally create private endpoints for worker nodes too.
33
+
34
+
**Private DNS zone**. An Azure private DNS zone resolves hostnames within a linked virtual network, and within any peered virtual network. Domain records for nodes are created in a private DNS zone selected for their cluster. Be sure to use fully qualified domain names (FQDN) for nodes' PostgreSQL connection strings.
56
35
57
36
## Private link
58
37
59
-
You can use [private endpoints](../../private-link/private-endpoint-overview.md)
60
-
for your clusters to allow hosts on a virtual network
You can use [private endpoints](../../private-link/private-endpoint-overview.md) for your clusters to allow hosts on a virtual network (VNet) to securely access data over a [Private Link](../../private-link/private-link-overview.md).
63
39
64
-
The cluster's private endpoint uses an IP address from the virtual
65
-
network's address space. Traffic between hosts on the virtual network and
66
-
nodes goes over a private link on the Microsoft backbone
67
-
network, eliminating exposure to the public Internet.
40
+
The cluster's private endpoint uses an IP address from the virtual network's address space. Traffic between hosts on the virtual network and nodes goes over a private link on the Microsoft backbone network, eliminating exposure to the public Internet.
68
41
69
-
Applications in the virtual network can connect to the nodes
70
-
over the private endpoint seamlessly, using the same connection strings and
71
-
authorization mechanisms that they would use otherwise.
42
+
Applications in the virtual network can connect to the nodes over the private endpoint seamlessly, using the same connection strings and authorization mechanisms that they would use otherwise.
72
43
73
-
You can select private access during cluster creation,
74
-
and you can switch from public access to private access at any point.
44
+
You can select private access during cluster creation, and you can switch from public access to private access at any point.
75
45
76
46
### Using a private DNS zone
77
47
78
-
A new private DNS zone is automatically provisioned for each private endpoint,
79
-
unless you select one of the private DNS zones previously created by Azure
80
-
Cosmos DB for PostgreSQL. For more information, see the [private DNS zones
81
-
overview](../../dns/private-dns-overview.md).
48
+
A new private DNS zone is automatically provisioned for each private endpoint, unless you select one of the private DNS zones previously created by Azure Cosmos DB for PostgreSQL. For more information, see the [private DNS zones overview](../../dns/private-dns-overview.md).
82
49
83
50
The Azure Cosmos DB for PostgreSQL service creates DNS records such as
84
-
`c-mygroup01.12345678901234.privatelink.postgres.cosmos.azure.com` in the selected private
85
-
DNS zone for each node with a private endpoint. When you connect to a
86
-
node from an Azure VM via private endpoint, Azure DNS
87
-
resolves the node’s FQDN into a private IP address.
88
-
89
-
Private DNS zone settings and virtual network peering are independent of each
90
-
other. If you want to connect to a node in the cluster from a client
91
-
that's provisioned in another virtual network (from the same region or a
92
-
different region), you have to link the private DNS zone with the virtual
93
-
network. For more information, see [Link the virtual
`c-mygroup01.12345678901234.privatelink.postgres.cosmos.azure.com` in the selected private DNS zone for each node with a private endpoint. When you connect to a node from an Azure VM via private endpoint, Azure DNS resolves the node’s FQDN into a private IP address.
52
+
53
+
Private DNS zone settings and virtual network peering are independent of each other. If you want to connect to a node in the cluster from a client that's provisioned in another virtual network (from the same region or a different region), you have to link the private DNS zone with the virtual network. For more information, see [Link the virtual network](../../dns/private-dns-getstarted-portal.md#link-the-virtual-network).
If you're using a custom DNS server, you must use a DNS forwarder to resolve the FQDN of nodes. The forwarder IP address should be 168.63.129.16. The custom DNS server should be inside the virtual network or reachable via the virtual network's DNS server setting. To learn more, see [Name resolution that uses your own DNS server](../../virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances.md#name-resolution-that-uses-your-own-dns-server).
110
64
111
65
### Recommendations
112
66
113
-
When you enable private access for your cluster,
114
-
consider:
67
+
When you enable private access for your cluster, consider:
68
+
69
+
***Subnet size**: When selecting subnet size for a cluster, consider current needs such as IP addresses for coordinator or all nodes in that cluster, and future needs such as growth of that cluster.
70
+
71
+
Make sure you have enough private IP addresses for the current and future needs. Keep in mind, Azure reserves five IP addresses in each subnet.
72
+
73
+
See more details [in this FAQ](../../virtual-network/virtual-networks-faq.md#configuration).
115
74
116
-
***Subnet size**: When selecting subnet size for a cluster,
117
-
consider current needs such as IP addresses for coordinator or all
118
-
nodes in that cluster, and future needs such as growth of that cluster.
119
-
Make sure you have enough private IP addresses for the current and
120
-
future needs. Keep in mind, Azure reserves five IP addresses in each subnet.
***Private DNS zone**: DNS records with private IP addresses are going to be
124
-
maintained by Azure Cosmos DB for PostgreSQL service. Make sure you don’t delete private
125
-
DNS zone used for clusters.
75
+
***Private DNS zone**: DNS records with private IP addresses are going to be maintained by Azure Cosmos DB for PostgreSQL service. Make sure you don’t delete private DNS zone used for clusters.
126
76
127
77
## Limits and limitations
128
78
129
-
See Azure Cosmos DB for PostgreSQL [limits and limitations](reference-limits.md)
130
-
page.
79
+
See Azure Cosmos DB for PostgreSQL [limits and limitations](reference-limits.md) page.
131
80
132
81
## Next steps
133
82
134
83
* Learn how to [enable and manage private access](howto-private-access.md)
135
-
* Follow a [tutorial](tutorial-private-access.md) to see private access in
0 commit comments