Patroni


YAML Configuration Settings

Log

Bootstrap configuration

Note

Once Patroni has initialized the cluster for the first time and settings have been stored in the DCS, all future changes to the bootstrap.dcs section of the YAML configuration will not take any effect! If you want to change them please use either patronictl edit-config or the Patroni REST API.

  • bootstrap:

    • dcs: This section will be written into /<namespace>/<scope>/config of the given configuration store after initializing the new cluster. The global dynamic configuration for the cluster. You can put any of the parameters described in the Dynamic Configuration settings under bootstrap.dcs and after Patroni has initialized (bootstrapped) the new cluster, it will write this section into /<namespace>/<scope>/config of the configuration store.

    • 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: (optional) list options to be passed on to initdb.

    • 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.

Citus

Enables integration Patroni with Citus. If configured, Patroni will take care of registering Citus worker nodes on the coordinator. You can find more information about Citus support here.

Consul

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

The token needs to have the following ACL permissions:

service_prefix "${scope}" {
    policy = "write"
}
key_prefix "${namespace}/${scope}" {
    policy = "write"
}
session_prefix "" {
    policy = "write"
}

Etcd

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

Etcdv3

If you want that Patroni works with Etcd cluster via protocol version 3, you need to use the etcd3 section in the Patroni configuration file. All configuration parameters are the same as for etcd.

Warning

Keys created with protocol version 2 are not visible with protocol version 3 and the other way around, therefore it is not possible to switch from etcd to etcd3 just by updating Patroni config file.

ZooKeeper

Note

It is required to install kazoo>=2.6.0 to support SSL.

Raft (deprecated)

  • self_addr: ip:port to listen on for Raft connections. The self_addr must be accessible from other nodes of the cluster. If not set, the node will not participate in consensus.

  • bind_addr: (optional) ip:port to listen on for Raft connections. If not specified the self_addr will be used.

  • partner_addrs: list of other Patroni nodes in the cluster in format: [‘ip1:port’, ‘ip2:port’, ‘etc…’]

  • data_dir: directory where to store Raft log and snapshot. If not specified the current working directory is used.

  • password: (optional) Encrypt Raft traffic with a specified password, requires cryptography python module.

    Short FAQ about Raft implementation ** Q: How to list all the nodes providing consensus?

    + A: syncobj_admin+ ``-conn++ ``+host:port`+ ``-status+` where the host:port is the address of one of the cluster nodes

    • Q: Node that was a part of consensus and has gone and I can’t reuse the same IP for other node. How to remove this node from the consensus?

      A: syncobj_admin+ ``-conn++ ``+host:port+ ``-remove++ ``+host2:port2 where the host2:port2 is the address of the node you want to remove from consensus.

    • Q: Where to get the syncobj_admin utility?

      A: It is installed together with pysyncobj module (python RAFT implementation), which is Patroni dependency.

    • Q: it is possible to run Patroni node without adding in to the consensus?

      A: Yes, just comment out or remove raft.self_addr from Patroni configuration.

    • Q: It is possible to run Patroni and PostgreSQL only on two nodes?

      A: Yes, on the third node you can run patroni_raft_controller (without Patroni and PostgreSQL). In such a setup, one can temporarily lose one node without affecting the primary.

PostgreSQL

replication:

  • username: replication username; the user will be created during initialization. Replicas will use this user to access the replication source via streaming replication

  • password: replication password; the user will be created during initialization.

  • sslmode: (optional) maps to the sslmode connection parameter, which allows a client to specify the type of TLS negotiation mode with the server. For more information on how each mode works, please visit the PostgreSQL documentation. The default mode is prefer.

  • sslkey: (optional) maps to the sslkey connection parameter, which specifies the location of the secret key used with the client’s certificate.

  • sslpassword: (optional) maps to the sslpassword connection parameter, which specifies the password for the secret key specified in sslkey.

  • sslcert: (optional) maps to the sslcert connection parameter, which specifies the location of the client certificate.

  • sslrootcert: (optional) maps to the sslrootcert connection parameter, which specifies the location of a file containing one ore more certificate authorities (CA) certificates that the client will use to verify a server’s certificate.

  • sslcrl: (optional) maps to the sslcrl connection parameter, which specifies the location of a file containing a certificate revocation list. A client will reject connecting to any server that has a certificate present in this list.

  • sslcrldir: (optional) maps to the sslcrldir connection parameter, which specifies the location of a directory with files containing a certificate revocation list. A client will reject connecting to any server that has a certificate present in this list.

  • gssencmode: (optional) maps to the gssencmode connection parameter, which determines whether or with what priority a secure GSS TCP/IP connection will be negotiated with the server

  • channel_binding: (optional) maps to the channel_binding connection parameter, which controls the client’s use of channel binding.

