For the postgresql helper, hardened the code to get "the" cursor of the postgresql instance.
For the statuspage, a small status json is returned.
To find out what status a PostgreSQL cluster is in we use the cursor (instead of the provided query() function), as the query function does some retrying etc. For the healthcheck we want to simple provide an answer to a simple query, if we have to reconnect, we are not *that* healthy anyway.
Dropped catching exceptions in the do_GET block, as the HTTPServer will do that nicely for us anyway.
Basically this is rollback to the original decision tree with the small exception:
1 - If leader is defined and it's not me - then slave would be started immidiately
with the correct recovery conf.
2 - If leader is defined in and it's my host, then it will start instance in
readonly (but without primary_conninfo in recovery.conf)
3 - And the third case - if the leader is not defined - it also will start
instance in readonly, without primary_conninfo.
After performing 2 or 3 it will perform usual decision tree.
Also governor is able to pick up already running master and slave
instances without restarting them.
In case is you have a lock and postgres is not running behaviour remains
the same: it will start master in read only mode and then promote if it
still has the lock.
The StatusPage uses a BaseHTTPServer to server 3 simple http endpoints:
- pg_master, returns 200 if PostgreSQL is running as master
- pg_slave, returns 200 if PostgreSQL is running as slave
- pg_status, returns some information about the cluster
It does this by relying on the PostgreSQL connection of the Governor.
Now methods supporting the case when leader is not defined. There would
be no primary_conninfo in recovery.conf. I like it more comparing to
postgres://169.0.0.1:5432
Create a superuser role with a given name and password (or change
the postgres role if the name is not given). Also, create an admin
role with the name and the password provided. The admin role has
CREATEDB and CREATEROLE permisssions, effectively making it the
most powerful role after the superuser.
When PostgreSQL is running inside the docker container, it should provide
the address of the host it's running on and not the address from inside
of the container to the outside world.
Feike Steenbergen