YAML Configuration Settings

Global/Universal

  • name: the name of the host. Must be unique for the cluster.
  • namespace: path within the configuration store where Patroni will keep information about the cluster. Default value: “/service”
  • scope: cluster name

Bootstrap configuration

  • dcs: This section will be written into /<namespace>/<scope>/config of a given configuration store after initializing of new cluster. This is the global configuration for the cluster. If you want to change some parameters for all cluster nodes - just do it in DCS (or via Patroni API) and all nodes will apply this configuration.
    • loop_wait: the number of seconds the loop will sleep. Default value: 10
    • ttl: the TTL to acquire the leader lock. Think of it as the length of time before initiation of the automatic failover process. Default value: 30
    • retry_timeout: timeout for DCS and PostgreSQL operation retries. DCS or network issues shorter than this will not cause Patroni to demote the leader. Default value: 10
    • maximum_lag_on_failover: the maximum bytes a follower may lag to be able to participate in leader election.
    • master_start_timeout: the amount of time a master is allowed to recover from failures before failover is triggered. Default is 300 seconds. When set to 0 failover is done immediately after a crash is detected if possible. When using asynchronous replication a failover can cause lost transactions. Best worst case failover time for master failure is: loop_wait + master_start_timeout + loop_wait, unless master_start_timeout is zero, in which case it’s just loop_wait. Set the value according to your durability/availability tradeoff.
    • synchronous_mode: turns on synchronous replication mode. In this mode a replica will be chosen as synchronous and only the latest leader and synchronous replica are able to participate in leader election. Synchronous mode makes sure that successfully committed transactions will not be lost at failover, at the cost of losing availability for writes when Patroni cannot ensure transaction durability. See replication modes documentation for details.
    • synchronous_mode_strict: prevents disabling synchronous replication if no synchronous replicas are available, blocking all client writes to the master. See replication modes documentation for details.
    • postgresql:
      • use_pg_rewind: whether or not to use pg_rewind
      • use_slots: whether or not to use replication_slots. Must be False for PostgreSQL 9.3. You should comment out max_replication_slots before it becomes ineligible for leader status.
      • recovery_conf: additional configuration settings written to recovery.conf when configuring follower.
      • parameters: list of configuration settings for Postgres. Many of these are required for replication to work.
    • standby_cluster: if this section is defined, we want to bootstrap a standby cluster.
      • host: an address of remote master
      • port: a port of remote master
      • primary_slot_name: which slot on the remote master to use for replication. This parameter is optional, the default value is derived from the instance name (see function slot_name_from_member_name).
      • create_replica_methods: an ordered list of methods that can be used to bootstrap standby leader from the remote master, can be different from the list defined in PostgreSQL
      • restore_command: command to restore WAL records from the remote master to standby leader, can be different from the list defined in PostgreSQL
      • archive_cleanup_command: cleanup command for standby leader
      • recovery_min_apply_delay: how long to wait before actually apply WAL records on a standby leader
    • slots: define permanent replication slots. These slots will be preserved during switchover/failover. Patroni will try to create slots before opening connections to the cluster.
      • my_slot_name: the name of replication slot. It is the responsibility of the operator to make sure that there are no clashes in names between replication slots automatically created by Patroni for members and permanent replication slots.
        • type: slot type. Could be physical or logical. If the slot is logical, you have to additionally define database and plugin. database: the database name where logical slots should be created. plugin: the plugin name for the logical slot.
  • method: custom script to use for bootstrapping this cluster. See custom bootstrap methods documentation for details. When initdb is specified revert to the default initdb command. initdb is also triggered when no method parameter is present in the configuration file.
  • initdb: List options to be passed on to initdb.
    • - data-checksums: Must be enabled when pg_rewind is needed on 9.3.
    • - encoding: UTF8: default encoding for new databases.
    • - locale: UTF8: default locale for new databases.
  • pg_hba: list of lines that you should add to pg_hba.conf.
    • - host all all 0.0.0.0/0 md5.
    • - host replication replicator 127.0.0.1/32 md5: A line like this is required for replication.
  • users: Some additional users which need to be created after initializing new cluster
    • admin: the name of user
      • password: zalando:
      • options: list of options for CREATE USER statement
        • - createrole
        • - createdb
  • post_bootstrap or post_init: An additional script that will be executed after initializing the cluster. The script receives a connection string URL (with the cluster superuser as a user name). The PGPASSFILE variable is set to the location of pgpass file.

Consul

