Categories
Disaster Recovery

**

DevOps ਇੰਜੀਨੀਅਰਾਂ, ਡਾਟਾਬੇਸ ਐਡਮਿਨਿਸਟ੍ਰੇਟਰਾਂ (DBAs), ਅਤੇ IT ਸਿਸਟਮ ਆਰਕੀਟੈਕਟਾਂ ਲਈ, ਰਿਕਵਰੀ ਟਾਈਮ ਓਬਜੈਕਟਿਵ (RTO) ਅਤੇ ਰਿਕਵਰੀ ਪੁਆਇੰਟ ਓਬਜੈਕਟਿਵ (RPO) ਸਿਰਫ਼ ਕਾਰੋਬਾਰੀ ਨਿਰੰਤਰਤਾ ਦੇ ਸ਼ਬਦਾਂ ਤੋਂ ਵੱਧ ਹਨ—ਇਹ ਸਖ਼ਤ ਇੰਜੀਨੀਅਰਿੰਗ ਸੀਮਾਵਾਂ ਹਨ। ਮਿਸ਼ਨ-ਕ੍ਰਿਟੀਕਲ ਡਾਟਾਬੇਸ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੇ ਸਮੇਂ, ਇਹਨਾਂ ਮੈਟ੍ਰਿਕਸ ਦੀ ਸਹੀ ਗਣਨਾ ਕਰਨ, ਉਹਨਾਂ ਲਈ ਆਰਕੀਟੈਕਚਰ ਤਿਆਰ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਰਹਿਣ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਡਾਟਾ ਦਾ ਭਾਰੀ ਨੁਕਸਾਨ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਲਈ ਡਾਊਨਟਾਈਮ ਹੋ ਸਕਦਾ ਹੈ।

ਆਧੁਨਿਕ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ, RTO ਅਤੇ RPO ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਡਾਟਾਬੇਸ ਇੰਟਰਨਲਸ, ਸਟੋਰੇਜ I/O, ਨੈੱਟਵਰਕ ਥ੍ਰੂਪੁੱਟ, ਅਤੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਮਕੈਨਿਕਸ ਦੀ ਡੂੰਘੀ ਸਮਝ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ ਗਾਈਡ ਪ੍ਰੋਡਕਸ਼ਨ ਡਾਟਾਬੇਸ ਸਿਸਟਮਾਂ ਲਈ RTO ਅਤੇ RPO ਦੀ ਗਣਨਾ, ਟੈਸਟਿੰਗ ਅਤੇ ਅਨੁਕੂਲਤਾ ਲਈ ਤਕਨੀਕੀ ਵਿਧੀਆਂ ਦੀ ਪੜਚੋਲ ਕਰਦੀ ਹੈ।

ਡਾਟਾਬੇਸ ਸਿਸਟਮਾਂ ਵਿੱਚ RPO (ਰਿਕਵਰੀ ਪੁਆਇੰਟ ਓਬਜੈਕਟਿਵ) ਨੂੰ ਸਮਝਣਾ

RPO ਸਮੇਂ ਦੇ ਰੂਪ ਵਿੱਚ ਮਾਪੇ ਗਏ ਡਾਟਾ ਦੇ ਨੁਕਸਾਨ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਸਵੀਕਾਰਯੋਗ ਮਾਤਰਾ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ RPO 15 ਮਿੰਟ ਹੈ, ਤਾਂ ਦੁਪਹਿਰ 12:00 ਵਜੇ ਆਈ ਕਿਸੇ ਆਫ਼ਤ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਘੱਟੋ-ਘੱਟ 11:45 AM ਤੱਕ ਦੇ ਸਾਰੇ ਕਮਿਟ ਕੀਤੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਰਿਕਵਰ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਡਾਟਾਬੇਸ ਲਈ, RPO ਤੁਹਾਡੀ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਪ੍ਰਬੰਧਨ ਰਣਨੀਤੀ (PostgreSQL ਵਿੱਚ WAL, Oracle ਵਿੱਚ Redo Logs, SQL Server ਵਿੱਚ Transaction Logs) ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਡਾਟਾ ਦੇ ਨੁਕਸਾਨ ਅਤੇ ਲੌਗ ਜਨਰੇਸ਼ਨ ਦੇ ਮਕੈਨਿਕਸ

