Previously, the leader key was watched for changes after a failover. This resulted in a delay
of up to 10 seconds to report a healthy failover back to the client.
With this patch, we are not relying on the role of a member registered in the dcs anymore.
For managing Patroni clusters, the Patroni api can be used. For many tasks, a command line interface for
this api would be a useful addition. This commit adds patroncli (The name is still under debate).
The command line interface needs access to the DCS; this is required for any operation. For some tasks it is required
to have access to the Patroni api.
A small summary of the additions to get the cli/ctl started:
* Updated Docker image to use 'true' as the archive_command, to ensure disk not filling up during failover
testing.
* The cli currently can list members, failover a master and remove a given cluster from DCS.
* The cli can be configured with a command, for repeated access to the same DCS
* Added some simple tests for the cli, code coverage is very low
As the Dockerfile is there mainly to support developers, we want to build the Dockerfile using the current working
directory instead of a previously released version.
To help in developing features, the Dockerfile and its entrypoint have been extended.
The README.md explains stuff in detail, in short:
- you can now run a Patroni cluster with a single command
Due to the renaming of Governor to Patroni some old references needed to be updated.
Also some python packages need to be added.
Added entrypoint.sh as a script, to ensure Patroni will have PID = 1 when the container is run.
The Dockerfile now only builds upon the publicly available Ubuntu docker image, thereby reducing the size of the image.
etcd release 2.0.12 was released today as well, updated that dependency.
Removed aws reference from Dockerfile, remove unnecessary steps.
Connect using libpq parameters, therefore providing nice application name for Governor.
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.
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.
Feike Steenbergen