Most of the parameters are optional, but you have to specify one of the host or url

  • host: the host:port for the Consul endpoint, in format: http(s)://host:port
  • url: url for the Consul endpoint
  • port: (optional) Consul port
  • scheme: (optional) http or https, defaults to http
  • token: (optional) ACL token
  • verify: (optional) whether to verify the SSL certificate for HTTPS requests
  • cacert: (optional) The ca certificate. If present it will enable validation.
  • cert: (optional) file with the client certificate
  • key: (optional) file with the client key. Can be empty if the key is part of cert.
  • dc: (optional) Datacenter to communicate with. By default the datacenter of the host is used.
  • checks: (optional) list of Consul health checks used for the session. If not specified Consul will use “serfHealth” in additional to the TTL based check created by Patroni. Additional checks, in particular the “serfHealth”, may cause the leader lock to expire faster than in ttl seconds when the leader instance becomes unavailable

Etcd

Most of the parameters are optional, but you have to specify one of the host, hosts, url, proxy or srv

  • host: the host:port for the etcd endpoint.
  • hosts: list of etcd endpoint in format host1:port1,host2:port2,etc… Could be a comma separated string or an actual yaml list.
  • url: url for the etcd
  • proxy: proxy url for the etcd. If you are connecting to the etcd using proxy, use this parameter instead of url
  • srv: Domain to search the SRV record(s) for cluster autodiscovery.
  • protocol: (optional) http or https, if not specified http is used. If the url or proxy is specified - will take protocol from them.
  • username: (optional) username for etcd authentication
  • password: (optional) password for etcd authentication.
  • cacert: (optional) The ca certificate. If present it will enable validation.
  • cert: (optional) file with the client certificate
  • key: (optional) file with the client key. Can be empty if the key is part of cert.

Exhibitor

  • hosts: initial list of Exhibitor (ZooKeeper) nodes in format: ‘host1,host2,etc…’. This list updates automatically whenever the Exhibitor (ZooKeeper) cluster topology changes.
  • poll_interval: how often the list of ZooKeeper and Exhibitor nodes should be updated from Exhibitor
  • port: Exhibitor port.

Kubernetes

  • namespace: (optional) Kubernetes namespace where Patroni pod is running. Default value is default.
  • labels: Labels in format {label1: value1, label2: value2}. These labels will be used to find existing objects (Pods and either Endpoints or ConfigMaps) associated with the current cluster. Also Patroni will set them on every object (Endpoint or ConfigMap) it creates.
  • scope_label: (optional) name of the label containing cluster name. Default value is cluster-name.
  • role_label: (optional) name of the label containing role (master or replica). Patroni will set this label on the pod it runs in. Default value is role.
  • use_endpoints: (optional) if set to true, Patroni will use Endpoints instead of ConfigMaps to run leader elections and keep cluster state.
  • pod_ip: (optional) IP address of the pod Patroni is running in. This value is required when use_endpoints is enabled and is used to populate the leader endpoint subsets when the pod’s PostgreSQL is promoted.
  • ports: (optional) if the Service object has the name for the port, the same name must appear in the Endpoint object, otherwise service won’t work. For example, if your service is defined as {Kind: Service, spec: {ports: [{name: postgresql, port: 5432, targetPort: 5432}]}}, then you have to set kubernetes.ports: {[{"name": "postgresql", "port": 5432}]} and Patroni will use it for updating subsets of the leader Endpoint. This parameter is used only if kubernetes.use_endpoints is set.