ਪ੍ਰਾਪਤ ਕਰਨ ਯੋਗ RPO ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਆਪਣੇ ਡਾਟਾਬੇਸ ਦੀ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਜਨਰੇਸ਼ਨ ਦਰ ਨੂੰ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਹਰ 15 ਮਿੰਟਾਂ ਵਿੱਚ ਬੈਕਅੱਪ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਲੌਗ ਭੇਜ ਰਹੇ ਹੋ, ਪਰ ਤੁਹਾਡਾ ਨੈੱਟਵਰਕ ਉਸ ਸਮੇਂ ਦੇ ਅੰਦਰ 15 ਮਿੰਟਾਂ ਦੇ ਲੌਗ ਟ੍ਰਾਂਸਫਰ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ ਅਸਲ RPO ਲਗਾਤਾਰ ਘਟਦਾ ਜਾਵੇਗਾ।

ਤੁਸੀਂ ਨੇਟਿਵ SQL ਕਮਾਂਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਪਣੀ ਲੌਗ ਜਨਰੇਸ਼ਨ ਦਰ ਨੂੰ ਬੇਸਲਾਈਨ ਕਰ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨ ਲਈ, PostgreSQL (ਵਰਜਨ 10+) ਵਿੱਚ, ਤੁਸੀਂ ਇੱਕ ਖਾਸ ਅੰਤਰਾਲ ਵਿੱਚ ਰਾਈਟ-ਅਹੇਡ ਲੌਗ (WAL) ਜਨਰੇਸ਼ਨ ਦਰ ਨੂੰ ਮਾਪ ਸਕਦੇ ਹੋ:

-- Run this at T=0
SELECT pg_current_wal_lsn() AS start_lsn;

-- Wait exactly 5 minutes (300 seconds), then run:
SELECT pg_current_wal_lsn() AS end_lsn,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), 'START_LSN_VALUE')) AS wal_generated_size,
       pg_wal_lsn_diff(pg_current_wal_lsn(), 'START_LSN_VALUE') / 300 AS bytes_per_second;

ਜੇਕਰ ਇਹ ਕੁਐਰੀ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਪੀਕ ਲੋਡ ਦੌਰਾਨ 50 MB/s WAL ਡਾਟਾ ਤਿਆਰ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ 15-ਮਿੰਟ ਦੇ RPO ਲਈ ਤੁਹਾਡੇ ਬੈਕਅੱਪ ਸਟੋਰੇਜ ਵਿੱਚ 45 GB ਲੌਗ ਡਾਟਾ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਇਸ RPO ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣ ਲਈ ਤੁਹਾਡੇ ਨੈੱਟਵਰਕ ਅਤੇ ਸਟੋਰੇਜ ਟਾਰਗੇਟਾਂ ਨੂੰ 50 MB/s ਤੋਂ ਵੱਧ ਦੀ ਨਿਰੰਤਰ ਰਾਈਟ ਸਪੀਡ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਸਿੰਕ੍ਰੋਨਸ ਬਨਾਮ ਅਸਿੰਕ੍ਰੋਨਸ ਰਿਪਲੀਕੇਸ਼ਨ ਦਾ ਪ੍ਰਭਾਵ