rewind:

  • username: (optional) name for the user for pg_rewind; the user will be created during initialization of postgres 11+ and all necessary permissions will be granted.

  • password: (optional) password for the user for pg_rewind; the user will be created during initialization.

  • sslmode: (optional) maps to the sslmode connection parameter, which allows a client to specify the type of TLS negotiation mode with the server. For more information on how each mode works, please visit the PostgreSQL documentation. The default mode is prefer.

  • sslkey: (optional) maps to the sslkey connection parameter, which specifies the location of the secret key used with the client’s certificate.

  • sslpassword: (optional) maps to the sslpassword connection parameter, which specifies the password for the secret key specified in sslkey.

  • sslcert: (optional) maps to the sslcert connection parameter, which specifies the location of the client certificate.

  • sslrootcert: (optional) maps to the sslrootcert connection parameter, which specifies the location of a file containing one ore more certificate authorities (CA) certificates that the client will use to verify a server’s certificate.

  • sslcrl: (optional) maps to the sslcrl connection parameter, which specifies the location of a file containing a certificate revocation list. A client will reject connecting to any server that has a certificate present in this list.

  • sslcrldir: (optional) maps to the sslcrldir connection parameter, which specifies the location of a directory with files containing a certificate revocation list. A client will reject connecting to any server that has a certificate present in this list.

  • gssencmode: (optional) maps to the gssencmode connection parameter, which determines whether or with what priority a secure GSS TCP/IP connection will be negotiated with the server

  • channel_binding: (optional) maps to the channel_binding connection parameter, which controls the client’s use of channel binding.

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 postgres restarts (without changing role).

  • on_role_change: run this script when the postgres is being promoted or demoted.

  • on_start: run this script when the postgres starts.

  • on_stop: run this script when the postgres stops.

connect_address: IP address + port through which Postgres is accessible from other nodes and applications.

proxy_address: IP address + port through which a connection pool (e.g. pgbouncer) running next to Postgres is accessible. The value is written to the member key in DCS as proxy_url and could be used/useful for service discovery.

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: (optional) Path to PostgreSQL binaries (pg_ctl, initdb, pg_controldata, pg_basebackup, postgres, pg_isready, pg_rewind). If not provided or is an empty string, PATH environment variable will be used to find the executables.

bin_name: (optional) Make it possible to override Postgres binary names, if you are using a custom Postgres distribution:

  • pg_ctl: (optional) Custom name for pg_ctl binary.

  • initdb: (optional) Custom name for initdb binary.

  • pgcontroldata: (optional) Custom name for pg_controldata binary.

  • pg_basebackup: (optional) Custom name for pg_basebackup binary.

  • postgres: (optional) Custom name for postgres binary.

  • pg_isready: (optional) Custom name for pg_isready binary.

  • pg_rewind: (optional) Custom name for pg_rewind binary.

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 defined, Patroni will use the 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 the default value should be used and omit host from the connection parameters.

use_unix_socket_repl: specifies that Patroni should prefer to use unix sockets for replication user cluster connection. Default value is false. If unix_socket_directories is defined, Patroni will use the 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 the default value should be used and omit host from the 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. Patroni ignores this parameter if hba_file PostgreSQL parameter is set to a non-default value. Together with dynamic configuration this parameter 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_ident: list of lines that Patroni will use to generate pg_ident.conf. Patroni ignores this parameter if ident_file PostgreSQL parameter is set to a non-default value. Together with dynamic configuration this parameter simplifies management of pg_ident.conf.

  • - mapname1 systemname1 pguser1

  • - mapname1 systemname2 pguser2

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 the PostgreSQL data directory and recreate the replica. Otherwise it will try to follow the new leader. Default value is false.

