PostgreSQL ਨੇਟਿਵ ਉੱਚ ਉਪਲਬਧਤਾ: ਪੈਟਰੋਨੀ, ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ, ਅਤੇ ਉਤਪਾਦਨ ਫੇਲਓਵਰ ਰਣਨੀਤੀਆਂ

ਇੱਕ ਸਿੰਗਲ PostgreSQL ਉਦਾਹਰਨ ਨੂੰ ਚਲਾਉਣਾ ਸਿੱਧਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਪਹਿਲੀ ਗੈਰ-ਯੋਜਨਾਬੱਧ ਆਊਟੇਜ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹੈ ਕਿ ਇੱਕ ਡੇਟਾਬੇਸ ਸਿਰਫ ਉਸਦੀ ਉਪਲਬਧਤਾ ਦੇ ਰੂਪ ਵਿੱਚ ਹੀ ਕੀਮਤੀ ਹੈ। ਡਿਸਕ ਫੇਲ੍ਹ ਹੋਣ, ਕਰਨਲ ਪੈਨਿਕ, ਨੈੱਟਵਰਕ ਭਾਗ, ਅਤੇ ਬੋਚਡ ਅੱਪਗਰੇਡ ਸਿਧਾਂਤਕ ਖਤਰੇ ਨਹੀਂ ਹਨ - ਇਹ ਲੰਬੇ ਸਮੇਂ ਲਈ ਕਾਰਜਸ਼ੀਲ ਨਿਸ਼ਚਿਤਤਾ ਹਨ। PostgreSQL ਬਿਲਟ-ਇਨ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ ਨਾਲ ਸ਼ਿਪ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਉਪਲਬਧ ਕਲੱਸਟਰ ਬਣਾਉਣ ਲਈ ਲੋੜੀਂਦੇ ਸਾਰੇ ਰੀਪਲੀਕੇਸ਼ਨ ਪ੍ਰਾਈਮਿਟਿਵ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਪੈਟਰੋਨੀ, ਇੱਕ ਓਪਨ-ਸੋਰਸ HA ਫਰੇਮਵਰਕ ਜੋ ਜ਼ਲੈਂਡੋ ਦੁਆਰਾ ਬਣਾਈ ਰੱਖਿਆ ਗਿਆ ਹੈ, ਉਹਨਾਂ ਮੁੱਢਲੇ ਲੋਕਾਂ ਨੂੰ ਇੱਕ ਉਤਪਾਦਨ-ਗਰੇਡ ਫੇਲਓਵਰ ਸਿਸਟਮ ਵਿੱਚ ਆਰਕੈਸਟ੍ਰੇਟ ਕਰਦਾ ਹੈ ਜਿਸਦੀ ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਹਜ਼ਾਰਾਂ PostgreSQL ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਪੈਮਾਨੇ 'ਤੇ ਲੜਾਈ-ਜਾਂਚ ਕੀਤੀ ਗਈ ਹੈ।

ਇਹ ਲੇਖ ਇੱਕ ਡੂੰਘੀ-ਡਾਈਵ ਇੰਜੀਨੀਅਰਿੰਗ ਗਾਈਡ ਹੈ। ਅਸੀਂ PostgreSQL ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ (ਸਮਕਾਲੀ ਅਤੇ ਅਸਿੰਕਰੋਨਸ), ਪੈਟਰੋਨੀ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਸੰਰਚਨਾ, ਆਦਿ ਨੂੰ ਇੱਕ ਵਿਤਰਿਤ ਸੰਰਚਨਾ ਸਟੋਰ ਦੇ ਤੌਰ 'ਤੇ, ਰੀਡ-ਰਾਈਟ ਸਪਲਿਟਿੰਗ ਦੇ ਨਾਲ ਕਨੈਕਸ਼ਨ ਰੂਟਿੰਗ ਲਈ HAProxy, ਕੁਨੈਕਸ਼ਨ ਪੂਲਿੰਗ ਲਈ PgBouncer, WAL ਆਰਕਾਈਵਿੰਗ ਅਤੇ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ, ਸਿੰਕ੍ਰੋਨਾਈਜ਼ਲ ਡਾਟਾ ਸਿਲੈਕਸ਼ਨ, ਸਿੰਚਰੋਨਿਕ ਰੀਕਵਰ ਲਈ ਕਵਰ ਕਰਾਂਗੇ। ਸ਼ੁਰੂਆਤੀ ਸਟੈਂਡਬਾਏ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਲਈ pg_basebackup, Patroni ਦੇ ਵਿਕਲਪ ਵਜੋਂ repmgr, AWS, Azure, ਅਤੇ GCP ਲਈ ਕਲਾਉਡ-ਵਿਸ਼ੇਸ਼ ਤੈਨਾਤੀ ਪੈਟਰਨ, ਰੈਂਚਰ ਅਤੇ ਲੋਂਗਹੋਰਨ ਦੇ ਨਾਲ ਬੇਅਰ ਮੈਟਲ k3s ਤੈਨਾਤੀ, pg_stat_replication ਅਤੇ Prometheus/Prometheus/XPR4 ਐਕਸਪ੍ਰੋਸੀਵਰਸ, ਫਾਸਟ-ਓਵਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨਾਲ ਨਿਗਰਾਨੀ। ਫੇਲਓਵਰ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਰੋਕਥਾਮ, ਉਤਪਾਦਨ ਟਿਊਨਿੰਗ, ਅਤੇ ਹਫੜਾ-ਦਫੜੀ ਇੰਜੀਨੀਅਰਿੰਗ।

PostgreSQL ਸਟ੍ਰੀਮਿੰਗ ਰਿਪਲੀਕੇਸ਼ਨ ਫੰਡਾਮੈਂਟਲਜ਼

ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ PostgreSQL ਉੱਚ ਉਪਲਬਧਤਾ ਦੀ ਰੀੜ੍ਹ ਦੀ ਹੱਡੀ ਹੈ। ਇਹ ਰਾਈਟ-ਅਹੇਡ ਲੌਗ (WAL) ਰਿਕਾਰਡਾਂ ਨੂੰ ਪ੍ਰਾਇਮਰੀ ਸਰਵਰ ਤੋਂ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਸਟੈਂਡਬਾਏ ਸਰਵਰਾਂ ਤੱਕ ਲਗਾਤਾਰ ਭੇਜ ਕੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਸਟੈਂਡਬਾਏ ਉਹਨਾਂ WAL ਰਿਕਾਰਡਾਂ ਨੂੰ ਰੀਅਲ ਟਾਈਮ ਵਿੱਚ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਪ੍ਰਾਇਮਰੀ ਦੇ ਡੇਟਾ ਦੀ ਲਗਭਗ ਇੱਕੋ ਜਿਹੀ ਕਾਪੀ ਬਣਾਈ ਰੱਖਦਾ ਹੈ। ਇਹ ਵਿਧੀ PostgreSQL 9.0 ਵਿੱਚ ਪੇਸ਼ ਕੀਤੀ ਗਈ ਸੀ ਅਤੇ ਹਰ ਅਗਲੀ ਰੀਲੀਜ਼ ਵਿੱਚ ਸੁਧਾਰੀ ਗਈ ਹੈ।

ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਦੋ ਮੋਡ ਹਨ:ਅਸਿੰਕ੍ਰੋਨਸਅਤੇਸਮਕਾਲੀ। ਅਸਿੰਕ੍ਰੋਨਸ ਮੋਡ ਵਿੱਚ, ਪ੍ਰਾਇਮਰੀ ਇੱਕ ਲੈਣ-ਦੇਣ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ WAL ਰਿਕਾਰਡਾਂ ਦੀ ਰਸੀਦ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਸਟੈਂਡਬਾਏ ਦੀ ਉਡੀਕ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਇਹ ਅਧਿਕਤਮ ਲਿਖਣ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦਿੰਦਾ ਹੈ ਪਰ ਸੰਭਾਵੀ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਦੀ ਇੱਕ ਵਿੰਡੋ ਪੇਸ਼ ਕਰਦਾ ਹੈ — ਜੇਕਰ ਸਟੈਂਡਬਾਏ ਨੂੰ ਸਭ ਤੋਂ ਤਾਜ਼ਾ WAL ਪ੍ਰਾਪਤ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਾਇਮਰੀ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਉਹ ਲੈਣ-ਦੇਣ ਖਤਮ ਹੋ ਜਾਂਦੇ ਹਨ। ਸਮਕਾਲੀ ਮੋਡ ਵਿੱਚ, ਪ੍ਰਾਇਮਰੀ ਇਸ ਗੱਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਸਟੈਂਡਬਾਏ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ ਕਿ ਵਚਨਬੱਧ ਵਜੋਂ ਇੱਕ ਲੈਣ-ਦੇਣ ਦੀ ਰਿਪੋਰਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ WAL ਰਿਕਾਰਡ ਟਿਕਾਊ ਸਟੋਰੇਜ ਵਿੱਚ ਲਿਖੇ ਗਏ ਹਨ। ਇਹ ਵਧੇ ਹੋਏ ਵਚਨਬੱਧ ਲੇਟੈਂਸੀ ਦੀ ਕੀਮਤ 'ਤੇ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਹਰੇਕ ਲਿਖਤ ਨੂੰ ਸਟੈਂਡਬਾਏ ਲਈ ਰਾਉਂਡ-ਟਰਿੱਪ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਸਮਕਾਲੀ ਅਤੇ ਅਸਿੰਕਰੋਨਸ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਵਿਚਕਾਰ ਚੋਣ ਬਾਈਨਰੀ ਨਹੀਂ ਹੈ। PostgreSQL ਸੈਸ਼ਨ ਪੱਧਰ 'ਤੇsynchronous_commitਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਇਸਲਈ ਲੇਟੈਂਸੀ-ਸੰਵੇਦਨਸ਼ੀਲ ਵਰਕਲੋਡ ਅਸਿੰਕ੍ਰੋਨਸ ਕਮਿਟਾਂ ਦੀ ਚੋਣ ਕਰ ਸਕਦੇ ਹਨ ਜਦੋਂ ਕਿ ਗੰਭੀਰ ਵਿੱਤੀ ਲੈਣ-ਦੇਣ ਉਸੇ ਕਲੱਸਟਰ ਦੇ ਅੰਦਰ ਸਮਕਾਲੀ ਕਮਿਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।

ਪ੍ਰਤੀਕ੍ਰਿਤੀ

ਪ੍ਰਾਇਮਰੀ ਸਰਵਰ ਨੂੰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਲਈ ਕਾਫੀ ਪੱਧਰ 'ਤੇ WAL ਰਿਕਾਰਡ ਬਣਾਉਣ ਲਈ ਅਤੇ ਸਟੈਂਡਬਾਏ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਲਈ ਕੌਂਫਿਗਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਹੇਠ ਲਿਖੀਆਂpostgresql.confਸੈਟਿੰਗਾਂ ਜ਼ਰੂਰੀ ਹਨ।

# postgresql.conf on the primary
wal_level = replica                    # minimum for streaming replication
max_wal_senders = 10                   # max concurrent replication connections
max_replication_slots = 10             # prevent WAL removal before standby consumption
wal_keep_size = 2GB                    # retain WAL as fallback if slots are unused
hot_standby = on                       # allow read queries on standbys
synchronous_commit = on                # 'on' for sync, 'off' for pure async
synchronous_standby_names = 'ANY 1 (standby1, standby2)'  # sync replication targets
archive_mode = on                      # enable WAL archiving for PITR
archive_command = 'test ! -f /archive/%f && cp %p /archive/%f'
listening_addresses = '*'
port = 5432

ਪ੍ਰਮਾਣੀਕਰਨ ਨੂੰpg_hba.confਵਿੱਚ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ। ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਕਨੈਕਸ਼ਨ ਇੱਕ ਸਮਰਪਿਤ ਕਨੈਕਸ਼ਨ ਕਿਸਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।

# pg_hba.conf — replication entries
# TYPE   DATABASE        USER            ADDRESS              METHOD
host     replication     replicator      10.0.1.0/24          scram-sha-256
host     replication     replicator      10.0.2.0/24          scram-sha-256
host     all             all             10.0.0.0/16          scram-sha-256

