This page describes how to use cross-data-center replication by creating and working with secondary database clusters in Kubernetes.
For a conceptual overview of cross-data-center replication, see About cross-data-center replication.
Before you begin
- Install AlloyDB Omni Operator version 1.1.0 or higher to deploy AlloyDB Omni on a Kubernetes cluster in the primary data center and a Kubernetes cluster in the secondary data center.
- Create an AlloyDB Omni database cluster on the Kubernetes cluster in the primary data center.
Create a secondary database cluster
To create an AlloyDB Omni secondary database cluster and enable replication from your primary database cluster, follow these steps:
Kubernetes
Ensure external connectivity is enabled on your AlloyDB Omni primary database cluster. If external connectivity is not enabled, add the following to the spec section of the database cluster manifest:
kind: DBCluster spec: allowExternalIncomingTraffic: true
To enable replication on your primary database cluster, apply a manifest similar to the following to your Kubernetes cluster on the primary data center:
apiVersion: v1 kind: Secret metadata: name: ha-rep-pw-DB_CLUSTER_NAME type: Opaque data: rep-user-pw: "ENCODED_PASSWORD" --- apiVersion: alloydbomni.dbadmin.goog/v1 kind: Replication metadata: name: REPLICATION_NAME spec: dbcluster: name: DB_CLUSTER_NAME upstream: password: name: ha-rep-pw-DB_CLUSTER_NAME
Replace the following:
DB_CLUSTER_NAME
: The name of the database cluster—for example,dbc-1
.ENCODED_PASSWORD
: The password for the database user to be used for replication from secondary databases, encoded as a base64 string—for example,Q2hhbmdlTWUxMjM= for ChangeMe123
. The default value isalloydbreplica
.REPLICATION_NAME
: the name of the replication—for example,replication-1
.
Wait for the replication status to be ready.
To get the upstream connection information that is used to configure replication on the secondary database cluster, run the following command:
kubectl get replication REPLICATION_NAME
kubectl get replication REPLICATION_NAME -o json | jq .status.upstream
Sample output looks similar to the following:
{ "host": "35.230.32.36", "password": { "name": "ha-rep-pw-dbc-1" }, "port": 5432, "replicationSlotName": "dbc_1_replication_1", "username": "alloydbreplica" }
Take a note of the output since you need it to enable replication on the secondary database cluster in the following step.
Create an AlloyDB Omni cluster on your Kubernetes cluster in the secondary data center with configuration identical to your primary database cluster.
Ensure external connectivity is enabled on your AlloyDB Omni secondary database cluster.
If external connectivity is not enabled, add the following to the spec section of its manifest:
allowExternalIncomingTraffic: true
To enable replication on your secondary database cluster, apply a manifest similar to the following to your Kubernetes cluster on the secondary data center:
apiVersion: v1 kind: Secret metadata: name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME type: Opaque data: rep-user-pw: "ENCODED_PASSWORD" --- apiVersion: alloydbomni.dbadmin.goog/v1 kind: Replication metadata: name: SECONDARY_REPLICATION_NAME spec: dbcluster: name: SECONDARY_DB_CLUSTER_NAME downstream: host: PRIMARY_HOST port: PRIMARY_PORT username: alloydbreplica password: name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME replicationSlotName: PRIMARY_REPLICATION_SLOT control: setup
Replace the following:
SECONDARY_DB_CLUSTER_NAME
: The name of the secondary database cluster—for example,dbc-2
.ENCODED_PASSWORD
: The password for the database user to be used for replication the primary database cluster, encoded as a base64 string—for example,Q2hhbmdlTWUxMjM= for ChangeMe123
. The default value isalloydbreplica
.SECONDARY_REPLICATION_NAME
: the name of the replication—for example,replication-2
.PRIMARY_HOST
: the connection endpoint of the primary database cluster from the output in step 3 that the secondary database can access for replication.PRIMARY_PORT
: the connection port of the primary database cluster from the output in step 3 that the secondary database can access for replication.PRIMARY_REPLICATION_SLOT
: the name of the replication slot on the primary database cluster from the output in step 3 that the secondary database can use for replication.
View replication on the secondary database cluster
To view detailed information about an AlloyDB Omni secondary database cluster and its replication status, run the following commands:
Kubernetes
kubectl get dbcluster SECONDARY_DB_CLUSTER_NAME
kubectl get replication SECONDARY_REPLICATION_NAME
When the secondary database cluster is successfully set up and has streaming replication from the primary database cluster, the replication status is both ready and healthy.
Promote a secondary database cluster
Before you promote a secondary database cluster, perform the following steps to verify that the secondary database cluster has applied all transactions received from the primary database cluster:
Kubernetes
Check the replication status of the secondary database cluster, to ensure that it's both ready and healthy.
kubectl get replication SECONDARY_REPLICATION_NAME
Stop all writes to the primary database cluster. Run the following query on your primary database cluster to check the replication lag of the secondary database. Confirm that the result shows a minimal lag.
A lag value of 0 is ideal. If the lag is greater than 0, you can still promote the secondary database cluster, at the risk of losing some recent transactions already committed on the primary database cluster.
psql -h PRIMARY_HOST -U postgres -d postgres -c 'SELECT application_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;'
To promote a secondary database cluster to a primary database cluster, update the control field of your secondary database cluster's replication manifest to promote
, and apply that on your Kubernetes cluster on the secondary data center.
Kubernetes
apiVersion: v1
kind: Secret
metadata:
name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
type: Opaque
data:
rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
name: SECONDARY_REPLICATION_NAME
spec:
dbcluster:
name: SECONDARY_DB_CLUSTER_NAME
downstream:
host: PRIMARY_HOST
port: PRIMARY_PORT
username: alloydbreplica
password:
name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
replicationSlotName: PRIMARY_REPLICATION_SLOT
control: promote
Perform a switchover
Before you perform a switchover, verify that the primary and the secondary database clusters that belong to both data centers are online and that the database clusters are in a healthy state.
To ensure data consistency of your primary and secondary database clusters during switchover, perform the following steps to verify that the secondary database cluster has applied all transactions received from the primary database cluster:
Kubernetes
Check the replication status of the secondary database cluster, to ensure that it's both ready and healthy.
kubectl get replication SECONDARY_REPLICATION_NAME
Stop all writes to the primary database cluster. Run the following query on your primary database cluster to check the replication lag of the secondary database. Confirm that the result shows a lag value of
0
.psql -h PRIMARY_HOST -U postgres -d postgres -c 'SELECT application_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;'
To perform a switchover, complete the following steps:
Kubernetes
To convert your AlloyDB Omni secondary database cluster into a primary database cluster, update its replication manifest on your Kubernetes cluster in the secondary data center as follows:
apiVersion: v1 kind: Secret metadata: name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME type: Opaque data: rep-user-pw: "ENCODED_PASSWORD" --- apiVersion: alloydbomni.dbadmin.goog/v1 kind: Replication metadata: name: SECONDARY_REPLICATION_NAME spec: dbcluster: name: SECONDARY_DB_CLUSTER_NAME upstream: password: name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
Wait for the replication status to be ready.
To get the upstream connection information for replication, run the following command:
kubectl get replication SECONDARY_REPLICATION_NAME
kubectl get replication SECONDARY_REPLICATION_NAME -o json | jq .status.upstream
Sample output looks similar to the following:
{ "host": "34.23.207.137", "password": { "name": "ha-rep-pw-dbc-2" }, "port": 5432, "replicationSlotName": "dbc_2_replication_2", "username": "alloydbreplica" }
To convert your AlloyDB Omni primary database cluster into a secondary database cluster, update its replication manifest on your Kubernetes cluster on the primary data center similar to the following:
apiVersion: v1 kind: Secret metadata: name: ha-rep-pw-DB_CLUSTER_NAME type: Opaque data: rep-user-pw: "ENCODED_PASSWORD" --- apiVersion: alloydbomni.dbadmin.goog/v1 kind: Replication metadata: name: REPLICATION_NAME spec: dbcluster: name: DB_CLUSTER_NAME downstream: host: SECONDARY_HOST port: SECONDARY_PORT username: alloydbreplica password: name: ha-rep-pw-DB_CLUSTER_NAME replicationSlotName: SECONDARY_REPLICATION_SLOT control: rewind
Wait for the replication status to become ready and healthy.
To verify the replication status use:
kubectl get replication REPLICATION_NAME