ਬਹੁਤ ਸਾਰੇ DBAs RPO ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਹਾਈ ਅਵੇਲੇਬਿਲਿਟੀ (HA) ਰਿਪਲੀਕੇਸ਼ਨ ‘ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਹਾਲਾਂਕਿ, ਰਿਪਲੀਕੇਸ਼ਨ ਬੈਕਅੱਪ ਨਹੀਂ ਹੈ। ਇੱਕ ਡ੍ਰੌਪ ਕੀਤੀ ਗਈ ਟੇਬਲ (DROP TABLE users;) ਤੁਰੰਤ ਰਿਪਲੀਕੇਟ ਹੋ ਜਾਂਦੀ ਹੈ।

ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ (DR) ਲਈ ਰਿਪਲੀਕੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਰਿਪਲੀਕੇਸ਼ਨ ਮੋਡ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ RPO ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ:
* ਸਿੰਕ੍ਰੋਨਸ ਰਿਪਲੀਕੇਸ਼ਨ: ਜ਼ੀਰੋ ਦੇ RPO (RPO=0) ਦੀ ਗਰੰਟੀ ਦਿੰਦਾ ਹੈ। ਪ੍ਰਾਇਮਰੀ ਡਾਟਾਬੇਸ ਉਦੋਂ ਤੱਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਨੂੰ ਕਮਿਟ ਨਹੀਂ ਕਰੇਗਾ ਜਦੋਂ ਤੱਕ ਸਟੈਂਡਬਾਏ ਪ੍ਰਾਪਤੀ ਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰਦਾ। ਇਸਦਾ ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਪ੍ਰਾਇਮਰੀ ਰਾਈਟ ਓਪਰੇਸ਼ਨਾਂ ‘ਤੇ ਲੇਟੈਂਸੀ ਵਧ ਜਾਂਦੀ ਹੈ।
* ਅਸਿੰਕ੍ਰੋਨਸ ਰਿਪਲੀਕੇਸ਼ਨ: ਰਿਪਲੀਕੇਸ਼ਨ ਲੈਗ (ਦੇਰੀ) ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਤੁਹਾਡਾ RPO ਅਸਲ ਵਿੱਚ ਤੁਹਾਡੀ ਮੌਜੂਦਾ ਰਿਪਲੀਕੇਸ਼ਨ ਲੈਗ ਦੇ ਬਰਾਬਰ ਹੁੰਦਾ ਹੈ।

PostgreSQL ਵਿੱਚ ਅਸਿੰਕ੍ਰੋਨਸ ਰਿਪਲੀਕੇਸ਼ਨ ਲੈਗ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ, ਇਸਦੀ ਵਰਤੋਂ ਕਰੋ:

SELECT application_name,
       client_addr,
       state,
       sync_state,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replication_lag_bytes
FROM pg_stat_replication;

ਵੱਡੇ ਪੱਧਰ ਦੇ ਡਾਟਾਬੇਸ ਲਈ RTO (ਰਿਕਵਰੀ ਟਾਈਮ ਓਬਜੈਕਟਿਵ) ਨੂੰ ਸਮਝਣਾ

RTO ਡਾਊਨਟਾਈਮ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਸਹਿਣਯੋਗ ਮਿਆਦ ਹੈ। ਡਾਟਾਬੇਸ RTO ਦੀ ਗਣਨਾ ਕਰਨਾ ਬਹੁਤ ਗੁੰਝਲਦਾਰ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਿਰਫ਼ ਫਾਈਲਾਂ ਨੂੰ ਸਰਵਰ ‘ਤੇ ਵਾਪਸ ਕਾਪੀ ਕਰਨ ਵਿੱਚ ਲੱਗਣ ਵਾਲਾ ਸਮਾਂ ਨਹੀਂ ਹੈ।

RTO ਗਣਨਾ ਲਈ ਗਣਿਤਿਕ ਮਾਡਲ

ਇੱਕ ਯਥਾਰਥਵਾਦੀ ਡਾਟਾਬੇਸ RTO ਗਣਨਾ ਵਿੱਚ ਚਾਰ ਵੱਖਰੇ ਪੜਾਵਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:

RTO = T(infra) + T(transfer) + T(restore) + T(recovery)

  1. T(infra) – ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ: ਰਿਪਲੇਸਮੈਂਟ ਕੰਪਿਊਟ ਅਤੇ ਸਟੋਰੇਜ ਨੂੰ ਚਾਲੂ ਕਰਨ ਦਾ ਸਮਾਂ। (ਪਹਿਲਾਂ ਤੋਂ ਤਿਆਰ DR ਸਾਈਟਾਂ ਜਾਂ ਇਨਫਰਾਸਟ੍ਰਕਚਰ-ਐਜ਼-ਕੋਡ ਪਾਈਪਲਾਈਨਾਂ ਨਾਲ ਇਹ ਲਗਭਗ ਜ਼ੀਰੋ ਹੋ ਸਕਦਾ ਹੈ)।
  2. T(transfer) – ਡਾਟਾ ਟ੍ਰਾਂਸਫਰ: ਬੈਕਅੱਪ ਪੇਲੋਡ ਨੂੰ ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਡਾਟਾਬੇਸ ਸਰਵਰ ਤੱਕ ਲਿਜਾਣ ਦਾ ਸਮਾਂ।
  3. T(restore) – ਫਿਜ਼ੀਕਲ ਰੀਸਟੋਰ: ਡਾਟਾ ਫਾਈਲਾਂ ਨੂੰ ਟਾਰਗੇਟ ਡਿਸਕ ‘ਤੇ ਲਿਖਣ ਦਾ ਸਮਾਂ।
  4. T(recovery) – ਡਾਟਾਬੇਸ ਕਰੈਸ਼ ਰਿਕਵਰੀ: ਡਾਟਾਬੇਸ ਇੰਜਣ ਲਈ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗਸ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣ, ਕਮਿਟ ਕੀਤੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਅੱਗੇ ਵਧਾਉਣ, ਅਤੇ ਅਨਕਮਿਟ ਕੀਤੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਵਾਪਸ ਲੈਣ ਦਾ ਸਮਾਂ।

ਟ੍ਰਾਂਸਫਰ ਅਤੇ ਰੀਸਟੋਰ ਸਮੇਂ ਦੀ ਗਣਨਾ

T(transfer) ਅਤੇ T(restore) ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਆਪਣੇ ਨੈੱਟਵਰਕ ਬੈਂਡਵਿਡਥ ਅਤੇ ਡਿਸਕ IOPS/ਥ੍ਰੂਪੁੱਟ ਨੂੰ ਬੇਸਲਾਈਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਸਿਧਾਂਤਕ ਅਧਿਕਤਮ ‘ਤੇ ਨਿਰਭਰ ਨਾ ਰਹੋ; ਆਪਣੇ ਅਸਲ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਦੀ ਜਾਂਚ ਕਰੋ।

ਆਪਣੀ ਬੈਕਅੱਪ ਰਿਪੋਜ਼ਟਰੀ ਅਤੇ ਡਾਟਾਬੇਸ ਸਰਵਰ ਵਿਚਕਾਰ ਨੈੱਟਵਰਕ ਥ੍ਰੂਪੁੱਟ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ iperf3 ਦੀ ਵਰਤੋਂ ਕਰੋ:

# On the backup repository (server)
iperf3 -s

# On the database server (client)
iperf3 -c <backup_repo_ip> -t 60 -P 4

ਆਪਣੇ ਡਾਟਾਬੇਸ ਸਟੋਰੇਜ ਵਾਲਿਊਮ ਦੀ ਕ੍ਰਮਵਾਰ ਰਾਈਟ ਕਾਰਗੁਜ਼ਾਰੀ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ fio ਦੀ ਵਰਤੋਂ ਕਰੋ, ਜੋ ਡਾਟਾਬੇਸ ਰੀਸਟੋਰ ਓਪਰੇਸ਼ਨ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ:

fio --name=restore_sim --ioengine=libaio --rw=write --bs=1M --size=10G --numjobs=4 --iodepth=32 --direct=1 --filename=/var/lib/postgresql/data/testfile

ਜੇਕਰ ਤੁਹਾਡਾ ਡਾਟਾਬੇਸ 5 TB ਹੈ, ਅਤੇ ਤੁਹਾਡੇ fio ਟੈਸਟ 500 MB/s ਦੀ ਅਧਿਕਤਮ ਨਿਰੰਤਰ ਰਾਈਟ ਸਪੀਡ ਦਿਖਾਉਂਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਡਾ ਬਿਲਕੁਲ ਘੱਟੋ-ਘੱਟ T(restore) ਲਗਭਗ 2.8 ਘੰਟੇ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ ਬਿਜ਼ਨਸ SLA 1-ਘੰਟੇ ਦੇ RTO ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ, ਤਾਂ ਰਵਾਇਤੀ ਸਟ੍ਰੀਮਿੰਗ ਰੀਸਟੋਰ ਅਸਫਲ ਹੋ ਜਾਣਗੇ। ਤੁਹਾਨੂੰ ਆਪਣੇ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਸਟੋਰੇਜ-ਪੱਧਰ ਦੇ ਸਨੈਪਸ਼ਾਟ ਜਾਂ ਬਲਾਕ-ਪੱਧਰ ਦੀ ਰਿਪਲੀਕੇਸ਼ਨ ਵੱਲ ਮੋੜਨਾ ਚਾਹੀਦਾ ਹੈ।