ਪ੍ਰਾਇਮਰੀ 'ਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਉਪਭੋਗਤਾ ਬਣਾਓ।

CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'strong_replication_password';

pg_basebackup

pg_basebackupਉਪਯੋਗਤਾ ਪ੍ਰਾਇਮਰੀ ਦੀ ਡਾਟਾ ਡਾਇਰੈਕਟਰੀ ਦੀ ਇੱਕ ਭੌਤਿਕ ਕਾਪੀ ਬਣਾਉਂਦੀ ਹੈ, ਜੋ ਇੱਕ ਨਵੇਂ ਸਟੈਂਡਬਾਏ ਲਈ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਬਣ ਜਾਂਦੀ ਹੈ। ਇਹ ਬੇਸ ਬੈਕਅੱਪ ਅਤੇ WAL ਸਟ੍ਰੀਮਿੰਗ ਨੂੰ ਪਰਮਾਣੂ ਤੌਰ 'ਤੇ ਹੈਂਡਲ ਕਰਦਾ ਹੈ, ਇਸਲਈ ਨਤੀਜਾ ਕਾਪੀ ਇਕਸਾਰ ਹੈ।

# On the standby server
pg_basebackup -h primary-host -U replicator -D /var/lib/postgresql/16/main \
  -Fp -Xs -P -R

# -Fp: plain format
# -Xs: stream WAL during backup
# -P:  show progress
# -R:  create standby.signal and configure primary_conninfo in postgresql.auto.conf

-Rਫਲੈਗ ਮਹੱਤਵਪੂਰਨ ਹੈ — ਇਹprimary_conninfoਨੂੰpostgresql.auto.confਵਿੱਚ ਲਿਖਦਾ ਹੈ ਅਤੇstandby.signalਬਣਾਉਂਦਾ ਹੈ, ਜੋ PostgreSQL ਨੂੰ ਸਟੈਂਡਬਾਏ ਮੋਡ ਵਿੱਚ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ। PostgreSQL 12 ਅਤੇ ਬਾਅਦ ਵਿੱਚ,recovery.confਨੂੰ ਇਹਨਾਂ ਦੋ ਵਿਧੀਆਂ ਦੁਆਰਾ ਬਦਲਿਆ ਗਿਆ ਹੈ।

# postgresql.auto.conf (generated by pg_basebackup -R)
primary_conninfo = 'host=primary-host port=5432 user=replicator password=strong_replication_password application_name=standby1'
primary_slot_name = 'standby1_slot'

ਸਟੈਂਡਬਾਏ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਾਇਮਰੀ 'ਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸਲਾਟ ਬਣਾਓ, ਤਾਂ ਜੋ ਸਟੈਂਡਬਾਏ ਦੁਆਰਾ ਇਸ ਨੂੰ ਖਪਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ WAL ਨੂੰ ਸਾਫ਼ ਹੋਣ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕੇ।

SELECT pg_create_physical_replication_slot('standby1_slot');
SELECT pg_create_physical_replication_slot('standby2_slot');

Patroni: ਆਟੋਮੇਟਿਡ HA ਆਰਕੈਸਟਰੇਸ਼ਨ

ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਤੁਹਾਨੂੰ ਡਾਟਾ ਰਿਡੰਡੈਂਸੀ ਦਿੰਦੀ ਹੈ, ਪਰ ਇਹ ਤੁਹਾਨੂੰ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ ਨਹੀਂ ਦਿੰਦੀ। ਜੇਕਰ ਪ੍ਰਾਇਮਰੀ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕਿਸੇ ਵਿਅਕਤੀ ਨੂੰ — ਇੱਕ ਮਨੁੱਖੀ ਆਪਰੇਟਰ ਜਾਂ ਇੱਕ ਆਟੋਮੇਸ਼ਨ ਸਿਸਟਮ — ਨੂੰ ਇੱਕ ਸਟੈਂਡਬਾਏ ਨੂੰ ਪ੍ਰਾਇਮਰੀ ਤੱਕ ਉਤਸ਼ਾਹਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਨਵੇਂ ਪ੍ਰਾਇਮਰੀ ਦੀ ਪਾਲਣਾ ਕਰਨ ਲਈ ਬਾਕੀ ਸਟੈਂਡਬਾਏ ਨੂੰ ਮੁੜ ਸੰਰਚਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕੁਨੈਕਸ਼ਨ ਰੂਟਿੰਗ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਪੈਟਰੋਨੀ ਇਸ ਸਭ ਨੂੰ ਆਟੋਮੇਟ ਕਰਦਾ ਹੈ।

ਪੈਟਰੋਨੀ ਇੱਕ Python ਡੈਮਨ ਹੈ ਜੋ ਹਰੇਕ PostgreSQL ਉਦਾਹਰਨ ਦੇ ਨਾਲ ਚੱਲਦਾ ਹੈ। ਇਹ ਲੀਡਰ ਇਲੈਕਸ਼ਨ ਅਤੇ ਕਲੱਸਟਰ ਸਟੇਟ ਦਾ ਤਾਲਮੇਲ ਕਰਨ ਲਈ ਡਿਸਟ੍ਰੀਬਿਊਟਿਡ ਕੌਂਫਿਗਰੇਸ਼ਨ ਸਟੋਰ (DCS) - ਖਾਸ ਤੌਰ 'ਤੇ etcd, ਪਰ ZooKeeper ਜਾਂ Consul - ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਹਰ ਪੈਟਰੋਨੀ ਨੋਡ ਲਗਾਤਾਰ ਆਪਣੀ ਸਿਹਤ ਸਥਿਤੀ DCS ਨੂੰ ਲਿਖਦਾ ਹੈ। ਜਦੋਂ ਲੀਡਰ (ਪ੍ਰਾਇਮਰੀ) ਕੌਂਫਿਗਰ ਕੀਤੇ TTL ਦੇ ਅੰਦਰ ਆਪਣੀ DCS ਕੁੰਜੀ ਨੂੰ ਰੀਨਿਊ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ Patroni ਸਿਹਤਮੰਦ ਸਟੈਂਡਬਾਏ ਵਿਚਕਾਰ ਇੱਕ ਲੀਡਰ ਚੋਣ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਜੇਤੂ ਨੂੰ ਪ੍ਰਾਇਮਰੀ ਵਿੱਚ ਅੱਗੇ ਵਧਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਬਾਕੀ ਬਚੇ ਨੋਡ ਆਪਣੇ ਆਪ ਨੂੰ ਨਵੇਂ ਪ੍ਰਾਇਮਰੀ ਦੇ ਸਟੈਂਡਬਾਏ ਦੇ ਰੂਪ ਵਿੱਚ ਮੁੜ ਸੰਰਚਿਤ ਕਰਦੇ ਹਨ - ਸਾਰੇ ਆਪਣੇ ਆਪ, ਆਮ ਤੌਰ 'ਤੇ 10-30 ਸਕਿੰਟਾਂ ਦੇ ਅੰਦਰ।

Patroni YAML ਸੰਰਚਨਾ

Patroni ਨੂੰ ਇੱਕ YAML ਫਾਈਲ ਦੁਆਰਾ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ ਜੋ DCS ਕਨੈਕਸ਼ਨ, PostgreSQL ਪੈਰਾਮੀਟਰ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਵਿਵਹਾਰ, ਅਤੇ ਬੂਟਸਟਰੈਪ ਸੈਟਿੰਗਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਪ੍ਰਾਇਮਰੀ ਨੋਡ ਲਈ ਹੇਠ ਦਿੱਤੀ ਇੱਕ ਉਤਪਾਦਨ-ਗਰੇਡ ਸੰਰਚਨਾ ਹੈ।

# /etc/patroni/patroni.yml — Node 1 (Primary)
scope: pg-ha-cluster
namespace: /postgresql-ha/
name: node1

restapi:
  listen: 0.0.0.0:8008
  connect_address: 10.0.1.10:8008

etcd3:
  hosts:
    - 10.0.2.10:2379
    - 10.0.2.11:2379
    - 10.0.2.12:2379

bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    maximum_lag_on_failover: 1048576  # 1MB — only promote standbys within this lag
    synchronous_mode: true
    synchronous_mode_strict: false
    postgresql:
      use_pg_rewind: true
      use_slots: true
      parameters:
        wal_level: replica
        hot_standby: 'on'
        max_connections: 200
        max_wal_senders: 10
        max_replication_slots: 10
        wal_keep_size: 2GB
        synchronous_commit: 'on'
        archive_mode: 'on'
        archive_command: 'test ! -f /archive/%f && cp %p /archive/%f'
        archive_timeout: 60
        wal_log_hints: 'on'
        shared_preload_libraries: 'pg_stat_statements'
        track_commit_timestamp: 'on'
      pg_hba:
        - host replication replicator 10.0.0.0/16 scram-sha-256
        - host all all 10.0.0.0/16 scram-sha-256
        - host all all 0.0.0.0/0 scram-sha-256

  initdb:
    - encoding: UTF8
    - data-checksums

  users:
    admin:
      password: 'admin_secure_password'
      options:
        - createrole
        - createdb
    replicator:
      password: 'repl_secure_password'
      options:
        - replication

postgresql:
  listen: 0.0.0.0:5432
  connect_address: 10.0.1.10:5432
  data_dir: /var/lib/postgresql/16/main
  bin_dir: /usr/lib/postgresql/16/bin
  config_dir: /var/lib/postgresql/16/main
  pgpass: /tmp/pgpass0
  authentication:
    superuser:
      username: postgres
      password: 'postgres_secure_password'
    replication:
      username: replicator
      password: 'repl_secure_password'
    rewind:
      username: postgres
      password: 'postgres_secure_password'
  parameters:
    unix_socket_directories: '/var/run/postgresql'
  create_replica_methods:
    - basebackup
  basebackup:
    max-rate: 100M
    checkpoint: fast

tags:
  nofailover: false
  noloadbalance: false
  clonefrom: false
  nosync: false

ਸਟੈਂਡਬਾਏ ਨੋਡ ਆਪਣੇ ਖੁਦ ਦੇname,connect_address, ਅਤੇlistenਮੁੱਲਾਂ ਦੇ ਨਾਲ ਇੱਕ ਸਮਾਨ ਸੰਰਚਨਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਪੈਟਰੋਨੀ ਬਾਕੀ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ - ਇਹ ਪਤਾ ਲਗਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਇੱਕ ਨੋਡ ਲੀਡਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ DCS ਸਥਿਤੀ ਦੇ ਅਧਾਰ ਤੇ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਅਤੇ PostgreSQL ਨੂੰ ਉਸ ਅਨੁਸਾਰ ਕੌਂਫਿਗਰ ਕਰਦਾ ਹੈ।

etcd

etcd ਇੱਕ ਪੈਟਰੋਨੀ ਕਲੱਸਟਰ ਦਾ ਨਰਵਸ ਸਿਸਟਮ ਹੈ। ਇਹ ਮੌਜੂਦਾ ਲੀਡਰ ਪਛਾਣ, ਕਲੱਸਟਰ ਟੋਪੋਲੋਜੀ, ਲੋੜੀਂਦੀ ਸੰਰਚਨਾ, ਅਤੇ ਹਰੇਕ ਨੋਡ ਦੀ ਸਿਹਤ ਸਥਿਤੀ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਇੱਕ ਤਿੰਨ-ਨੋਡ etcd ਕਲੱਸਟਰ ਉਤਪਾਦਨ ਲਈ ਨਿਊਨਤਮ ਹੈ, ਕੋਰਮ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਦੌਰਾਨ ਇੱਕ ਨੋਡ ਦੀ ਅਸਫਲਤਾ ਨੂੰ ਬਰਦਾਸ਼ਤ ਕਰਦਾ ਹੈ।

