ਜ਼ਲੈਂਡੋ Postgres ਆਪਰੇਟਰ ਦੇ ਨਾਲ PostgreSQL ਉੱਚ ਉਪਲਬਧਤਾ: ਮਲਟੀ-ਕਲਾਊਡ Kubernetes ਡਿਪਲਾਇਮੈਂਟ ਗਾਈਡ

ਜਾਣ-ਪਛਾਣ: Kubernetes ਮਾਮਲਿਆਂ 'ਤੇ PostgreSQL ਉੱਚ ਉਪਲਬਧਤਾ

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

Zalando Postgres ਆਪਰੇਟਰਇੱਕ ਓਪਨ-ਸਰੋਤ, ਲੜਾਈ-ਪਰੀਖਣ ਵਾਲਾ ਹੱਲ ਹੈ ਜੋ Zalando—ਯੂਰਪ ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਔਨਲਾਈਨ ਫੈਸ਼ਨ ਰਿਟੇਲਰ — ਉਤਪਾਦਨ ਵਿੱਚ ਸੈਂਕੜੇ PostgreSQL ਕਲੱਸਟਰਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਇਹ ਸਹਿਮਤੀ-ਆਧਾਰਿਤ ਨੇਤਾ ਚੋਣ ਲਈPatroni, PostgreSQL ਕੰਟੇਨਰ ਚਿੱਤਰ ਦੇ ਤੌਰ 'ਤੇSpilo, ਲਗਾਤਾਰ ਆਰਕਾਈਵਿੰਗ ਅਤੇ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਲਈWAL-G, ਅਤੇ ਕਨੈਕਸ਼ਨ pooling ਲਈPgBouncerਦਾ ਲਾਭ ਉਠਾਉਂਦਾ ਹੈ। ਇਕੱਠੇ ਮਿਲ ਕੇ, ਇਹ ਕੰਪੋਨੈਂਟ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਵੈਚਲਿਤ, ਸਵੈ-ਇਲਾਜ ਕਰਨ ਵਾਲੀ PostgreSQL ਤੈਨਾਤੀ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ ਜੋ ਕਿਸੇ ਵੀ Kubernetes ਵੰਡ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ — AWS EKS, Azure AKS, ਅਤੇ Google GKE ਵਰਗੀਆਂ ਪ੍ਰਬੰਧਿਤ ਕਲਾਉਡ ਸੇਵਾਵਾਂ ਤੋਂ ਲੈ ਕੇ ਰੈਂਚਰ ਨਾਲ k3s ਚਲਾ ਰਹੇ ਬੇਅਰ-ਮੈਟਲ ਕਲੱਸਟਰਾਂ ਤੱਕ।

ਇਸ ਵਿਆਪਕ ਗਾਈਡ ਵਿੱਚ, ਅਸੀਂ Zalando Postgres ਆਪਰੇਟਰ ਦੇ ਆਰਕੀਟੈਕਚਰ ਦੀ ਪੜਚੋਲ ਕਰਾਂਗੇ, ਮਲਟੀਪਲ Kubernetes ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਸਥਾਪਨਾ ਅਤੇ ਸੰਰਚਨਾ ਦੁਆਰਾ ਚੱਲਾਂਗੇ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ, ਬੈਕਅੱਪ, ਤਬਾਹੀ ਰਿਕਵਰੀ, ਨਿਗਰਾਨੀ, ਅਤੇ ਉਤਪਾਦਨ ਟਿਊਨਿੰਗ ਵਿੱਚ ਡੂੰਘੀ ਡੁਬਕੀ ਲਗਾਵਾਂਗੇ। ਅੰਤ ਤੱਕ, ਤੁਹਾਡੇ ਕੋਲ ਕਿਸੇ ਵੀ Kubernetes ਬੁਨਿਆਦੀ ਢਾਂਚੇ 'ਤੇ ਉਤਪਾਦਨ-ਗ੍ਰੇਡ PostgreSQL HA ਕਲੱਸਟਰਾਂ ਨੂੰ ਤੈਨਾਤ ਅਤੇ ਸੰਚਾਲਿਤ ਕਰਨ ਦਾ ਗਿਆਨ ਹੋਵੇਗਾ।

ਜ਼ਲੈਂਡੋ Postgres ਆਪਰੇਟਰ ਆਰਕੀਟੈਕਚਰ

ਤੈਨਾਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਸਮਝਣਾ ਜ਼ਰੂਰੀ ਹੈ। ਜ਼ਲੈਂਡੋ Postgres ਆਪਰੇਟਰ Kubernetes ਆਪਰੇਟਰ ਪੈਟਰਨ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ: ਇਹpostgresqlਕਿਸਮ ਦੀਆਂ ਕਸਟਮ ਰਿਸੋਰਸ ਪਰਿਭਾਸ਼ਾਵਾਂ (CRDs) ਲਈ ਦੇਖਦਾ ਹੈ ਅਤੇ ਅਸਲ Kubernetes ਸਰੋਤਾਂ ਵਿੱਚ ਲੋੜੀਂਦੀ ਸਥਿਤੀ ਨੂੰ ਮਿਲਾ ਲੈਂਦਾ ਹੈ। ਇਹ ਹੈ ਕਿ ਹਿੱਸੇ ਕਿਵੇਂ ਇਕੱਠੇ ਫਿੱਟ ਹੁੰਦੇ ਹਨ:

ਸਪਾਈਲੋ: PostgreSQL ਕੰਟੇਨਰ ਚਿੱਤਰ

SpiloZalando ਦਾ Docker ਚਿੱਤਰ ਹੈ ਜੋ PostgreSQL ਨੂੰ Patroni, WAL-G, ਅਤੇ ਜ਼ਰੂਰੀ ਐਕਸਟੈਂਸ਼ਨਾਂ ਨਾਲ ਬੰਡਲ ਕਰਦਾ ਹੈ। ਸਟੇਟਫੁੱਲਸੈੱਟ ਵਿੱਚ ਹਰੇਕ ਪੌਡ ਇੱਕ ਸਪਾਈਲੋ ਕੰਟੇਨਰ ਚਲਾਉਂਦਾ ਹੈ। ਸਪਾਈਲੋ ਹੈਂਡਲ:

• PostgreSQL ਸਰਵਰ— ਡਾਟਾਬੇਸ ਇੰਜਣ ਖੁਦ, ਸੰਸਕਰਣ 13 ਤੋਂ 16
ਤੱਕ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ
• Patroni— HA ਏਜੰਟ ਜੋ ਲੀਡਰ ਚੋਣ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ, ਅਤੇ ਫੇਲਓਵਰ
ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ
• WAL-G— ਲਗਾਤਾਰ WAL ਆਰਕਾਈਵਿੰਗ ਅਤੇ ਬੇਸ ਬੈਕਅੱਪ ਟੂਲ
• pg_cron, pg_stat_statements, PostGIS— ਆਮ ਤੌਰ 'ਤੇ ਲੋੜੀਂਦੇ ਐਕਸਟੈਂਸ਼ਨਾਂ ਪਹਿਲਾਂ ਤੋਂ ਸਥਾਪਿਤ

Patroni: ਲੀਡਰ ਇਲੈਕਸ਼ਨ ਅਤੇ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ

ਪੈਟਰੋਨੀ HA ਵਿਧੀ ਦਾ ਦਿਲ ਹੈ। ਇਹ ਕਲੱਸਟਰ ਸਥਿਤੀ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਅਤੇ ਲੀਡਰ ਚੋਣ ਕਰਨ ਲਈ ਇੱਕ ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਕੌਂਫਿਗਰੇਸ਼ਨ ਸਟੋਰ (DCS) ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਜ਼ਲੈਂਡੋ ਆਪਰੇਟਰ ਸੰਦਰਭ ਵਿੱਚ, ਪੈਟਰੋਨੀ ਇੱਕ ਬਾਹਰੀ etcd ਜਾਂ ZooKeeper ਕਲੱਸਟਰ ਦੀ ਲੋੜ ਨੂੰ ਖਤਮ ਕਰਦੇ ਹੋਏ, DCS (ਐਂਡਪੁਆਇੰਟ ਜਾਂ ਕੌਂਫਿਗਮੈਪਸ ਦੁਆਰਾ) ਦੇ ਤੌਰ ਤੇKubernetes APIਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

ਇੱਥੇ Patroni ਦੀ ਫੇਲਓਵਰ ਪ੍ਰਕਿਰਿਆ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ:

1. ਸਿਹਤ ਜਾਂਚਾਂ— ਹਰੇਕ ਪੈਟਰੋਨੀ ਏਜੰਟ ਆਪਣੀ ਸਥਾਨਕ PostgreSQL ਸਥਿਤੀ ਦੀ ਲਗਾਤਾਰ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ ਅਤੇ DCS ਨੂੰ ਸਿਹਤ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ।
2. ਲੀਡਰ ਲਾਕ— ਪ੍ਰਾਇਮਰੀ ਵਿੱਚ DCS (ਇੱਕ Kubernetes ਐਂਡਪੁਆਇੰਟ ਆਬਜੈਕਟ) ਵਿੱਚ ਇੱਕ ਲੀਡਰ ਲਾਕ ਹੁੰਦਾ ਹੈ। ਲਾਕ ਵਿੱਚ ਇੱਕ TTL (ਪੂਰਵ-ਨਿਰਧਾਰਤ 30 ਸਕਿੰਟ) ਹੈ।
3. ਅਸਫਲਤਾ ਖੋਜ— ਜੇਕਰ ਪ੍ਰਾਇਮਰੀ TTL ਦੇ ਅੰਦਰ ਆਪਣੇ ਲੌਕ ਨੂੰ ਰੀਨਿਊ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਪ੍ਰਤੀਰੂਪ ਗੈਰਹਾਜ਼ਰੀ ਦਾ ਪਤਾ ਲਗਾਉਂਦੇ ਹਨ।
4. ਚੋਣ— ਯੋਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਲੀਡਰ ਲਾਕ ਲਈ ਮੁਕਾਬਲਾ ਕਰਦੀਆਂ ਹਨ। ਸਭ ਤੋਂ ਘੱਟ ਰੀਪਲੀਕੇਸ਼ਨ ਲੈਗ ਵਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਜਿੱਤ ਜਾਂਦੀ ਹੈ।
5. ਪ੍ਰੋਮੋਸ਼ਨ— ਜੇਤੂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਆਪਣੇ ਆਪ ਨੂੰ ਪ੍ਰਾਇਮਰੀ ਵਿੱਚ ਅੱਗੇ ਵਧਾਉਂਦੀ ਹੈ, DCS ਨੂੰ ਅੱਪਡੇਟ ਕਰਦੀ ਹੈ, ਅਤੇ Kubernetesmasterਸਰਵਿਸ ਐਂਡਪੁਆਇੰਟ ਆਪਣੇ ਆਪ ਅੱਪਡੇਟ ਹੋ ਜਾਂਦੀ ਹੈ।
6. ਫੈਂਸਿੰਗ— ਸਪਲਿਟ-ਬ੍ਰੇਨ ਨੂੰ ਰੋਕਣ ਲਈ ਪੁਰਾਣੀ ਪ੍ਰਾਇਮਰੀ ਨੂੰ ਫੈਂਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ ਜਾਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਵਿੱਚ ਘਟਾਇਆ ਜਾਂਦਾ ਹੈ)।

ਇਹ ਪੂਰੀ ਫੇਲਓਵਰ ਪ੍ਰਕਿਰਿਆ ਆਮ ਤੌਰ 'ਤੇ15-30 ਸਕਿੰਟਾਂ ਵਿੱਚ ਪੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਤੁਹਾਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਘੱਟ ਤੋਂ ਘੱਟ ਡਾਊਨਟਾਈਮ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ।

WAL-G: ਲਗਾਤਾਰ ਪੁਰਾਲੇਖ ਅਤੇ ਬੈਕਅੱਪ

WAL-G PostgreSQL ਲਈ ਅਗਲੀ ਪੀੜ੍ਹੀ ਦਾ ਆਰਕਾਈਵਲ ਟੂਲ ਹੈ ਜੋ S3, Google ਕਲਾਊਡ ਸਟੋਰੇਜ (GCS), ਅਤੇ Azure ਬਲੌਬ ਸਟੋਰੇਜ ਲਈ ਬੈਕਅੱਪ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਇਹ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ:

• ਬੇਸ ਬੈਕਅੱਪ—pg_basebackup
ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਪੂਰਾ ਭੌਤਿਕ ਬੈਕਅੱਪ
• WAL ਆਰਕਾਈਵਿੰਗ— ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ
ਲਈ ਨਿਰੰਤਰ ਲਿਖਣ-ਅੱਗੇ ਲੌਗ ਸ਼ਿਪਿੰਗ
• ਡੈਲਟਾ ਬੈਕਅੱਪ— ਵਾਧੇ ਵਾਲੇ ਬੈਕਅੱਪ ਜੋ ਸਿਰਫ਼ ਬਦਲੇ ਹੋਏ ਪੰਨਿਆਂ ਨੂੰ ਸਟੋਰ ਕਰਦੇ ਹਨ
• ਐਨਕ੍ਰਿਪਸ਼ਨ— ਬਾਕੀ
'ਤੇ ਬੈਕਅੱਪ ਦੀ AES-256 ਇਨਕ੍ਰਿਪਸ਼ਨ
• ਕੰਪਰੈਸ਼ਨ— ਘੱਟ ਸਟੋਰੇਜ ਲਾਗਤਾਂ ਲਈ LZ4 ਜਾਂ ZSTD ਕੰਪਰੈਸ਼ਨ

Kubernetes ਸਰੋਤ ਲੜੀ

ਜਦੋਂ ਤੁਸੀਂ ਇੱਕpostgresqlਕਸਟਮ ਸਰੋਤ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਆਪਰੇਟਰ ਕਲੱਸਟਰ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ Kubernetes ਸਰੋਤਾਂ ਦਾ ਇੱਕ ਵਿਆਪਕ ਸੈੱਟ ਬਣਾਉਂਦਾ ਹੈ। ਸਮੱਸਿਆ ਨਿਪਟਾਰਾ ਅਤੇ ਨਿਗਰਾਨੀ ਲਈ ਇਸ ਲੜੀ ਨੂੰ ਸਮਝਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ:

ਸਰੋਤ

• StatefulSet— ਸਥਿਰ ਨੈੱਟਵਰਕ ਪਛਾਣਾਂ ਅਤੇ ਆਰਡਰ ਕੀਤੇ ਤੈਨਾਤੀ
ਨਾਲ PostgreSQL ਪੌਡਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ
• ਸੇਵਾਵਾਂ— ਦੋ ਕਲੱਸਟਰਆਈਪੀ ਸੇਵਾਵਾਂ: ਪ੍ਰਾਇਮਰੀ ਲਈ<cluster-name>ਅਤੇ ਰੀਡ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਲਈ<cluster-name>-repl
• ਅੰਤਮ ਬਿੰਦੂ— Patroni ਸਹਿਜ ਫੇਲਓਵਰ
ਲਈ ਮੌਜੂਦਾ ਲੀਡਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਲਈ ਅੰਤਮ ਬਿੰਦੂਆਂ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ
• PodDisruption Budgets (PDB)— ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਸਵੈ-ਇੱਛਤ ਰੁਕਾਵਟਾਂ
ਦੌਰਾਨ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਉਦਾਹਰਣ ਉਪਲਬਧ ਰਹੇ।
• ਭੇਦ— PostgreSQL ਸੁਪਰਯੂਜ਼ਰ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਮਾਣ ਪੱਤਰ Kubernetes ਸੀਕਰੇਟਸ
ਵਜੋਂ ਸਟੋਰ ਕੀਤੇ ਗਏ ਹਨ
• ਪਰਸਿਸਟੈਂਟ ਵਾਲਿਊਮ ਦਾਅਵੇ (PVCs)— PostgreSQL ਲਈ ਇੱਕ PVC ਪ੍ਰਤੀ ਪੌਡ ਡਾਟਾ ਸਟੋਰੇਜ
• PgBouncer ਤੈਨਾਤੀ— ਵਿਕਲਪਿਕ ਕਨੈਕਸ਼ਨ ਪੂਲਰ ਨੂੰ ਆਪਣੀ ਖੁਦ ਦੀ ਸੇਵਾ
ਨਾਲ ਇੱਕ ਵੱਖਰੀ ਤੈਨਾਤੀ ਵਜੋਂ ਤੈਨਾਤ ਕੀਤਾ ਗਿਆ ਹੈ

ਕਈ Kubernetes ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ

ਸਥਾਪਨਾ

ਪੂਰਵ-ਲੋੜਾਂ

Zalando Postgres ਆਪਰੇਟਰ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਹੈ:

• ਇੱਕ ਚੱਲ ਰਿਹਾ Kubernetes ਕਲੱਸਟਰ (v1.25+)
• kubectlਕਲੱਸਟਰ ਐਡਮਿਨ ਐਕਸੈਸ
ਨਾਲ ਸੰਰਚਿਤ
• helmv3
ਸਥਾਪਤ ਕੀਤਾ
• ਇੱਕ ਪੂਰਵ-ਨਿਰਧਾਰਤ ਸਟੋਰੇਜ ਕਲਾਸ
ਸੰਰਚਿਤ ਹੈ

ਓਪਰੇਟਰ ਸਥਾਪਨਾ

ਸਿਫ਼ਾਰਿਸ਼ ਕੀਤੀ ਇੰਸਟਾਲੇਸ਼ਨ ਵਿਧੀ Helm ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਇਹ ਸਾਰੇ Kubernetes ਪਲੇਟਫਾਰਮਾਂ ਵਿੱਚ ਲਗਾਤਾਰ ਕੰਮ ਕਰਦਾ ਹੈ:

# Add the Zalando Postgres Operator Helm repository
helm repo add postgres-operator-charts https://opensource.zalando.com/postgres-operator/charts/postgres-operator
helm repo add postgres-operator-ui-charts https://opensource.zalando.com/postgres-operator/charts/postgres-operator-ui
helm repo update

# Create a dedicated namespace
kubectl create namespace postgres-operator

# Install the operator with custom values
helm install postgres-operator postgres-operator-charts/postgres-operator \
  --namespace postgres-operator \
  --set configKubernetes.enable_pod_antiaffinity=true \
  --set configKubernetes.pod_environment_configmap=postgres-pod-config \
  --set configAwsOrGcp.aws_region=us-east-1 \
  --set configLoadBalancer.db_hosted_zone=db.example.com \
  --set configConnectionPooler.connection_pooler_default_cpu_request=500m \
  --set configConnectionPooler.connection_pooler_default_memory_request=100Mi

# Optionally install the operator UI for visual management
helm install postgres-operator-ui postgres-operator-ui-charts/postgres-operator-ui \
  --namespace postgres-operator

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਓਪਰੇਟਰ ਚੱਲ ਰਿਹਾ ਹੈ:

kubectl get pods -n postgres-operator
# Expected output:
# NAME                                 READY   STATUS    RESTARTS   AGE
# postgres-operator-7f8b9c6d4-x2k9j   1/1     Running   0          2m

AWS EKS ਤੈਨਾਤੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ

Amazon EKS ਨੂੰ ਅਨੁਕੂਲ PostgreSQL ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਖਾਸ ਸੰਰਚਨਾ ਦੀ ਲੋੜ ਹੈ:

# EKS-specific Helm values (eks-values.yaml)
configAwsOrGcp:
  aws_region: us-east-1
  enable_ebs_gp3_migration: true
  additional_secret_mount: "aws-iam-token"

configKubernetes:
  enable_pod_antiaffinity: true
  pod_environment_configmap: "postgres-pod-config"
  spilo_privileged: false
  storage_resize_mode: pvc