ਲੁਕਿਆ ਹੋਇਆ ਜਾਲ: T(recovery)

ਸਭ ਤੋਂ ਵੱਧ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਵਿੱਚ ਗਲਤੀ T(recovery) ਦੀ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਹਫਤਾਵਾਰੀ ਪੂਰਾ ਬੈਕਅੱਪ ਰੀਸਟੋਰ ਕਰਦੇ ਹੋ ਅਤੇ ਆਪਣੇ RPO ਤੱਕ ਪਹੁੰਚਣ ਲਈ 6 ਦਿਨਾਂ ਦੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਡਾਟਾਬੇਸ ਇੰਜਣ ਨੂੰ ਹਰ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਨੂੰ ਕ੍ਰਮਵਾਰ ਦੁਬਾਰਾ ਚਲਾਉਣਾ ਪਵੇਗਾ।

500 GB ਦੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗਸ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣ ਵਿੱਚ ਘੰਟੇ ਲੱਗ ਸਕਦੇ ਹਨ, ਜੋ ਸਿੰਗਲ-ਥ੍ਰੈੱਡ CPU ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਸਟੋਰੇਜ IOPS ਦੁਆਰਾ ਬੁਰੀ ਤਰ੍ਹਾਂ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦੇ ਹਨ। T(recovery) ਨੂੰ ਘੱਟ ਕਰਨ ਲਈ, ਆਪਣੇ ਪੂਰੇ ਜਾਂ ਡਿਫਰੈਂਸ਼ੀਅਲ ਬੈਕਅੱਪ ਦੀ ਬਾਰੰਬਾਰਤਾ ਵਧਾਓ।

ਅੰਤਰ ਨੂੰ ਪੂਰਾ ਕਰਨਾ: RTO ਅਤੇ RPO ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਲਈ ਵਿਹਾਰਕ ਕਦਮ

ਸਿਧਾਂਤਕ RTO ਅਤੇ RPO ਦੀ ਗਣਨਾ ਕਰਨਾ ਸਿਰਫ਼ ਪਹਿਲਾ ਕਦਮ ਹੈ। ਮਿਸ਼ਨ-ਕ੍ਰਿਟੀਕਲ ਵਾਤਾਵਰਣਾਂ ਲਈ ਨਿਰੰਤਰ ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਕਦਮ 1: ਨਿਰੰਤਰ ਆਰਕਾਈਵਿੰਗ ਲਾਗੂ ਕਰੋ

ਸਿੰਕ੍ਰੋਨਸ ਰਿਪਲੀਕੇਸ਼ਨ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਨੁਕਸਾਨ ਤੋਂ ਬਿਨਾਂ ਸਬ-ਮਿੰਟ RPOs ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਨਿਰੰਤਰ ਲੌਗ ਆਰਕਾਈਵਿੰਗ ਲਾਗੂ ਕਰੋ। ਲੌਗ ਫਾਈਲ ਦੇ ਭਰਨ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਬਜਾਏ (ਜਿਸ ਵਿੱਚ ਘੱਟ-ਟ੍ਰੈਫਿਕ ਪੀਰੀਅਡਾਂ ਦੌਰਾਨ ਘੰਟੇ ਲੱਗ ਸਕਦੇ ਹਨ), ਨਿਯਮਤ ਅੰਤਰਾਲਾਂ ‘ਤੇ ਲੌਗ ਸਵਿੱਚਾਂ ਨੂੰ ਮਜਬੂਰ ਕਰੋ।

SQL Server ਵਿੱਚ, ਤੁਸੀਂ ਅਕਸਰ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਬੈਕਅੱਪ ਨੂੰ ਆਟੋਮੇਟ ਕਰ ਸਕਦੇ ਹੋ:

BACKUP LOG [MissionCriticalDB] 
TO DISK = N'\BackupRepoSQLMissionCriticalDB_Log.trn' 
WITH NOFORMAT, NOINIT, 
NAME = N'MissionCriticalDB-Transaction Log Backup', 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;

ਵਧੀਆ ਅਭਿਆਸ: ਇਸ ਜੌਬ ਨੂੰ ਤੁਹਾਡੀਆਂ RPO ਲੋੜਾਂ ਦੇ ਆਧਾਰ ‘ਤੇ ਹਰ 1-5 ਮਿੰਟਾਂ ਵਿੱਚ ਚੱਲਣ ਲਈ ਤਹਿ ਕਰੋ।

ਕਦਮ 2: ਰੀਸਟੋਰ ਟੈਸਟਿੰਗ ਨੂੰ ਆਟੋਮੇਟ ਕਰੋ

ਇੱਕ ਅਣਪ੍ਰਮਾਣਿਤ ਬੈਕਅੱਪ ਸਿਰਫ਼ ਇੱਕ ਸਿਧਾਂਤਕ ਸੰਕਲਪ ਹੈ। ਆਪਣੇ ਗਣਨਾ ਕੀਤੇ RTO ਦੀ ਗਰੰਟੀ ਦੇਣ ਲਈ, ਤੁਹਾਨੂੰ ਆਟੋਮੇਟਿਡ ਰੀਸਟੋਰ ਟੈਸਟਿੰਗ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

CloudSave ਵਰਗੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਬੈਕਅੱਪ ਪਲੇਟਫਾਰਮ ਆਟੋਮੇਟਿਡ, ਆਈਸੋਲੇਟਿਡ ਰਿਕਵਰੀ ਟੈਸਟਿੰਗ ਪ੍ਰਦਾਨ ਕਰਕੇ ਇਸਨੂੰ ਸਰਲ ਬਣਾਉਂਦੇ ਹਨ। CloudSave ਆਪਣੇ ਆਪ ਇੱਕ ਸੈਂਡਬੌਕਸ ਵਾਤਾਵਰਣ ਨੂੰ ਚਾਲੂ ਕਰ ਸਕਦਾ ਹੈ, ਨਵੀਨਤਮ ਬੈਕਅੱਪ ਨੂੰ ਮਾਊਂਟ ਕਰ ਸਕਦਾ ਹੈ, ਪੂਰੀ ਡਾਟਾਬੇਸ ਰਿਕਵਰੀ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਹੀ RTO ਨੂੰ ਮਾਪਣ ਅਤੇ ਡਾਟਾ ਦੀ ਇਕਸਾਰਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਸਟਮ ਵੈਲੀਡੇਸ਼ਨ ਸਕ੍ਰਿਪਟਾਂ (ਜਿਵੇਂ ਕਿ SQL Server ਲਈ DBCC CHECKDB) ਨੂੰ ਚਲਾ ਸਕਦਾ ਹੈ। ਇਹ RTO ਨੂੰ ਇੱਕ ਅਨੁਮਾਨ ਤੋਂ ਇੱਕ ਸਾਬਤ, ਰਿਪੋਰਟ ਕਰਨ ਯੋਗ ਮੈਟ੍ਰਿਕ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।

ਕਦਮ 3: SLA ਉਲੰਘਣਾਵਾਂ ‘ਤੇ ਨਿਗਰਾਨੀ ਅਤੇ ਚੇਤਾਵਨੀ