# Install and configure etcd on three dedicated nodes
# /etc/etcd/etcd.conf.yml — Node etcd1 (10.0.2.10)
name: etcd1
data-dir: /var/lib/etcd
listen-client-urls: http://0.0.0.0:2379
listen-peer-urls: http://0.0.0.0:2380
advertise-client-urls: http://10.0.2.10:2379
initial-advertise-peer-urls: http://10.0.2.10:2380
initial-cluster: etcd1=http://10.0.2.10:2380,etcd2=http://10.0.2.11:2380,etcd3=http://10.0.2.12:2380
initial-cluster-state: new
initial-cluster-token: patroni-etcd-cluster

# Start etcd
systemctl enable --now etcd

# Verify cluster health
etcdctl endpoint health --cluster \
  --endpoints=http://10.0.2.10:2379,http://10.0.2.11:2379,http://10.0.2.12:2379

ਉਤਪਾਦਨ ਤੈਨਾਤੀਆਂ ਲਈ, etcd ਸਾਥੀਆਂ ਅਤੇ etcd ਅਤੇ Patroni ਗਾਹਕਾਂ ਵਿਚਕਾਰ TLS ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ। ਗੈਰ-ਇਨਕ੍ਰਿਪਟਡ etcd ਟ੍ਰੈਫਿਕ ਕਲੱਸਟਰ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਅਤੇ ਸੰਰਚਨਾ ਨੂੰ ਨੈੱਟਵਰਕ-ਪੱਧਰ ਦੇ ਹਮਲਾਵਰਾਂ ਨੂੰ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ।

ਕਨੈਕਸ਼ਨ ਰੂਟਿੰਗ ਲਈ

HAProxy

Patroni ਹਰੇਕ ਨੋਡ (ਪੋਰਟ 8008 ਮੂਲ ਰੂਪ ਵਿੱਚ) 'ਤੇ ਇੱਕ REST API ਦਾ ਪਰਦਾਫਾਸ਼ ਕਰਦਾ ਹੈ ਜੋ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਨੋਡ ਮੌਜੂਦਾ ਲੀਡਰ ਹੈ ਜਾਂ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਹੈ। HAProxy ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੂਟ ਕਰਨ ਲਈ ਇਹਨਾਂ ਸਿਹਤ ਜਾਂਚ ਅੰਤਮ ਬਿੰਦੂਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ: ਲੀਡਰ ਨੂੰ ਲਿਖਦਾ ਹੈ, ਸਿਹਤਮੰਦ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਐਪਲੀਕੇਸ਼ਨ-ਪੱਧਰ ਦੇ ਬਦਲਾਅ ਦੇ ਆਟੋਮੈਟਿਕ ਰੀਡ-ਰਾਈਟ ਸਪਲਿਟਿੰਗ ਦਿੰਦਾ ਹੈ।

# /etc/haproxy/haproxy.cfg
global
    maxconn 2000
    log /dev/log local0
    stats socket /var/run/haproxy.sock mode 660 level admin

defaults
    mode tcp
    log global
    retries 3
    timeout client 30m
    timeout connect 4s
    timeout server 30m
    timeout check 5s
    maxconn 1000

listen pg_write
    bind *:5000
    option httpchk GET /primary
    http-check expect status 200
    default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
    server node1 10.0.1.10:5432 check port 8008
    server node2 10.0.1.11:5432 check port 8008
    server node3 10.0.1.12:5432 check port 8008

listen pg_read
    bind *:5001
    balance roundrobin
    option httpchk GET /replica
    http-check expect status 200
    default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
    server node1 10.0.1.10:5432 check port 8008
    server node2 10.0.1.11:5432 check port 8008
    server node3 10.0.1.12:5432 check port 8008

listen stats
    bind *:7000
    mode http
    stats enable
    stats uri /
    stats refresh 10s

/primaryਅੰਤਮ ਬਿੰਦੂ HTTP 200 ਸਿਰਫ਼ ਮੌਜੂਦਾ ਪੈਟਰੋਨੀ ਲੀਡਰ 'ਤੇ ਵਾਪਸ ਕਰਦਾ ਹੈ।/replicaਐਂਡਪੁਆਇੰਟ ਸਿਹਤਮੰਦ ਸਟੈਂਡਬਾਏ 'ਤੇ 200 ਵਾਪਸ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ ਫੇਲਓਵਰ ਵਾਪਰਦਾ ਹੈ, ਤਾਂ ਨਵਾਂ ਪ੍ਰਾਇਮਰੀ/primary'ਤੇ 200 ਵਾਪਸ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ HAProxy ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਰਾਈਟ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੀਡਾਇਰੈਕਟ ਕਰਦਾ ਹੈ — ਖਾਸ ਤੌਰ 'ਤੇ ਇੱਕ ਸਿਹਤ ਜਾਂਚ ਅੰਤਰਾਲ (3 ਸਕਿੰਟ) ਦੇ ਅੰਦਰ।on-marked-down shutdown-sessionsਡਾਇਰੈਕਟਿਵ ਇੱਕ ਅਸਫਲ ਪ੍ਰਾਇਮਰੀ ਲਈ ਮੌਜੂਦਾ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਤੁਰੰਤ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ, ਗਾਹਕਾਂ ਨੂੰ ਨਵੇਂ ਲੀਡਰ ਨਾਲ ਮੁੜ ਜੁੜਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ।

PgBouncer

PostgreSQL ਹਰੇਕ ਕਲਾਇੰਟ ਕੁਨੈਕਸ਼ਨ ਲਈ ਇੱਕ ਨਵੀਂ ਬੈਕਐਂਡ ਪ੍ਰਕਿਰਿਆ ਬਣਾਉਂਦਾ ਹੈ। ਪੈਮਾਨੇ 'ਤੇ - ਸੈਂਕੜੇ ਜਾਂ ਹਜ਼ਾਰਾਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਹਰੇਕ ਕੁਨੈਕਸ਼ਨ ਪੂਲ ਨੂੰ ਕਾਇਮ ਰੱਖਦੀਆਂ ਹਨ - ਪ੍ਰਕਿਰਿਆ ਬਣਾਉਣ ਅਤੇ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਦਾ ਓਵਰਹੈੱਡ ਮਹੱਤਵਪੂਰਨ ਬਣ ਜਾਂਦਾ ਹੈ। PgBouncer ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ PostgreSQL ਦੇ ਵਿਚਕਾਰ ਬੈਠਦਾ ਹੈ, ਸਰਵਰ-ਸਾਈਡ ਕਨੈਕਸ਼ਨਾਂ ਅਤੇ ਮਲਟੀਪਲੈਕਸਿੰਗ ਕਲਾਇੰਟ ਕੁਨੈਕਸ਼ਨਾਂ ਦੇ ਪੂਲ ਨੂੰ ਉਹਨਾਂ 'ਤੇ ਕਾਇਮ ਰੱਖਦਾ ਹੈ।

# /etc/pgbouncer/pgbouncer.ini
[databases]
* = host=127.0.0.1 port=5432 dbname=appdb

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt

pool_mode = transaction
max_client_conn = 1000
default_pool_size = 50
min_pool_size = 10
reserve_pool_size = 10
reserve_pool_timeout = 3
server_lifetime = 3600
server_idle_timeout = 600
server_connect_timeout = 5
server_login_retry = 3

log_connections = 1
log_disconnections = 1
stats_period = 60

ਜਦੋਂ Patroni ਨਾਲ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, PgBouncer ਆਮ ਤੌਰ 'ਤੇ ਹਰੇਕ PostgreSQL ਨੋਡ ਜਾਂ HAProxy ਨੋਡਾਂ 'ਤੇ ਸਹਿ-ਸਥਿਤ ਹੁੰਦਾ ਹੈ।transactionਪੂਲ ਮੋਡ ਜ਼ਿਆਦਾਤਰ ਵਰਕਲੋਡਾਂ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਵਿਕਲਪ ਹੈ — ਇਹ ਇੱਕ ਲੈਣ-ਦੇਣ ਦੀ ਮਿਆਦ ਲਈ ਇੱਕ ਸਰਵਰ ਕਨੈਕਸ਼ਨ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਲੈਣ-ਦੇਣ ਦੇ ਵਿਚਕਾਰ ਪੂਲ ਵਿੱਚ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਇਹsessionਮੋਡ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਕੁਸ਼ਲ ਹੈ, ਜੋ ਪੂਰੇ ਕਲਾਇੰਟ ਸੈਸ਼ਨ ਲਈ ਕਨੈਕਸ਼ਨ ਰੱਖਦਾ ਹੈ।

WAL ਆਰਕਾਈਵਿੰਗ ਅਤੇ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ

ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸਰਵਰ ਦੀ ਅਸਫਲਤਾ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ, ਪਰ ਇਹ ਤਰਕਪੂਰਨ ਗਲਤੀਆਂ ਤੋਂ ਸੁਰੱਖਿਆ ਨਹੀਂ ਕਰਦੀ — ਇੱਕ ਦੁਰਘਟਨਾਤਮਕDROP TABLEਜਾਂ ਇੱਕ ਖਰਾਬ ਐਪਲੀਕੇਸ਼ਨ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਤੁਰੰਤ ਸਾਰੇ ਸਟੈਂਡਬਾਏਜ਼ ਲਈ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ। ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ (PITR) ਦੇ ਨਾਲ ਮਿਲ ਕੇ WAL ਆਰਕਾਈਵਿੰਗ ਤੁਹਾਨੂੰ ਗਲਤੀ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਵੀ ਪਲ ਨੂੰ ਰੀਸਟੋਰ ਕਰਨ ਦਿੰਦੀ ਹੈ।

WAL ਆਰਕਾਈਵਿੰਗ ਕਾਪੀਆਂ ਨੇ ਇੱਕ ਟਿਕਾਊ ਪੁਰਾਲੇਖ ਵਿੱਚ WAL ਭਾਗਾਂ ਨੂੰ ਪੂਰਾ ਕੀਤਾ — ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ S3 ਬਾਲਟੀ, ਇੱਕ NFS ਮਾਊਂਟ, ਜਾਂ ਇੱਕ ਸਮਰਪਿਤ ਬੈਕਅੱਪ ਸਰਵਰ।pgBackRestਅਤੇWAL-Gਵਰਗੇ ਟੂਲ ਕੰਪਰੈਸ਼ਨ, ਐਨਕ੍ਰਿਪਸ਼ਨ, ਅਤੇ ਸਮਾਨਾਂਤਰ ਟ੍ਰਾਂਸਫਰ ਦੇ ਨਾਲ ਕੁਸ਼ਲਤਾ ਨਾਲ ਪੁਰਾਲੇਖ ਨੂੰ ਹੈਂਡਲ ਕਰਦੇ ਹਨ।

# pgBackRest configuration — /etc/pgbackrest/pgbackrest.conf
[global]
repo1-type=s3
repo1-s3-bucket=pg-wal-archive
repo1-s3-endpoint=s3.eu-west-1.amazonaws.com
repo1-s3-region=eu-west-1
repo1-s3-key=AKIAIOSFODNN7EXAMPLE
repo1-s3-key-secret=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
repo1-path=/pgbackrest
repo1-retention-full=4
repo1-retention-diff=7
repo1-cipher-type=aes-256-cbc
repo1-cipher-pass=strong_encryption_passphrase
compress-type=zst
compress-level=3
process-max=4

[pg-ha-cluster]
pg1-path=/var/lib/postgresql/16/main
pg1-port=5432

# In postgresql.conf
archive_command = 'pgbackrest --stanza=pg-ha-cluster archive-push %p'
restore_command = 'pgbackrest --stanza=pg-ha-cluster archive-get %f "%p"'

ਇੱਕ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਕਰਨ ਲਈ, ਇੱਕ ਟੀਚਾ ਟਾਈਮਸਟੈਂਪ ਨਿਰਧਾਰਤ ਕਰੋ।

# Restore to a specific point in time
pgbackrest --stanza=pg-ha-cluster --type=time \
  --target="2026-04-12 11:25:00" \
  --target-action=promote \
  restore

ਲਾਜ਼ੀਕਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ

ਜਦੋਂ ਕਿ ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਪੂਰੇ ਡੇਟਾਬੇਸ ਕਲੱਸਟਰ ਦੀ ਇੱਕ ਸਹੀ ਭੌਤਿਕ ਕਾਪੀ ਬਣਾਉਂਦੀ ਹੈ, ਤਾਰਕਿਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਟੇਬਲ ਪੱਧਰ 'ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ, ਵਿਅਕਤੀਗਤ ਟੇਬਲਾਂ ਜਾਂ ਸੁਤੰਤਰ PostgreSQL ਉਦਾਹਰਨਾਂ ਦੇ ਵਿਚਕਾਰ ਡੇਟਾ ਦੇ ਉਪ ਸਮੂਹਾਂ ਦੀ ਨਕਲ ਕਰਦੀ ਹੈ। ਇਹ ਜ਼ੀਰੋ-ਡਾਊਨਟਾਈਮ ਮੁੱਖ ਸੰਸਕਰਣ ਅੱਪਗਰੇਡਾਂ, ਕ੍ਰਾਸ-ਰੀਜਨ ਰੀਡ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਲਈ ਲਾਭਦਾਇਕ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਿਰਫ਼ ਖਾਸ ਟੇਬਲ, ਡਾਟਾ ਵੇਅਰਹਾਊਸ ਫੀਡਿੰਗ, ਅਤੇ ਮਲਟੀ-ਟੇਨੈਂਟ ਡਾਟਾ ਵੰਡ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

# On the publisher (source database)
wal_level = logical  # must be 'logical' — higher than 'replica'

CREATE PUBLICATION app_pub FOR TABLE orders, customers, products;

# On the subscriber (target database)
CREATE SUBSCRIPTION app_sub
  CONNECTION 'host=publisher-host port=5432 dbname=appdb user=replicator password=pass'
  PUBLICATION app_pub;

ਲਾਜ਼ੀਕਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਨਾਲ ਚੱਲ ਸਕਦੀ ਹੈ। ਇੱਕ ਆਮ ਪੈਟਰਨ HA (ਤੇਜ਼ ਭੌਤਿਕ ਫੇਲਓਵਰ) ਲਈ ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਅਤੇ ਕਰਾਸ-ਖੇਤਰ ਵਿਸ਼ਲੇਸ਼ਣ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਲਈ ਲਾਜ਼ੀਕਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਿਰਫ਼ ਟੇਬਲਾਂ ਦੇ ਇੱਕ ਉਪ ਸਮੂਹ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਮਲਟੀ-ਰੀਜਨ ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ

ਆਫ਼ਤ ਰਿਕਵਰੀ ਅਤੇ ਗਲੋਬਲ ਰੀਡ ਪ੍ਰਦਰਸ਼ਨ ਲਈ, PostgreSQL ਕਲੱਸਟਰ ਕਈ ਖੇਤਰਾਂ ਵਿੱਚ ਫੈਲ ਸਕਦੇ ਹਨ। ਸਟੈਂਡਰਡ ਪੈਟਰਨ ਇੱਕ ਖੇਤਰ ਦੇ ਅੰਦਰ ਸਮਕਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਹੈ (ਸਥਾਨਕ ਫੇਲਓਵਰ 'ਤੇ ਜ਼ੀਰੋ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਲਈ) ਅਤੇ ਖੇਤਰਾਂ ਵਿੱਚ ਅਸਿੰਕਰੋਨਸ ਪ੍ਰਤੀਕ੍ਰਿਤੀ (ਹਰ ਲਿਖਤ 'ਤੇ ਅੰਤਰ-ਖੇਤਰ ਲੇਟੈਂਸੀ ਜੁਰਮਾਨੇ ਤੋਂ ਬਚਣ ਲਈ)। ਸਥਾਨਕ ਰੀਡ ਰੂਟਿੰਗ ਲਈ ਹਰੇਕ ਖੇਤਰ ਦੀ ਆਪਣੀ HAProxy ਹੁੰਦੀ ਹੈ।

ਫੇਲਓਵਰ ਅਤੇ ਸਵਿਚਓਵਰ ਪ੍ਰਕਿਰਿਆਵਾਂ

ਫੇਲਓਵਰ ਅਤੇ ਸਵਿਚਓਵਰ ਵਿੱਚ ਅੰਤਰ ਨੂੰ ਸਮਝਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇੱਕਫੇਲਓਵਰਇੱਕ ਗੈਰ-ਯੋਜਨਾਬੱਧ ਪ੍ਰਚਾਰ ਹੈ ਜੋ ਮੌਜੂਦਾ ਪ੍ਰਾਇਮਰੀ ਦੀ ਅਸਫਲਤਾ ਦੁਆਰਾ ਸ਼ੁਰੂ ਕੀਤਾ ਗਿਆ ਹੈ। ਇੱਕਸਵਿੱਚਓਵਰਇੱਕ ਯੋਜਨਾਬੱਧ, ਸ਼ਾਨਦਾਰ ਭੂਮਿਕਾ ਤਬਦੀਲੀ ਹੈ — ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਰੱਖ-ਰਖਾਅ ਤੋਂ ਪਹਿਲਾਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਸਰਪ੍ਰਸਤ ਦੋਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।

ਯੋਜਨਾਬੱਧ ਸਵਿੱਚਓਵਰ

# List cluster members
patronictlctl -c /etc/patroni/patroni.yml list

# Perform switchover to a specific node
patronictlctl -c /etc/patroni/patroni.yml switchover \
  --master node1 --candidate node2 --force

# Or use the Patroni REST API
curl -s http://10.0.1.10:8008/switchover -XPOST \
  -d '{"leader": "node1", "candidate": "node2"}'

ਇੱਕ ਸਵਿੱਚਓਵਰ ਦੇ ਦੌਰਾਨ, ਪੈਟਰੋਨੀ ਮੌਜੂਦਾ ਪ੍ਰਾਇਮਰੀ ਨੂੰ ਇੱਕ ਸਟੈਂਡਬਾਏ ਵਿੱਚ ਘਟਾ ਦਿੰਦਾ ਹੈ, ਟੀਚੇ ਦੇ ਉਮੀਦਵਾਰ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਵੀਂ ਪ੍ਰਾਇਮਰੀ ਦੀ ਪਾਲਣਾ ਕਰਨ ਲਈ ਹੋਰ ਸਾਰੇ ਸਟੈਂਡਬਾਏ ਨੂੰ ਮੁੜ ਸੰਰਚਿਤ ਕਰਦਾ ਹੈ। ਪ੍ਰਕਿਰਿਆ 5-15 ਸਕਿੰਟ ਲੈਂਦੀ ਹੈ. HAProxy ਸਿਹਤ ਜਾਂਚਾਂ ਰਾਹੀਂ ਤਬਦੀਲੀ ਦਾ ਪਤਾ ਲਗਾਉਂਦਾ ਹੈ ਅਤੇ ਆਵਾਜਾਈ ਨੂੰ ਆਪਣੇ ਆਪ ਰੀਡਾਇਰੈਕਟ ਕਰਦਾ ਹੈ।

ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ ਕ੍ਰਮ

ਜਦੋਂ ਪ੍ਰਾਇਮਰੀ ਅਚਾਨਕ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਪੈਟਰੋਨੀ ਸੇਵਾ ਨੂੰ ਬਹਾਲ ਕਰਨ ਲਈ ਇੱਕ ਸਟੀਕ ਕ੍ਰਮ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤਾ ਚਿੱਤਰ ਕਦਮਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ।

ਸਪਲਿਟ-ਬ੍ਰੇਨ ਪ੍ਰੀਵੈਨਸ਼ਨ

ਸਪਲਿਟ-ਬ੍ਰੇਨ — ਜਿੱਥੇ ਦੋ ਨੋਡ ਇੱਕੋ ਸਮੇਂ ਮੰਨਦੇ ਹਨ ਕਿ ਉਹ ਪ੍ਰਾਇਮਰੀ ਹਨ — ਕਿਸੇ ਵੀ HA ਸਿਸਟਮ ਵਿੱਚ ਸਭ ਤੋਂ ਖਤਰਨਾਕ ਅਸਫਲਤਾ ਮੋਡ ਹੈ। ਪੈਟਰੋਨੀ ਕਈ ਵਿਧੀਆਂ ਦੁਆਰਾ ਸਪਲਿਟ-ਬ੍ਰੇਨ ਨੂੰ ਰੋਕਦਾ ਹੈ:

1. DCS-ਅਧਾਰਿਤ ਲੀਡਰ ਲੌਕ:ਸਿਰਫ਼ ਇੱਕ ਨੋਡ ਕਿਸੇ ਵੀ ਸਮੇਂ etcd ਵਿੱਚ ਲੀਡਰ ਕੁੰਜੀ ਨੂੰ ਰੱਖ ਸਕਦਾ ਹੈ। ਕੁੰਜੀ ਵਿੱਚ ਇੱਕ TTL ਹੈ, ਅਤੇ ਲੀਡਰ ਨੂੰ ਇਸਨੂੰ ਲਗਾਤਾਰ ਰੀਨਿਊ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਇੱਕ ਨੈੱਟਵਰਕ ਭਾਗ ਲੀਡਰ ਨੂੰ etcd ਤੋਂ ਅਲੱਗ ਕਰਦਾ ਹੈ, ਤਾਂ ਕੁੰਜੀ ਦੀ ਮਿਆਦ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਲੀਡਰ ਆਪਣੇ ਆਪ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।
2. ਵਾਚਡੌਗ:ਪੈਟਰੋਨੀ ਇੱਕ Linux ਵਾਚਡੌਗ ਡਿਵਾਈਸ (/dev/watchdog) ਨੂੰ ਕੌਂਫਿਗਰ ਕਰ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਪੈਟਰੋਨੀ DCS ਤੱਕ ਪਹੁੰਚ ਗੁਆ ਦਿੰਦਾ ਹੈ ਅਤੇ ਇਹ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਲੀਡਰ ਬਣੇ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਵਾਚਡੌਗ ਨੋਡ ਨੂੰ ਰੀਬੂਟ ਜਾਂ ਪਾਵਰ-ਆਫ ਕਰ ਦੇਵੇਗਾ - ਇੱਕ ਸਖ਼ਤ ਫੈਂਸਿੰਗ ਵਿਧੀ ਜੋ ਗਾਰੰਟੀ ਦਿੰਦੀ ਹੈ ਕਿ ਪੁਰਾਣੀ ਪ੍ਰਾਇਮਰੀ ਲਿਖਤਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਜਾਰੀ ਨਹੀਂ ਰੱਖੇਗੀ।
3. pg_rewind:ਜਦੋਂ ਕੋਈ ਸਾਬਕਾ ਪ੍ਰਾਇਮਰੀ ਔਨਲਾਈਨ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਇਸ ਵਿੱਚ WAL ਰਿਕਾਰਡ ਹੋ ਸਕਦੇ ਹਨ ਜੋ ਕਦੇ ਵੀ ਨਕਲ ਨਹੀਂ ਕੀਤੇ ਗਏ ਸਨ।pg_rewindਟਾਈਮਲਾਈਨ ਨੂੰ ਵਿਭਿੰਨਤਾ ਦੇ ਬਿੰਦੂ 'ਤੇ ਰੀਵਾਇੰਡ ਕਰਦਾ ਹੈ, ਨੋਡ ਨੂੰ ਪੂਰੇ ਬੇਸ ਬੈਕਅਪ ਦੇ ਬਿਨਾਂ ਸਟੈਂਡਬਾਏ ਵਜੋਂ ਦੁਬਾਰਾ ਜੁੜਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। Patroni ਦੀuse_pg_rewind: trueਸੈਟਿੰਗ ਇਸਨੂੰ ਆਟੋਮੇਟ ਕਰਦੀ ਹੈ।

# Enable watchdog in Patroni config
bootstrap:
  dcs:
    postgresql:
      use_pg_rewind: true
      parameters:
        wal_log_hints: 'on'  # required for pg_rewind

# Watchdog configuration
watchdog:
  mode: required        # 'off', 'automatic', or 'required'
  device: /dev/watchdog
  safety_margin: 5      # seconds before TTL expiry to trigger watchdog

repmgr Patroni