# Use EBS gp3 StorageClass for better performance
# Create the StorageClass first:
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-gp3-postgres
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "6000"
  throughput: "400"
  encrypted: "true"
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

, ਸੇਵਾ ਖਾਤਿਆਂ (IRSA) ਲਈ IAM ਰੋਲ ਕੌਂਫਿਗਰ ਕਰੋ:

# Create IAM policy for WAL-G S3 access
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:ListBucket",
        "s3:DeleteObject",
        "s3:GetBucketLocation"
      ],
      "Resource": [
        "arn:aws:s3:::my-pg-backups",
        "arn:aws:s3:::my-pg-backups/*"
      ]
    }
  ]
}

Azure AKS ਤੈਨਾਤੀ

Azure AKS ਨਿਰੰਤਰ ਸਟੋਰੇਜ ਲਈ Azure ਡਿਸਕ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਅਤੇ ਬੈਕਅੱਪ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਪ੍ਰਬੰਧਿਤ ਪਛਾਣ:

# AKS-specific StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-postgres
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_LRS
  cachingMode: ReadOnly
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
---
# WAL-G backup to Azure Blob Storage environment variables
apiVersion: v1
kind: ConfigMap
metadata:
  name: postgres-pod-config
  namespace: default
data:
  AZURE_STORAGE_ACCOUNT: "pgbackupsstorage"
  AZURE_STORAGE_ACCESS_KEY: "" # Use Managed Identity instead
  WALG_AZ_PREFIX: "azure://pg-wal-backups/$(SCOPE)"
  USE_WALG_BACKUP: "true"
  USE_WALG_RESTORE: "true"
  BACKUP_SCHEDULE: "0 2 * * *"
  BACKUP_NUM_TO_RETAIN: "7"

Google GKE ਤੈਨਾਤੀ

Google Kubernetes ਇੰਜਣ GCS ਬੈਕਅੱਪ ਪਹੁੰਚ ਲਈ ਪਰਸਿਸਟੈਂਟ ਡਿਸਕ ਅਤੇ ਵਰਕਲੋਡ ਪਛਾਣ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ:

# GKE StorageClass for SSD Persistent Disks
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ssd-postgres
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-ssd
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
---
# GCS backup configuration
apiVersion: v1
kind: ConfigMap
metadata:
  name: postgres-pod-config
  namespace: default
data:
  WALG_GS_PREFIX: "gs://my-pg-backups/$(SCOPE)"
  USE_WALG_BACKUP: "true"
  USE_WALG_RESTORE: "true"
  GOOGLE_APPLICATION_CREDENTIALS: "/var/secrets/google/key.json"
  BACKUP_SCHEDULE: "0 2 * * *"
  BACKUP_NUM_TO_RETAIN: "7"

ਬੇਅਰ ਮੈਟਲ k3s/ਰੈਂਚਰ

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

# Install k3s on all nodes
# Master node:
curl -sfL https://get.k3s.io | sh -s - server \
  --cluster-init \
  --disable traefik \
  --write-kubeconfig-mode 644

# Worker nodes:
curl -sfL https://get.k3s.io | sh -s - agent \
  --server https://master-ip:6443 \
  --token $(cat /var/lib/rancher/k3s/server/node-token)

# Install Longhorn for persistent storage
helm repo add longhorn https://charts.longhorn.io
helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace \
  --set defaultSettings.defaultReplicaCount=3 \
  --set defaultSettings.defaultDataPath=/mnt/longhorn

# Install MetalLB for LoadBalancer services
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.5/config/manifests/metallb-native.yaml

# Configure MetalLB IP pool
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: postgres-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.1.200-192.168.1.210

PostgreSQL ਕਲੱਸਟਰ CRD ਨਿਰਧਾਰਨ

ਤੈਨਾਤ ਕਰਨ ਦਾ ਮੂਲ a ਜ਼ਲੈਂਡੋ ਆਪਰੇਟਰ ਵਾਲਾ PostgreSQL ਕਲੱਸਟਰpostgresqlਕਸਟਮ ਸਰੋਤ ਹੈ। ਇਹ YAML ਮੈਨੀਫੈਸਟ ਤੁਹਾਡੇ ਕਲੱਸਟਰ ਦੀ ਲੋੜੀਂਦੀ ਸਥਿਤੀ ਦਾ ਐਲਾਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਓਪਰੇਟਰ ਇਸਨੂੰ ਅਸਲੀਅਤ ਵਿੱਚ ਮਿਲਾ ਦਿੰਦਾ ਹੈ। ਹੇਠਾਂ ਇੱਕ ਵਿਆਪਕ, ਉਤਪਾਦਨ ਲਈ ਤਿਆਰ CRD ਨਿਰਧਾਰਨ ਹੈ:

apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
  name: pg-production-cluster
  namespace: databases
  labels:
    team: platform
    environment: production
spec:
  teamId: "platform"
  volume:
    size: 100Gi
    storageClass: ebs-gp3-postgres
  numberOfInstances: 3
  enableConnectionPooler: true
  enableReplicaConnectionPooler: true
  connectionPooler:
    numberOfInstances: 2
    mode: transaction
    schema: pooler
    user: pooler
    resources:
      requests:
        cpu: 500m
        memory: 100Mi
      limits:
        cpu: "1"
        memory: 256Mi
  users:
    app_user:
    - superuser
    - createdb
    readonly_user: []
  databases:
    app_database: app_user
  postgresql:
    version: "16"
    parameters:
      shared_buffers: "2GB"
      max_connections: "200"
      work_mem: "64MB"
      maintenance_work_mem: "512MB"
      effective_cache_size: "6GB"
      random_page_cost: "1.1"
      effective_io_concurrency: "200"
      wal_buffers: "64MB"
      max_wal_size: "4GB"
      min_wal_size: "1GB"
      checkpoint_completion_target: "0.9"
      default_statistics_target: "100"
      log_statement: "ddl"
      log_min_duration_statement: "1000"
      idle_in_transaction_session_timeout: "600000"
      lock_timeout: "30000"
      statement_timeout: "60000"
  patroni:
    initdb:
      encoding: "UTF8"
      locale: "en_US.UTF-8"
      data-checksums: "true"
    pg_hba:
    - hostssl all all 0.0.0.0/0 md5
    - host    all all 0.0.0.0/0 md5
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    synchronous_mode: false
    synchronous_mode_strict: false
    maximum_lag_on_failover: 33554432
  resources:
    requests:
      cpu: "2"
      memory: 8Gi
    limits:
      cpu: "4"
      memory: 16Gi
  podAnnotations:
    prometheus.io/scrape: "true"
    prometheus.io/port: "9187"
  tolerations:
  - key: "database"
    operator: "Equal"
    value: "postgres"
    effect: "NoSchedule"
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: workload-type
          operator: In
          values:
          - database
  enableShmVolume: true
  spiloRunAsUser: 101
  spiloRunAsGroup: 103
  spiloFSGroup: 103

ਕੁੰਜੀ CRD ਫੀਲਡ

• numberOfInstances— ਪੌਡਾਂ ਦੀ ਕੁੱਲ ਸੰਖਿਆ। ਆਪਰੇਟਰ ਆਪਣੇ ਆਪ ਹੀ ਇੱਕ ਨੂੰ ਪ੍ਰਾਇਮਰੀ ਅਤੇ ਬਾਕੀ ਨੂੰ ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਵਜੋਂ ਮਨੋਨੀਤ ਕਰਦਾ ਹੈ।
• ਕਨੈਕਸ਼ਨਪੂਲਰ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ— ਪ੍ਰਾਇਮਰੀ ਸੇਵਾ ਲਈ PgBouncer ਸਾਈਡਕਾਰ ਤੈਨਾਤ ਕਰਦਾ ਹੈ, ਕਨੈਕਸ਼ਨ ਓਵਰਹੈੱਡ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।
• enableReplicaConnectionPooler— ਰੀਪਲੀਕਾ ਸੇਵਾ ਲਈ ਇੱਕ ਵੱਖਰਾ PgBouncer ਤੈਨਾਤ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਰੀਡ-ਹੈਵੀ ਵਰਕਲੋਡ ਲਈ ਜ਼ਰੂਰੀ ਹੈ।
• postgresql.parameters— ਡਾਇਰੈਕਟ PostgreSQL ਕੌਂਫਿਗਰੇਸ਼ਨ ਪੈਰਾਮੀਟਰpostgresql.confਨੂੰ ਪਾਸ ਕੀਤੇ ਗਏ।
• patroni— TTL, ਲੂਪ ਉਡੀਕ, ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦਾ ਸਮਾਂ ਸਮਾਪਤ, ਅਤੇ ਸਮਕਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਮੋਡ ਸਮੇਤ Patroni ਵਿਵਹਾਰ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਦਾ ਹੈ।
• volume.storageClass— ਪਲੇਟਫਾਰਮ-ਵਿਸ਼ੇਸ਼ ਸਟੋਰੇਜ ਕਲਾਸ ਦੇ ਨਕਸ਼ੇ (AWS 'ਤੇ EBS gp3, Azure 'ਤੇ ਪ੍ਰੀਮੀਅਮ SSD, GCP 'ਤੇ SSD PD, k3s 'ਤੇ Longhorn)।
• enableShmVolume— PostgreSQL ਸਾਂਝੀ ਕੀਤੀ ਮੈਮੋਰੀ ਲਈ/dev/shm'ਤੇ ਇੱਕtmpfsਨੂੰ ਮਾਊਂਟ ਕਰਦਾ ਹੈ, ਕਾਰਗੁਜ਼ਾਰੀ ਲਈ ਮਹੱਤਵਪੂਰਨ।

ਕਨੈਕਸ਼ਨ ਪੂਲਿੰਗ

