Configure a secondary

This page describes how to pair an appliance as a disaster recovery secondary and how to secure the replication connection. It applies to Automated disaster recovery on the DCT appliance.

Pair the appliance as a secondary

First, install the appliance you intend to use as the secondary the same way you install any DCT appliance, and complete its initial setup so it is up and running as a standalone appliance. Then configure it as a secondary using the steps below.

You establish the relationship from the appliance you want to use as the secondary. On that appliance's Disaster Recovery tile, select Configure as secondary and provide the following:

Field	Required	Description
Display name	No	A friendly label for this secondary, shown in the primary's list of replicas.
Primary host / IP	Yes	The hostname or IP address of the primary appliance to replicate from. If you later enable certificate validation, this value must match the primary's certificate, so use an address that will remain stable.
Sysadmin username	Yes	A sysadmin-level account on the primary. It is used once to authorize the pairing; DCT then generates dedicated replication credentials automatically, so this login is not stored.
Sysadmin password	Yes	The password for the sysadmin account above.
Bypass SSL validation	No	Controls how the secondary validates the primary's certificate. See Securing replication. Leave unchecked for production.

When you submit, DCT runs a set of connection checks against the primary before it changes anything, and stops immediately with a specific message if any check fails. Because nothing is saved when a check fails, you can safely use Configure as secondary to verify your network and credentials before an actual cutover. The checks confirm, in order:

1. The primary is reachable over HTTPS (port 443).

2. The primary's certificate is valid (unless you bypass validation).

3. The sysadmin credentials are accepted.

4. The DCT and PostgreSQL versions match.

5. The primary is reachable on the database port (5433).

6. The replication credentials can log in to the primary's database.

Each check reports a distinct message, so if configuration fails you can tell exactly which requirement is not yet met — for example, that HTTPS works but the database port is blocked.

After configuration completes, the appliance transitions to the Secondary role and begins streaming.

Securing replication (TLS and certificates)

The connection from the secondary to the primary is always encrypted. What you control is whether the secondary also verifies the primary's identity.

Two settings govern this, and they interact:

• Bypass SSL validation — when enabled, the secondary trusts whatever certificate the primary presents and does not check that the certificate matches the primary's address. The connection is still encrypted, but it cannot cryptographically confirm that it is talking to the intended primary. This is convenient for a lab or test setup that uses a self-signed certificate, but it is not recommended for production.

• Replication CA certificate — the certificate authority (or certificate chain) the secondary should trust when validating the primary.

Bypass takes priority. If Bypass SSL validation is enabled, the secondary uses it even if you have also uploaded a CA certificate. An uploaded CA certificate takes effect only after you turn bypass off. In practice this means the connection behaves as follows:

Setting	Connection behavior
Bypass enabled	Encrypted, no identity check.
Bypass disabled, no CA certificate uploaded	Encrypted, no identity check. This is the default after initial setup.
Bypass disabled, CA certificate uploaded	Encrypted, with full validation of the primary's identity against the uploaded certificate.

Certificates are managed on the appliance's existing Network Security tile on the Setup Dashboard — the same place you manage the appliance's other certificates. There is no separate disaster-recovery certificate screen.

• On the primary, the replication certificate the secondary connects to is listed under the Network Security tile's key store, alongside the appliance's other certificates. You can replace it with one issued by your own certificate authority.

• On the secondary, you add the certificate (or chain) that signs the primary's replication certificate to the Network Security tile's trust store.

Enabling full certificate validation

To move a secondary from encrypted-only to fully validated:

1. (Optional) On the primary, replace the replication certificate under Network Security with one issued by your certificate authority. If you skip this, the primary keeps its existing self-signed certificate, which still works with the steps below.

2. Obtain the certificate or certificate chain that signs the primary's replication certificate.

3. On the secondary, add that certificate to the Network Security trust store.

4. On the secondary, reconfigure the secondary with Bypass SSL validation unchecked. Turning bypass off is what activates the trusted certificate — adding it to the trust store alone does not.

5. On the Disaster Recovery tile, confirm that SSL validation shows as validated and the replication CA certificate shows as configured.

Once validation is enabled, the primary's address must match its certificate. If the primary's address changes later, replace or reissue its certificate to cover the new address before the secondary can validate it again.

Related pages