Access from outside the compose application?

[coyhile]

With no CNS names setup or anything else, how would one determine the address of the master in order to access the database? If I add a label: triton.cns.servivces=mydb, that's set on every instance, not just the writeable instance.

[teutat3s]

The general assumption is that the first container created will be the read/write primary. You could anticipate its auto-created CNS record with the $NAME.inst.$UUID.cns.domain record.
For example:
postgres-db-1.inst.fb75e85c-4e77-4e18-bb36-4b3e272baddd.basement.cns.coyhile.com

[coyhile]

Ah, thank you! I never remember the foobar.inst. names get created. But, what about when a failure occurs?

[misterbisson]

We had discussed a feature to support adding/removing CNS names at runtime (as would be necessary to use CNS when an instance is promoted to primary to replace a failed primary), but I don't believe this was ever implemented IIRC.

If you're looking for a one-off answer, I'd check your Consul cluster to see which pg instance has the lock as the primary.

If you're looking to do this at scale, I'd strongly consider implementing Consul-based dynamic discovery/configuration to the client app. Second to that, a proxy could perform that task, running either in the client instance, the pg host instance, or something in between.

[coyhile]

I always forget about foo.inst CNS records. But how does that help with failover?

…

Sent from my iPhone

On Jun 28, 2022, at 06:18, teutates ***@***.***> wrote:  The general assumption is that the first container created will be the read/write primary. You could anticipate its auto-created CNS record with the $NAME.inst.$UUID.cns.domain record. For example: postgres-db-1.inst.fb75e85c-4e77-4e18-bb36-4b3e272baddd.basement.cns.coyhile.com — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.