PostgreSQL ਦਾ ਪ੍ਰਕਿਰਿਆ-ਪ੍ਰਤੀ-ਕੁਨੈਕਸ਼ਨ ਮਾਡਲ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਕਲਾਇੰਟ ਕੁਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸੰਭਾਲਣਾ ਮਹਿੰਗਾ ਬਣਾਉਂਦਾ ਹੈ। ਹਰੇਕ ਕੁਨੈਕਸ਼ਨ ਲਗਭਗ 10MB RAM ਦੀ ਖਪਤ ਕਰਦਾ ਹੈ। PgBouncer ਅਸਲ PostgreSQL ਕਨੈਕਸ਼ਨਾਂ ਦੇ ਇੱਕ ਛੋਟੇ ਪੂਲ ਉੱਤੇ ਹਜ਼ਾਰਾਂ ਕਲਾਇੰਟ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਮਲਟੀਪਲੈਕਸ ਕਰਕੇ ਇਸਦਾ ਹੱਲ ਕਰਦਾ ਹੈ।

ਜ਼ਲੈਂਡੋ ਆਪਰੇਟਰ ਨੇਟਿਵ ਤੌਰ 'ਤੇ PgBouncer ਤੈਨਾਤੀ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ CRD ਵਿੱਚenableConnectionPooler: trueਸੈਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਓਪਰੇਟਰ ਬਣਾਉਂਦਾ ਹੈ:

• ਸੰਰਚਨਾਯੋਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਗਿਣਤੀ ਦੇ ਨਾਲ ਇੱਕ PgBouncer ਤੈਨਾਤੀ
• ਪੂਲਡ ਕਨੈਕਸ਼ਨਾਂ ਲਈ ਇੱਕ ਸਮਰਪਿਤ ਸੇਵਾ (<cluster-name>-pooler)
PostgreSQLਨਾਲ
• ਆਟੋਮੈਟਿਕ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ

PgBouncer ਕੌਂਫਿਗਰੇਸ਼ਨ ਮੋਡ

# PgBouncer connection pooler modes:
#
# transaction (recommended for most workloads)
#   - Connection returned to pool after each transaction
#   - Best balance of efficiency and compatibility
#   - Cannot use session-level features (prepared statements, temp tables)
#
# session
#   - Connection held for entire client session
#   - Full PostgreSQL compatibility
#   - Lower pooling efficiency
#
# statement
#   - Connection returned after each statement
#   - Most efficient but most restrictive
#   - Only works with autocommit queries

# Custom PgBouncer configuration via operator
spec:
  connectionPooler:
    numberOfInstances: 3
    mode: transaction
    schema: pooler
    user: pooler
    defaultPoolSize: 25
    maxDBConnections: 100
    resources:
      requests:
        cpu: 250m
        memory: 128Mi
      limits:
        cpu: "1"
        memory: 256Mi

ਉਹਨਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਜਿਹਨਾਂ ਨੂੰ ਤਿਆਰ ਸਟੇਟਮੈਂਟਾਂ ਜਾਂ ਸੈਸ਼ਨ-ਪੱਧਰ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, PgBouncer ਨੂੰ ਬਾਈਪਾਸ ਕਰਦੇ ਹੋਏ PostgreSQL ਸੇਵਾਵਾਂ ਨਾਲ ਸਿੱਧਾ ਜੁੜੋ, ਜਾਂ ਘੱਟ ਕੁਨੈਕਸ਼ਨ ਕੁਸ਼ਲਤਾ ਦੇ ਵਪਾਰ ਦੇ ਨਾਲsessionਪੂਲਿੰਗ ਮੋਡ ਦੀ ਵਰਤੋਂ ਕਰੋ।

ਮਲਟੀ-ਰੀਜਨ PostgreSQL ਪ੍ਰਤੀਕ੍ਰਿਤੀ

ਗਲੋਬਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਈ ਭੂਗੋਲਿਕ ਸਥਾਨਾਂ ਤੋਂ ਘੱਟ-ਲੇਟੈਂਸੀ ਰੀਡ ਜਾਂ ਖੇਤਰਾਂ ਵਿੱਚ ਆਫ਼ਤ ਰਿਕਵਰੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਬਹੁ-ਖੇਤਰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਜ਼ਰੂਰੀ ਹੈ। ਜ਼ਲੈਂਡੋ ਆਪਰੇਟਰ ਸਟੈਂਡਬਾਏ ਕਲੱਸਟਰਾਂ ਦੁਆਰਾ ਇਸਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਜੋ ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਜਾਂ WAL-G ਪੁਰਾਲੇਖਾਂ ਦੁਆਰਾ ਪ੍ਰਾਇਮਰੀ ਕਲੱਸਟਰ ਤੋਂ ਨਕਲ ਕਰਦੇ ਹਨ।

ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੰਰਚਨਾ

PostgreSQL ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ Zalando ਆਪਰੇਟਰ ਵਿੱਚ HA ਦੀ ਬੁਨਿਆਦ ਹੈ। ਇਹ ਰਾਈਟ-ਅਹੇਡ ਲੌਗ (WAL) ਰਿਕਾਰਡਾਂ ਨੂੰ ਪ੍ਰਾਇਮਰੀ ਤੋਂ ਰਿਪਲੀਕਾਸ ਨੂੰ ਨਜ਼ਦੀਕੀ-ਰੀਅਲ-ਟਾਈਮ ਵਿੱਚ ਭੇਜ ਕੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਆਪਰੇਟਰ ਇਸਨੂੰ ਆਪਣੇ ਆਪ ਹੀ ਕੌਂਫਿਗਰ ਕਰਦਾ ਹੈ, ਪਰ ਵੇਰਵਿਆਂ ਨੂੰ ਸਮਝਣ ਨਾਲ ਟਿਊਨਿੰਗ ਅਤੇ ਸਮੱਸਿਆ ਨਿਪਟਾਰਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਮਿਲਦੀ ਹੈ।

• ਸਮਕਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ— ਪ੍ਰਾਇਮਰੀ ਇੱਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ WAL ਰਸੀਦ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ। ਇਹ ਜ਼ੀਰੋ ਡਾਟਾ ਨੁਕਸਾਨ (RPO=0) ਦੀ ਗਰੰਟੀ ਦਿੰਦਾ ਹੈ ਪਰ ਲੇਟੈਂਸੀ ਜੋੜਦਾ ਹੈ।patroni.synchronous_mode: trueਨਾਲ ਯੋਗ ਕਰੋ।
• ਅਸਿੰਕ੍ਰੋਨਸ ਰੀਪਲੀਕੇਸ਼ਨ— ਪ੍ਰਾਇਮਰੀ ਕਮਿਟ ਤੁਰੰਤ ਕਰਦਾ ਹੈ ਅਤੇ WAL ਨੂੰ ਅਸਿੰਕ੍ਰੋਨਸ ਰੂਪ ਵਿੱਚ ਭੇਜਦਾ ਹੈ। ਫੇਲਓਵਰ ਦੇ ਦੌਰਾਨ ਥੋੜ੍ਹਾ ਘੱਟ ਲੇਟੈਂਸੀ ਪਰ ਸੰਭਾਵੀ ਡੇਟਾ ਦਾ ਨੁਕਸਾਨ। ਇਹ ਡਿਫਾਲਟ ਹੈ।
• ਕੈਸਕੇਡਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ— ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਪ੍ਰਾਇਮਰੀ ਦੀ ਬਜਾਏ ਹੋਰ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਤੋਂ ਨਕਲ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਵੱਡੇ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਪ੍ਰਾਇਮਰੀ ਉੱਤੇ ਲੋਡ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ।

# Enable synchronous replication for zero data loss
spec:
  patroni:
    synchronous_mode: true
    synchronous_mode_strict: false  # Allow async if no sync replica available
    synchronous_node_count: 1       # Number of sync replicas required
  postgresql:
    parameters:
      synchronous_commit: "on"      # Matches Patroni synchronous_mode
      max_wal_senders: "10"         # Maximum WAL sender processes
      wal_keep_size: "1GB"          # WAL retention for replica catch-up
      hot_standby: "on"             # Allow queries on replicas
      hot_standby_feedback: "on"    # Reduce query conflicts on replicas

ਬੈਕਅੱਪ ਅਤੇ ਰਿਕਵਰੀ

WAL-G ਬੈਕਅੱਪ ਸੰਰਚਨਾ

ਸਹੀ ਬੈਕਅੱਪ ਸੰਰਚਨਾ ਆਫ਼ਤ ਰਿਕਵਰੀ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜ਼ਲੈਂਡੋ ਆਪਰੇਟਰ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਲਈ ਲਗਾਤਾਰ ਬੈਕਅੱਪ ਲਈ WAL-G ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਕਰਦਾ ਹੈ। ਇੱਥੇ S3-ਅਨੁਕੂਲ ਸਟੋਰੇਜ ਲਈ ਇੱਕ ਸੰਪੂਰਨ ਸੰਰਚਨਾ ਹੈ:

# ConfigMap for WAL-G backup configuration
apiVersion: v1
kind: ConfigMap
metadata:
  name: postgres-pod-config
  namespace: databases
data:
  # S3 backup configuration
  AWS_ENDPOINT: "https://s3.us-east-1.amazonaws.com"
  AWS_S3_FORCE_PATH_STYLE: "false"
  AWS_REGION: "us-east-1"
  WALG_S3_PREFIX: "s3://my-pg-backups/$(SCOPE)"
  WALG_DISABLE_S3_SSE: "false"
  WALG_S3_SSE: "aws:kms"
  WALG_S3_SSE_KMS_ID: "arn:aws:kms:us-east-1:123456789:key/mrk-abcdef"

  # Backup scheduling and retention
  USE_WALG_BACKUP: "true"
  USE_WALG_RESTORE: "true"
  BACKUP_SCHEDULE: "0 1 * * *"       # Daily at 1 AM UTC
  BACKUP_NUM_TO_RETAIN: "14"          # Keep 14 daily backups

  # WAL archiving
  WALG_COMPRESSION_METHOD: "zstd"     # Better compression than lz4
  WALG_DELTA_MAX_STEPS: "6"           # Delta backups between full backups
  WALG_UPLOAD_CONCURRENCY: "4"        # Parallel upload streams
  WALG_DOWNLOAD_CONCURRENCY: "4"      # Parallel download for restore
  WALG_UPLOAD_DISK_CONCURRENCY: "4"   # Disk read concurrency

  # Clone configuration
  CLONE_AWS_ENDPOINT: "https://s3.us-east-1.amazonaws.com"
  CLONE_AWS_REGION: "us-east-1"
  CLONE_WALG_S3_PREFIX: "s3://my-pg-backups/$(CLONE_SCOPE)"
  CLONE_METHOD: "CLONE_WITH_WALG"
  CLONE_USE_WALG_RESTORE: "true"

ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ (PITR)

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

# Clone a cluster with PITR
apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
  name: pg-restored-cluster
  namespace: databases
spec:
  teamId: "platform"
  volume:
    size: 100Gi
    storageClass: ebs-gp3-postgres
  numberOfInstances: 3
  postgresql:
    version: "16"
  clone:
    cluster: "pg-production-cluster"
    timestamp: "2026-04-11T14:30:00+00:00"  # Restore to this exact moment
    s3_wal_path: "s3://my-pg-backups/wal/16/pg-production-cluster"
    s3_endpoint: "https://s3.us-east-1.amazonaws.com"
    s3_access_key_id: ""      # Use IAM role instead
    s3_secret_access_key: ""  # Use IAM role instead

ਜਦੋਂ ਇਹ CRD ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਆਪਰੇਟਰ ਹੇਠਾਂ ਦਿੱਤੇ ਕਦਮਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ:

1. ਟੀਚਾ ਟਾਈਮਸਟੈਂਪ
ਤੋਂ ਪਹਿਲਾਂ ਨਵੀਨਤਮ ਬੇਸ ਬੈਕਅੱਪ ਲੱਭਦਾ ਹੈ
2. ਨਵੇਂ ਸਟੇਟਫੁਲਸੈੱਟ ਦੇ ਪ੍ਰਾਇਮਰੀ ਪੋਡ
ਲਈ ਬੇਸ ਬੈਕਅੱਪ ਨੂੰ ਰੀਸਟੋਰ ਕਰਦਾ ਹੈ
3. ਨਿਰਧਾਰਿਤ ਟਾਈਮਸਟੈਂਪ
ਤੱਕ WAL ਭਾਗਾਂ ਨੂੰ ਰੀਪਲੇਅ ਕਰਦਾ ਹੈ
4. ਰੀਡ-ਰਾਈਟ ਓਪਰੇਸ਼ਨ
ਲਈ ਡਾਟਾਬੇਸ ਖੋਲ੍ਹਦਾ ਹੈ
5. ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਪੌਡ
ਲਈ ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਕਰਦਾ ਹੈ

ਸਟੈਂਡਬਾਏ ਕਲੱਸਟਰ

ਇੱਕ ਸਟੈਂਡਬਾਏ ਕਲੱਸਟਰ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਕਲੱਸਟਰ ਤੋਂ ਲਗਾਤਾਰ ਨਕਲ ਕਰਦਾ ਹੈ, ਇੱਕ ਗਰਮ ਸਟੈਂਡਬਾਏ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਕਿਸੇ ਆਫ਼ਤ ਦੌਰਾਨ ਅੱਗੇ ਵਧਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਕਲੱਸਟਰ ਦੇ ਅੰਦਰ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਤੋਂ ਵੱਖਰਾ ਹੈ—ਇੱਕ ਸਟੈਂਡਬਾਏ ਕਲੱਸਟਰ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੁਤੰਤਰ Kubernetes ਸਰੋਤ ਹੈ ਜੋ ਕਿ ਇੱਕ ਵੱਖਰੇ ਨੇਮਸਪੇਸ, ਕਲੱਸਟਰ, ਜਾਂ ਇੱਥੋਂ ਤੱਕ ਕਿ ਖੇਤਰ ਵਿੱਚ ਚੱਲ ਸਕਦਾ ਹੈ।

# Standby cluster in a different region
apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
  name: pg-standby-eu
  namespace: databases
spec:
  teamId: "platform"
  volume:
    size: 100Gi
    storageClass: managed-premium-postgres
  numberOfInstances: 2
  postgresql:
    version: "16"
  standby:
    standby_host: "pg-production-cluster.databases.svc.cluster.local"
    standby_port: "5432"
    # Alternative: replicate from S3 WAL archive
    # s3_wal_path: "s3://my-pg-backups/wal/16/pg-production-cluster"
  enableConnectionPooler: true
  enableReplicaConnectionPooler: true

ਇੱਕ ਸਟੈਂਡਬਾਏ ਕਲੱਸਟਰ ਨੂੰ ਇੱਕ ਸੁਤੰਤਰ ਪ੍ਰਾਇਮਰੀ (ਆਫਤ ਰਿਕਵਰੀ ਦੇ ਦੌਰਾਨ) ਵਿੱਚ ਉਤਸ਼ਾਹਿਤ ਕਰਨ ਲਈ, CRD ਤੋਂstandbyਭਾਗ ਨੂੰ ਹਟਾਓ ਅਤੇ ਲਾਗੂ ਕਰੋ:

# Edit the standby cluster CRD to remove standby section
kubectl patch postgresql pg-standby-eu -n databases --type json \
  -p '[{"op": "remove", "path": "/spec/standby"}]'

# The operator will promote the standby to primary
# Update your application DNS/service mesh to point to the new primary

ਨਿਗਰਾਨੀ

ਵਿਆਪਕ ਨਿਗਰਾਨੀ ਉਤਪਾਦਨ PostgreSQL ਤੈਨਾਤੀਆਂ ਲਈ ਗੈਰ-ਸੰਵਾਦਯੋਗ ਹੈ। ਜ਼ਲੈਂਡੋ ਆਪਰੇਟਰpostgres_exporterਸਾਈਡਕਾਰ ਦੁਆਰਾ Prometheus ਮੈਟ੍ਰਿਕਸ ਨਿਰਯਾਤ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਇੱਥੇ ਇੱਕ ਸੰਪੂਰਨ ਨਿਗਰਾਨੀ ਸਟੈਕ ਕਿਵੇਂ ਸਥਾਪਤ ਕਰਨਾ ਹੈ:

Prometheus

ਸਰਵਿਸ ਮਾਨੀਟਰ

# ServiceMonitor for PostgreSQL metrics
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: postgres-monitor
  namespace: databases
  labels:
    team: platform
    release: prometheus
spec:
  selector:
    matchLabels:
      team: platform
  namespaceSelector:
    matchNames:
    - databases
  endpoints:
  - port: exporter
    interval: 15s
    scrapeTimeout: 10s
    path: /metrics
    relabelings:
    - sourceLabels: [__meta_kubernetes_pod_label_spilo_role]
      targetLabel: role
    - sourceLabels: [__meta_kubernetes_pod_label_cluster_name]
      targetLabel: cluster
---
# PodMonitor alternative (scrapes pods directly)
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: postgres-pod-monitor
  namespace: databases
spec:
  selector:
    matchLabels:
      application: spilo
  podMetricsEndpoints:
  - port: exporter
    interval: 15s
    path: /metrics

ਮੁੱਖ ਮੈਟ੍ਰਿਕਸ

ਇਹ ਤੁਹਾਡੇ Grafana ਡੈਸ਼ਬੋਰਡਾਂ ਵਿੱਚ ਟਰੈਕ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ PostgreSQL ਮੈਟ੍ਰਿਕਸ ਹਨ:

• pg_stat_replication_lag— ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਬਾਈਟ ਅਤੇ ਸਕਿੰਟਾਂ ਵਿੱਚ ਪਛੜ ਗਈ। ਜੇਕਰ ਪਛੜ ਤੁਹਾਡੀ RPO ਥ੍ਰੈਸ਼ਹੋਲਡ ਤੋਂ ਵੱਧ ਜਾਂਦੀ ਹੈ ਤਾਂ ਚੇਤਾਵਨੀ।
• pg_stat_activity_count— ਰਾਜ ਦੁਆਰਾ ਕਿਰਿਆਸ਼ੀਲ ਕਨੈਕਸ਼ਨ। ਕੁਨੈਕਸ਼ਨ ਪੂਲ ਥਕਾਵਟ 'ਤੇ ਚੇਤਾਵਨੀ.
• pg_stat_database_tup_fetched/returned/inserted/updated/deleted— ਪੁੱਛਗਿੱਛ ਥ੍ਰਰੂਪੁਟ ਮੈਟ੍ਰਿਕਸ।
• pg_stat_bgwriter_buffers_checkpoint/clean/backend— ਬਫਰ ਪ੍ਰਬੰਧਨ ਕੁਸ਼ਲਤਾ।
• pg_database_size_bytes— ਸਮਰੱਥਾ ਯੋਜਨਾ ਲਈ ਸਮੇਂ ਦੇ ਨਾਲ ਡਾਟਾਬੇਸ ਦੇ ਆਕਾਰ ਵਿੱਚ ਵਾਧਾ।
• pg_locks_count— ਲਾਕ ਵਿਵਾਦ। ਬਹੁਤ ਜ਼ਿਆਦਾ ਉਡੀਕ ਤਾਲੇ 'ਤੇ ਚੇਤਾਵਨੀ.
• pg_stat_statements_calls/mean_time— ਸੁਯੋਗਕਰਨ ਲਈ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਅੰਕੜਿਆਂ ਦੀ ਪੁੱਛਗਿੱਛ ਕਰੋ।
• patroni_postgres_running— Patroni ਸਿਹਤ ਸਥਿਤੀ (1 = ਚੱਲ ਰਿਹਾ ਹੈ, 0 = ਹੇਠਾਂ)।
• patroni_master— ਕਿਹੜਾ ਪੌਡ ਮੌਜੂਦਾ ਪ੍ਰਾਇਮਰੀ ਹੈ (1 = ਮਾਸਟਰ, 0 = ਪ੍ਰਤੀਕ੍ਰਿਤੀ)।
• pg_up— ਮੂਲ PostgreSQL ਉਪਲਬਧਤਾ ਪੜਤਾਲ।

ਚੇਤਾਵਨੀ ਨਿਯਮ

# PrometheusRule for PostgreSQL alerts
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: postgres-alerts
  namespace: databases
spec:
  groups:
  - name: postgresql.rules
    rules:
    - alert: PostgreSQLDown
      expr: pg_up == 0
      for: 1m
      labels:
        severity: critical
      annotations:
        summary: "PostgreSQL instance {{ $labels.instance }} is down"
    - alert: PostgreSQLReplicationLag
      expr: pg_stat_replication_pg_wal_lsn_diff > 100000000
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Replication lag is {{ $value }} bytes on {{ $labels.instance }}"
    - alert: PostgreSQLHighConnections
      expr: sum(pg_stat_activity_count) by (instance) > 180
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "{{ $value }} active connections on {{ $labels.instance }}"
    - alert: PostgreSQLDeadlocks
      expr: rate(pg_stat_database_deadlocks[5m]) > 0
      for: 1m
      labels:
        severity: warning
      annotations:
        summary: "Deadlocks detected on {{ $labels.datname }}"
    - alert: PatroniFailover
      expr: changes(patroni_master[5m]) > 0
      labels:
        severity: critical
      annotations:
        summary: "Patroni failover occurred in cluster {{ $labels.cluster }}"

ਉਤਪਾਦਨ ਟਿਊਨਿੰਗ ਗਾਈਡ

Kubernetes 'ਤੇ PostgreSQL ਤੋਂ ਵੱਧ ਤੋਂ ਵੱਧ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਐਕਸਟਰੈਕਟ ਕਰਨ ਲਈ ਸਹੀ ਟਿਊਨਿੰਗ ਜ਼ਰੂਰੀ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੇ ਮਾਪਦੰਡ ਤੁਹਾਡੀ ਪੌਡ ਸਰੋਤ ਸੀਮਾਵਾਂ ਅਤੇ ਵਰਕਲੋਡ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਅਧਾਰ 'ਤੇ ਐਡਜਸਟ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ।

ਮੈਮੋਰੀ ਕੌਂਫਿਗਰੇਸ਼ਨ

# For a pod with 16GB memory limit:
postgresql:
  parameters:
    # shared_buffers: 25% of total memory
    shared_buffers: "4GB"

    # effective_cache_size: 75% of total memory
    # (tells planner how much OS cache to expect)
    effective_cache_size: "12GB"

    # work_mem: shared_buffers / (max_connections * 2)
    # Conservative to prevent OOM
    work_mem: "10MB"

    # maintenance_work_mem: 5-10% of total memory
    # Used for VACUUM, CREATE INDEX, ALTER TABLE
    maintenance_work_mem: "1GB"

    # temp_buffers: memory for temp tables per session
    temp_buffers: "32MB"

    # huge_pages: try to use huge pages (requires OS config)
    huge_pages: "try"

WAL ਅਤੇ ਚੈੱਕਪੁਆਇੰਟ ਕੌਂਫਿਗਰੇਸ਼ਨ

postgresql:
  parameters:
    # WAL settings
    wal_buffers: "64MB"           # 1/32 of shared_buffers, max 64MB
    wal_compression: "zstd"        # Compress WAL (PG 15+)
    max_wal_size: "8GB"            # Before forced checkpoint
    min_wal_size: "2GB"            # WAL disk reservation
    wal_level: "replica"           # Required for replication

    # Checkpoint settings
    checkpoint_completion_target: "0.9"  # Spread I/O over 90% of interval
    checkpoint_timeout: "15min"          # Max time between checkpoints

ਪੁੱਛਗਿੱਛ ਯੋਜਨਾਕਾਰ ਅਤੇ I/O

postgresql:
  parameters:
    # Cost parameters for SSD storage
    random_page_cost: "1.1"          # SSD: close to seq_page_cost
    seq_page_cost: "1.0"             # Sequential I/O baseline
    effective_io_concurrency: "200"   # Concurrent I/O for SSD

    # Planner behavior
    default_statistics_target: "200"  # More accurate statistics
    from_collapse_limit: 12           # JOIN planning threshold
    join_collapse_limit: 12           # JOIN planning threshold

    # Parallel queries
    max_parallel_workers_per_gather: "4"
    max_parallel_workers: "8"
    max_parallel_maintenance_workers: "4"
    parallel_tuple_cost: "0.01"
    parallel_setup_cost: "1000"

ਕਨੈਕਸ਼ਨ ਅਤੇ ਲੌਗਿੰਗ

postgresql:
  parameters:
    # Connection limits
    max_connections: "200"                   # Keep low, use PgBouncer
    superuser_reserved_connections: "5"       # Reserve for admin access

    # Logging for troubleshooting
    log_statement: "ddl"                     # Log DDL statements
    log_min_duration_statement: "500"         # Log queries > 500ms
    log_checkpoints: "on"                    # Log checkpoint activity
    log_connections: "off"                   # Too noisy in production
    log_disconnections: "off"                # Too noisy in production
    log_lock_waits: "on"                     # Log lock waits
    log_temp_files: "0"                      # Log all temp file usage
    log_autovacuum_min_duration: "1000"       # Log slow autovacuum

    # Statement timeouts
    statement_timeout: "60000"               # 60 second query timeout
    lock_timeout: "30000"                    # 30 second lock timeout
    idle_in_transaction_session_timeout: "600000"  # 10 min idle txn timeout

ਰੋਲਿੰਗ ਅੱਪਡੇਟ ਅਤੇ ਵਰਜਨ ਅੱਪਗ੍ਰੇਡ

ਮਾਈਨਰ ਵਰਜਨ ਅੱਪਗਰੇਡ

ਮਾਈਨਰ ਸੰਸਕਰਣ ਅੱਪਗਰੇਡ (ਉਦਾਹਰਨ ਲਈ, 16.2 ਤੋਂ 16.3) ਨੂੰ ਓਪਰੇਟਰ ਦੁਆਰਾ ਆਪਣੇ ਆਪ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਸਪਾਈਲੋ ਚਿੱਤਰ ਟੈਗ ਨੂੰ ਅਪਡੇਟ ਕਰਦੇ ਹੋ। ਆਪਰੇਟਰ ਇੱਕ ਰੋਲਿੰਗ ਰੀਸਟਾਰਟ ਕਰਦਾ ਹੈ:

# Update the operator configuration to use a new Spilo image
helm upgrade postgres-operator postgres-operator-charts/postgres-operator \
  --namespace postgres-operator \
  --set configGeneral.docker_image=ghcr.io/zalando/spilo-16:3.1-p1 \
  --reuse-values

# The operator will perform rolling updates:
# 1. Restart replicas one at a time
# 2. Failover the primary to a freshly updated replica
# 3. Restart the old primary (now a replica)

ਮੁੱਖ ਸੰਸਕਰਣ ਅੱਪਗਰੇਡ

ਮੁੱਖ ਸੰਸਕਰਣ ਅੱਪਗਰੇਡਾਂ (ਉਦਾਹਰਨ ਲਈ, PostgreSQL 15 ਤੋਂ 16) ਲਈ ਵਧੇਰੇ ਧਿਆਨ ਨਾਲ ਯੋਜਨਾਬੰਦੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜ਼ਲੈਂਡੋ ਆਪਰੇਟਰpg_upgrade:

# Step 1: Update the CRD to the new major version
spec:
  postgresql:
    version: "16"  # Changed from "15"

# Step 2: The operator detects the version change and:
# a) Scales down the StatefulSet to 1 replica
# b) Runs pg_upgrade on the primary pod
# c) Scales back up to the desired numberOfInstances
# d) Replicas are rebuilt from the upgraded primary

# Step 3: Verify the upgrade
kubectl exec -it pg-production-cluster-0 -n databases -- \
  su postgres -c "psql -c 'SELECT version()'"

# Step 4: Run ANALYZE to update statistics after upgrade
kubectl exec -it pg-production-cluster-0 -n databases -- \
  su postgres -c "psql -c 'ANALYZE VERBOSE'"

ਮੁੱਖ ਅੱਪਗਰੇਡਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਵਿਚਾਰ:

ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਮੇਸ਼ਾ ਇੱਕ ਨਵਾਂ ਬੈਕਅੱਪ ਲਓ
• ਪਹਿਲੇ
ਨੂੰ ਕਲੋਨ ਕੀਤੇ ਕਲੱਸਟਰ 'ਤੇ ਅੱਪਗ੍ਰੇਡ ਦੀ ਜਾਂਚ ਕਰੋ
• ਮੁੱਖ ਅੱਪਗਰੇਡਾਂ ਲਈ ਡਾਊਨਟਾਈਮ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਆਮ ਤੌਰ 'ਤੇ ਡਾਟਾਬੇਸ ਆਕਾਰ ਦੇ ਆਧਾਰ 'ਤੇ 5-30 ਮਿੰਟ)
ਨੂੰ ਤੋੜਨ ਵਾਲੀਆਂ ਤਬਦੀਲੀਆਂ ਲਈ PostgreSQL ਰੀਲੀਜ਼ ਨੋਟਸ ਦੀ ਸਮੀਖਿਆ ਕਰੋ
• ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਮੁੜ ਨਿਰਮਾਣ ਦੇ ਬਾਅਦ
ਮਾਨੀਟਰ ਰੀਪਲੀਕੇਸ਼ਨ ਨੇੜਿਓਂ ਪਛੜ ਗਿਆ
• ਪੁੱਛਗਿੱਛ ਯੋਜਨਾਕਾਰ ਅੰਕੜੇ
ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਲਈ ਸਾਰੇ ਡੇਟਾਬੇਸ 'ਤੇANALYZEਚਲਾਓ

ਐਡਵਾਂਸਡ ਓਪਰੇਸ਼ਨਲ ਪੈਟਰਨ

ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ

ਭੌਤਿਕ WAL-G ਬੈਕਅੱਪ ਤੋਂ ਇਲਾਵਾ, ਆਪਰੇਟਰpg_dumpਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ ਕਰਾਸ-ਵਰਜ਼ਨ ਮਾਈਗ੍ਰੇਸ਼ਨ ਅਤੇ ਚੋਣਵੇਂ ਟੇਬਲ ਰੀਸਟੋਰ ਲਈ ਉਪਯੋਗੀ ਹਨ:

# Enable logical backups in the operator configuration
helm upgrade postgres-operator postgres-operator-charts/postgres-operator \
  --namespace postgres-operator \
  --set configLogicalBackup.logical_backup_schedule="0 3 * * *" \
  --set configLogicalBackup.logical_backup_s3_bucket="my-pg-logical-backups" \
  --set configLogicalBackup.logical_backup_s3_region="us-east-1" \
  --set configLogicalBackup.logical_backup_s3_sse="AES256" \
  --reuse-values

# The operator creates a CronJob for each cluster that:
# 1. Connects to the primary PostgreSQL instance
# 2. Runs pg_dumpall (or pg_dump per database)
# 3. Compresses and uploads to S3

ਕਸਟਮ ਪੌਡ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ

ਤੁਸੀਂ ConfigMap ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਨੂੰ ਸਪਾਈਲੋ ਪੌਡਾਂ ਵਿੱਚ ਇੰਜੈਕਟ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ WAL-G, ਕਸਟਮ ਸਕ੍ਰਿਪਟਾਂ, ਜਾਂ OS-ਪੱਧਰ ਦੇ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਟਿਊਨ ਕਰਨ ਲਈ ਉਪਯੋਗੀ ਹੈ:

apiVersion: v1
kind: ConfigMap
metadata:
  name: postgres-pod-config
  namespace: databases
data:
  # Custom Spilo configurations
  SPILO_CONFIGURATION: |
    bootstrap:
      dcs:
        ttl: 30
        loop_wait: 10
        retry_timeout: 10
        maximum_lag_on_failover: 33554432
        postgresql:
          use_pg_rewind: true
          use_slots: true
          parameters:
            archive_mode: "on"
            archive_timeout: 1800s
  # Enable pg_stat_statements
  POSTGRESQL_SHARED_PRELOAD_LIBRARIES: "bg_mon,pg_stat_statements,pgextwlist,pg_auth_mon,set_user,timescaledb,pg_cron,pg_stat_kcache"
  # Cron jobs inside PostgreSQL
  ENABLE_PG_CRON: "true"

ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ

ਉਤਪਾਦਨ ਵਿੱਚ, Kubernetes ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ PostgreSQL ਪੌਡਾਂ ਤੱਕ ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਨੂੰ ਸੀਮਤ ਕਰੋ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: postgres-network-policy
  namespace: databases
spec:
  podSelector:
    matchLabels:
      application: spilo
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: app-namespace
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - protocol: TCP
      port: 5432
    - protocol: TCP
      port: 8008   # Patroni REST API
  - from:
    - namespaceSelector:
        matchLabels:
          name: monitoring
    ports:
    - protocol: TCP
      port: 9187   # Prometheus exporter
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
    ports:
    - protocol: TCP
      port: 443    # S3/GCS/Azure for backups

ਆਮ ਸਮੱਸਿਆਵਾਂ ਦਾ ਨਿਪਟਾਰਾ ਕਰਨਾ

ਆਟੋਮੇਸ਼ਨ ਦੇ ਨਾਲ ਵੀ, ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ। ਜ਼ਲੈਂਡੋ ਆਪਰੇਟਰ ਨਾਲ PostgreSQL ਚਲਾਉਣ ਵੇਲੇ ਇੱਥੇ ਸਭ ਤੋਂ ਆਮ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਹੱਲ ਹਨ:

1. ਪੈਂਡਿੰਗ ਸਟੇਟ ਵਿੱਚ ਫਸਿਆ ਹੋਇਆ ਪੋਡ

# Check events for the pod
kubectl describe pod pg-production-cluster-0 -n databases

# Common causes:
# - No nodes with matching tolerations/affinity
# - Insufficient CPU or memory on nodes
# - PVC cannot be provisioned (check StorageClass)

# Fix: Check node resources and storage availability
kubectl get nodes -o custom-columns=NAME:.metadata.name,CPU:.status.allocatable.cpu,MEM:.status.allocatable.memory
kubectl get pvc -n databases

2. ਰੀਪਲੀਕੇਸ਼ਨ ਲੈਗ ਵਧਦਾ

# Check replication status on the primary
kubectl exec -it pg-production-cluster-0 -n databases -- \
  su postgres -c "psql -c 'SELECT client_addr, state, sent_lsn, write_lsn, flush_lsn, replay_lsn, write_lag, flush_lag, replay_lag FROM pg_stat_replication'"

# Common causes:
# - Replica CPU/IO saturation
# - Network bandwidth limits
# - Long-running queries on replica blocking WAL replay
# - Insufficient wal_keep_size

# Fix: Check replica resources and cancel blocking queries
kubectl exec -it pg-production-cluster-1 -n databases -- \
  su postgres -c "psql -c 'SELECT pg_cancel_backend(pid) FROM pg_stat_activity WHERE state = \"active\" AND query_start < now() - interval \"5 minutes\"'"

3. ਫੇਲਓਵਰ

# Check Patroni cluster status
kubectl exec -it pg-production-cluster-0 -n databases -- \
  su postgres -c "patronictl list"

# Check Patroni logs
kubectl logs pg-production-cluster-0 -n databases -c postgres | grep -i patroni

# Manual failover (if auto-failover is stuck)
kubectl exec -it pg-production-cluster-0 -n databases -- \
  su postgres -c "patronictl failover --candidate pg-production-cluster-1 --force"

4. ਬੈਕਅੱਪ ਅਸਫਲਤਾਵਾਂ

# Check WAL-G backup status
kubectl exec -it pg-production-cluster-0 -n databases -- \
  su postgres -c "envdir /run/etc/wal-e.d/env wal-g backup-list"

# Check backup CronJob logs
kubectl logs -l application=spilo,cluster-name=pg-production-cluster -n databases | grep -i wal-g

# Verify S3/GCS credentials
kubectl exec -it pg-production-cluster-0 -n databases -- \
  su postgres -c "envdir /run/etc/wal-e.d/env aws s3 ls s3://my-pg-backups/"

ਸੁਰੱਖਿਆ ਵਧੀਆ ਅਭਿਆਸ

Kubernetes 'ਤੇ PostgreSQL ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ ਇੱਕ ਰੱਖਿਆ-ਵਿੱਚ-ਡੂੰਘਾਈ ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੈ:

• TLS ਇਨਕ੍ਰਿਪਸ਼ਨ— ਸਾਰੇ ਕਲਾਇੰਟ ਕਨੈਕਸ਼ਨਾਂ ਲਈ SSL ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ। ਆਪਰੇਟਰ ਪ੍ਰਮਾਣ-ਪੱਤਰ-ਪ੍ਰਬੰਧਕ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਦਾ ਪ੍ਰਬੰਧ ਕਰ ਸਕਦਾ ਹੈ।
• ਗੁਪਤ ਪ੍ਰਬੰਧਨ— ਡਾਟਾਬੇਸ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਲਈ Kubernetes ਸੀਕਰੇਟਸ (ਜਾਂ ਬਾਹਰੀ ਗੁਪਤ ਪ੍ਰਬੰਧਕ ਜਿਵੇਂ ਵਾਲਟ) ਦੀ ਵਰਤੋਂ ਕਰੋ। ConfigMaps ਵਿੱਚ ਕਦੇ ਵੀ ਪਾਸਵਰਡ ਸਟੋਰ ਨਾ ਕਰੋ।
• RBAC— ਸੀਮਾ ਓਪਰੇਟਰ ਸੇਵਾ ਖਾਤਾ ਅਨੁਮਤੀਆਂ। ਐਪਲੀਕੇਸ਼ਨ ਡੇਟਾਬੇਸ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਘੱਟੋ-ਘੱਟ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਦੀ ਵਰਤੋਂ ਕਰੋ।
• ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ— ਪੌਡ-ਟੂ-ਪੋਡ ਸੰਚਾਰ ਨੂੰ ਪ੍ਰਤਿਬੰਧਿਤ ਕਰੋ ਜਿਵੇਂ ਕਿ ਪਿਛਲੇ ਭਾਗ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ।
• pg_hba.conf— ਇਹ ਸੀਮਤ ਕਰਨ ਲਈ ਹੋਸਟ-ਅਧਾਰਿਤ ਪ੍ਰਮਾਣਿਕਤਾ ਕੌਂਫਿਗਰ ਕਰੋ ਕਿ ਕਿਹੜੇ IP ਅਤੇ ਉਪਭੋਗਤਾ ਕਨੈਕਟ ਕਰ ਸਕਦੇ ਹਨ।
• ਆਡਿਟ ਲੌਗਿੰਗ— ਨਿਯੰਤ੍ਰਿਤ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ SQL ਆਡਿਟ ਲੌਗਿੰਗ ਲਈpgauditਐਕਸਟੈਂਸ਼ਨ ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ।
• ਇਨਕ੍ਰਿਪਟਡ ਸਟੋਰੇਜ— ਇਨਕ੍ਰਿਪਟਡ ਸਟੋਰੇਜ ਕਲਾਸਾਂ (EBS ਇਨਕ੍ਰਿਪਸ਼ਨ, Azure ਡਿਸਕ ਇਨਕ੍ਰਿਪਸ਼ਨ, ਆਦਿ) ਦੀ ਵਰਤੋਂ ਕਰੋ।
• Pod ਸੁਰੱਖਿਆ ਮਿਆਰ— ਪ੍ਰਤੀਬੰਧਿਤ ਸੁਰੱਖਿਆ ਸੰਦਰਭਾਂ ਦੇ ਨਾਲ ਗੈਰ-ਰੂਟ ਦੇ ਤੌਰ 'ਤੇ ਸਪਾਈਲੋ ਪੌਡ ਚਲਾਓ।

# Security-hardened CRD settings
spec:
  spiloRunAsUser: 101
  spiloRunAsGroup: 103
  spiloFSGroup: 103
  enableShmVolume: true
  patroni:
    pg_hba:
    - hostssl all all 0.0.0.0/0 md5
    - host    replication standby all md5
    - hostssl replication standby all md5
  postgresql:
    parameters:
      ssl: "on"
      ssl_min_protocol_version: "TLSv1.3"
      password_encryption: "scram-sha-256"
  additionalVolumes:
  - name: postgres-tls
    mountPath: /tls
    secret:
      secretName: pg-tls-cert
      defaultMode: 0640

ਸਮਰੱਥਾ ਯੋਜਨਾ ਅਤੇ ਆਕਾਰ

ਸਹੀ ਆਕਾਰ ਸਥਿਰ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਲਾਗਤ ਕੁਸ਼ਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ। ਇਹਨਾਂ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਦੇ ਤੌਰ 'ਤੇ ਵਰਤੋ ਅਤੇ ਆਪਣੇ ਵਰਕਲੋਡ ਨਿਗਰਾਨੀ ਡੇਟਾ ਦੇ ਆਧਾਰ 'ਤੇ ਵਿਵਸਥਿਤ ਕਰੋ:

ਮੁਕੰਮਲ ਐਂਡ-ਟੂ-ਐਂਡ ਡਿਪਲਾਇਮੈਂਟ ਉਦਾਹਰਨ

ਆਉ ਅਸੀਂ ਇੱਕ ਨਵੇਂ Kubernetes ਕਲੱਸਟਰ 'ਤੇ ਸ਼ੁਰੂ ਤੋਂ ਪੂਰੀ ਤੈਨਾਤੀ ਦੇ ਨਾਲ ਸਭ ਕੁਝ ਇਕੱਠੇ ਰੱਖੀਏ:

# Step 1: Create namespace and configure storage
kubectl create namespace databases
kubectl create namespace postgres-operator

# Step 2: Install the Zalando Postgres Operator
helm repo add postgres-operator-charts \
  https://opensource.zalando.com/postgres-operator/charts/postgres-operator
helm repo update

helm install postgres-operator postgres-operator-charts/postgres-operator \
  --namespace postgres-operator \
  --set configKubernetes.enable_pod_antiaffinity=true \
  --set configKubernetes.pod_environment_configmap=databases/postgres-pod-config

# Step 3: Create backup configuration
kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: postgres-pod-config
  namespace: databases
data:
  USE_WALG_BACKUP: "true"
  USE_WALG_RESTORE: "true"
  WALG_S3_PREFIX: "s3://my-pg-backups/\$(SCOPE)"
  BACKUP_SCHEDULE: "0 1 * * *"
  BACKUP_NUM_TO_RETAIN: "14"
EOF

# Step 4: Deploy the PostgreSQL cluster
kubectl apply -f - <<EOF
apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
  name: pg-app-cluster
  namespace: databases
  labels:
    team: platform
spec:
  teamId: "platform"
  volume:
    size: 50Gi
  numberOfInstances: 3
  enableConnectionPooler: true
  enableReplicaConnectionPooler: true
  users:
    app_user:
    - superuser
    - createdb
  databases:
    app_db: app_user
  postgresql:
    version: "16"
    parameters:
      shared_buffers: "2GB"
      work_mem: "64MB"
      effective_cache_size: "6GB"
  resources:
    requests:
      cpu: "2"
      memory: 8Gi
    limits:
      cpu: "4"
      memory: 16Gi
EOF

# Step 5: Wait for cluster readiness
kubectl wait --for=condition=Running postgresql/pg-app-cluster \
  -n databases --timeout=300s

# Step 6: Verify cluster status
kubectl get postgresql -n databases
kubectl get pods -n databases -l cluster-name=pg-app-cluster
kubectl get svc -n databases -l cluster-name=pg-app-cluster

# Step 7: Get connection credentials
export PGPASSWORD=$(kubectl get secret app-user.pg-app-cluster.credentials.postgresql.acid.zalan.do \
  -n databases -o jsonpath='{.data.password}' | base64 -d)

# Step 8: Connect and verify
kubectl run pg-client --rm -it --image=postgres:16 -n databases -- \
  psql -h pg-app-cluster-pooler -U app_user -d app_db -c "SELECT version();"

ਸਿੱਟਾ

ਜ਼ਲੈਂਡੋ Postgres ਆਪਰੇਟਰ PostgreSQL ਨੂੰ Kubernetes 'ਤੇ ਇੱਕ ਗੁੰਝਲਦਾਰ ਸੰਚਾਲਨ ਚੁਣੌਤੀ ਤੋਂ ਇੱਕ ਪ੍ਰਬੰਧਨਯੋਗ, ਸਵੈਚਲਿਤ ਤੈਨਾਤੀ ਵਿੱਚ ਬਦਲਦਾ ਹੈ। ਸਹਿਮਤੀ-ਆਧਾਰਿਤ ਫੇਲਓਵਰ ਲਈ Patroni, ਬੈਟਰੀਆਂ-ਸ਼ਾਮਲ ਕੰਟੇਨਰ ਚਿੱਤਰ ਲਈ Spilo, ਲਗਾਤਾਰ ਬੈਕਅੱਪ ਅਤੇ ਰਿਕਵਰੀ ਲਈ WAL-G, ਅਤੇ ਕੁਸ਼ਲ ਕਨੈਕਸ਼ਨ ਪੂਲਿੰਗ ਲਈ PgBouncer ਦਾ ਲਾਭ ਲੈ ਕੇ, ਤੁਹਾਨੂੰ ਇੱਕ ਉਤਪਾਦਨ-ਗਰੇਡ ਡਾਟਾਬੇਸ ਪਲੇਟਫਾਰਮ ਮਿਲਦਾ ਹੈ ਜੋ AWS EKS, Azure, GPR6X, XPRKeal, XPRKE, AKS18 ਅਤੇ ਬਾਰਾਂ ਵਿੱਚ ਲਗਾਤਾਰ ਕੰਮ ਕਰਦਾ ਹੈ।

ਇਸ ਗਾਈਡ ਤੋਂ ਮੁੱਖ ਉਪਾਅ ਹਨ:

• ਹਰ ਚੀਜ਼ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰੋ— ਓਪਰੇਟਰ ਨੂੰ ਸਟੇਟਫੁਲਸੈੱਟ ਪ੍ਰਬੰਧਨ, ਫੇਲਓਵਰ, ਅਤੇ ਬੈਕਅੱਪ ਸਮਾਂ-ਸਾਰਣੀ ਨੂੰ ਸੰਭਾਲਣ ਦਿਓ। ਦਸਤੀ ਦਖਲ ਅਪਵਾਦ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ.
• ਆਕ੍ਰਾਮਕ ਢੰਗ ਨਾਲ ਨਿਗਰਾਨੀ ਕਰੋ— Prometheus ਅਤੇ Grafana ਨੂੰ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਲਾਗੂ ਕਰੋ। ਰਿਪਲੀਕੇਸ਼ਨ ਲੈਗ, ਕਨੈਕਸ਼ਨ ਗਿਣਤੀ, ਅਤੇ ਲੌਕ ਵਿਵਾਦ ਤੁਹਾਡੇ ਸ਼ੁਰੂਆਤੀ ਚੇਤਾਵਨੀ ਸੰਕੇਤ ਹਨ।
• ਆਫ਼ਤ ਲਈ ਯੋਜਨਾ— WAL-G ਬੈਕਅੱਪ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰੋ, ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ PITR ਦੀ ਜਾਂਚ ਕਰੋ, ਅਤੇ ਨਾਜ਼ੁਕ ਵਰਕਲੋਡ ਲਈ ਸਟੈਂਡਬਾਏ ਕਲੱਸਟਰ ਨੂੰ ਬਣਾਈ ਰੱਖੋ।
ਤੁਹਾਡੇ ਵਰਕਲੋਡ ਲਈ
• ਟਿਊਨ— ਪੂਰਵ-ਨਿਰਧਾਰਤ PostgreSQL ਪੈਰਾਮੀਟਰ ਕੰਜ਼ਰਵੇਟਿਵ ਹਨ। ਤੁਹਾਡੇ ਸਰੋਤ ਅਲਾਟਮੈਂਟ ਅਤੇ ਪੁੱਛਗਿੱਛ ਪੈਟਰਨਾਂ ਦੇ ਆਧਾਰ 'ਤੇ shared_buffers, work_mem, ਅਤੇ ਚੈੱਕਪੁਆਇੰਟ ਸੈਟਿੰਗਾਂ ਨੂੰ ਵਿਵਸਥਿਤ ਕਰੋ।
• ਮੂਲ ਰੂਪ ਵਿੱਚ ਸੁਰੱਖਿਅਤ— TLS ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ, SCRAM-SHA-256 ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਵਰਤੋਂ ਕਰੋ, ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਨੂੰ ਪ੍ਰਤਿਬੰਧਿਤ ਕਰੋ, ਅਤੇ ਬਾਕੀ ਦੇ ਸਮੇਂ ਸਟੋਰੇਜ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰੋ।
• ਟੈਸਟ ਅੱਪਗਰੇਡ— ਹਮੇਸ਼ਾ ਆਪਣੇ ਕਲੱਸਟਰ ਨੂੰ ਕਲੋਨ ਕਰੋ ਅਤੇ ਉਤਪਾਦਨ 'ਤੇ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮੁੱਖ ਸੰਸਕਰਣ ਅੱਪਗ੍ਰੇਡਾਂ ਦੀ ਜਾਂਚ ਕਰੋ।

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