remove_data_directory_on_diverged_timelines: Patroni will remove the PostgreSQL data directory and recreate the replica if it notices that timelines are diverging and the former primary can not start streaming from the new primary. This option is useful when pg_rewind can not be used. While performing timelines divergence check on PostgreSQL v10 and older Patroni will try to connect with replication credential to the “postgres” database. Hence, such access should be allowed in the pg_hba.conf. 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”.

pre_promote: a fencing script that executes during a failover after acquiring the leader lock but before promoting the replica. If the script exits with a non-zero code, Patroni does not promote the replica and removes the leader key from DCS.

before_stop: a script that executes immediately prior to stopping postgres. As opposed to a callback, this script runs synchronously, blocking shutdown until it has completed. The return code of this script does not impact whether shutdown proceeds afterwards.

REST API

certfile: (optional): 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: (optional): Specifies the file with the secret key in the PEM format.

keyfile_password: (optional): Specifies a password for decrypting the keyfile.

cafile: (optional): Specifies the file with the CA_BUNDLE with certificates of trusted CAs to use while verifying client certs.

ciphers: (optional): Specifies the permitted cipher suites (e.g. “ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:!SSLv1:!SSLv2:!SSLv3:!TLSv1:!TLSv1.1”)

verify_client: (optional): none (default), optional or required. When none REST API will not check client certificates. When required client certificates are required for all REST API calls. When optional client certificates are required for all unsafe REST API endpoints. When required is used, then client authentication succeeds, if the certificate signature verification succeeds. For optional the client cert will only be checked for PUT, POST, PATCH, and DELETE requests.

allowlist: (optional): Specifies the set of hosts that are allowed to call unsafe REST API endpoints. The single element could be a host name, an IP address or a network address using CIDR notation. By default allow`+ ``+all` is used. In case if allowlist or allowlist_include_members are set, anything that is not included is rejected.

allowlist_include_members: (optional): If set to true it allows accessing unsafe REST API endpoints from other cluster members registered in DCS (IP address or hostname is taken from the members api_url). Be careful, it might happen that OS will use a different IP for outgoing connections.

  • http_extra_headers*: (optional): HTTP headers let the REST API server pass additional information with an HTTP response.

  • https_extra_headers*: (optional): HTTPS headers let the REST API server pass additional information with an HTTP response when TLS is enabled. This will also pass additional information set in + http_extra_headers+.

request_queue_size: (optional): Sets request queue size for TCP socket used by Patroni REST API. Once the queue is full, further requests get a “Connection denied” error. The default value is 5.

Here is an example of both * http_extra_headers* and * https_extra_headers*:

restapi:
  listen: <listen>
  connect_address: <connect_address>
  authentication:
    username: <username>
    password: <password>
   http_extra_headers:
    'X-Frame-Options': 'SAMEORIGIN'
    'X-XSS-Protection': '1; mode=block'
    'X-Content-Type-Options': 'nosniff'
  cafile: <ca file>
  certfile: <cert>
  keyfile: <key>
   https_extra_headers:
    'Strict-Transport-Security': 'max-age=31536000; includeSubDomains'

Warning

CTL

insecure: Allow connections to REST API without verifying SSL certs.

cacert: Specifies the file with the CA_BUNDLE file or directory with certificates of trusted CAs to use while verifying REST API SSL certs. If not provided patronictl will use the value provided for REST API “cafile” parameter.

certfile: Specifies the file with the client certificate in the PEM format.

keyfile: Specifies the file with the client secret key in the PEM format.

keyfile_password: Specifies a password for decrypting the client keyfile.

Tags

Warning

Provide only one of nofailover or failover_priority. Providing nofailover:+ ``+true is the same as failover_priority:+ ``+0, and providing nofailover:`+ ``+false` will give the node priority 1.

In addition to these predefined tags, you can also add your own ones:

Tags are visible in the REST API and patronictl list You can also check for an instance health using these tags. If the tag isn’t defined for an instance, or if the respective value doesn’t match the querying value, it will return HTTP Status Code 503.


© Copyright 2015 Compose, Zalando SE. Revision 3d527f57.

Built with Sphinx using a theme provided by Read the Docs.

Read the Docs v: master