ਡਾਟਾਬੇਸ ਐਡਮਿਨਿਸਟ੍ਰੇਟਰਾਂ (DBAs) ਅਤੇ DevOps ਇੰਜੀਨੀਅਰਾਂ ਲਈ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ PostgreSQL ਦਾ ਪ੍ਰਬੰਧਨ ਕਰ ਰਹੇ ਹਨ, ਲਗਭਗ ਜ਼ੀਰੋ ਰਿਕਵਰੀ ਪੁਆਇੰਟ ਓਬਜੈਕਟਿਵ (RPO) ਪ੍ਰਾਪਤ ਕਰਨਾ ਇੱਕ ਮੁੱਖ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ। PostgreSQL ਦੀ ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ ਅਤੇ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ (PITR) ਸਮਰੱਥਾਵਾਂ ਦੇ ਕੇਂਦਰ ਵਿੱਚ ਰਾਈਟ-ਅਹੇਡ ਲੌਗਿੰਗ (WAL) ਹੈ। ਜਦੋਂ ਕਿ WAL ਡੇਟਾ ਫਾਈਲਾਂ ਵਿੱਚ ਲਿਖੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਲੈਣ-ਦੇਣ ਨੂੰ ਲੌਗ ਕਰਕੇ ACID ਪਾਲਣਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ, WAL ਆਰਕਾਈਵਿੰਗ ਉਹ ਵਿਧੀ ਹੈ ਜੋ ਇਹਨਾਂ ਲੌਗਾਂ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਦੇ ਬੈਕਅੱਪ ਅਤੇ ਰੀਪਲੀਕੇਸ਼ਨ ਲਈ ਸੁਰੱਖਿਅਤ ਰੱਖਦੀ ਹੈ।
ਹਾਲਾਂਕਿ, WAL ਆਰਕਾਈਵਿੰਗ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨਾ “ਇੱਕ ਵਾਰ ਸੈੱਟ ਕਰੋ ਅਤੇ ਭੁੱਲ ਜਾਓ” ਵਾਲਾ ਕੰਮ ਨਹੀਂ ਹੈ। ਗਲਤ ਕੌਂਫਿਗਰੇਸ਼ਨ, ਚੁੱਪ-ਚਾਪ ਅਸਫਲਤਾਵਾਂ, ਅਤੇ ਆਰਕੀਟੈਕਚਰਲ ਗਲਤਫਹਿਮੀਆਂ ਕਾਰਨ ਡੇਟਾ ਦਾ ਭਾਰੀ ਨੁਕਸਾਨ, ਸਪਲਿਟ-ਬ੍ਰੇਨ ਸਥਿਤੀਆਂ, ਜਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਡਾਟਾਬੇਸ ਬੰਦ ਹੋ ਸਕਦਾ ਹੈ।
ਇਸ ਵਿਆਪਕ ਗਾਈਡ ਵਿੱਚ, ਅਸੀਂ PostgreSQL WAL ਆਰਕਾਈਵਿੰਗ ਦੇ ਆਰਕੀਟੈਕਚਰ ਦੀ ਪੜਚੋਲ ਕਰਾਂਗੇ, ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਵੱਲ ਲੈ ਜਾਣ ਵਾਲੀਆਂ ਸਭ ਤੋਂ ਆਮ ਕਮੀਆਂ ਦੀ ਪਛਾਣ ਕਰਾਂਗੇ, ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਪ੍ਰੋਡਕਸ਼ਨ-ਗ੍ਰੇਡ ਵਧੀਆ ਅਭਿਆਸਾਂ ਦੀ ਰੂਪਰੇਖਾ ਤਿਆਰ ਕਰਾਂਗੇ ਕਿ ਤੁਹਾਡਾ ਡਾਟਾਬੇਸ ਲਚਕੀਲਾ ਬਣਿਆ ਰਹੇ।
PostgreSQL WAL ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਸਮਝਣਾ
ਕਮੀਆਂ ਵਿੱਚ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਸਮਝਣਾ ਬਹੁਤ ਜ਼ਰੂਰੀ ਹੈ ਕਿ PostgreSQL ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗਸ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦਾ ਹੈ।
PostgreSQL ਸਾਰੇ ਬਦਲਾਵਾਂ ਨੂੰ WAL ਸੈਗਮੈਂਟਾਂ (ਡਿਫੌਲਟ ਤੌਰ ‘ਤੇ 16MB ਫਾਈਲਾਂ) ਵਿੱਚ ਲਿਖਦਾ ਹੈ ਜੋ pg_wal ਡਾਇਰੈਕਟਰੀ (ਵਰਜਨ 10 ਤੋਂ ਪਹਿਲਾਂ pg_xlog) ਵਿੱਚ ਸਥਿਤ ਹੁੰਦੇ ਹਨ। ਹਰ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਨੂੰ ਲੌਗ ਸੀਕਵੈਂਸ ਨੰਬਰ (LSN) ਦੁਆਰਾ ਚਿੰਨ੍ਹਿਤ ਕਰਕੇ ਕ੍ਰਮਵਾਰ ਰਿਕਾਰਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਜਦੋਂ ਇੱਕ WAL ਸੈਗਮੈਂਟ ਭਰ ਜਾਂਦਾ ਹੈ, ਤਾਂ PostgreSQL ਇੱਕ ਨਵੇਂ ਸੈਗਮੈਂਟ ‘ਤੇ ਸਵਿਚ ਕਰਦਾ ਹੈ। pg_wal ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਬੇਅੰਤ ਵਧਣ ਤੋਂ ਰੋਕਣ ਲਈ, PostgreSQL ਪੁਰਾਣੇ WAL ਸੈਗਮੈਂਟਾਂ ਨੂੰ ਰੀਸਾਈਕਲ ਜਾਂ ਹਟਾ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਉਹਨਾਂ ਦੀ ਕਰੈਸ਼ ਰਿਕਵਰੀ ਜਾਂ ਰੀਪਲੀਕੇਸ਼ਨ ਲਈ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ।
WAL ਆਰਕਾਈਵਿੰਗ ਇਸ ਰੀਸਾਈਕਲਿੰਗ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਰੋਕਦੀ ਹੈ। ਜਦੋਂ archive_mode ਸਮਰੱਥ ਹੁੰਦਾ ਹੈ, ਤਾਂ PostgreSQL ਇੱਕ ਉਪਭੋਗਤਾ-ਪ੍ਰਭਾਸ਼ਿਤ archive_command ਚਲਾਉਂਦਾ ਹੈ (ਜਾਂ PostgreSQL 15+ ਵਿੱਚ archive_library ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ) ਤਾਂ ਜੋ ਪੂਰੇ ਹੋਏ WAL ਸੈਗਮੈਂਟ ਨੂੰ ਮਿਟਾਏ ਜਾਣ ਜਾਂ ਓਵਰਰਾਈਟ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸੁਰੱਖਿਅਤ, ਸੈਕੰਡਰੀ ਸਥਾਨ ‘ਤੇ ਕਾਪੀ ਕੀਤਾ ਜਾ ਸਕੇ।
ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ (PITR) ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਦੋ ਭਾਗਾਂ ਦੀ ਲੋੜ ਹੈ:
1. ਇੱਕ ਵੈਧ ਬੇਸ ਬੈਕਅੱਪ।
2. ਬੇਸ ਬੈਕਅੱਪ ਦੇ ਸਮੇਂ ਤੋਂ ਲੈ ਕੇ ਤੁਹਾਡੇ ਟੀਚੇ ਦੇ ਰਿਕਵਰੀ ਸਮੇਂ ਤੱਕ ਆਰਕਾਈਵ ਕੀਤੀਆਂ WAL ਫਾਈਲਾਂ ਦੀ ਇੱਕ ਅਟੁੱਟ ਲੜੀ।
ਜੇਕਰ ਉਹ WAL ਲੜੀ ਟੁੱਟ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ PITR ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ।
ਪ੍ਰੋਡਕਸ਼ਨ ਲਈ WAL ਆਰਕਾਈਵਿੰਗ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨਾ
WAL ਆਰਕਾਈਵਿੰਗ ਨੂੰ ਸਮਰੱਥ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਆਪਣੀ postgresql.conf ਫਾਈਲ ਨੂੰ ਸੋਧਣਾ ਪਵੇਗਾ। ਇੱਕ ਬੁਨਿਆਦੀ ਕੌਂਫਿਗਰੇਸ਼ਨ ਲਈ wal_level ਸੈੱਟ ਕਰਨ, archive_mode ਨੂੰ ਸਮਰੱਥ ਕਰਨ, ਅਤੇ archive_command ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
# postgresql.conf
wal_level = replica # 'replica' ਜਾਂ 'logical' ਆਰਕਾਈਵਿੰਗ ਲਈ ਲੋੜੀਂਦਾ ਹੈ
archive_mode = on # ਆਰਕਾਈਵਰ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਮਰੱਥ ਕਰਦਾ ਹੈ
archive_command = 'test ! -f /mnt/nfs/archive/%f && cp %p /mnt/nfs/archive/%f'
archive_timeout = 600 # ਹਰ 10 ਮਿੰਟਾਂ ਵਿੱਚ ਇੱਕ WAL ਸਵਿੱਚ ਨੂੰ ਮਜਬੂਰ ਕਰੋ
archive_command ਵਿੱਚ:
* %p ਆਰਕਾਈਵ ਕਰਨ ਲਈ WAL ਫਾਈਲ ਦਾ ਪੂਰਾ ਮਾਰਗ ਦਰਸਾਉਂਦਾ ਹੈ।
* %f WAL ਫਾਈਲ ਦਾ ਫਾਈਲ ਨਾਮ ਦਰਸਾਉਂਦਾ ਹੈ।
ਹਾਲਾਂਕਿ ਉਪਰੋਕਤ ਕੌਂਫਿਗਰੇਸ਼ਨ ਸਿੱਧੀ ਜਾਪਦੀ ਹੈ, ਪਰ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਾਤਾਵਰਣ ਵਿੱਚ ਸਧਾਰਨ ਸ਼ੈੱਲ ਕਮਾਂਡਾਂ ‘ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਜੋਖਮ ਪੈਦਾ ਕਰਦਾ ਹੈ।
WAL ਆਰਕਾਈਵਿੰਗ ਵਿੱਚ ਆਮ ਕਮੀਆਂ
ਕਮੀ 1: archive_command ਦੀ “ਚੁੱਪ ਸਫਲਤਾ”
PostgreSQL ਪੂਰੀ ਤਰ੍ਹਾਂ archive_command ਦੇ ਐਗਜ਼ਿਟ ਕੋਡ ‘ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਕਮਾਂਡ 0 ਵਾਪਸ ਕਰਦੀ ਹੈ, ਤਾਂ PostgreSQL ਮੰਨ ਲੈਂਦਾ ਹੈ ਕਿ WAL ਫਾਈਲ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਆਰਕਾਈਵ ਕੀਤੀ ਗਈ ਹੈ ਅਤੇ ਅਸਲ ਫਾਈਲ ਨੂੰ ਰੀਸਾਈਕਲ ਕਰਨ ਲਈ ਅੱਗੇ ਵਧਦਾ ਹੈ।
ਇੱਕ ਆਮ ਗਲਤੀ ਅਜਿਹੀ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ ਜੋ 0 ਵਾਪਸ ਕਰਦੀ ਹੈ ਭਾਵੇਂ ਡੇਟਾ ਸਥਾਈ ਸਟੋਰੇਜ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਫਲੱਸ਼ ਨਾ ਕੀਤਾ ਗਿਆ ਹੋਵੇ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਸਧਾਰਨ cp ਕਮਾਂਡ ਜਿਵੇਂ ਹੀ ਡੇਟਾ ਡੈਸਟੀਨੇਸ਼ਨ ਸਰਵਰ ‘ਤੇ OS ਪੇਜ ਕੈਸ਼ ਵਿੱਚ ਪਹੁੰਚਦਾ ਹੈ, ਸਫਲਤਾ ਵਾਪਸ ਕਰ ਸਕਦੀ ਹੈ। ਜੇਕਰ ਡੈਸਟੀਨੇਸ਼ਨ ਸਰਵਰ ਕੈਸ਼ ਦੇ ਡਿਸਕ ‘ਤੇ ਫਲੱਸ਼ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਪਾਵਰ ਗੁਆ ਦਿੰਦਾ ਹੈ, ਤਾਂ WAL ਫਾਈਲ ਗੁੰਮ ਹੋ ਜਾਂਦੀ ਹੈ, ਪਰ PostgreSQL ਨੇ ਆਪਣੀ ਸਥਾਨਕ ਕਾਪੀ ਪਹਿਲਾਂ ਹੀ ਮਿਟਾ ਦਿੱਤੀ ਹੈ।
ਜੋਖਮ: ਇੱਕ ਟੁੱਟੀ ਹੋਈ WAL ਲੜੀ ਅਤੇ PITR ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥਾ, ਜੋ ਸਿਰਫ ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ ਦੌਰਾਨ ਪਤਾ ਲੱਗਦੀ ਹੈ।
ਸੁਧਾਰ: ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੀ ਆਰਕਾਈਵਿੰਗ ਸਕ੍ਰਿਪਟ ਸਿੰਕ੍ਰੋਨਸ ਰਾਈਟਸ ਨੂੰ ਲਾਗੂ ਕਰਦੀ ਹੈ। ਜੇਕਰ ਸਟੈਂਡਰਡ ਸ਼ੈੱਲ ਕਮਾਂਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਉਹਨਾਂ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੋ ਡੇਟਾ ਦੇ ਫਲੱਸ਼ ਹੋਣ ਦੀ ਗਰੰਟੀ ਦਿੰਦੇ ਹਨ, ਜਾਂ ਇੱਕ ਰੈਪਰ ਸਕ੍ਰਿਪਟ ਲਿਖੋ ਜੋ ਟ੍ਰਾਂਸਫਰ ਤੋਂ ਬਾਅਦ ਫਾਈਲ ਦੇ ਆਕਾਰ ਅਤੇ ਚੈਕਸਮ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ।
ਕਮੀ 2: pg_wal ਪਾਰਟੀਸ਼ਨ ਦਾ ਖਤਮ ਹੋਣਾ (WAL ਬਲੋਟ)
ਜੇਕਰ archive_command ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ (ਗੈਰ-ਜ਼ੀਰੋ ਐਗਜ਼ਿਟ ਕੋਡ ਵਾਪਸ ਕਰਦੀ ਹੈ)—ਨੈੱਟਵਰਕ ਆਊਟੇਜ, ਗਲਤ ਅਨੁਮਤੀਆਂ, ਜਾਂ ਪੂਰੀ ਡੈਸਟੀਨੇਸ਼ਨ ਡਿਸਕ ਕਾਰਨ—ਤਾਂ PostgreSQL WAL ਫਾਈਲ ਨੂੰ pg_wal ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਰੱਖੇਗਾ ਅਤੇ ਅਣਮਿੱਥੇ ਸਮੇਂ ਲਈ ਕਮਾਂਡ ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ।
ਹਾਲਾਂਕਿ ਇਹ ਅਣ-ਆਰਕਾਈਵ ਕੀਤੇ WALs ਨੂੰ ਨਾ ਮਿਟਾ ਕੇ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਪਰ ਇਹ ਉਪਲਬਧਤਾ ਦਾ ਗੰਭੀਰ ਜੋਖਮ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਜੇਕਰ pg_wal ਡਾਇਰੈਕਟਰੀ ਅਜਿਹੇ ਪਾਰਟੀਸ਼ਨ ‘ਤੇ ਰਹਿੰਦੀ ਹੈ ਜੋ 100% ਭਰ ਜਾਂਦਾ ਹੈ, ਤਾਂ PostgreSQL ਇੱਕ PANIC ਜਾਰੀ ਕਰੇਗਾ ਅਤੇ ਕਰੈਸ਼ ਹੋ ਜਾਵੇਗਾ। ਡਾਟਾਬੇਸ ਉਦੋਂ ਤੱਕ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਵੇਗਾ ਜਦੋਂ ਤੱਕ ਜਗ੍ਹਾ ਖਾਲੀ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ।
ਜੋਖਮ: ਪੂਰੀ pg_wal ਪਾਰਟੀਸ਼ਨ ਕਾਰਨ ਡਾਟਾਬੇਸ ਦਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਹੋਣਾ।
ਸੁਧਾਰ:
1. pg_wal ਨੂੰ ਹਮੇਸ਼ਾ ਇੱਕ ਸਮਰਪਿਤ ਡਿਸਕ ਪਾਰਟੀਸ਼ਨ ‘ਤੇ ਰੱਖੋ।
2. pg_wal ਡਾਇਰੈਕਟਰੀ ਦੇ ਆਕਾਰ ‘ਤੇ ਸਖ਼ਤ ਨਿਗਰਾਨੀ ਲਾਗੂ ਕਰੋ।
3. ਅਸਫਲ ਆਰਕਾਈਵ ਕਮਾਂਡਾਂ ਦਾ ਤੁਰੰਤ ਪਤਾ ਲਗਾਉਣ ਲਈ pg_stat_archiver ਵਿਊ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ।
ਕਮੀ 3: ਅਧੂਰੇ ਬੇਸ ਬੈਕਅੱਪ
ਬੇਸ ਬੈਕਅੱਪ ਬੈਕਅੱਪ ਪ੍ਰਕਿਰਿਆ ਦੇ ਦੌਰਾਨ ਤਿਆਰ ਕੀਤੀਆਂ WAL ਫਾਈਲਾਂ ਤੋਂ ਬਿਨਾਂ ਬੇਕਾਰ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਫਾਈਲਸਿਸਟਮ-ਪੱਧਰ ਦਾ ਸਨੈਪਸ਼ਾਟ ਲੈਂਦੇ ਹੋ ਜਾਂ WALs ਨੂੰ ਸਟ੍ਰੀਮ ਕੀਤੇ ਬਿਨਾਂ pg_basebackup (-X stream) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਬੈਕਅੱਪ ਦੇ ਸ਼ੁਰੂ ਅਤੇ ਅੰਤ ਦੇ ਵਿਚਕਾਰ ਤਿਆਰ ਕੀਤੀਆਂ WAL ਫਾਈਲਾਂ ਸਫਲਤਾਪੂਰਵਕ ਆਰਕਾਈਵ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ।
ਜੇਕਰ ਤੁਹਾਡਾ ਆਰਕਾਈਵਰ ਪਛੜ ਰਿਹਾ ਹੈ ਜਾਂ ਅਸਫਲ ਹੋ ਰਿਹਾ ਹੈ, ਅਤੇ ਉਹ ਖਾਸ WAL ਫਾਈਲਾਂ ਗੁੰਮ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਬੇਸ ਬੈਕਅੱਪ ਨੂੰ ਇਕਸਾਰ ਸਥਿਤੀ ਵਿੱਚ ਨਹੀਂ ਲਿਆਂਦਾ ਜਾ ਸਕਦਾ।
ਜੋਖਮ: ਖਰਾਬ ਜਾਂ ਅਣ-ਰਿਕਵਰ ਹੋਣ ਯੋਗ ਬੇਸ ਬੈਕਅੱਪ।
ਸੁਧਾਰ: ਬੈਕਅੱਪ ਪੇਲੋਡ ਵਿੱਚ ਹੀ ਲੋੜੀਂਦੀਆਂ WAL ਫਾਈਲਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਲਈ pg_basebackup -X stream ਦੀ ਵਰਤੋਂ ਕਰੋ, ਜਾਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਬੈਕਅੱਪ ਹੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੋ ਬੇਸ ਬੈਕਅੱਪ ਅਤੇ WAL ਸੈਗਮੈਂਟਾਂ ਵਿਚਕਾਰ ਨਿਰਭਰਤਾ ਨੂੰ ਆਪਣੇ ਆਪ ਪ੍ਰਬੰਧਿਤ ਕਰਦੇ ਹਨ।
ਕਮੀ 4: ਟਾਈਮਲਾਈਨ ਉਲਝਣ ਅਤੇ ਸਪਲਿਟ-ਬ੍ਰੇਨ ਸਥਿਤੀਆਂ
ਜਦੋਂ ਇੱਕ ਸਟੈਂਡਬਾਏ ਸਰਵਰ ਨੂੰ ਪ੍ਰਾਇਮਰੀ ਵਿੱਚ ਪ੍ਰਮੋਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ PostgreSQL “ਟਾਈਮਲਾਈਨ ID” (WAL ਫਾਈਲ ਨਾਮ ਦਾ ਪਹਿਲਾ ਹਿੱਸਾ, ਉਦਾਹਰਨ ਲਈ, 0000000200000001000000A4) ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ। ਇਹ ਨਵੇਂ ਪ੍ਰਾਇਮਰੀ ਨੂੰ ਪੁਰਾਣੇ ਪ੍ਰਾਇਮਰੀ ਦੇ WAL ਇਤਿਹਾਸ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਹਾਲਾਂਕਿ, ਜੇਕਰ ਪੁਰਾਣਾ ਪ੍ਰਾਇਮਰੀ ਗਲਤੀ ਨਾਲ ਸਹੀ ਤਰ੍ਹਾਂ ਫੈਂਸ ਕੀਤੇ ਬਿਨਾਂ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ (ਇੱਕ ਸਪਲਿਟ-ਬ੍ਰੇਨ ਸਥਿਤੀ), ਤਾਂ ਇਹ ਪੁਰਾਣੀ ਟਾਈਮਲਾਈਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਸੇ ਆਰਕਾਈਵ ਸਥਾਨ ‘ਤੇ WAL ਫਾਈਲਾਂ ਨੂੰ ਪੁਸ਼ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ archive_command ਅੰਨ੍ਹੇਵਾਹ ਫਾਈਲਾਂ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਆਪਣੀ ਆਰਕਾਈਵ ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦੇ ਹੋ।
ਜੋਖਮ: ਓਵਰਰਾਈਟ ਕੀਤੀਆਂ WAL ਫਾਈਲਾਂ, ਖਰਾਬ ਆਰਕਾਈਵ, ਅਤੇ ਅਣ-ਰਿਕਵਰ ਹੋਣ ਯੋਗ ਡਾਟਾਬੇਸ।
ਸੁਧਾਰ: ਤੁਹਾਡੇ archive_command ਨੂੰ ਕਦੇ ਵੀ ਮੌਜੂਦਾ ਫਾਈਲ ਨੂੰ ਓਵਰਰਾਈਟ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਪਹਿਲਾਂ ਦਿੱਤੀ ਗਈ ਬੁਨਿਆਦੀ ਕੌਂਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਨੋਟ ਕਰੋ, ਅਸੀਂ test ! -f /mnt/nfs/archive/%f ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਸੀ ਤਾਂ ਜੋ ਜੇਕਰ ਫਾਈਲ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੋਵੇ ਤਾਂ ਸਪੱਸ਼ਟ ਤੌਰ ‘ਤੇ ਅਸਫਲ ਹੋ ਜਾਵੇ।
ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਦੇ ਜੋਖਮਾਂ ਨੂੰ ਘਟਾਉਣਾ: ਪ੍ਰੋਡਕਸ਼ਨ ਦੇ ਵਧੀਆ ਅਭਿਆਸ
ਆਪਣੀ PostgreSQL ਆਰਕਾਈਵਿੰਗ ਰਣਨੀਤੀ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਨ ਲਈ, ਹੇਠਾਂ ਦਿੱਤੇ ਵਧੀਆ ਅਭਿਆਸਾਂ ਨੂੰ ਲਾਗੂ ਕਰੋ।
1. ਆਰਕਾਈਵਰ ਪ੍ਰਕਿਰਿਆ ਦੀ ਮੂਲ ਰੂਪ ਵਿੱਚ ਨਿਗਰਾਨੀ ਕਰੋ
PostgreSQL ਇੱਕ ਬਿਲਟ-ਇਨ ਵਿਊ, pg_stat_archiver ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜੋ ਤੁਹਾਡੀ ਆਰਕਾਈਵਿੰਗ ਪ੍ਰਕਿਰਿਆ ਦੀ ਸਫਲਤਾ ਅਤੇ ਅਸਫਲਤਾ ਨੂੰ ਟਰੈਕ ਕਰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਇਸ ਵਿਊ ਨੂੰ ਆਪਣੇ ਓਬਜ਼ਰਵੇਬਿਲਿਟੀ ਸਟੈਕ (ਉਦਾਹਰਨ ਲਈ, Prometheus, Datadog, ਜਾਂ Zabbix) ਵਿੱਚ ਜੋੜਨਾ ਚਾਹੀਦਾ ਹੈ।
SELECT
archived_count,
last_archived_wal,
last_archived_time,
failed_count,
last_failed_wal,
last_failed_time,
stats_reset
FROM pg_stat_archiver;
ਕੌਂਫਿਗਰ ਕਰਨ ਲਈ ਅਲਰਟਿੰਗ ਥ੍ਰੈਸ਼ਹੋਲਡ:
* ਜੇਕਰ failed_count ਵਧਦਾ ਹੈ ਤਾਂ ਅਲਰਟ ਕਰੋ।
* ਜੇਕਰ now() ਅਤੇ last_archived_time ਵਿਚਕਾਰ ਸਮੇਂ ਦਾ ਅੰਤਰ ਤੁਹਾਡੇ RPO ਥ੍ਰੈਸ਼ਹੋਲਡ (ਉਦਾਹਰਨ ਲਈ, 15 ਮਿੰਟ) ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ ਤਾਂ ਅਲਰਟ ਕਰੋ, ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਕਿ ਘੱਟ-ਟ੍ਰੈਫਿਕ ਵਾਲੇ ਡਾਟਾਬੇਸ ਵਿੱਚ ਕੁਦਰਤੀ ਤੌਰ ‘ਤੇ ਦੇਰੀ ਹੋ ਸਕਦੀ ਹੈ ਜਦੋਂ ਤੱਕ archive_timeout ਸੈੱਟ ਨਹੀਂ ਹੁੰਦਾ।
2. archive_timeout ਦਾ ਲਾਭ ਉਠਾਓ
ਘੱਟ ਰਾਈਟ ਵਾਲੀਅਮ ਵਾਲੇ ਡਾਟਾਬੇਸ ਵਿੱਚ, ਇੱਕ 16MB WAL ਫਾਈਲ ਨੂੰ ਭਰਨ ਵਿੱਚ ਘੰਟੇ ਲੱਗ ਸਕਦੇ ਹਨ। ਜਦੋਂ ਤੱਕ ਇਹ ਭਰ ਨਹੀਂ ਜਾਂਦੀ, ਇਹ ਆਰਕਾਈਵ ਨਹੀਂ ਹੁੰਦੀ। ਜੇਕਰ ਸਰਵਰ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਥਾਨਕ ਡਿਸਕ ਗੁੰਮ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਘੰਟਿਆਂ ਦੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਗੁਆ ਦਿੰਦੇ ਹੋ।
archive_timeout = 600 (10 ਮਿੰਟ) ਸੈੱਟ ਕਰਨਾ PostgreSQL ਨੂੰ ਇੱਕ ਨਵੀਂ WAL ਫਾਈਲ ‘ਤੇ ਸਵਿਚ ਕਰਨ ਅਤੇ ਮੌਜੂਦਾ ਨੂੰ ਆਰਕਾਈਵ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ, ਭਾਵੇਂ ਇਹ ਪੂਰੀ ਨਾ ਹੋਵੇ। ਇਹ ਗਰੰਟੀ ਦਿੰਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ RPO 10 ਮਿੰਟ ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੁੰਦਾ, ਅੰਸ਼ਕ ਤੌਰ ‘ਤੇ ਭਰੀਆਂ WAL ਫਾਈਲਾਂ ਕਾਰਨ ਥੋੜ੍ਹੀ ਜਿਹੀ ਜ਼ਿਆਦਾ ਸਟੋਰੇਜ ਵਰਤੋਂ ਦੀ ਕੀਮਤ ‘ਤੇ।
3. archive_library (PostgreSQL 15+) ‘ਤੇ ਤਬਦੀਲੀ
ਇਤਿਹਾਸਕ ਤੌਰ ‘ਤੇ, archive_command ਹਰ ਇੱਕ WAL ਫਾਈਲ ਲਈ ਇੱਕ ਨਵੀਂ ਸ਼ੈੱਲ ਪ੍ਰਕਿਰਿਆ ਪੈਦਾ ਕਰਦਾ ਸੀ। ਉੱਚ-ਥ੍ਰੂਪੁੱਟ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਜੋ ਪ੍ਰਤੀ ਮਿੰਟ ਸੈਂਕੜੇ WAL ਫਾਈਲਾਂ ਤਿਆਰ ਕਰਦੇ ਹਨ, ਸ਼ੈੱਲ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਫੋਰਕ ਕਰਨ ਦਾ ਓਵਰਹੈੱਡ ਇੱਕ ਪ੍ਰਦਰਸ਼ਨ ਰੁਕਾਵਟ ਬਣ ਜਾਂਦਾ ਹੈ।
PostgreSQL 15 ਨੇ archive_library ਪੈਰਾਮੀਟਰ ਪੇਸ਼ ਕੀਤਾ, ਜਿਸ ਨਾਲ WAL ਆਰਕਾਈਵਿੰਗ ਨੂੰ ਡਾਇਨਾਮਿਕ ਤੌਰ ‘ਤੇ ਲੋਡ ਕੀਤੇ C ਮੋਡੀਊਲਾਂ ਦੁਆਰਾ ਸੰਭਾਲਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਸ਼ੈੱਲ-ਫੋਰਕਿੰਗ ਓਵਰਹੈੱਡ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਬਹੁਤ ਜ਼ਿਆਦਾ ਮਜ਼ਬੂਤ, ਉੱਚ-ਪ੍ਰਦਰਸ਼ਨ ਵਾਲੀ ਆਰਕਾਈਵਿੰਗ ਵਿਧੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ PostgreSQL 15 ਜਾਂ ਇਸ ਤੋਂ ਉੱਚੇ ਵਰਜਨ ‘ਤੇ ਹੋ, ਤਾਂ ਉਹਨਾਂ ਬੈਕਅੱਪ ਟੂਲਸ ਦੀ ਭਾਲ ਕਰੋ ਜੋ ਕਸਟਮ ਆਰਕਾਈਵ ਮੋਡੀਊਲਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ।
4. ਨਿਯਮਿਤ ਤੌਰ ‘ਤੇ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਦੀ ਜਾਂਚ ਕਰੋ
ਇੱਕ ਅਣ-ਟੈਸਟ ਕੀਤਾ ਬੈਕਅੱਪ ਬੈਕਅੱਪ ਨਹੀਂ ਹੈ; ਇਹ ਇੱਕ ਇੱਛਾ ਹੈ। ਇਹ ਤਸਦੀਕ ਕਰਨ ਦਾ ਇੱਕੋ ਇੱਕ ਤਰੀਕਾ ਹੈ ਕਿ ਤੁਹਾਡੀ WAL ਆਰਕਾਈਵਿੰਗ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰ ਰਹੀ ਹੈ, ਤੁਹਾਡੀ WAL ਲੜੀ ਅਟੁੱਟ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਬੇਸ ਬੈਕਅੱਪ ਇਕਸਾਰ ਹਨ, ਉਹ ਹੈ ਨਿਯਮਤ, ਸਵੈਚਲਿਤ PITR ਟੈਸਟ ਕਰਨਾ।
ਇੱਕ ਅਸਥਾਈ ਇੰਸਟੈਂਸ ਨੂੰ ਸਪਿਨ ਅੱਪ ਕਰੋ, ਬੇਸ ਬੈਕਅੱਪ ਨੂੰ ਰੀਸਟੋਰ ਕਰੋ, ਆਪਣੇ ਆਰਕਾਈਵ ਤੋਂ ਖਿੱਚਣ ਲਈ restore_command ਨੂੰ ਕੌਂਫਿਗਰ ਕਰੋ, ਅਤੇ ਇੱਕ ਖਾਸ ਟਾਈਮਸਟੈਂਪ ‘ਤੇ ਰਿਕਵਰ ਕਰੋ। ਤਸਦੀਕ ਕਰੋ ਕਿ ਡਾਟਾਬੇਸ ਇੱਕ ਇਕਸਾਰ ਸਥਿਤੀ ‘ਤੇ ਪਹੁੰਚਦਾ ਹੈ ਅਤੇ ਕਨੈਕਸ਼ਨਾਂ ਲਈ ਖੁੱਲ੍ਹਦਾ ਹੈ।
CloudSave ਨਾਲ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਬੈਕਅੱਪ ਅਤੇ ਰਿਕਵਰੀ
archive_command ਲਈ ਕਸਟਮ ਸ਼ੈੱਲ ਸਕ੍ਰਿਪਟਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ, WAL ਡਿਡਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸੰਭਾਲਣਾ, ਅਤੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗਸ ਲਈ ਸੁਰੱਖਿਅਤ, ਆਫਸਾਈਟ ਸਟੋਰੇਜ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ IT ਟੀਮਾਂ ਲਈ ਜਲਦੀ ਹੀ ਇੱਕ ਸੰਚਾਲਨ ਬੋਝ ਬਣ ਸਕਦਾ ਹੈ।
ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ CloudSave ਐਂਟਰਪ੍ਰਾਈਜ਼ PostgreSQL ਵਾਤਾਵਰਣਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਮੁੱਲ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। CloudSave ਉੱਪਰ ਚਰਚਾ ਕੀਤੀਆਂ ਗਈਆਂ ਮੈਨੂਅਲ ਕਮੀਆਂ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ PostgreSQL ਦੇ ਨੇਟਿਵ ਬੈਕਅੱਪ ਅਤੇ WAL ਆਰਕਾਈਵਿੰਗ API ਨਾਲ ਜੁੜਦਾ ਹੈ।
ਨਾਜ਼ੁਕ ਬੈਸ਼ ਸਕ੍ਰਿਪਟਾਂ ਲਿਖਣ ਦੀ ਬਜਾਏ, CloudSave ਇੱਕ ਮਜ਼ਬੂਤ, ਏਜੰਟ-ਅਧਾਰਿਤ ਜਾਂ ਏਜੰਟ-ਰਹਿਤ ਏਕੀਕਰਣ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ:
* ਡਿਲੀਵਰੀ ਦੀ ਗਰੰਟੀ ਦਿੰਦਾ ਹੈ: ਸਟੈਂਡਰਡ ਸ਼ੈੱਲ ਕਮਾਂਡਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਆਫਸਾਈਟ ਜਾਂ ਕਲਾਉਡ ਸਟੋਰੇਜ ਲਈ ਪ੍ਰਮਾਣਿਤ, ਚੈਕਸਮ-ਵੈਲੀਡੇਟਿਡ ਟ੍ਰਾਂਸਫਰ ਨਾਲ ਬਦਲਦਾ ਹੈ।
* WAL ਬਲੋਟ ਨੂੰ ਰੋਕਦਾ ਹੈ: ਸਰਗਰਮੀ ਨਾਲ pg_wal ਡਾਇਰੈਕਟਰੀ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ ਅਤੇ ਪਾਰਟੀਸ਼ਨ ਖਤਮ ਹੋਣ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ ਪ੍ਰਸ਼ਾਸਕਾਂ ਨੂੰ ਅਲਰਟ ਕਰਦਾ ਹੈ।
* PITR ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਦਾ ਹੈ: ਇੱਕ ਅਨੁਭਵੀ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਨੂੰ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਉਹ ਸਹੀ ਮਿੰਟ ਚੁਣਦੇ ਹੋ ਜਿਸ ‘ਤੇ ਤੁਸੀਂ ਰਿਕਵਰ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ CloudSave ਆਪਣੇ ਆਪ ਸਹੀ ਬੇਸ ਬੈਕਅੱਪ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸ ਸਥਿਤੀ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਲੋੜੀਂਦੀਆਂ WAL ਫਾਈਲਾਂ ਦੀ ਸਹੀ ਲੜੀ ਨੂੰ ਸਟ੍ਰੀਮ ਕਰਦਾ ਹੈ।
* ਟਾਈਮਲਾਈਨਾਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ: ਸਮਝਦਾਰੀ ਨਾਲ PostgreSQL ਟਾਈਮਲਾਈਨ ਇਤਿਹਾਸ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਫੇਲਓਵਰ ਅਤੇ ਸਪਲਿਟ-ਬ੍ਰੇਨ ਸਥਿਤੀਆਂ ਤੁਹਾਡੀ ਬੈਕਅੱਪ ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਖਰਾਬ ਨਾ ਕਰਨ।
WAL ਪ੍ਰਬੰਧਨ ਦੇ ਭਾਰੀ ਕੰਮ ਨੂੰ CloudSave ‘ਤੇ ਪਾ ਕੇ, DBAs ਕੁਐਰੀ ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਅਤੇ ਡਾਟਾਬੇਸ ਪ੍ਰਦਰਸ਼ਨ ‘ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰ ਸਕਦੇ ਹਨ, ਇਹ ਜਾਣਦੇ ਹੋਏ ਕਿ ਉਹਨਾਂ ਦੇ RPO ਅਤੇ RTO SLAs ਇੱਕ ਐਂਟਰਪ੍ਰਾਈਜ਼-ਗ੍ਰੇਡ ਪਲੇਟਫਾਰਮ ਦੁਆਰਾ ਸੁਰੱਖਿਅਤ ਹਨ।
ਸਿੱਟਾ
PostgreSQL WAL ਆਰਕਾਈਵਿੰਗ ਡਾਟਾਬੇਸ ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ ਦੀ ਰੀੜ੍ਹ ਦੀ ਹੱਡੀ ਹੈ। ਹਾਲਾਂਕਿ ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਤੋਂ ਦੂਜੀ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਫਾਈਲ ਕਾਪੀ ਕਰਨ ਦਾ ਸੰਕਲਪ ਸਧਾਰਨ ਜਾਪਦਾ ਹੈ, ਪਰ ਐਜ ਕੇਸ—ਚੁੱਪ-ਚਾਪ ਅਸਫਲਤਾਵਾਂ, ਡਿਸਕ ਦਾ ਖਤਮ ਹੋਣਾ, ਅਤੇ ਟਾਈਮਲਾਈਨ ਦਾ ਭਟਕਣਾ—ਡੇਟਾ ਦੀ ਇਕਸਾਰਤਾ ਲਈ ਗੰਭੀਰ ਜੋਖਮ ਪੈਦਾ ਕਰਦੇ ਹਨ।
pg_wal ਦੇ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਸਮਝ ਕੇ, ਵਿਨਾਸ਼ਕਾਰੀ archive_command ਕੌਂਫਿਗਰੇਸ਼ਨਾਂ ਤੋਂ ਸਖਤੀ ਨਾਲ ਬਚ ਕੇ, pg_stat_archiver ਦੀ ਨਿਗਰਾਨੀ ਕਰਕੇ, ਅਤੇ CloudSave ਵਰਗੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਬੈਕਅੱਪ ਪਲੇਟਫਾਰਮਾਂ ਦਾ ਲਾਭ ਉਠਾ ਕੇ, ਤੁਸੀਂ ਇੱਕ ਲਚਕੀਲਾ PostgreSQL ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਬਣਾ ਸਕਦੇ ਹੋ ਜੋ ਹਾਰਡਵੇਅਰ ਅਸਫਲਤਾਵਾਂ, ਮਨੁੱਖੀ ਗਲਤੀਆਂ, ਅਤੇ ਭਿਆਨਕ ਆਊਟੇਜ ਤੋਂ ਬਚਣ ਦੇ ਸਮਰੱਥ ਹੈ, ਬਿਨਾਂ ਕਿਸੇ ਇੱਕ ਕਮਿਟ ਕੀਤੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਨੂੰ ਗੁਆਏ।
PostgreSQL WAL ਆਰਕਾਈਵਿੰਗ ਦੀਆਂ ਆਮ ਕਮੀਆਂ ਬਾਰੇ ਜਾਣੋ ਜੋ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਵੱਲ ਲੈ ਜਾਂਦੀਆਂ ਹਨ। ਮਾਹਰ DBA ਵਧੀਆ ਅਭਿਆਸਾਂ, ਕੌਂਫਿਗਰੇਸ਼ਨ ਸੁਝਾਅ, ਅਤੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਡਾਟਾਬੇਸ ਲਈ ਭਰੋਸੇਯੋਗ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ (PITR) ਨੂੰ ਕਿਵੇਂ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ, ਇਸ ਬਾਰੇ ਸਿੱਖੋ।
