Skip to content

Instantly share code, notes, and snippets.

@tpo

tpo/understanding_patroni.md

Last active June 11, 2020 13:41
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tpo/242c899d49784d6082f9e9a20b25de91 to your computer and use it in GitHub Desktop.
Save tpo/242c899d49784d6082f9e9a20b25de91 to your computer and use it in GitHub Desktop.
Download ZIP
understanding patroni
Raw
understanding_patroni.md

There are two fundamental stages in Patroni:

  • bootstrap
  • running the cluster

Bootstrap stage

In the bootstrap stage, Patroni will:

  • generate DCS (etcd, zookeper, consul, etc.) contents
  • generate a postgres configuration

Patroni detects that it has not yet bootstrapped by checking whether both:

  • the /initialize key exists in the defined namespace in the DCS

  • and the configured postgresql.data_dir directory exists

The most simple case is when postgresql.data_dir is empty and there is no /initialize key in the DCS.

Then Patroni will try to create the /initialize key and on success will either run initdb or the configured custom bootstrap script, both of which will create the postgresql.data_dir.

If initdb or custom bootstrap fails then Patroni will remove the /initialize key from the DCS.

If Patroni gets terminated during bootstrap then the /initialize key will be set and needs to be removed manually.

Once postgres is up and running Patroni will put the cluster system identifier into the /initialize key.

Running the cluster

When Patroni runs the cluster:

  • it first determines who in the cluster is the leader via DCS

  • accordingly the participants in the cluster will resync their database contents from the leader

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment