Physical cluster replication is only supported in CockroachDB self-hosted clusters.
In this tutorial, you will set up physical cluster replication (PCR) between a primary cluster and standby cluster. The primary cluster is active, serving application traffic. The standby cluster is passive, accepting updates from the primary cluster. The replication stream will send changes from the primary to the standby.
The unit of replication is a virtual cluster, which is part of the underlying infrastructure in the primary and standby clusters.
In this tutorial, you will connect to:
- The system virtual cluster for administration tasks in both clusters, and starting the replication stream from the standby cluster.
- The application virtual cluster on the primary cluster to work with databases, tables, workloads, and so on.
Overview
The high-level steps in this tutorial are:
- Create and start the primary cluster.
- Configure and create a user on the primary cluster.
- Create and start the standby cluster.
- Configure and create a user on the standby cluster.
- Securely copy certificates.
- Start the replication stream from the standby cluster.
Before you begin
- Two separate CockroachDB clusters (primary and standby) with a minimum of three nodes each, and each using the same CockroachDB v24.3 version.
- To set up each cluster, you can follow Deploy CockroachDB on Premises. When you initialize the cluster with the
cockroach init
command, you must pass the--virtualized
or--virtualized-empty
flag. Refer to the cluster creation steps for the primary cluster and for the standby cluster for details. - The Deploy CockroachDB on Premises tutorial creates a self-signed certificate for each self-hosted cluster. To create certificates signed by an external certificate authority, refer to Create Security Certificates using OpenSSL.
- To set up each cluster, you can follow Deploy CockroachDB on Premises. When you initialize the cluster with the
- All nodes in each cluster will need access to the Certificate Authority for the other cluster. Refer to Manage the cluster certificates.
- An Enterprise license on the primary and standby clusters. You must use the system virtual cluster on the primary and standby clusters to enable your Enterprise license.
- The primary and standby clusters must have the same region topology. For example, replicating a multi-region primary cluster to a single-region standby cluster is not supported. Mismatching regions between a multi-region primary and standby cluster is also not supported.
To set up PCR from an existing CockroachDB cluster, which will serve as the primary cluster, refer to Set up PCR from an existing cluster.
Step 1. Create the primary cluster
Initialize the primary cluster
To enable PCR, it is necessary to initialize the CockroachDB cluster with the appropriate flag to create the appropriate virtual clusters on the primary and standby cluster.
When initializing the primary cluster, you pass the --virtualized
flag to create a virtualized cluster with a system
virtual cluster and a main
virtual cluster. When initializing the standby cluster, you pass the --virtualized-empty
flag to create a virtualized standby cluster that contains a system
virtual cluster.
For example, the cockroach init
command to initialize the primary cluster (according to the prerequisite deployment guide):
cockroach init --certs-dir=certs --host={address of any node on --join list} --virtualized
Ensure that you follow the prerequisite deployment guide to initialize your cluster before continuing to set up PCR.
Connect to the primary cluster system virtual cluster
Connect to your primary cluster's system virtual cluster using cockroach sql
.
To connect to the system virtual cluster, pass the
options=-ccluster=system
parameter in the URL:cockroach sql --url \ "postgresql://root@{node IP or hostname}:26257?options=-ccluster=system&sslmode=verify-full" \ --certs-dir "certs"
The prompt will include
system
when you are connected to the system virtual cluster.Note:You should only connect to the system virtual cluster for cluster administration. To work with databases, tables, or workloads, connect to a virtual cluster.
Add your cluster organization and Enterprise license to the cluster:
SET CLUSTER SETTING cluster.organization = 'your organization';
SET CLUSTER SETTING enterprise.license = 'your enterprise license';
Set the
kv.rangefeed.enabled
cluster setting totrue
. The replication job connects to a long-lived request, a rangefeed, which pushes changes as they happen:SET CLUSTER SETTING kv.rangefeed.enabled = true;
Confirm the status of your virtual cluster:
SHOW VIRTUAL CLUSTERS;
The output will include the
system
virtual cluster and themain
virtual cluster:id | name | data_state | service_mode -----+--------+------------+--------------- 1 | system | ready | shared 3 | main | ready | shared (2 rows)
Because this is the primary cluster rather than the standby cluster, the
data_state
of all rows isready
, rather thanreplicating
or another status.
Create a replication user and password
The standby cluster connects to the primary cluster's system virtual cluster using an identity with the REPLICATION
privilege. Connect to the primary cluster's system virtual cluster and create a user with a password:
From the primary's system virtual cluster SQL shell, create a user and password:
CREATE USER {your username} WITH PASSWORD '{your password}';
Grant the
REPLICATION
system privilege to your user:GRANT SYSTEM REPLICATION TO {your username};
If you need to change the password later, refer to
ALTER USER
.
Connect to the primary virtual cluster (optional)
If you would like to run a sample workload on the primary's virtual cluster, open a new terminal window and use
cockroach workload
to run the workload.For example, to initiate the
movr
workload:cockroach workload init movr "postgresql://root@{node_advertise_address}:{node_advertise_port}?options=-ccluster=main&sslmode=verify-full&sslrootcert=certs/ca.crt&sslcert=certs/client.root.crt&sslkey=certs/client.root.key"
Replace
{node_advertise_address}
and{node_advertise_port}
with a node's--advertise-addr
IP address or hostname and port.The
cockroach workload
command does not support connection or security flags like othercockroach
commands. Instead, you must use a connection string at the end of the command. As a result, for the example in this tutorial, you will need:options=-ccluster=main
sslmode=verify-full
sslrootcert={path}/certs/ca.crt
: the path to the CA certificate.sslcert={path}/certs/client.root.crt
: the path to the client certificate.sslkey={path}/certs/client.root.key
: the path to the client private key.
For additional detail on the standard CockroachDB connection parameters, refer to Client Connection Parameters.
Run the
movr
workload for a set duration using the same connection string:cockroach workload run movr --duration=5m "postgresql://root@{node_advertise_address}:{node_advertise_port}?options=-ccluster=main&sslmode=verify-full&sslrootcert=certs/ca.crt&sslcert=certs/client.root.crt&sslkey=certs/client.root.key"
To connect to the primary cluster's virtual cluster, use the
options=-ccluster={virtual_cluster_name}
parameter:cockroach sql --url \ "postgresql://root@{node IP or hostname}:26257?options=-ccluster=main&sslmode=verify-full" \ --certs-dir "certs"
The prompt will include
main
when you are connected to the virtual cluster.Create a user for your primary cluster's
main
virtual cluster:CREATE USER {your username} WITH PASSWORD '{your password}';
You can connect to the DB Console with this user to observe activity on the primary cluster. Open a web browser at
https://{node IP or hostname}:8080/
and enter your credentials.
Step 2. Create the standby cluster
Initialize the standby cluster
Similarly to the primary cluster, you must initialize the standby cluster with the --virtualized-empty
flag. This creates a virtualized cluster with a system virtual cluster.
For example, the cockroach init
command to initialize the standby cluster (according to the prerequisite deployment guide):
cockroach init --certs-dir=certs --host={address of any node on --join list} --virtualized-empty
Ensure that you follow the prerequisite deployment guide to initialize your cluster before continuing to set up PCR.
Connect to the standby cluster system virtual cluster
Connect to your standby cluster's system virtual cluster using cockroach sql
.
To connect to the system virtual cluster, pass the
options=-ccluster=system
parameter in the URL:cockroach sql --url \ "postgresql://root@{node IP or hostname}:{26257}?options=-ccluster=system&sslmode=verify-full" \ --certs-dir "certs"
Add your cluster organization and Enterprise license to the cluster:
SET CLUSTER SETTING cluster.organization = 'your organization';
SET CLUSTER SETTING enterprise.license = 'your enterprise license';
Set the
kv.rangefeed.enabled
cluster setting totrue
. The replication job connects to a long-lived request, a rangefeed, which pushes changes as they happen:SET CLUSTER SETTING kv.rangefeed.enabled = true;
Confirm the status of your virtual cluster:
SHOW VIRTUAL CLUSTERS;
The output will show the
system
virtual cluster, but nomain
virtual cluster:id | name | data_state | service_mode ---+----------+------------+--------------- 1 | system | ready | shared (1 rows)
Create a user for the standby cluster
If you would like to access the DB Console to observe your replication, you will need to create a user:
Create a user:
CREATE USER {your username} WITH LOGIN PASSWORD {'your password'};
To observe the replication activity, your user will need
admin
privileges:GRANT admin TO {your username};
Open the DB Console in your web browser:
https://{node IP or hostname}:8080/
, where you will be prompted for these credentials. Refer to Physical Cluster Replication Monitoring for more detail on tracking relevant metrics for your replication stream.
Step 3. Manage the cluster certificates
It is important to carefully manage the exchange of CA certificates between clusters if you have generated self-signed certificates with cockroach cert
as part of the prerequisite deployment tutorial.
To create certificates signed by an external certificate authority, refer to Create Security Certificates using OpenSSL.
At this point, the primary and standby clusters are both running. The next step allows the standby cluster to connect to the primary cluster and begin ingesting its data. Depending on how you manage certificates, you must ensure that all nodes on the primary and the standby cluster have access to the certificate of the other cluster.
You can use the cockroach encode-uri
command to generate a connection string containing a cluster's certificate for any PCR statements that require a connection string.
For example, in this tutorial you will need a connection string for the primary cluster when you start the replication stream from the standby.
To generate a connection string, pass the replication user, IP and port, along with the directory to the certificate for the primary cluster:
cockroach encode-uri {replication user}:{password}@{node IP or hostname}:26257 --ca-cert certs/ca.crt --inline
The connection string output contains the primary cluster's certificate:
postgresql://{replication user}:{password}@{node IP or hostname}:26257/defaultdb?options=-ccluster%3Dsystem&sslinline=true&sslmode=verify-full&sslrootcert=-----BEGIN+CERTIFICATE-----{encoded_cert}-----END+CERTIFICATE-----%0A
Copy the output ready for Step 4, which requires the connection string to the primary cluster.
Step 4. Start replication
The system virtual cluster in the standby cluster initiates and controls the replication stream by pulling from the primary cluster. In this section, you will connect to the primary from the standby to initiate the replication stream.
From the standby cluster, use your connection string to the primary:
If you generated the connection string using
cockroach encode-uri
:CREATE VIRTUAL CLUSTER main FROM REPLICATION OF main ON 'postgresql://{replication user}:{password}@{node IP or hostname}:{26257}/defaultdb?options=-ccluster%3Dsystem&sslinline=true&sslmode=verify-full&sslrootcert=-----BEGIN+CERTIFICATE-----{encoded_cert}-----END+CERTIFICATE-----%0A';
Otherwise, pass the connection string that contains:
- The replication user and password that you created for the primary cluster.
- The node IP address or hostname of one node from the primary cluster.
- The path to the primary node's certificate on the standby cluster.
CREATE VIRTUAL CLUSTER main FROM REPLICATION OF main ON 'postgresql://{replication user}:{password}@{node IP or hostname}:{26257}?options=-ccluster=system&sslmode=verify-full&sslrootcert=certs/{primary cert}.crt';
Once the standby cluster has made a connection to the primary cluster, the standby will pull the topology of the primary cluster and will distribute the replication work across all nodes in the primary and standby.
Tip:You can also start a PCR stream that includes a read-only standby virtual cluster that allows you to read data on the standby cluster. For more details, refer to the
CREATE VIRTUAL CLUSTER
page.To view all virtual clusters on the standby, run:
SHOW VIRTUAL CLUSTERS;
The standby cluster will show the
main
virtual cluster is in areplicating
state.id | name | data_state | service_mode -----+--------+-------------+--------------- 1 | system | ready | shared 3 | main | replicating | none (2 rows)
The standby cluster's virtual cluster is offline while the replication stream is running. To bring it online, you must explicitly start its service after failover.
To manage the replication stream, you can pause and resume the replication stream as well as show the current details for the job:
ALTER VIRTUAL CLUSTER main PAUSE REPLICATION;
ALTER VIRTUAL CLUSTER main RESUME REPLICATION;
SHOW VIRTUAL CLUSTER main WITH REPLICATION STATUS;
id | name | source_tenant_name | source_cluster_uri | retained_time | replicated_time | replication_lag | failover_time | status ---+------+--------------------+--------------------------------------------------------+-------------------------------+------------------------+-----------------+--------------+-------------- 3 | main | main | postgresql://user@{node IP or hostname}:{26257}?redacted | 2024-04-17 20:14:31.952783+00 | 2024-04-17 20:18:50+00 | 00:00:08.738176 | NULL | replicating (1 row)
With the replication stream running, you can monitor the job via the DB Console, SQL shell, or Prometheus. You can also verify data is correct on the standby cluster at a specific point in time. For more detail, refer to Physical Cluster Replication Monitoring.
Set up PCR from an existing cluster
You can replicate data from an existing CockroachDB cluster that does not have cluster virtualization enabled to a standby cluster with cluster virtualization enabled. In the PCR setup, the existing cluster is the primary cluster, which serves application traffic.
Before you begin, you will need:
- An existing primary cluster that is running v24.3. If you need to upgrade your existing cluster, refer to Upgrade to CockroachDB v24.2.
- A v24.2 standby cluster. To set up the cluster, you can follow Deploy CockroachDB on Premises. When you initialize the cluster with the
cockroach init
command, you must pass the--virtualized-empty
flag. For details, refer to the cluster creation steps for the standby cluster. - Review the remaining prerequisites at the start of this page, which also apply to running PCR from an existing cluster.
Example
To configure the standby cluster ready for PCR, follow the steps outlined in Connect to the standby cluster system virtual cluster that include enabling the necessary cluster settings.
Create a user on both clusters and grant the
SYSTEM REPLICATION
privilege to the created user on each cluster:CREATE USER {your username} WITH PASSWORD '{your password}';
GRANT SYSTEM REPLICATION TO {your username};
View the virtual clusters on both clusters:
SHOW VIRTUAL CLUSTERS;
You will find that both clusters only have the
system
virtual cluster:id | name | data_state | service_mode -----+--------+------------+--------------- 1 | system | ready | shared (1 row)
To create the replication job, you will need a connection string for the primary cluster containing its CA certificate. For steps to generate a connection string with
cockroach encode-uri
, refer to Step 3. Manage the cluster certificates.If you would like to run a test workload on your existing primary cluster, you can use
cockroach workload
like the following:cockroach workload init movr 'postgresql://root@{node IP or hostname}:{26257}?options=-ccluster=main&sslmode=verify-full&sslrootcert=certs/ca.crt&sslcert=certs/client.root.crt&sslkey=certs/client.root.key'
To start the replication, you will need to replicate
system
from the existing primary cluster in order to create a new virtual cluster on the standby cluster (main
in this example).On the standby cluster, run:
CREATE VIRTUAL CLUSTER main FROM REPLICATION OF system ON '{postgresql://{replication user}:{password}@{node IP or hostname}:26257/defaultdb?options=-ccluster%3Dsystem&sslinline=true&sslmode=verify-full&sslrootcert=-----BEGIN+CERTIFICATE-----{encoded_cert}-----END+CERTIFICATE-----%0A}';
This statement includes:
main
: The name of the virtual cluster to create on the standby cluster.system
: The system virtual cluster on the existing primary cluster.- The connection string for the existing primary cluster.
View the virtual clusters on the standby cluster:
SHOW VIRTUAL CLUSTERS;
The output shows the newly created
main
virtual cluster and that the replication job isinitializing
:id | name | data_state | service_mode -----+--------+--------------------------+--------------- 1 | system | ready | shared 3 | main | initializing replication | none (2 rows)
At this point, your replication stream will be running.
To fail over to the standby cluster, follow the instructions on the Fail Over from a Primary Cluster to a Standby Cluster page.
For details on how to fail back after replicating a non-virtualized cluster, refer to Fail back after PCR from an existing cluster.
Connection reference
This table outlines the connection strings you will need for this setup tutorial.
For additional detail on the standard CockroachDB connection parameters, refer to Client Connection Parameters.
You can use an external connection to define a name for connections using the postgresql://
scheme.
The table uses main
as an example name for the virtual cluster that contains user table data in the primary and standby clusters.
Cluster | Virtual Cluster | Usage | URL and Parameters |
---|---|---|---|
Primary | System | Set up a replication user and view running virtual clusters. Connect with cockroach sql . |
"postgresql://root@{node IP or hostname}:{26257}?options=-ccluster=system&sslmode=verify-full"
--certs-dir flag to specify the path to your certificate. |
Primary | Main | Add and run a workload with cockroach workload . |
"postgresql://root@{node IP or hostname}:{26257}?options=-ccluster=main&sslmode=verify-full&sslrootcert=certs/ca.crt&sslcert=certs/client.root.crt&sslkey=certs/client.root.key" The cockroach workload command does not support connection or security flags like other cockroach commands. Instead, you must use a connection string at the end of the command. As a result, for the example in this tutorial, you will need:
|
Standby | System | Manage the replication stream. Connect with cockroach sql . |
"postgresql://root@{node IP or hostname}:{26257}?options=-ccluster=system&sslmode=verify-full"
--certs-dir flag to specify the path to your certificate. |
Standby/Primary | System | Connect to the other cluster. | "postgresql://{replication user}:{password}@{node IP or hostname}:{26257}/defaultdb?options=-ccluster%3Dsystem&sslinline=true&sslmode=verify-full&sslrootcert=-----BEGIN+CERTIFICATE-----{encoded_cert}-----END+CERTIFICATE-----%0A" Generate the connection string with cockroach encode-uri . Use the generated connection string in:
|
Standby | Read only | Run read queries on the standby's replicating virtual cluster | "postgresql://root@{node IP or hostname}:{26257}?options=-ccluster=main-readonly&sslmode=verify-full"
--certs-dir flag to specify the path to your certificate. |