VeilNet

Database Replication

Stream a PostgreSQL primary to a replica in another region over the overlay, and connect app servers in both regions to the primary.

Needs
A primary, a replica and an app server in each region, with root access and outbound internet access
Uses
conflux up on every machine

Before and After VeilNet

Use this setup when database nodes and app servers in different regions need to reach each other, without a database proxy or VPN gateway between the regions.

Today, a database cluster across regions needs a database proxy and a VPN gateway in each region, tunnels between the gateways and a certificate on every node. The tunnels use RSA and ECDHE, and a quantum computer can break both.

With VeilNet, every database node and app server joins the overlay with an interface. They connect to the primary directly when the network allows it, and through a relay when it does not. You configure PostgreSQL as you would on a single network.

Today and with VeilNetDatabases

Today, TLS 1.2, RSA and ECDHE protect these links. A quantum computer can break all of them. With VeilNet, ML-DSA-87, ML-KEM-1024 and AES-256-GCM protect every link.

Setting Up Replication

0 of 7 done

  1. Follow Installation on each machine. Every machine in this guide runs conflux up to get an interface. The replica and the app servers need it to connect into the overlay, and the primary needs it to see each caller's own address.

On a sovereign network, the guardian commissions each machine and issues its manifest. Install it with sudo conflux enrol --manifest FILE, then run conflux up without --taint, because the credential carries the taints. See Joining a sovereign network.

Verifying the Setup

On the primary, query pg_stat_replication. You should see the replica streaming from its overlay address:

primary
$ sudo -u postgres psql -c 'SELECT client_addr, state FROM pg_stat_replication;'
              client_addr               |   state
----------------------------------------+-----------
 fd80:c4b9:99ae:d753:b981:caef:656a:375 | streaming
(1 row)

To see how the replica reaches the primary, run sudo conflux route -to on the replica with the primary's full AnchorID, from its anchor row. It prints direct, or the relays on the route:

replica
$ sudo conflux route -to anchor6btpa3gn6w4stipba4hekzho7caw6srfyy5puvbz7mfanaiept5a
direct

A relayed route shows relayed -> followed by its hops. To try to make it direct, run sudo conflux punch -to with the same ID. It prints the path is now direct, or explains why it could not.

Reference

ConfluxPublishing ServicesHow to bind a service on a machine with an interface, and which address a peer arrives from.Anchor protocolRouting and AddressesHow a route is chosen, and where each overlay address comes from.Anchor protocolDiscovery and NAT TraversalNAT traversal, hole punching and relays.Anchor protocolRun ModesLow-latency mode, and what it changes.