repmgrPostgreSQL ਲਈ ਇੱਕ ਹੋਰ ਪ੍ਰਸਿੱਧ HA ਟੂਲ ਹੈ। ਇਹ ਸਟੈਂਡਬਾਏ ਪ੍ਰਬੰਧਨ, ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ, ਅਤੇ ਸਵਿਚਓਵਰ ਸਮਰੱਥਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇਹ ਪੈਟਰੋਨੀ ਤੋਂ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਵੱਖਰੀ ਪਹੁੰਚ ਲੈਂਦਾ ਹੈ। repmgr ਇੱਕ ਵਿਟਨੇਸ ਨੋਡ ਅਤੇ ਇੱਕ ਡੈਮਨ (repmgrd) ਦੀ ਵਰਤੋਂ ਇੱਕ ਵਿਤਰਿਤ ਸਹਿਮਤੀ ਸਟੋਰ ਦੀ ਬਜਾਏ ਅਸਫਲਤਾ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਕਰਦਾ ਹੈ। ਇਹ ਇਸ ਨੂੰ ਤੈਨਾਤ ਕਰਨਾ ਸੌਖਾ ਬਣਾਉਂਦਾ ਹੈ ਪਰ ਗੁੰਝਲਦਾਰ ਨੈੱਟਵਰਕ ਭਾਗ ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚ ਸਪਲਿਟ-ਬ੍ਰੇਨ ਲਈ ਵਧੇਰੇ ਸੰਵੇਦਨਸ਼ੀਲ ਬਣਾਉਂਦਾ ਹੈ।

# repmgr.conf on the primary
node_id=1
node_name='node1'
conninfo='host=10.0.1.10 user=repmgr dbname=repmgr connect_timeout=2'
data_directory='/var/lib/postgresql/16/main'
failover=automatic
promote_command='repmgr standby promote -f /etc/repmgr.conf --log-to-file'
follow_command='repmgr standby follow -f /etc/repmgr.conf --log-to-file --upstream-node-id=%n'
monitoring_history=yes
monitor_interval_secs=5
reconnect_attempts=6
reconnect_interval=10

ਨਵੀਆਂ ਤੈਨਾਤੀਆਂ ਲਈ, ਪੈਟਰੋਨੀ ਇਸਦੀ ਮਜ਼ਬੂਤ ​​ਵਿਭਾਗ-ਦਿਮਾਗ ਦੀ ਰੋਕਥਾਮ ਦੀ ਗਾਰੰਟੀ ਅਤੇ ਵਧੇਰੇ ਸਰਗਰਮ ਵਿਕਾਸ ਭਾਈਚਾਰੇ ਦੇ ਕਾਰਨ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਚੋਣ ਹੈ। repmgr ਸਰਲ ਸੈੱਟਅੱਪ ਜਾਂ ਟੂਲ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਨਿਵੇਸ਼ ਕੀਤੇ ਸੰਗਠਨਾਂ ਲਈ ਇੱਕ ਵਾਜਬ ਵਿਕਲਪ ਬਣਿਆ ਹੋਇਆ ਹੈ।

ਕਲਾਊਡ ਡਿਪਲਾਇਮੈਂਟ ਪੈਟਰਨ

AWS ਤੈਨਾਤੀ: EC2, EBS, ਅਤੇ Route53

AWS 'ਤੇ, ਹਰੇਕ PostgreSQL + Patroni ਨੋਡ ਨੂੰ EBS gp3 ਜਾਂ io2 ਵਾਲੀਅਮ ਦੇ ਨਾਲ ਇੱਕ EC2 ਉਦਾਹਰਨ 'ਤੇ ਤੈਨਾਤ ਕਰੋ। HA ਲਈ ਮਲਟੀਪਲ ਉਪਲਬਧਤਾ ਜ਼ੋਨਾਂ ਵਿੱਚ ਵੱਖਰੀਆਂ ਉਦਾਹਰਣਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ। etcd ਨੋਡਾਂ ਨੂੰ AZs ਵੀ ਫੈਲਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।

# Terraform sketch for PostgreSQL HA on AWS
resource "aws_instance" "pg_node" {
  count                = 3
  ami                  = "ami-0abcdef1234567890"  # Ubuntu 22.04
  instance_type        = "r6g.2xlarge"             # 8 vCPU, 64GB RAM
  subnet_id            = aws_subnet.private[count.index].id
  vpc_security_group_ids = [aws_security_group.pg_sg.id]
  availability_zone    = element(["eu-west-1a", "eu-west-1b", "eu-west-1c"], count.index)

  root_block_device {
    volume_size = 50
    volume_type = "gp3"
  }

  tags = {
    Name = "pg-node-${count.index + 1}"
    Role = "patroni"
  }
}

resource "aws_ebs_volume" "pg_data" {
  count             = 3
  availability_zone = element(["eu-west-1a", "eu-west-1b", "eu-west-1c"], count.index)
  size              = 500
  type              = "gp3"
  iops              = 6000
  throughput        = 250
  encrypted         = true

  tags = {
    Name = "pg-data-${count.index + 1}"
  }
}

resource "aws_route53_health_check" "pg_primary" {
  count             = 3
  ip_address        = aws_instance.pg_node[count.index].private_ip
  port              = 8008
  type              = "HTTP"
  resource_path     = "/primary"
  failure_threshold = 3
  request_interval  = 10
}

ਜੇਕਰ ਤੁਸੀਂ AWS-ਪ੍ਰਬੰਧਿਤ ਹੱਲ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹੋ ਤਾਂ HAProxy ਦੀ ਬਜਾਏ ਇੱਕ ਨੈੱਟਵਰਕ ਲੋਡ ਬੈਲੈਂਸਰ (NLB) ਦੀ ਵਰਤੋਂ ਕਰੋ। NLB ਮੌਜੂਦਾ ਪ੍ਰਾਇਮਰੀ ਤੱਕ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੂਟ ਕਰਨ ਲਈ Patroni REST API ਦੇ ਵਿਰੁੱਧ ਟੀਚਾ ਸਮੂਹ ਸਿਹਤ ਜਾਂਚਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ।

Azure ਤੈਨਾਤੀ: VM, ਪ੍ਰਬੰਧਿਤ ਡਿਸਕ, ਅਤੇ Azure LB

Azure 'ਤੇ, ਡਾਟਾ ਵਾਲੀਅਮ ਲਈ ਪ੍ਰੀਮੀਅਮ SSD ਪ੍ਰਬੰਧਿਤ ਡਿਸਕਾਂ ਦੇ ਨਾਲ ਸਟੈਂਡਰਡ_E8s_v5 VM (ਮੈਮੋਰੀ-ਅਨੁਕੂਲ) ਦੀ ਵਰਤੋਂ ਕਰੋ। ਉਪਲਬਧਤਾ ਜ਼ੋਨਾਂ ਵਿੱਚ ਤੈਨਾਤ ਕਰੋ। Azure ਲੋਡ ਬੈਲੈਂਸਰ Patroni REST API ਦੇ ਵਿਰੁੱਧ ਸਿਹਤ ਜਾਂਚਾਂ ਦੇ ਨਾਲ HAProxy ਦੇ ਬਰਾਬਰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

# Azure CLI — create PostgreSQL VM with Managed Disk
az vm create \
  --resource-group pg-ha-rg \
  --name pg-node-1 \
  --image Canonical:0001-com-ubuntu-server-jammy:22_04-lts:latest \
  --size Standard_E8s_v5 \
  --zone 1 \
  --vnet-name pg-vnet \
  --subnet pg-subnet \
  --nsg pg-nsg \
  --admin-username pgadmin \
  --ssh-key-value ~/.ssh/id_rsa.pub

az disk create \
  --resource-group pg-ha-rg \
  --name pg-data-1 \
  --size-gb 512 \
  --sku Premium_LRS \
  --zone 1

az vm disk attach \
  --resource-group pg-ha-rg \
  --vm-name pg-node-1 \
  --name pg-data-1

# Azure Load Balancer health probe for Patroni
az network lb probe create \
  --resource-group pg-ha-rg \
  --lb-name pg-lb \
  --name patroni-primary-probe \
  --protocol Http \
  --port 8008 \
  --path /primary \
  --interval 5 \
  --threshold 3

GCP ਡਿਪਲਾਇਮੈਂਟ: ਕੰਪਿਊਟ ਇੰਜਣ ਅਤੇ ਕਲਾਉਡ ਲੋਡ ਬੈਲੇਂਸਿੰਗ

GCP 'ਤੇ, SSD ਪਰਸਿਸਟੈਂਟ ਡਿਸਕਾਂ ਦੇ ਨਾਲ n2-ਹਾਈਮੇਮ-8 ਉਦਾਹਰਨਾਂ (8 vCPU, 64GB RAM) ਦੀ ਵਰਤੋਂ ਕਰੋ। ਇੱਕ ਖੇਤਰ ਦੇ ਅੰਦਰ ਜ਼ੋਨਾਂ ਵਿੱਚ ਵੰਡੋ। ਪੈਟਰੋਨੀ ਸਿਹਤ ਜਾਂਚਾਂ ਦੇ ਨਾਲ ਇੱਕ ਅੰਦਰੂਨੀ TCP/UDP ਲੋਡ ਬੈਲੇਂਸਰ ਦੀ ਵਰਤੋਂ ਕਰੋ।

# GCP — create instance and persistent disk
gcloud compute instances create pg-node-1 \
  --zone=europe-west1-b \
  --machine-type=n2-highmem-8 \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud \
  --boot-disk-size=50GB \
  --network=pg-network \
  --subnet=pg-subnet

gcloud compute disks create pg-data-1 \
  --zone=europe-west1-b \
  --size=500GB \
  --type=pd-ssd

gcloud compute instances attach-disk pg-node-1 \
  --disk=pg-data-1 \
  --zone=europe-west1-b

# Health check for Patroni primary endpoint
gcloud compute health-checks create http patroni-primary-check \
  --port=8008 \
  --request-path=/primary \
  --check-interval=5s \
  --timeout=5s \
  --unhealthy-threshold=3 \
  --healthy-threshold=2

ਬੇਅਰ ਮੈਟਲ k3s ਰੈਂਚਰ ਅਤੇ ਲੋਂਗਹੋਰਨ

ਉਹਨਾਂ ਸੰਸਥਾਵਾਂ ਲਈ ਜੋ ਆਪਣਾ ਖੁਦ ਦਾ ਹਾਰਡਵੇਅਰ ਚਲਾਉਂਦੇ ਹਨ, k3s, Rancher, ਅਤੇ Longhorn ਦੇ ਨਾਲ ਬੇਅਰ ਮੈਟਲ 'ਤੇ PostgreSQL HA ਨੂੰ ਤੈਨਾਤ ਕਰਨਾ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਓਪਨ-ਸੋਰਸ, ਕਲਾਊਡ-ਸੁਤੰਤਰ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। k3s ਇੱਕ ਹਲਕਾ Kubernetes ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਹੈ ਜੋ ਪੂਰੀ Kubernetes ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਦੇ ਓਵਰਹੈੱਡ ਤੋਂ ਬਿਨਾਂ ਬੇਅਰ ਮੈਟਲ ਸਰਵਰਾਂ 'ਤੇ ਕੁਸ਼ਲਤਾ ਨਾਲ ਚੱਲਦਾ ਹੈ।

k3s ਅਤੇ Longhorn ਸੈੱਟਅੱਪ

# Install k3s on the first server node
curl -sfL https://get.k3s.io | K3S_TOKEN=my-cluster-token \
  INSTALL_K3S_EXEC="server --cluster-init --disable traefik --disable servicelb" sh -

# Join additional server nodes
curl -sfL https://get.k3s.io | K3S_TOKEN=my-cluster-token \
  K3S_URL=https://10.0.0.1:6443 \
  INSTALL_K3S_EXEC="server" sh -

# Install Longhorn for distributed block storage
helm repo add longhorn https://charts.longhorn.io
helm install longhorn longhorn/longhorn \
  --namespace longhorn-system --create-namespace \
  --set defaultSettings.defaultDataPath=/mnt/longhorn \
  --set defaultSettings.replicaCount=3 \
  --set defaultSettings.storageMinimalAvailablePercentage=15