ਤੁਹਾਡੇ ਮਾਨੀਟਰਿੰਗ ਸਟੈਕ (Prometheus, Datadog, Zabbix) ਨੂੰ ਉਹਨਾਂ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਸਰਗਰਮੀ ਨਾਲ ਟਰੈਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ RTO/RPO SLAs ਨੂੰ ਖਤਰਾ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਚੇਤਾਵਨੀ ਨਿਯਮਾਂ ਨੂੰ ਇਹਨਾਂ ਲਈ ਕੌਂਫਿਗਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ:
* ਬੈਕਅੱਪ ਜੌਬ ਅਸਫਲਤਾਵਾਂ: RPO ਲਈ ਤੁਰੰਤ ਖਤਰਾ।
* ਲੌਗ ਸ਼ਿਪਿੰਗ ਲੇਟੈਂਸੀ: ਜੇਕਰ ਲੌਗ ਟ੍ਰਾਂਸਫਰ ਜਨਰੇਸ਼ਨ ਅੰਤਰਾਲ ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੈਂਦਾ ਹੈ।
* ਸਟੋਰੇਜ IOPS ਥ੍ਰੋਟਲਿੰਗ: ਕਲਾਉਡ ਪ੍ਰੋਵਾਈਡਰ (ਜਿਵੇਂ ਕਿ AWS EBS) IOPS ਨੂੰ ਥ੍ਰੋਟਲ ਕਰਦੇ ਹਨ ਜੇਕਰ ਬਰਸਟ ਕ੍ਰੈਡਿਟ ਖਤਮ ਹੋ ਜਾਂਦੇ ਹਨ, ਜੋ ਅਸਲ ਐਮਰਜੈਂਸੀ ਦੌਰਾਨ ਤੁਹਾਡੇ RTO ਨੂੰ ਚੁੱਪਚਾਪ ਨਸ਼ਟ ਕਰ ਦੇਵੇਗਾ।

ਸਖ਼ਤ SLAs ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਡਾਟਾਬੇਸ ਬੈਕਅੱਪ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ

ਜਦੋਂ ਗਣਿਤਿਕ ਗਣਨਾਵਾਂ ਇਹ ਦਰਸਾਉਂਦੀਆਂ ਹਨ ਕਿ ਤੁਹਾਡਾ ਮੌਜੂਦਾ ਆਰਕੀਟੈਕਚਰ ਕਾਰੋਬਾਰੀ SLAs ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਤੁਹਾਨੂੰ ਆਪਣੀ ਬੈਕਅੱਪ ਰਣਨੀਤੀ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।

1. ਬਲਾਕ-ਪੱਧਰ ਦੇ ਇਨਕਰੀਮੈਂਟਲ ਬੈਕਅੱਪ ਦਾ ਲਾਭ ਉਠਾਓ

ਰਵਾਇਤੀ ਡਾਟਾਬੇਸ ਡੰਪ (ਲੌਜੀਕਲ ਬੈਕਅੱਪ ਜਿਵੇਂ ਕਿ pg_dump ਜਾਂ mysqldump) ਮਿਸ਼ਨ-ਕ੍ਰਿਟੀਕਲ RTOs ਲਈ ਬਹੁਤ ਹੌਲੀ ਹਨ। ਫਿਜ਼ੀਕਲ, ਬਲਾਕ-ਪੱਧਰ ਦੇ ਬੈਕਅੱਪ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਬਲਾਕ-ਪੱਧਰ ਦੇ ਇਨਕਰੀਮੈਂਟਲ ਬੈਕਅੱਪ ਸਿਰਫ਼ ਉਹਨਾਂ ਡਿਸਕ ਬਲਾਕਾਂ ਨੂੰ ਕਾਪੀ ਕਰਦੇ ਹਨ ਜੋ ਪਿਛਲੇ ਬੈਕਅੱਪ ਤੋਂ ਬਾਅਦ ਬਦਲੇ ਹਨ, ਜਿਸ ਨਾਲ T(transfer) ਅਤੇ ਨੈੱਟਵਰਕ ਓਵਰਹੈੱਡ ਵਿੱਚ ਕਾਫ਼ੀ ਕਮੀ ਆਉਂਦੀ ਹੈ।

2. ਸਟੋਰੇਜ ਸਨੈਪਸ਼ਾਟ ਦੀ ਵਰਤੋਂ ਕਰੋ