PostgreSQL

  • authentication:
    • superuser:
      • username: name for the superuser, set during initialization (initdb) and later used by Patroni to connect to the postgres.
      • password: password for the superuser, set during initialization (initdb).
    • replication:
      • username: replication username; the user will be created during initialization. Replicas will use this user to access master via streaming replication
      • password: replication password; the user will be created during initialization.
  • callbacks: callback scripts to run on certain actions. Patroni will pass the action, role and cluster name. (See scripts/aws.py as an example of how to write them.)
    • on_reload: run this script when configuration reload is triggered.
    • on_restart: run this script when the cluster restarts.
    • on_role_change: run this script when the cluster is being promoted or demoted.
    • on_start: run this script when the cluster starts.
    • on_stop: run this script when the cluster stops.
  • connect_address: IP address + port through which Postgres is accessible from other nodes and applications.
  • create_replica_methods: an ordered list of the create methods for turning a Patroni node into a new replica. “basebackup” is the default method; other methods are assumed to refer to scripts, each of which is configured as its own config item. See custom replica creation methods documentation for further explanation.
  • data_dir: The location of the Postgres data directory, either existing or to be initialized by Patroni.
  • config_dir: The location of the Postgres configuration directory, defaults to the data directory. Must be writable by Patroni.
  • bin_dir: Path to PostgreSQL binaries (pg_ctl, pg_rewind, pg_basebackup, postgres). The default value is an empty string meaning that PATH environment variable will be used to find the executables.
  • listen: IP address + port that Postgres listens to; must be accessible from other nodes in the cluster, if you’re using streaming replication. Multiple comma-separated addresses are permitted, as long as the port component is appended after to the last one with a colon, i.e. listen: 127.0.0.1,127.0.0.2:5432. Patroni will use the first address from this list to establish local connections to the PostgreSQL node.
  • use_unix_socket: specifies that Patroni should prefer to use unix sockets to connect to the cluster. Default value is false. If unix_socket_directories is definded, Patroni will use first suitable value from it to connect to the cluster and fallback to tcp if nothing is suitable. If unix_socket_directories is not specified in postgresql.parameters, Patroni will assume that default value should be used and omit host from connection parameters.
  • pgpass: path to the .pgpass password file. Patroni creates this file before executing pg_basebackup, the post_init script and under some other circumstances. The location must be writable by Patroni.
  • recovery_conf: additional configuration settings written to recovery.conf when configuring follower.
  • custom_conf : path to an optional custom postgresql.conf file, that will be used in place of postgresql.base.conf. The file must exist on all cluster nodes, be readable by PostgreSQL and will be included from its location on the real postgresql.conf. Note that Patroni will not monitor this file for changes, nor backup it. However, its settings can still be overridden by Patroni’s own configuration facilities - see dynamic configuration for details.
  • parameters: list of configuration settings for Postgres. Many of these are required for replication to work.
  • pg_hba: list of lines that Patroni will use to generate pg_hba.conf. This parameter has higher priority than bootstrap.pg_hba. Together with dynamic configuration it simplifies management of pg_hba.conf.
    • - host all all 0.0.0.0/0 md5.
    • - host replication replicator 127.0.0.1/32 md5: A line like this is required for replication.
  • pg_ctl_timeout: How long should pg_ctl wait when doing start, stop or restart. Default value is 60 seconds.
  • use_pg_rewind: try to use pg_rewind on the former leader when it joins cluster as a replica.
  • remove_data_directory_on_rewind_failure: If this option is enabled, Patroni will remove postgres data directory and recreate replica. Otherwise it will try to follow the new leader. Default value is false.
  • replica_method: for each create_replica_methods other than basebackup, you would add a configuration section of the same name. At a minimum, this should include “command” with a full path to the actual script to be executed. Other configuration parameters will be passed along to the script in the form “parameter=value”.

REST API

  • connect_address: IP address (or hostname) and port, to access the Patroni’s REST API. All the members of the cluster must be able to connect to this address, so unless the Patroni setup is intended for a demo inside the localhost, this address must be a non “localhost” or loopback addres (ie: “localhost” or “127.0.0.1”). It can serve as a endpoint for HTTP health checks (read below about the “listen” REST API parameter), and also for user queries (either directly or via the REST API), as well as for the health checks done by the cluster members during leader elections (for example, to determine whether the master is still running, or if there is a node which has a WAL position that is ahead of the one doing the query; etc.) The connect_address is put in the member key in DCS, making it possible to translate the member name into the address to connect to its REST API.
  • listen: IP address (or hostname) and port that Patroni will listen to for the REST API - to provide also the same health checks and cluster messaging between the participating nodes, as described above. to provide health-check information for HAProxy (or any other load balancer capable of doing a HTTP “OPTION” or “GET” checks).
  • Optional:
    • authentication:
      • username: Basic-auth username to protect unsafe REST API endpoints.
      • password: Basic-auth password to protect unsafe REST API endpoints.
    • certfile: Specifies the file with the certificate in the PEM format. If the certfile is not specified or is left empty, the API server will work without SSL.
    • keyfile: Specifies the file with the secret key in the PEM format.

CTL

  • Optional:
    • insecure: Allow connections to REST API without verifying SSL certs.
    • cacert: Specifices the file with the CA_BUNDLE file or directory with certificates of trusted CAs to use while verifying REST API SSL certs.
    • certfile: Specifies the file with the certificate in the PEM format to use while verifying REST API SSL certs. If not provided patronictl will use the value provided for REST API “certfile” parameter.

ZooKeeper

  • hosts: list of ZooKeeper cluster members in format: [‘host1:port1’, ‘host2:port2’, ‘etc…’].

Watchdog

  • mode: off, automatic or required. When off watchdog is disabled. When automatic watchdog will be used if available, but ignored if it is not. When required the node will not become a leader unless watchdog can be successfully enabled.
  • device: Path to watchdog device. Defaults to /dev/watchdog.
  • safety_margin: Number of seconds of safety margin between watchdog triggering and leader key expiration.