# Deploy PostgreSQL with Patroni using the Zalando Postgres Operator
helm repo add postgres-operator-charts https://opensource.zalando.com/postgres-operator/charts/postgres-operator
helm install postgres-operator postgres-operator-charts/postgres-operator \
  --namespace postgres-system --create-namespace

# PostgreSQL cluster manifest for the Zalando Postgres Operator
apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
  name: pg-ha-cluster
  namespace: production
spec:
  teamId: "platform"
  numberOfInstances: 3
  volume:
    size: 500Gi
    storageClass: longhorn
  users:
    appuser:
      - superuser
      - createdb
    replicator: []
  databases:
    appdb: appuser
  postgresql:
    version: "16"
    parameters:
      shared_buffers: "16GB"
      effective_cache_size: "48GB"
      work_mem: "256MB"
      maintenance_work_mem: "2GB"
      max_connections: "200"
      max_wal_senders: "10"
      wal_level: replica
      synchronous_commit: "on"
      wal_keep_size: "2GB"
      archive_mode: "on"
      track_commit_timestamp: "on"
  patroni:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    maximum_lag_on_failover: 1048576
    synchronous_mode: true
  resources:
    requests:
      cpu: "4"
      memory: 32Gi
    limits:
      cpu: "8"
      memory: 64Gi

HAProxy VIP

# /etc/keepalived/keepalived.conf on lb1
vrrp_script chk_haproxy {
    script "killall -0 haproxy"
    interval 2
    weight 2
}

vrrp_instance VI_PG {
    state MASTER
    interface eth0
    virtual_router_id 52
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass pgha_vip_pass
    }
    virtual_ipaddress {
        10.0.0.100/24
    }
    track_script {
        chk_haproxy
    }
}

ਨਿਗਰਾਨੀ PostgreSQL ਪ੍ਰਤੀਕ੍ਰਿਤੀ

ਮਾਨੀਟਰਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸਿਹਤ ਉਤਪਾਦਨ ਵਿੱਚ ਗੈਰ-ਵਿਵਾਦਯੋਗ ਹੈ। PostgreSQL ਇਸ ਉਦੇਸ਼ ਲਈ ਕਈ ਬਿਲਟ-ਇਨ ਦ੍ਰਿਸ਼ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਅਤੇ Grafana ਦੇ ਨਾਲ Prometheus ਲੰਬੇ ਸਮੇਂ ਦੀ ਦਿੱਖ ਅਤੇ ਤੁਹਾਨੂੰ ਲੋੜੀਂਦੀ ਚੇਤਾਵਨੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਬਿਲਟ-ਇਨ ਨਿਗਰਾਨੀ ਪੁੱਛਗਿੱਛ

-- Check replication status on the primary
SELECT
    client_addr,
    application_name,
    state,
    sync_state,
    sent_lsn,
    write_lsn,
    flush_lsn,
    replay_lsn,
    (sent_lsn - replay_lsn) AS replication_lag_bytes,
    write_lag,
    flush_lag,
    replay_lag
FROM pg_stat_replication;

-- Check replication slot status
SELECT
    slot_name,
    slot_type,
    active,
    wal_status,
    pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS slot_lag
FROM pg_replication_slots;

-- Check standby recovery status (run on standby)
SELECT
    pg_is_in_recovery() AS is_standby,
    pg_last_wal_receive_lsn() AS last_received,
    pg_last_wal_replay_lsn() AS last_replayed,
    pg_last_xact_replay_timestamp() AS last_replayed_timestamp,
    EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp()))::int AS replay_lag_seconds;

-- Monitor WAL generation rate
SELECT
    pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), '0/0')) AS total_wal_generated,
    pg_size_pretty(sum(size)) AS wal_directory_size
FROM pg_ls_waldir();

-- Check for long-running queries that could block replication
SELECT
    pid,
    now() - pg_stat_activity.query_start AS duration,
    query,
    state
FROM pg_stat_activity
WHERE (now() - pg_stat_activity.query_start) > interval '5 minutes'
  AND state != 'idle'
ORDER BY duration DESC;

Prometheus ਅਤੇ Grafana ਸਟੈਕ

postgres_exporterPrometheus ਫਾਰਮੈਟ ਵਿੱਚ PostgreSQL ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਉਜਾਗਰ ਕਰਦਾ ਹੈ।patroni_exporterਦੇ ਨਾਲ ਮਿਲਾ ਕੇ, ਤੁਹਾਨੂੰ ਡਾਟਾਬੇਸ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ HA ਕਲੱਸਟਰ ਸਥਿਤੀ ਦੋਵਾਂ ਵਿੱਚ ਪੂਰੀ ਦਿੱਖ ਮਿਲਦੀ ਹੈ।

# Deploy postgres_exporter as a sidecar or standalone
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

# Custom queries for postgres_exporter
# /etc/postgres_exporter/queries.yaml
pg_replication_lag:
  query: |
    SELECT
      CASE WHEN pg_is_in_recovery() THEN
        EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp()))::float
      ELSE 0 END AS lag_seconds
  master: true
  metrics:
    - lag_seconds:
        usage: "GAUGE"
        description: "Replication lag in seconds"

pg_replication_slots:
  query: |
    SELECT
      slot_name,
      active::int AS active,
      pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)::float AS slot_lag_bytes
    FROM pg_replication_slots
  master: true
  metrics:
    - slot_name:
        usage: "LABEL"
    - active:
        usage: "GAUGE"
        description: "Whether the slot is active"
    - slot_lag_bytes:
        usage: "GAUGE"
        description: "Slot lag in bytes"

# PrometheusRule for PostgreSQL HA alerts
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: postgresql-ha-alerts
  namespace: monitoring
spec:
  groups:
    - name: postgresql-replication
      rules:
        - alert: PostgreSQLReplicationLagHigh
          expr: pg_replication_lag_seconds > 30
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "PostgreSQL replication lag exceeds 30s on {{ $labels.instance }}"

        - alert: PostgreSQLReplicationSlotInactive
          expr: pg_replication_slots_active == 0
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Replication slot {{ $labels.slot_name }} is inactive"

        - alert: PostgreSQLReplicationSlotLagHigh
          expr: pg_replication_slots_slot_lag_bytes > 1073741824
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "Replication slot lag exceeds 1GB on {{ $labels.slot_name }}"

        - alert: PatroniClusterUnhealthy
          expr: patroni_cluster_members_count < 3
          for: 2m
          labels:
            severity: critical
          annotations:
            summary: "Patroni cluster has fewer than 3 members"

ਉਤਪਾਦਨ ਟਿਊਨਿੰਗ ਪੈਰਾਮੀਟਰ

PostgreSQL ਦੀ ਡਿਫੌਲਟ ਕੌਂਫਿਗਰੇਸ਼ਨ ਰੂੜੀਵਾਦੀ ਹੈ, ਇੱਕ ਛੋਟੇ ਸ਼ੇਅਰ ਹੋਸਟਿੰਗ ਵਾਤਾਵਰਣ ਲਈ ਟਿਊਨ ਕੀਤੀ ਗਈ ਹੈ। ਉਤਪਾਦਨ HA ਕਲੱਸਟਰਾਂ ਲਈ ਪ੍ਰਤੀਕ੍ਰਿਤੀ, ਮੈਮੋਰੀ, ਅਤੇ WAL ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਧਿਆਨ ਨਾਲ ਟਿਊਨਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਹੇਠ ਦਿੱਤੀ ਸਾਰਣੀ NVMe ਸਟੋਰੇਜ ਵਾਲੇ 64GB RAM ਸਰਵਰ ਲਈ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਸੈਟਿੰਗਾਂ ਦਾ ਸਾਰ ਦਿੰਦੀ ਹੈ।

# postgresql.conf — Production HA tuning

# === Replication ===
wal_level = replica
max_wal_senders = 10
max_replication_slots = 10
wal_keep_size = 4GB
synchronous_commit = on
synchronous_standby_names = 'ANY 1 (standby1, standby2)'
track_commit_timestamp = on
wal_log_hints = on

# === WAL ===
min_wal_size = 1GB
max_wal_size = 8GB
wal_buffers = 64MB
wal_compression = zstd
archive_mode = on
archive_timeout = 300
checkpoint_completion_target = 0.9
checkpoint_timeout = 15min

# === Memory ===
shared_buffers = 16GB              # 25% of RAM
effective_cache_size = 48GB        # 75% of RAM
work_mem = 256MB                   # per-operation sort/hash memory
maintenance_work_mem = 2GB         # for VACUUM, CREATE INDEX
huge_pages = try

# === Connections ===
max_connections = 200              # use PgBouncer for higher client counts
superuser_reserved_connections = 5

# === Query Performance ===
random_page_cost = 1.1             # SSD storage
effective_io_concurrency = 200     # NVMe SSD
default_statistics_target = 500
jit = on

# === Logging ===
log_min_duration_statement = 500   # log queries > 500ms
log_checkpoints = on
log_connections = on
log_disconnections = on
log_lock_waits = on
log_temp_files = 0
log_autovacuum_min_duration = 0

# === Autovacuum ===
autovacuum_max_workers = 4
autovacuum_naptime = 30s
autovacuum_vacuum_cost_limit = 2000
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02

ਟਿਊਨਿੰਗ ਪੈਟਰੋਨੀ DCS ਪੈਰਾਮੀਟਰ

ਪੈਟਰੋਨੀ ਦੇttl,loop_wait, ਅਤੇretry_timeoutਪੈਰਾਮੀਟਰਾਂ ਵਿਚਕਾਰ ਸਬੰਧ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਫੇਲਓਵਰ ਸਪੀਡ ਅਤੇ ਝੂਠੇ-ਸਕਾਰਾਤਮਕ ਜੋਖਮ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦੇ ਹਨ। ਇੱਕ ਛੋਟਾ TTL ਦਾ ਮਤਲਬ ਹੈ ਤੇਜ਼ ਫੇਲਓਵਰ ਖੋਜ ਪਰ ਸੰਖੇਪ ਨੈੱਟਵਰਕ ਬਲਿਪਸ ਦੇ ਦੌਰਾਨ ਬੇਲੋੜੇ ਫੇਲਓਵਰ ਦੇ ਜੋਖਮ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ।

# Conservative (production default)
ttl: 30
loop_wait: 10
retry_timeout: 10
# Failover detection: ~30-40 seconds

# Aggressive (low-latency failover)
ttl: 15
loop_wait: 5
retry_timeout: 5
# Failover detection: ~15-20 seconds
# Warning: Higher risk of false failovers in unstable networks

ਕੈਓਸ ਇੰਜੀਨੀਅਰਿੰਗ ਅਤੇ ਫੇਲਓਵਰ ਟੈਸਟਿੰਗ

ਇੱਕ ਫੇਲਓਵਰ ਸਿਸਟਮ ਜਿਸਦੀ ਕਦੇ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਗਈ ਇੱਕ ਸਿਸਟਮ ਹੈ ਜੋ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਕੈਓਸ ਇੰਜੀਨੀਅਰਿੰਗ ਇਹ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਲਈ ਨਿਯੰਤਰਿਤ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦੀ ਹੈ ਕਿ ਤੁਹਾਡਾ HA ਸੈਟਅਪ ਅਸਲ ਅਸਫਲ ਸਥਿਤੀਆਂ ਦੇ ਤਹਿਤ ਸਹੀ ਢੰਗ ਨਾਲ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ। ਹਰੇਕ ਪੈਟਰੋਨੀ ਕਲੱਸਟਰ ਨੂੰ ਨਿਯਮਤ ਫੇਲਓਵਰ ਡ੍ਰਿਲਸ ਦੇ ਅਧੀਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਫੇਲਓਵਰ ਟੈਸਟ ਪਲੇਬੁੱਕ

