Configuring Streaming Replication DR with WAL Archive Failback on Kubernetes Posgres
search cancel

Configuring Streaming Replication DR with WAL Archive Failback on Kubernetes Posgres

book

Article ID: 425889

calendar_today

Updated On:

Products

VMware Tanzu for Postgres

Issue/Introduction

When the Primary and DR side are:

  1. Using "Creating a TLS Secret Manually."
  2. Each side/instance use own CA
  3. For each we created "Custom List of Trusted Certificate Authories"

We observed the following issue when streaming:

kubectl get postgres/postgresql-dr -n <namespace> -oyaml
....
  streamingStatus: Pending
....

The cursor found that the direct connection from DR to primary is not working because it is not using the bundled certificate:

✅ DR instance STATUS: Running
✅ WAL Archive Fallback: Working (replication via pgBackRest)
❌ Streaming Replication: NOT working (direct connection from DR to primary)
⚠️ Streaming Status: "Pending" with error message

 

Does this mean we cannot use different CA's?

 

Resolution

The requirement is that both the Primary and Standby (DR) clusters must have TLS certificates generated using the same CA.

Certificates requirements for streaming replication 

Certificates requirements for streaming replication include:

  • The primary and DR site should use the certificates generated by the same CA.
  • If the active cluster is using the cert-manager-generated certificates then the cert-manager's Certificate Authority (CA) must be the same in the disaster recovery site.
  • If the active postgres cluster uses a custom Certificate Authority (CA) certificate then you must generate the server TLS certificate and Replication TLS certificate by using the same CA as the active cluster, and populate the 'spec.certificateSecretName' and 'spec.replicationCertificateSecretName' fields in the Disaster Recovery site.
  • The replication TLS certificate must have a Common Name (CN) setting that matches 'replication', which is the preset replication user.