patroni rest api command book

-- get info from current node
format:
curl --silent http://<patroni_node_ip>:<patroni_rest_api_port>/patroni | jq .

e.g.
curl -s http://10.10.10.10:8008/patroni | jq .
curl --silent http://10.10.10.10:8008/patroni | jq .role

filter objects:
. - get all
.role - get only related lines

-- get metrics 
curl --silent http://10.10.10.10:8008/metrics

-- get cluster info
curl --silent http://10.10.10.10:8008/cluster | jq

-- get config
curl --silent http://10.10.10.10:8008/config | jq

-- change config parameter with PATCH request
curl -s -X PATCH -d \
        '{"loop_wait":5,"ttl":20,"postgresql":{"parameters"
{"max_connections":"500"}}}' \
        http://10.10.10.10:8008/config | jq .

Deep note
curl, command line utility for transferring data (supports HTTP, HTTPS, FTP, SFTP, SCP, etc.)
jq, json query language command line utility
-X, using to define HTTP request method
-d, means that request is POST
PATCH, using to change only related parts (lines) (opposite is PUT)
-s, silent

pg_wal folder bloat problem on Standby nodes

Problem/Case
When using typical physical streaming, pg_wal size grows very fast and unexpectedly on DR (Disaster)/Backup/Standby node

Solution
Check inactive replication slots on DR node. If it exists, drop them

SQL> SELECT * FROM pg_replication_slots WHERE active = 'f';

Then run it:

SQL> SELECT pg_drop_replication_slot('inactive-node');

Problem/Case

When using patroni, pg_wal size grows very fast and unexpectedly on DR (Disaster)/Backup/Standby node

Solution

Check patroni maintenance mode by running "patronictl -c /etc/patroni/patroni.yml list"

If it is "pause" mode, then switch to "resume"

$ patronictl -c /etc/patroni/patroni.yml resume