# 1. Verify cluster health before testing
patronictlctl -c /etc/patroni/patroni.yml list
+----------+---------+---------+----+-----------+
| Member   | Host    | Role    | TL | Lag in MB |
+----------+---------+---------+----+-----------+
| node1    | 10.0.1.10| Leader |  5 |           |
| node2    | 10.0.1.11| Replica |  5 |         0 |
| node3    | 10.0.1.12| Replica |  5 |         0 |
+----------+---------+---------+----+-----------+

# 2. Simulate primary crash (on node1)
sudo systemctl stop patroni
# Or more aggressive: sudo kill -9 $(pgrep -f patroni)

# 3. Monitor failover (from any node with patronictl)
watch -n 1 'patronictl -c /etc/patroni/patroni.yml list'

# 4. Verify new leader is elected (within 30-45 seconds)
# Expected: node2 or node3 promoted to Leader

# 5. Test write availability through HAProxy
PGPASSWORD=app_password psql -h haproxy-host -p 5000 -U appuser -d appdb \
  -c "INSERT INTO health_check (ts) VALUES (now()) RETURNING *;"

# 6. Restart the former primary
sudo systemctl start patroni
# Patroni will use pg_rewind to rejoin as a replica

# 7. Verify the former primary rejoins as replica
patronictlctl -c /etc/patroni/patroni.yml list

ਨੈੱਟਵਰਕ ਪਾਰਟੀਸ਼ਨ ਟੈਸਟਿੰਗ

# Simulate network partition on the primary using iptables
# Block all traffic to etcd from the primary
sudo iptables -A OUTPUT -d 10.0.2.10 -j DROP
sudo iptables -A OUTPUT -d 10.0.2.11 -j DROP
sudo iptables -A OUTPUT -d 10.0.2.12 -j DROP

# Expected behaviour:
# 1. Primary loses DCS access
# 2. Leader key TTL expires
# 3. Primary demotes itself (with watchdog, node may reboot)
# 4. Standby acquires leader lock and promotes
# 5. After clearing iptables rules, former primary rejoins as replica

# Clean up
sudo iptables -D OUTPUT -d 10.0.2.10 -j DROP
sudo iptables -D OUTPUT -d 10.0.2.11 -j DROP
sudo iptables -D OUTPUT -d 10.0.2.12 -j DROP

ਆਟੋਮੇਟਿਡ ਕੈਓਸ ਟੈਸਟਿੰਗ

# Run Toxiproxy alongside your Patroni cluster
# Create proxies for etcd and replication connections
toxiproxy-cli create etcd_proxy -l 0.0.0.0:12379 -u 10.0.2.10:2379
toxiproxy-cli create pg_repl_proxy -l 0.0.0.0:15432 -u 10.0.1.10:5432

# Add latency to etcd connections (simulates degraded network)
toxiproxy-cli toxic add etcd_proxy -t latency -a latency=500 -a jitter=200

# Add bandwidth limit to replication (simulates WAN replication)
toxiproxy-cli toxic add pg_repl_proxy -t bandwidth -a rate=1024

# Completely sever the connection (simulates network partition)
toxiproxy-cli toxic add etcd_proxy -t timeout -a timeout=0

# Monitor Patroni behaviour and verify correct failover
watch -n 2 'curl -s http://10.0.1.10:8008/patroni | python3 -m json.tool'

ਨਿਰੰਤਰ ਪ੍ਰਮਾਣਿਕਤਾ ਸਕ੍ਰਿਪਟ

#!/bin/bash
# continuous_ha_check.sh — Run during chaos tests to measure availability

HAPROXY_HOST="10.0.0.100"
WRITE_PORT=5000
READ_PORT=5001
DATABASE="appdb"
USER="appuser"
LOGFILE="/var/log/ha_test_$(date +%Y%m%d_%H%M%S).log"

write_count=0
write_fail=0
read_count=0
read_fail=0

while true; do
    ts=$(date '+%Y-%m-%d %H:%M:%S.%3N')

    # Test write path
    if PGPASSWORD=app_password psql -h $HAPROXY_HOST -p $WRITE_PORT \
       -U $USER -d $DATABASE -c "SELECT 1" &>/dev/null; then
        ((write_count++))
    else
        ((write_fail++))
        echo "$ts WRITE_FAIL total_fails=$write_fail" >> $LOGFILE
    fi

    # Test read path
    if PGPASSWORD=app_password psql -h $HAPROXY_HOST -p $READ_PORT \
       -U $USER -d $DATABASE -c "SELECT 1" &>/dev/null; then
        ((read_count++))
    else
        ((read_fail++))
        echo "$ts READ_FAIL total_fails=$read_fail" >> $LOGFILE
    fi

    total=$((write_count + write_fail))
    if (( total % 100 == 0 )); then
        write_avail=$(echo "scale=2; $write_count * 100 / $total" | bc)
        read_total=$((read_count + read_fail))
        read_avail=$(echo "scale=2; $read_count * 100 / $read_total" | bc)
        echo "$ts Writes: ${write_avail}% ($write_count/$total) Reads: ${read_avail}% ($read_count/$read_total)"
    fi

    sleep 0.5
done

ਐਡਵਾਂਸਡ: ਕੈਸਕੇਡਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਅਤੇ ਦੇਰੀ ਵਾਲੇ ਸਟੈਂਡਬਾਏ

ਵੱਡੇ ਕਲੱਸਟਰਾਂ ਲਈ, ਕੈਸਕੇਡਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਪ੍ਰਾਇਮਰੀ 'ਤੇ ਲੋਡ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ। ਪ੍ਰਾਇਮਰੀ ਤੋਂ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਨਕਲ ਕਰਨ ਵਾਲੇ ਸਾਰੇ ਸਟੈਂਡਬਾਏ ਦੀ ਬਜਾਏ, ਕੁਝ ਸਟੈਂਡਬਾਏ ਦੂਜੇ ਸਟੈਂਡਬਾਏ ਤੋਂ ਨਕਲ ਕਰਦੇ ਹਨ। ਇਹ ਇੱਕ ਟ੍ਰੀ ਟੋਪੋਲੋਜੀ ਬਣਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਪ੍ਰਾਇਮਰੀ ਦੋ ਸਟੈਂਡਬਾਏ ਫੀਡ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਸਟੈਂਡਬਾਏ ਵਾਧੂ ਡਾਊਨਸਟ੍ਰੀਮ ਸਟੈਂਡਬਾਏ ਫੀਡ ਕਰਦੇ ਹਨ।

# postgresql.auto.conf on a cascading standby
primary_conninfo = 'host=standby1-host port=5432 user=replicator application_name=cascade1'
primary_slot_name = 'cascade1_slot'

Aਦੇਰੀ ਵਾਲਾ ਸਟੈਂਡਬਾਏਜਾਣਬੁੱਝ ਕੇ ਸਮੇਂ ਦੀ ਦੇਰੀ ਨਾਲ WAL ਰਿਕਾਰਡਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ — ਆਮ ਤੌਰ 'ਤੇ 1-4 ਘੰਟੇ। ਇਹ ਤਰਕਪੂਰਨ ਗਲਤੀਆਂ (ਦੁਰਘਟਨਾਤਮਕ ਮਿਟਾਉਣ, ਖਰਾਬ ਮਾਈਗ੍ਰੇਸ਼ਨ) ਦੇ ਵਿਰੁੱਧ ਇੱਕ ਬਚਾਅ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਤੁਰੰਤ ਸਮਕਾਲੀ ਸਟੈਂਡਬਾਏ ਵਿੱਚ ਦੁਹਰਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਜੇਕਰ ਕੋਈ ਆਫ਼ਤ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਦੇਰੀ ਵਾਲੇ ਸਟੈਂਡਬਾਏ 'ਤੇ WAL ਰੀਪਲੇਅ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹੋ ਅਤੇ ਗਲਤੀ ਤੋਂ ਪਹਿਲਾਂ ਡਾਟਾ ਰਿਕਵਰ ਕਰ ਸਕਦੇ ਹੋ।

# postgresql.conf on delayed standby
recovery_min_apply_delay = '1h'

ਕਨੈਕਸ਼ਨ ਸਟ੍ਰਿੰਗ ਰਣਨੀਤੀਆਂ

ਇੱਕ Patroni-ਪ੍ਰਬੰਧਿਤ ਕਲੱਸਟਰ ਨਾਲ ਜੁੜਨ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਹਮੇਸ਼ਾ HAProxy ਰਾਹੀਂ ਕਨੈਕਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂtarget_session_attrsਨਾਲ PostgreSQL ਦੀ ਬਿਲਟ-ਇਨ ਮਲਟੀ-ਹੋਸਟ ਕਨੈਕਸ਼ਨ ਸਤਰ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਇਹ ਇੱਕ ਲੋਡ ਬੈਲੈਂਸਰ 'ਤੇ ਨਿਰਭਰ ਕੀਤੇ ਬਿਨਾਂ ਕਲਾਇੰਟ-ਸਾਈਡ ਫੇਲਓਵਰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

# Multi-host connection string with target_session_attrs
# The client tries each host in order and connects to the one matching the target attribute
postgresql://appuser:password@node1:5432,node2:5432,node3:5432/appdb?target_session_attrs=read-write&sslmode=require

# For read-only connections
postgresql://appuser:password@node1:5432,node2:5432,node3:5432/appdb?target_session_attrs=prefer-standby&sslmode=require

ਇਹ ਪਹੁੰਚ ਉਹਨਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਵਧੀਆ ਕੰਮ ਕਰਦੀ ਹੈ ਜਿਹਨਾਂ ਨੂੰ HAProxy VIP ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਲਈ ਆਸਾਨੀ ਨਾਲ ਮੁੜ ਸੰਰਚਿਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। PostgreSQL ਕਲਾਇੰਟ ਲਾਇਬ੍ਰੇਰੀ (libpq) ਫੇਲਓਵਰ ਨੂੰ ਪਾਰਦਰਸ਼ੀ ਢੰਗ ਨਾਲ ਹੈਂਡਲ ਕਰਦੀ ਹੈ।

ਸੁਰੱਖਿਆ ਸਖਤੀ

ਇੱਕ ਉਤਪਾਦਨ PostgreSQL HA ਕਲੱਸਟਰ ਨੂੰ ਆਵਾਜਾਈ ਵਿੱਚ ਅਤੇ ਆਰਾਮ ਵਿੱਚ ਏਨਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਮਜ਼ਬੂਤ ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਵਰਤੋਂ ਕਰੋ, ਅਤੇ ਨੈੱਟਵਰਕ ਐਕਸਪੋਜਰ ਨੂੰ ਸੀਮਤ ਕਰੋ।

# Enable TLS in postgresql.conf
ssl = on
ssl_cert_file = '/etc/postgresql/certs/server.crt'
ssl_key_file = '/etc/postgresql/certs/server.key'
ssl_ca_file = '/etc/postgresql/certs/ca.crt'
ssl_min_protocol_version = 'TLSv1.3'

# Require TLS for all connections in pg_hba.conf
hostssl replication replicator 10.0.0.0/16 scram-sha-256
hostssl all         all        10.0.0.0/16 scram-sha-256

# etcd TLS
# In Patroni config
etcd3:
  hosts:
    - 10.0.2.10:2379
    - 10.0.2.11:2379
    - 10.0.2.12:2379
  protocol: https
  cacert: /etc/patroni/certs/etcd-ca.crt
  cert: /etc/patroni/certs/etcd-client.crt
  key: /etc/patroni/certs/etcd-client.key

ਬੈਕਅੱਪ ਰਣਨੀਤੀ

ਪੈਟਰੋਨੀ ਕਲੱਸਟਰਾਂ ਲਈ ਇੱਕ ਵਿਆਪਕ ਬੈਕਅਪ ਰਣਨੀਤੀ ਵਿੱਚ ਲਗਾਤਾਰ WAL ਪੁਰਾਲੇਖ, ਨਿਯਮਤ ਪੂਰਾ ਬੈਕਅਪ, ਅਤੇ ਪੂਰੇ ਬੈਕਅਪ ਦੇ ਵਿਚਕਾਰ ਅੰਤਰ ਜਾਂ ਵਾਧੇ ਵਾਲੇ ਬੈਕਅਪ ਸ਼ਾਮਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। pgBackRest ਉਤਪਾਦਨ PostgreSQL ਬੈਕਅੱਪ ਪ੍ਰਬੰਧਨ ਲਈ ਸਿਫਾਰਿਸ਼ ਕੀਤਾ ਟੂਲ ਹੈ।