15 ਮਿੰਟਾਂ ਤੋਂ ਘੱਟ ਦੇ RTO ਦੀ ਲੋੜ ਵਾਲੇ ਮਲਟੀ-ਟੈਰਾਬਾਈਟ ਡਾਟਾਬੇਸ ਲਈ, ਰਵਾਇਤੀ ਫਾਈਲ ਕਾਪੀ ਕਰਨਾ ਸਟੈਂਡਰਡ ਨੈੱਟਵਰਕਾਂ ‘ਤੇ ਸਰੀਰਕ ਤੌਰ ‘ਤੇ ਅਸੰਭਵ ਹੈ। SAN ਜਾਂ ਕਲਾਉਡ-ਨੇਟਿਵ ਸਟੋਰੇਜ ਸਨੈਪਸ਼ਾਟ (ਜਿਵੇਂ ਕਿ AWS EBS Snapshots, Pure Storage) ਨਾਲ ਏਕੀਕਰਣ ਲਗਭਗ ਤੁਰੰਤ T(restore) ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਡਾਟਾਬੇਸ ਇੰਜਣ ਨੂੰ ਫਿਰ ਸਿਰਫ਼ ਸਨੈਪਸ਼ਾਟ ‘ਤੇ ਕਰੈਸ਼ ਰਿਕਵਰੀ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

3. ਪੈਰਲਲਿਜ਼ਮ ਲਾਗੂ ਕਰੋ

ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ ਬੈਕਅੱਪ ਅਤੇ ਰੀਸਟੋਰ ਟੂਲ ਮਲਟੀ-ਥ੍ਰੈਡਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। pgbackrest ਜਾਂ SQL Server ਡਾਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ PostgreSQL ਡਾਟਾਬੇਸ ਨੂੰ ਰੀਸਟੋਰ ਕਰਦੇ ਸਮੇਂ, ਆਪਣੀ ਉਪਲਬਧ ਨੈੱਟਵਰਕ ਅਤੇ ਡਿਸਕ ਬੈਂਡਵਿਡਥ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵਰਤਣ ਲਈ ਪੈਰਲਲ ਵਰਕਰ ਥ੍ਰੈੱਡਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ ‘ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ।

# Example of parallel restore in pgBackRest
pgbackrest --stanza=prod_db --process-max=8 restore

ਸਿੱਟਾ

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

ਲੌਗ ਜਨਰੇਸ਼ਨ ਦਰਾਂ ਨੂੰ ਬੇਸਲਾਈਨ ਕਰਕੇ, ਡਾਟਾਬੇਸ ਰਿਕਵਰੀ ਦੇ ਵੱਖਰੇ ਪੜਾਵਾਂ ਨੂੰ ਸਮਝ ਕੇ, ਅਤੇ CloudSave ਵਰਗੇ ਮਜ਼ਬੂਤ ਪਲੇਟਫਾਰਮਾਂ ਰਾਹੀਂ ਆਟੋਮੇਟਿਡ ਟੈਸਟਿੰਗ ਲਾਗੂ ਕਰਕੇ, IT ਟੀਮਾਂ ਭਰੋਸੇ ਨਾਲ ਆਪਣੇ ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ SLAs ਦੀ ਗਰੰਟੀ ਦੇ ਸਕਦੀਆਂ ਹਨ। ਯਾਦ ਰੱਖੋ: ਡਾਟਾਬੇਸ ਪ੍ਰਸ਼ਾਸਨ ਦੇ ਖੇਤਰ ਵਿੱਚ, ਉਮੀਦ ਇੱਕ ਰਣਨੀਤੀ ਨਹੀਂ ਹੈ, ਅਤੇ ਅਣਪ੍ਰਮਾਣਿਤ ਬੈਕਅੱਪ ਇੱਕ ਦੇਣਦਾਰੀ ਹਨ।

ਜਾਣੋ ਕਿ ਕਿਵੇਂ DevOps ਇੰਜੀਨੀਅਰ ਅਤੇ DBAs ਉੱਨਤ ਰਿਕਵਰੀ ਮਕੈਨਿਕਸ, CLI ਟੂਲਸ, ਅਤੇ ਆਟੋਮੇਟਿਡ ਟੈਸਟਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮਿਸ਼ਨ-ਕ੍ਰਿਟੀਕਲ ਡਾਟਾਬੇਸ ਲਈ RTO ਅਤੇ RPO ਦੀ ਸਹੀ ਗਣਨਾ, ਟੈਸਟ ਅਤੇ ਅਨੁਕੂਲਤਾ ਕਰ ਸਕਦੇ ਹਨ।

Categories