Deploying across multiple hosts (maybe expand the tutorial?)

[sacrophyte]

The tutorial does a great job covering a super simple, very basic demo on one host. What about two hosts?

I currently have a primary running on host1 along with the monitor. When I try to add a secondary postgres node (which lives on host2), I get an error saying that "pg_autoctl is already running" with a PID on my localhost (host1). I know pg_autoctl is already running on the localhost, that is the whole point. I do not understand the error.

I then setup pg_autoctl on host2, but when trying to add the primary, I get "pg_autoctl does not know how to reach state "unknown" from "init"". I am very confused why pg_autoctl is trying to get to state unknown, that seems very bizarre to me.

Help?

[DimCitus]

Hi @sacrophyte ; are you referring to the README page (intended at contributors and first discovery of the concepts), or the full Azure tutorial on many nodes, as in https://pg-auto-failover.readthedocs.io/en/master/tutorial.html ? I believe the latter provides some of the answers you're looking for?

[sacrophyte]

Good point - yes, the Azure tutorial is what I am looking for. However, it is very hard to read for someone not used to Azure or VMs - every single pg_autoctl command is wrapped up in vm commands, which obfuscates the point of the documentation a little bit (at least for me).

For example, the command to "run a monitor":

ssh -l ha-admin `vm_ip monitor` -- \
  pg_autoctl create monitor \

It is not immediately intuitive to me exactly which host this is actually on - from the other commands, I think the host is ha-demo-monitor.internal.cloudapp.net, correct?

Likewise for node a, you bring up a node:

ssh -l ha-admin `vm_ip a` -- \
  pg_autoctl create postgres \
    --pgdata ha \
    --auth trust \
    --ssl-self-signed \
    --username ha-admin \
    --dbname appdb \
    --hostname ha-demo-a.internal.cloudapp.net \
...

I think this connects to ha-demo-a.internal.cloudapp.net; but if it does, why do you have to specify the --hostname if it is the same? Just to avoid the DNS lookup process?

I'll chew on this some more.

[DimCitus]

The confusion from the Azure integration is a very good point. We tried hard to keep a balance between a fully executable documentation and an easy to read one. This part is written in tutorial style, and you can actually copy/paste commands from the tutorial and run them and it all works. That's a nice property that we'd like to keep, even if simplifications would be needed.

Now, the vm_ip TARGET script gives you the public IP address of the node TARGET (one of monitor, a, b, app). The --hostname refers to the hostname used by the nodes to connect to each other. So that would use the private IP addresses of the nodes, and when you have a dedicated VLAN, the IP address on that VLAN. When using azure, we can also use their internal DNS names (here, ha-demo-a.internal.cloudapp.net for the node a of the demo network setup).