# Schedule backups via cron
# Full backup weekly (Sunday 2 AM)
0 2 * * 0 pgbackrest --stanza=pg-ha-cluster --type=full backup

# Differential backup daily (2 AM, Mon-Sat)
0 2 * * 1-6 pgbackrest --stanza=pg-ha-cluster --type=diff backup

# Verify backup integrity
pgbackrest --stanza=pg-ha-cluster --set=latest info

# Verify backup can be restored (dry run)
pgbackrest --stanza=pg-ha-cluster --set=latest verify

# List all backups
pgbackrest --stanza=pg-ha-cluster info
            full backup: 20260412-020000F
                timestamp: 2026-04-12 02:00:00 +0000
                wal start/stop: 000000050000000000000040 / 000000050000000000000042
                database size: 150GB, backup size: 150GB
                repository size: 45GB (compressed)
            diff backup: 20260412-020000F_20260413-020000D
                timestamp: 2026-04-13 02:00:00 +0000
                database size: 151GB, backup size: 2.1GB
                repository size: 650MB (compressed)

ਸੰਚਾਲਨ ਰਨਬੁੱਕ ਸੰਖੇਪ

ਪੈਟਰੋਨੀ ਕਲੱਸਟਰ ਚਲਾਉਣ ਵਾਲੀ ਹਰੇਕ ਟੀਮ ਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਦ੍ਰਿਸ਼ਾਂ ਨੂੰ ਕਵਰ ਕਰਨ ਵਾਲੀ ਰਨਬੁੱਕ ਬਣਾਈ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ। ਦਸਤਾਵੇਜ਼ੀ ਤੌਰ 'ਤੇ, ਟੈਸਟ ਕੀਤੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਤਣਾਅਪੂਰਨ ਆਊਟੇਜ ਨੂੰ ਰੁਟੀਨ ਓਪਰੇਸ਼ਨ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ।

# === Quick Reference Commands ===

# Cluster status
patronictlctl -c /etc/patroni/patroni.yml list
patronictlctl -c /etc/patroni/patroni.yml history

# Planned switchover
patronictlctl -c /etc/patroni/patroni.yml switchover --master node1 --candidate node2

# Restart PostgreSQL on a specific node (rolling restart)
patronictlctl -c /etc/patroni/patroni.yml restart pg-ha-cluster node2

# Reload PostgreSQL configuration without restart
patronictlctl -c /etc/patroni/patroni.yml reload pg-ha-cluster

# Pause automatic failover (during maintenance)
patronictlctl -c /etc/patroni/patroni.yml pause

# Resume automatic failover
patronictlctl -c /etc/patroni/patroni.yml resume

# Edit DCS configuration (applies to all nodes)
patronictlctl -c /etc/patroni/patroni.yml edit-config

# Reinitialise a failed replica
patronictlctl -c /etc/patroni/patroni.yml reinit pg-ha-cluster node3

# Check Patroni REST API directly
curl -s http://10.0.1.10:8008/patroni | python3 -m json.tool
curl -s http://10.0.1.10:8008/cluster | python3 -m json.tool

ਪ੍ਰਦਰਸ਼ਨ ਬੈਂਚਮਾਰਕਿੰਗ

ਉਤਪਾਦਨ 'ਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ, ਬੇਸਲਾਈਨ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਲਈ ਆਪਣੇ HA ਕਲੱਸਟਰ ਦਾ ਬੈਂਚਮਾਰਕ ਕਰੋ ਅਤੇ ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਵਰਕਲੋਡ ਲਈ ਸਮਕਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਲੇਟੈਂਸੀ ਸਵੀਕਾਰਯੋਗ ਹੈ।

# Benchmark with pgbench — initialise test data
pgbench -i -s 100 -h haproxy-host -p 5000 -U appuser appdb

# Run write-heavy benchmark (measures sync replication impact)
pgbench -h haproxy-host -p 5000 -U appuser -c 32 -j 8 -T 300 appdb
# Compare with async: temporarily set synchronous_commit = off

# Run read-only benchmark through read replica port
pgbench -h haproxy-host -p 5001 -U appuser -c 64 -j 16 -T 300 -S appdb

# Measure failover impact on transactions
# Run pgbench in background, then trigger a failover
pgbench -h haproxy-host -p 5000 -U appuser -c 8 -j 4 -T 600 appdb &
sleep 60 && patronictl switchover --master node1 --candidate node2 --force

ਸਿੱਟਾ

PostgreSQL ਮੂਲ ਉੱਚ ਉਪਲਬਧਤਾ ਇੱਕ ਸਿੰਗਲ-ਟੂਲ ਹੱਲ ਨਹੀਂ ਹੈ - ਇਹ ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ, ਵੰਡੀ ਸਹਿਮਤੀ, ਕੁਨੈਕਸ਼ਨ ਰੂਟਿੰਗ, ਕੁਨੈਕਸ਼ਨ ਪੂਲਿੰਗ, WAL ਆਰਕਾਈਵਿੰਗ, ਨਿਗਰਾਨੀ, ਅਤੇ ਸੰਚਾਲਨ ਅਨੁਸ਼ਾਸਨ ਦੀ ਇੱਕ ਏਕੀਕ੍ਰਿਤ ਪ੍ਰਣਾਲੀ ਹੈ। ਹਰੇਕ ਪਰਤ ਇੱਕ ਖਾਸ ਅਸਫਲਤਾ ਮੋਡ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਦੀ ਹੈ: ਸਟ੍ਰੀਮਿੰਗ ਰੀਪਲੀਕੇਸ਼ਨ ਡਾਟਾ ਰਿਡੰਡੈਂਸੀ ਨੂੰ ਹੈਂਡਲ ਕਰਦੀ ਹੈ, ਪੈਟਰੋਨੀ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ ਤਾਲਮੇਲ ਨੂੰ ਹੈਂਡਲ ਕਰਦੀ ਹੈ, etcd ਬਿਨਾਂ ਸਪਲਿਟ-ਬ੍ਰੇਨ ਦੇ ਲੀਡਰ ਚੋਣ ਲਈ ਲੋੜੀਂਦੀ ਵੰਡੀ ਸਹਿਮਤੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, HAProxy ਰੂਟ ਕੁਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸਹੀ ਲੀਡਰ ਲਈ, PgBouncer ਪੈਮਾਨੇ 'ਤੇ ਕਨੈਕਸ਼ਨ ਓਵਰਹੈੱਡ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ, ਅਤੇ WAL ਸਭ ਤੋਂ ਆਖਰੀ ਆਰਕਾਈਵਿੰਗ ਲਾਈਨ ਆਰਕਾਈਵਿੰਗ ਡਿਫੈਂਸ ਆਰਕਾਈਵਿੰਗ ਨਾਲ ਪੀ.ਜੀ. ਆਫ਼ਤ ਰਿਕਵਰੀ.

ਤੈਨਾਤੀ ਪੈਟਰਨ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਵੱਖੋ-ਵੱਖ ਹੁੰਦੇ ਹਨ — NLB ਅਤੇ Route53 ਦੇ ਨਾਲ AWS, ਉਪਲਬਧਤਾ ਜ਼ੋਨਾਂ ਦੇ ਨਾਲ Azure ਅਤੇ Azure ਲੋਡ ਬੈਲੈਂਸਰ, ਖੇਤਰੀ ਪ੍ਰਬੰਧਿਤ ਉਦਾਹਰਨ ਸਮੂਹਾਂ ਦੇ ਨਾਲ GCP, ਜਾਂ k3s, ਲੋਂਗਹੋਰਨ, ਅਤੇ Keepalived ਦੇ ਨਾਲ ਬੇਅਰ ਮੈਟਲ — ਪਰ ਕੋਰ ਆਰਕੀਟੈਕਚਰ ਇੱਕੋ ਜਿਹੇ ਹੀ ਰਹਿੰਦੇ ਹਨ। ਪੈਟਰੋਨੀ ਦੁਆਰਾ ਪ੍ਰਬੰਧਿਤ ਤਿੰਨ ਜਾਂ ਵੱਧ PostgreSQL ਨੋਡ, ਇੱਕ ਤਿੰਨ-ਨੋਡ etcd ਕਲੱਸਟਰ ਦੁਆਰਾ ਸਮਰਥਤ, ਇੱਕ ਲੋਡ ਬੈਲੈਂਸਰ ਦੁਆਰਾ ਫਰੰਟ ਕੀਤੇ ਗਏ ਜੋ ਪੈਟਰੋਨੀ ਦੇ ਸਿਹਤ ਜਾਂਚ ਅੰਤਮ ਬਿੰਦੂਆਂ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ।

ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਨਿਵੇਸ਼ ਜੋ ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ ਉਹ ਕੌਂਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਨਹੀਂ ਹੈ — ਇਹ ਟੈਸਟਿੰਗ ਵਿੱਚ ਹੈ। ਫੇਲਓਵਰ ਡ੍ਰਿਲਸ ਮਹੀਨਾਵਾਰ ਚਲਾਓ। ਨੈੱਟਵਰਕ ਭਾਗ ਇੰਜੈਕਟ ਕਰੋ। ਅਚਾਨਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਮਾਰੋ. ਰਿਕਵਰੀ ਸਮਾਂ ਅਤੇ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਨੂੰ ਮਾਪੋ। ਡੈਸ਼ਬੋਰਡ ਬਣਾਓ ਜੋ ਰਿਪਲੀਕੇਸ਼ਨ ਲੈਗ, WAL ਜਨਰੇਸ਼ਨ ਰੇਟ, ਕਨੈਕਸ਼ਨ ਪੂਲ ਸੰਤ੍ਰਿਪਤਾ, ਅਤੇ DCS ਹੈਲਥ ਨੂੰ ਰੀਅਲ ਟਾਈਮ ਵਿੱਚ ਦਿਖਾਉਂਦੇ ਹਨ। ਵਿਵਸਥਿਤ ਟੈਸਟਿੰਗ ਤੋਂ ਤੁਹਾਡੇ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਵਿਸ਼ਵਾਸ ਉਹ ਹੈ ਜੋ ਇੱਕ ਕਲੱਸਟਰ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ ਜੋ ਇਸਦੇ ਪਹਿਲੇ ਅਸਲ ਆਊਟੇਜ ਤੋਂ ਬਚਦਾ ਹੈ ਜੋ ਇੱਕ ਸਰਵਰ ਅਸਫਲਤਾ ਨੂੰ ਇੱਕ ਕਾਰੋਬਾਰੀ-ਪ੍ਰਭਾਵੀ ਘਟਨਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।

PostgreSQL ਤੁਹਾਨੂੰ ਸਾਰੇ ਰੀਪਲੀਕੇਸ਼ਨ ਪ੍ਰਾਈਮਿਟਿਵ ਦਿੰਦਾ ਹੈ। ਪਤ੍ਰੋਨਿ ਤੁਹਾਨੂੰ ਆਰਕੈਸਟਰਾ ਦਿੰਦਾ ਹੈ। etcd ਤੁਹਾਨੂੰ ਸਹਿਮਤੀ ਦਿੰਦਾ ਹੈ। ਤੁਹਾਡਾ ਕੰਮ ਉਹਨਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਜੋੜਨਾ, ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ ਕੰਮ ਦੇ ਬੋਝ ਲਈ ਟਿਊਨ ਕਰਨਾ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਲਗਾਤਾਰ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਹੈ। ਇਸ ਗਾਈਡ ਨੇ ਤੁਹਾਨੂੰ ਬਲੂਪ੍ਰਿੰਟ ਦਿੱਤੇ ਹਨ — ਹੁਣ ਭਰੋਸੇ ਨਾਲ ਬਣਾਓ, ਜਾਂਚ ਕਰੋ ਅਤੇ ਸੰਚਾਲਿਤ ਕਰੋ।