High availability

TwinCommit runs highly available as an active/passive pair. One replica holds a leader lease and streams; the other waits. Failover is safe because the checkpoint lives in the target and is committed with the data, so the new leader resumes from exactly where the old one stopped.

Kubernetes

The Helm chart enables leader election by default:

helm install prod-db2 twincommit/twincommit \
  --set replicaCount=2 \
  --set leaderElection.enabled=true \
  --set-file pipeline=./pipeline.yaml

The lease is a Kubernetes Lease object in the release namespace. If the leader stops renewing it (the default lease is 15 seconds), the standby takes over, opens the source log at the checkpoint and continues.

Outside Kubernetes

Use the ha block with a lock in the target database:

ha:
  mode: target-lock      # advisory lock on PostgreSQL, sp_getapplock on SQL Server
  lease: 15s

Run the same pipeline file on two hosts. Only the lock holder applies changes.

What failover costs

• Transactions that were buffered but not yet committed on the target are re-read from the source log by the new leader. Nothing is lost or duplicated.
• Large open transactions are read again from the log, so lag after failover can briefly rise.
• spill_dir contents are local to each replica and do not need to be shared.

Caution

Never run two instances of the same pipeline without leader election or a target lock. Both would apply the same changes, and while upserts make that harmless for data, the instances would compete for the checkpoint.