WAL-G: PostgreSQL DBMS ਦਾ ਬੈਕਅੱਪ ਅਤੇ ਰਿਕਵਰੀ

ਇਹ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ ਕਿ SQL ਡੰਪਾਂ ਵਿੱਚ ਬੈਕਅੱਪ ਬਣਾਉਣਾ (ਵਰਤੋਂ pg_dump ਜ pg_dumpall) ਇੱਕ ਚੰਗਾ ਵਿਚਾਰ ਨਹੀਂ ਹੈ। PostgreSQL DBMS ਦਾ ਬੈਕਅੱਪ ਲੈਣ ਲਈ, ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਿਹਤਰ ਹੈ pg_basebackup, ਜੋ WAL ਲੌਗਸ ਦੀ ਬਾਈਨਰੀ ਕਾਪੀ ਬਣਾਉਂਦਾ ਹੈ। ਪਰ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਕਾਪੀ ਬਣਾਉਣ ਅਤੇ ਰੀਸਟੋਰ ਕਰਨ ਦੀ ਪੂਰੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਅਧਿਐਨ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸਮਝੋਗੇ ਕਿ ਤੁਹਾਨੂੰ ਇਸ ਦੇ ਕੰਮ ਕਰਨ ਲਈ ਘੱਟੋ-ਘੱਟ ਦੋ ਟ੍ਰਾਈਸਾਈਕਲ ਲਿਖਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਉੱਪਰ ਅਤੇ ਹੇਠਾਂ ਦੋਵਾਂ ਵਿੱਚ ਦਰਦ ਨਹੀਂ ਹੋਵੇਗਾ. ਦੁੱਖਾਂ ਨੂੰ ਦੂਰ ਕਰਨ ਲਈ, WAL-G ਵਿਕਸਿਤ ਕੀਤਾ ਗਿਆ ਸੀ।

ਵਾਲ-ਜੀ PostgreSQL ਡੇਟਾਬੇਸ ਨੂੰ ਬੈਕਅੱਪ ਅਤੇ ਰੀਸਟੋਰ ਕਰਨ ਲਈ ਗੋ ਵਿੱਚ ਲਿਖਿਆ ਇੱਕ ਟੂਲ ਹੈ (ਅਤੇ ਹਾਲ ਹੀ ਵਿੱਚ MySQL/MariaDB, MongoDB ਅਤੇ FoundationDB). ਇਹ ਐਮਾਜ਼ਾਨ S3 ਸਟੋਰੇਜ਼ (ਅਤੇ ਐਨਾਲਾਗ, ਉਦਾਹਰਨ ਲਈ, ਯਾਂਡੇਕਸ ਆਬਜੈਕਟ ਸਟੋਰੇਜ), ਨਾਲ ਹੀ ਗੂਗਲ ਕਲਾਉਡ ਸਟੋਰੇਜ, ਅਜ਼ੂਰ ਸਟੋਰੇਜ, ਸਵਿਫਟ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਅਤੇ ਸਿਰਫ਼ ਫਾਈਲ ਸਿਸਟਮ ਨਾਲ ਕੰਮ ਕਰਨ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਪੂਰਾ ਸੈਟਅਪ ਸਧਾਰਨ ਕਦਮਾਂ 'ਤੇ ਆਉਂਦਾ ਹੈ, ਪਰ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ ਇਸ ਬਾਰੇ ਲੇਖ ਪੂਰੇ ਇੰਟਰਨੈਟ ਵਿੱਚ ਖਿੰਡੇ ਹੋਏ ਹਨ, ਇੱਥੇ ਕੋਈ ਸੰਪੂਰਨ ਕਿਵੇਂ-ਕਰਨੀ ਮੈਨੂਅਲ ਨਹੀਂ ਹੈ ਜਿਸ ਵਿੱਚ ਸ਼ੁਰੂ ਤੋਂ ਲੈ ਕੇ ਅੰਤ ਤੱਕ ਸਾਰੇ ਪੜਾਅ ਸ਼ਾਮਲ ਹੋਣਗੇ (ਹਬਰੇ 'ਤੇ ਕਈ ਪੋਸਟਾਂ ਹਨ, ਪਰ ਉੱਥੇ ਬਹੁਤ ਸਾਰੇ ਅੰਕ ਖੁੰਝ ਗਏ ਹਨ)।

ਇਹ ਲੇਖ ਮੁੱਖ ਤੌਰ 'ਤੇ ਮੇਰੇ ਗਿਆਨ ਨੂੰ ਵਿਵਸਥਿਤ ਕਰਨ ਲਈ ਲਿਖਿਆ ਗਿਆ ਸੀ। ਮੈਂ ਇੱਕ DBA ਨਹੀਂ ਹਾਂ ਅਤੇ ਮੈਂ ਆਪਣੇ ਆਪ ਨੂੰ ਕਿਤੇ ਵੀ ਆਮ ਆਦਮੀ ਦੀ ਭਾਸ਼ਾ ਵਿੱਚ ਪ੍ਰਗਟ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ, ਇਸ ਲਈ ਕਿਸੇ ਵੀ ਸੁਧਾਰ ਦਾ ਸਵਾਗਤ ਹੈ!

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

ਸੈਟਿੰਗ

ਇਸ ਲੇਖ ਨੂੰ ਲਿਖਣ ਦੇ ਸਮੇਂ, WAL-G ਦਾ ਸਥਿਰ ਸੰਸਕਰਣ ਹੈ v0.2.15 (ਮਾਰਚ 2020). ਇਹ ਉਹ ਹੈ ਜੋ ਅਸੀਂ ਵਰਤਾਂਗੇ (ਪਰ ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਨੂੰ ਮਾਸਟਰ ਬ੍ਰਾਂਚ ਤੋਂ ਖੁਦ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਗੀਥਬ ਰਿਪੋਜ਼ਟਰੀ ਕੋਲ ਇਸਦੇ ਲਈ ਸਾਰੀਆਂ ਹਦਾਇਤਾਂ ਹਨ). ਡਾਊਨਲੋਡ ਅਤੇ ਇੰਸਟਾਲ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ ਇਹ ਕਰਨ ਦੀ ਲੋੜ ਹੈ:

#!/bin/bash

curl -L "https://github.com/wal-g/wal-g/releases/download/v0.2.15/wal-g.linux-amd64.tar.gz" -o "wal-g.linux-amd64.tar.gz"
tar -xzf wal-g.linux-amd64.tar.gz
mv wal-g /usr/local/bin/

ਇਸ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ WAL-G, ਅਤੇ ਫਿਰ PostgreSQL ਨੂੰ ਸੰਰਚਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

WAL-G ਸੈੱਟਅੱਪ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

ਬੈਕਅੱਪ ਸਟੋਰ ਕਰਨ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਲਈ, Amazon S3 ਵਰਤਿਆ ਜਾਵੇਗਾ (ਕਿਉਂਕਿ ਇਹ ਮੇਰੇ ਸਰਵਰਾਂ ਦੇ ਨੇੜੇ ਹੈ ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਬਹੁਤ ਸਸਤੀ ਹੈ). ਇਸਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਇੱਕ "s3 ਬਾਲਟੀ" ਅਤੇ ਐਕਸੈਸ ਕੁੰਜੀਆਂ ਦੀ ਲੋੜ ਹੈ।

WAL-G ਬਾਰੇ ਸਾਰੇ ਪਿਛਲੇ ਲੇਖ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸੰਰਚਨਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਪਰ ਇਸ ਰੀਲੀਜ਼ ਦੇ ਨਾਲ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਸਥਿਤ ਹੋ ਸਕਦੀਆਂ ਹਨ .walg.json ਫ਼ਾਈਲ ਪੋਸਟਗ੍ਰੇਸ ਉਪਭੋਗਤਾ ਦੀ ਹੋਮ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ. ਇਸਨੂੰ ਬਣਾਉਣ ਲਈ, ਹੇਠਾਂ ਦਿੱਤੀ ਬੈਸ਼ ਸਕ੍ਰਿਪਟ ਚਲਾਓ:

#!/bin/bash

cat > /var/lib/postgresql/.walg.json << EOF
{
    "WALG_S3_PREFIX": "s3://your_bucket/path",
    "AWS_ACCESS_KEY_ID": "key_id",
    "AWS_SECRET_ACCESS_KEY": "secret_key",
    "WALG_COMPRESSION_METHOD": "brotli",
    "WALG_DELTA_MAX_STEPS": "5",
    "PGDATA": "/var/lib/postgresql/12/main",
    "PGHOST": "/var/run/postgresql/.s.PGSQL.5432"
}
EOF
# обязательно меняем владельца файла:
chown postgres: /var/lib/postgresql/.walg.json

ਮੈਨੂੰ ਸਾਰੇ ਪੈਰਾਮੀਟਰਾਂ ਬਾਰੇ ਥੋੜਾ ਜਿਹਾ ਸਮਝਾਉਣ ਦਿਓ:

• WALG_S3_PREFIX - ਤੁਹਾਡੀ S3 ਬਾਲਟੀ ਦਾ ਮਾਰਗ ਜਿੱਥੇ ਬੈਕਅੱਪ ਅੱਪਲੋਡ ਕੀਤੇ ਜਾਣਗੇ (ਤੁਸੀਂ ਜਾਂ ਤਾਂ ਰੂਟ ਜਾਂ ਫੋਲਡਰ ਵਿੱਚ ਜਾ ਸਕਦੇ ਹੋ);
• AWS_ACCESS_KEY_ID - S3 ਵਿੱਚ ਪਹੁੰਚ ਕੁੰਜੀ (ਇੱਕ ਟੈਸਟ ਸਰਵਰ 'ਤੇ ਰਿਕਵਰੀ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇਹਨਾਂ ਕੁੰਜੀਆਂ ਵਿੱਚ ਰੀਡਓਨਲੀ ਨੀਤੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ! ਇਹ ਰਿਕਵਰੀ 'ਤੇ ਭਾਗ ਵਿੱਚ ਹੋਰ ਵੇਰਵੇ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ.);
• AWS_SECRET_ACCESS_KEY - S3 ਸਟੋਰੇਜ਼ ਵਿੱਚ ਗੁਪਤ ਕੁੰਜੀ;
• WALG_COMPRESSION_METHOD - ਕੰਪਰੈਸ਼ਨ ਵਿਧੀ, ਬ੍ਰੋਟਲੀ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਿਹਤਰ ਹੈ (ਕਿਉਂਕਿ ਇਹ ਅੰਤਮ ਆਕਾਰ ਅਤੇ ਕੰਪਰੈਸ਼ਨ/ਡੀਕੰਪ੍ਰੇਸ਼ਨ ਸਪੀਡ ਵਿਚਕਾਰ ਸੁਨਹਿਰੀ ਮੱਧਮਾਨ ਹੈ);
• WALG_DELTA_MAX_STEPS - ਪੂਰਾ ਬੈਕਅੱਪ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ "ਡੈਲਟਾ" ਦੀ ਗਿਣਤੀ (ਉਹ ਡਾਊਨਲੋਡ ਕੀਤੇ ਡੇਟਾ ਦੇ ਸਮੇਂ ਅਤੇ ਆਕਾਰ ਦੀ ਬਚਤ ਕਰਦੇ ਹਨ, ਪਰ ਰਿਕਵਰੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਥੋੜ੍ਹਾ ਹੌਲੀ ਕਰ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਵੱਡੇ ਮੁੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਲਾਹ ਨਹੀਂ ਦਿੱਤੀ ਜਾਂਦੀ);
• PGDATA - ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਡੇਟਾ ਨਾਲ ਡਾਇਰੈਕਟਰੀ ਦਾ ਮਾਰਗ (ਤੁਸੀਂ ਕਮਾਂਡ ਚਲਾ ਕੇ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ pg_lscluster);
• PGHOST - ਡੇਟਾਬੇਸ ਨਾਲ ਜੁੜਨਾ, ਸਥਾਨਕ ਬੈਕਅੱਪ ਦੇ ਨਾਲ ਇਸ ਨੂੰ ਯੂਨਿਕਸ-ਸਾਕਟ ਦੁਆਰਾ ਕਰਨਾ ਬਿਹਤਰ ਹੈ ਜਿਵੇਂ ਕਿ ਇਸ ਉਦਾਹਰਣ ਵਿੱਚ ਹੈ।

ਹੋਰ ਪੈਰਾਮੀਟਰ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਲੱਭੇ ਜਾ ਸਕਦੇ ਹਨ: https://github.com/wal-g/wal-g/blob/v0.2.15/PostgreSQL.md#configuration.

PostgreSQL ਸੈਟ ਅਪ ਕਰਨਾ

ਡਾਟਾਬੇਸ ਦੇ ਅੰਦਰ ਆਰਕਾਈਵਰ ਨੂੰ ਕਲਾਉਡ 'ਤੇ WAL ਲੌਗਸ ਅੱਪਲੋਡ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਤੋਂ ਉਹਨਾਂ ਨੂੰ ਮੁੜ ਬਹਾਲ ਕਰਨ ਲਈ (ਜੇ ਲੋੜ ਹੋਵੇ), ਤੁਹਾਨੂੰ ਸੰਰਚਨਾ ਫਾਈਲ ਵਿੱਚ ਕਈ ਮਾਪਦੰਡ ਸੈੱਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। /etc/postgresql/12/main/postgresql.conf. ਸਿਰਫ਼ ਸ਼ੁਰੂਆਤ ਕਰਨ ਵਾਲਿਆਂ ਲਈ ਤੁਹਾਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈਕਿ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਸੈਟਿੰਗਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਕਿਸੇ ਹੋਰ ਮੁੱਲ 'ਤੇ ਸੈੱਟ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ, ਤਾਂ ਜੋ ਜਦੋਂ ਸੰਰਚਨਾ ਮੁੜ ਲੋਡ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ DBMS ਕਰੈਸ਼ ਨਾ ਹੋਵੇ। ਤੁਸੀਂ ਇਹਨਾਂ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜੋੜ ਸਕਦੇ ਹੋ:

#!/bin/bash

echo "wal_level=replica" >> /etc/postgresql/12/main/postgresql.conf
echo "archive_mode=on" >> /etc/postgresql/12/main/postgresql.conf
echo "archive_command='/usr/local/bin/wal-g wal-push "%p" >> /var/log/postgresql/archive_command.log 2>&1' " >> /etc/postgresql/12/main/postgresql.conf
echo “archive_timeout=60” >> /etc/postgresql/12/main/postgresql.conf
echo "restore_command='/usr/local/bin/wal-g wal-fetch "%f" "%p" >> /var/log/postgresql/restore_command.log 2>&1' " >> /etc/postgresql/12/main/postgresql.conf

# перезагружаем конфиг через отправку SIGHUP сигнала всем процессам БД
killall -s HUP postgres

ਸੈੱਟ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਮਾਪਦੰਡਾਂ ਦਾ ਵੇਰਵਾ:

• wal_level - WAL ਲੌਗਸ ਵਿੱਚ ਕਿੰਨੀ ਜਾਣਕਾਰੀ ਲਿਖਣੀ ਹੈ, "ਰਿਪਲੀਕਾ" - ਸਭ ਕੁਝ ਲਿਖੋ;
• ਪੁਰਾਲੇਖ_ਮੋਡ - ਪੈਰਾਮੀਟਰ ਤੋਂ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ WAL ਲੌਗਸ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਨ ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ archive_command;
• archive_command - ਇੱਕ ਮੁਕੰਮਲ WAL ਲੌਗ ਨੂੰ ਆਰਕਾਈਵ ਕਰਨ ਲਈ ਕਮਾਂਡ;
• archive_timeout - ਲੌਗਸ ਦਾ ਪੁਰਾਲੇਖ ਉਦੋਂ ਹੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਇਹ ਪੂਰਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਪਰ ਜੇਕਰ ਤੁਹਾਡਾ ਸਰਵਰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਥੋੜ੍ਹਾ ਜਿਹਾ ਡੇਟਾ ਬਦਲਦਾ/ਜੋੜਦਾ ਹੈ, ਤਾਂ ਇੱਥੇ ਸਕਿੰਟਾਂ ਵਿੱਚ ਇੱਕ ਸੀਮਾ ਨਿਰਧਾਰਤ ਕਰਨਾ ਸਮਝਦਾਰੀ ਰੱਖਦਾ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਆਰਕਾਈਵਿੰਗ ਕਮਾਂਡ ਨੂੰ ਜ਼ਬਰਦਸਤੀ ਬੁਲਾਇਆ ਜਾਵੇਗਾ (ਮੈਂ ਹਰ ਸਕਿੰਟ ਡੇਟਾਬੇਸ ਨੂੰ ਤੀਬਰਤਾ ਨਾਲ ਲਿਖਦਾ ਹਾਂ, ਇਸਲਈ ਮੈਂ ਇਸ ਪੈਰਾਮੀਟਰ ਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਸੈਟ ਨਾ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ);
• ਰੀਸਟੋਰ_ਕਮਾਂਡ - ਬੈਕਅੱਪ ਤੋਂ WAL ਲੌਗ ਨੂੰ ਰੀਸਟੋਰ ਕਰਨ ਲਈ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਵੇਗੀ ਜੇਕਰ "ਪੂਰਾ ਬੈਕਅੱਪ" (ਬੇਸ ਬੈਕਅੱਪ) ਡਾਟਾਬੇਸ ਵਿੱਚ ਨਵੀਨਤਮ ਤਬਦੀਲੀਆਂ ਦੀ ਘਾਟ ਹੈ।

ਤੁਸੀਂ ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਅਨੁਵਾਦ ਵਿੱਚ ਇਹਨਾਂ ਸਾਰੇ ਮਾਪਦੰਡਾਂ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ: https://postgrespro.ru/docs/postgresql/12/runtime-config-wal.

ਇੱਕ ਬੈਕਅੱਪ ਸਮਾਂ-ਸਾਰਣੀ ਸੈਟ ਅਪ ਕਰ ਰਿਹਾ ਹੈ

ਕੋਈ ਜੋ ਵੀ ਕਹੇ, ਇਸ ਨੂੰ ਚਲਾਉਣ ਦਾ ਸਭ ਤੋਂ ਸੁਵਿਧਾਜਨਕ ਤਰੀਕਾ ਹੈ ਕਰੋਨ। ਇਹ ਉਹ ਹੈ ਜੋ ਅਸੀਂ ਬੈਕਅੱਪ ਬਣਾਉਣ ਲਈ ਕੌਂਫਿਗਰ ਕਰਾਂਗੇ। ਆਉ ਇੱਕ ਪੂਰਾ ਬੈਕਅੱਪ ਬਣਾਉਣ ਲਈ ਕਮਾਂਡ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ: wal-g ਵਿੱਚ ਇਹ ਲਾਂਚ ਆਰਗੂਮੈਂਟ ਹੈ ਬੈਕਅੱਪ-ਪੁਸ਼. ਪਰ ਪਹਿਲਾਂ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਸਭ ਕੁਝ ਠੀਕ ਹੈ (ਅਤੇ ਇੱਥੇ ਕੋਈ ਐਕਸੈਸ ਗਲਤੀਆਂ ਨਹੀਂ ਹਨ) ਲਈ ਪੋਸਟਗ੍ਰੇਸ ਉਪਭੋਗਤਾ ਤੋਂ ਇਸ ਕਮਾਂਡ ਨੂੰ ਹੱਥੀਂ ਚਲਾਉਣਾ ਬਿਹਤਰ ਹੈ:

#!/bin/bash

su - postgres -c '/usr/local/bin/wal-g backup-push /var/lib/postgresql/12/main'

ਲਾਂਚ ਆਰਗੂਮੈਂਟਸ ਡੇਟਾ ਡਾਇਰੈਕਟਰੀ ਦੇ ਮਾਰਗ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ - ਮੈਂ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹਾਂ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਚਲਾ ਕੇ ਲੱਭ ਸਕਦੇ ਹੋ pg_lscluster.

ਜੇ ਸਭ ਕੁਝ ਗਲਤੀਆਂ ਤੋਂ ਬਿਨਾਂ ਹੋ ਗਿਆ ਅਤੇ ਡੇਟਾ ਨੂੰ S3 ਸਟੋਰੇਜ ਵਿੱਚ ਲੋਡ ਕੀਤਾ ਗਿਆ, ਤਾਂ ਤੁਸੀਂ ਫਿਰ ਕ੍ਰੋਨਟੈਬ ਵਿੱਚ ਸਮੇਂ-ਸਮੇਂ ਤੇ ਲਾਂਚ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰ ਸਕਦੇ ਹੋ:

#!/bin/bash

echo "15 4 * * *    /usr/local/bin/wal-g backup-push /var/lib/postgresql/12/main >> /var/log/postgresql/walg_backup.log 2>&1" >> /var/spool/cron/crontabs/postgres
# задаем владельца и выставляем правильные права файлу
chown postgres: /var/spool/cron/crontabs/postgres
chmod 600 /var/spool/cron/crontabs/postgres

ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ, ਬੈਕਅੱਪ ਪ੍ਰਕਿਰਿਆ ਹਰ ਰੋਜ਼ ਸਵੇਰੇ 4:15 ਵਜੇ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ।

ਪੁਰਾਣੇ ਬੈਕਅੱਪ ਮਿਟਾਏ ਜਾ ਰਹੇ ਹਨ

ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ, ਤੁਹਾਨੂੰ ਮੇਸੋਜ਼ੋਇਕ ਯੁੱਗ ਤੋਂ ਬਿਲਕੁਲ ਸਾਰੇ ਬੈਕਅੱਪ ਰੱਖਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਇਸਲਈ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਤੁਹਾਡੀ ਸਟੋਰੇਜ ("ਪੂਰੇ ਬੈਕਅੱਪ" ਅਤੇ WAL ਲੌਗਸ) ਨੂੰ "ਸਫਾਈ" ਕਰਨਾ ਲਾਭਦਾਇਕ ਹੋਵੇਗਾ। ਅਸੀਂ ਇਹ ਸਭ ਇੱਕ ਕ੍ਰੋਨ ਟਾਸਕ ਦੁਆਰਾ ਕਰਾਂਗੇ:

#!/bin/bash

echo "30 6 * * *    /usr/local/bin/wal-g delete before FIND_FULL $(date -d '-10 days' '+%FT%TZ') --confirm >> /var/log/postgresql/walg_delete.log 2>&1" >> /var/spool/cron/crontabs/postgres
# ещё раз задаем владельца и выставляем правильные права файлу (хоть это обычно это и не нужно повторно делать)
chown postgres: /var/spool/cron/crontabs/postgres
chmod 600 /var/spool/cron/crontabs/postgres

ਕ੍ਰੋਨ ਇਸ ਕੰਮ ਨੂੰ ਹਰ ਰੋਜ਼ ਸਵੇਰੇ 6:30 ਵਜੇ ਚਲਾਏਗਾ, ਪਿਛਲੇ 10 ਦਿਨਾਂ ਦੀਆਂ ਕਾਪੀਆਂ ਨੂੰ ਛੱਡ ਕੇ ਸਭ ਕੁਝ (ਪੂਰਾ ਬੈਕਅੱਪ, ਡੈਲਟਾ ਅਤੇ WAL) ਮਿਟਾਉਂਦਾ ਹੈ, ਪਰ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਬੈਕਅੱਪ ਛੱਡਦਾ ਹੈ। ਨੂੰ ਨਿਰਧਾਰਤ ਮਿਤੀ ਤਾਂ ਕਿ ਕੋਈ ਵੀ ਬਿੰਦੂ после ਮਿਤੀਆਂ ਨੂੰ PITR ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਸੀ।

ਬੈਕਅੱਪ ਤੋਂ ਰੀਸਟੋਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

ਇਹ ਕੋਈ ਭੇਤ ਨਹੀਂ ਹੈ ਕਿ ਇੱਕ ਸਿਹਤਮੰਦ ਡੇਟਾਬੇਸ ਦੀ ਕੁੰਜੀ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਬਹਾਲੀ ਅਤੇ ਅੰਦਰਲੇ ਡੇਟਾ ਦੀ ਇਕਸਾਰਤਾ ਦੀ ਤਸਦੀਕ ਹੈ. ਮੈਂ ਤੁਹਾਨੂੰ ਇਸ ਭਾਗ ਵਿੱਚ WAL-G ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਤਰੀਕੇ ਬਾਰੇ ਦੱਸਾਂਗਾ, ਅਤੇ ਅਸੀਂ ਬਾਅਦ ਵਿੱਚ ਜਾਂਚਾਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ।

ਇਹ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਜੋ ਕਿ ਇੱਕ ਟੈਸਟ ਵਾਤਾਵਰਨ ਵਿੱਚ ਬਹਾਲ ਕਰਨ ਲਈ (ਹਰ ਚੀਜ਼ ਜੋ ਉਤਪਾਦਨ ਨਹੀਂ ਹੈ) ਤੁਹਾਨੂੰ S3 ਵਿੱਚ ਸਿਰਫ਼ ਰੀਡ ਓਨਲੀ ਖਾਤੇ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਜੋ ਗਲਤੀ ਨਾਲ ਬੈਕਅੱਪ ਨੂੰ ਓਵਰਰਾਈਟ ਨਾ ਕੀਤਾ ਜਾ ਸਕੇ। WAL-G ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਗਰੁੱਪ ਪਾਲਿਸੀ ਵਿੱਚ S3 ਉਪਭੋਗਤਾ ਲਈ ਹੇਠਾਂ ਦਿੱਤੇ ਅਧਿਕਾਰਾਂ ਨੂੰ ਸੈੱਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ (ਪ੍ਰਭਾਵ: ਆਗਿਆ ਦਿਓ): s3: GetObject, s3:ListBucket, s3:GetBucketLocation. ਅਤੇ, ਬੇਸ਼ਕ, ਸੈੱਟ ਕਰਨਾ ਨਾ ਭੁੱਲੋ archive_mode=off ਸੈਟਿੰਗਜ਼ ਫਾਈਲ ਵਿੱਚ postgresql.conf, ਤਾਂ ਜੋ ਤੁਹਾਡਾ ਟੈਸਟ ਡੇਟਾਬੇਸ ਚੁੱਪਚਾਪ ਬੈਕਅੱਪ ਨਹੀਂ ਲੈਣਾ ਚਾਹੁੰਦਾ।

ਬਹਾਲੀ ਹੱਥ ਦੀ ਇੱਕ ਮਾਮੂਲੀ ਅੰਦੋਲਨ ਨਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਸਾਰੇ PostgreSQL ਡੇਟਾ ਨੂੰ ਮਿਟਾਉਣਾ (ਉਪਭੋਗਤਾਵਾਂ ਸਮੇਤ), ਇਸ ਲਈ ਕਿਰਪਾ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਹੇਠ ਲਿਖੀਆਂ ਕਮਾਂਡਾਂ ਚਲਾਉਂਦੇ ਹੋ ਤਾਂ ਬਹੁਤ ਸਾਵਧਾਨ ਰਹੋ।

#!/bin/bash

# если есть балансировщик подключений (например, pgbouncer), то вначале отключаем его, чтобы он не нарыгал ошибок в лог
service pgbouncer stop
# если есть демон, который перезапускает упавшие процессы (например, monit), то останавливаем в нём процесс мониторинга базы (у меня это pgsql12)
monit stop pgsql12
# или останавливаем мониторинг полностью
service monit stop
# останавливаем саму базу данных
service postgresql stop
# удаляем все данные из текущей базы (!!!); лучше предварительно сделать их копию, если есть свободное место на диске
rm -rf /var/lib/postgresql/12/main
# скачиваем резервную копию и разархивируем её
su - postgres -c '/usr/local/bin/wal-g backup-fetch /var/lib/postgresql/12/main LATEST'
# помещаем рядом с базой специальный файл-сигнал для восстановления (см. https://postgrespro.ru/docs/postgresql/12/runtime-config-wal#RUNTIME-CONFIG-WAL-ARCHIVE-RECOVERY ), он обязательно должен быть создан от пользователя postgres
su - postgres -c 'touch /var/lib/postgresql/12/main/recovery.signal'
# запускаем базу данных, чтобы она инициировала процесс восстановления
service postgresql start

ਉਹਨਾਂ ਲਈ ਜੋ ਰਿਕਵਰੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਜਾਂਚ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ, ਹੇਠਾਂ ਬੈਸ਼ ਮੈਜਿਕ ਦਾ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਟੁਕੜਾ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਜੋ ਰਿਕਵਰੀ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਹੋਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ, ਸਕ੍ਰਿਪਟ ਇੱਕ ਗੈਰ-ਜ਼ੀਰੋ ਐਗਜ਼ਿਟ ਕੋਡ ਨਾਲ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਵੇਗੀ। ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ, ਇਹ ਪਤਾ ਲਗਾਉਣ ਲਈ ਕਿ ਕੀ ਸਿਗਨਲ ਫਾਈਲ ਮਿਟਾਈ ਗਈ ਸੀ (ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੋਵੇਗਾ ਕਿ ਰਿਕਵਰੀ ਸਫਲ ਰਹੀ ਸੀ) 120 ਸਕਿੰਟਾਂ (ਰਿਕਵਰੀ ਲਈ ਕੁੱਲ 5 ਮਿੰਟ) ਦੀ ਮਿਆਦ ਦੇ ਨਾਲ 10 ਜਾਂਚਾਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ:

#!/bin/bash

CHECK_RECOVERY_SIGNAL_ITER=0
while [ ${CHECK_RECOVERY_SIGNAL_ITER} -le 120 ]
do
    if [ ! -f "/var/lib/postgresql/12/main/recovery.signal" ]
    then
        echo "recovery.signal removed"
        break
    fi
    sleep 5
    ((CHECK_RECOVERY_SIGNAL_ITER+1))
done

# если после всех проверок файл всё равно существует, то падаем с ошибкой
if [ -f "/var/lib/postgresql/12/main/recovery.signal" ]
then
    echo "recovery.signal still exists!"
    exit 17
fi

ਸਫਲ ਰਿਕਵਰੀ ਤੋਂ ਬਾਅਦ, ਸਾਰੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਵਾਪਸ ਸ਼ੁਰੂ ਕਰਨਾ ਨਾ ਭੁੱਲੋ (pgbouncer/monit, ਆਦਿ)।

ਰਿਕਵਰੀ ਤੋਂ ਬਾਅਦ ਡੇਟਾ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ

ਬਹਾਲੀ ਤੋਂ ਬਾਅਦ ਡੇਟਾਬੇਸ ਦੀ ਇਕਸਾਰਤਾ ਦੀ ਜਾਂਚ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ, ਤਾਂ ਜੋ ਟੁੱਟੇ/ਟੇਢੇ ਬੈਕਅੱਪ ਵਾਲੀ ਸਥਿਤੀ ਪੈਦਾ ਨਾ ਹੋਵੇ। ਅਤੇ ਹਰੇਕ ਬਣਾਏ ਗਏ ਪੁਰਾਲੇਖ ਨਾਲ ਅਜਿਹਾ ਕਰਨਾ ਬਿਹਤਰ ਹੈ, ਪਰ ਕਿੱਥੇ ਅਤੇ ਕਿਵੇਂ ਸਿਰਫ ਤੁਹਾਡੀ ਕਲਪਨਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ (ਤੁਸੀਂ ਇੱਕ ਘੰਟੇ ਦੇ ਆਧਾਰ 'ਤੇ ਵਿਅਕਤੀਗਤ ਸਰਵਰਾਂ ਨੂੰ ਵਧਾ ਸਕਦੇ ਹੋ ਜਾਂ ਸੀਆਈ ਵਿੱਚ ਇੱਕ ਚੈਕ ਚਲਾ ਸਕਦੇ ਹੋ)। ਪਰ ਘੱਟੋ ਘੱਟ, ਡੇਟਾਬੇਸ ਵਿੱਚ ਡੇਟਾ ਅਤੇ ਸੂਚਕਾਂਕ ਦੀ ਜਾਂਚ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ.

ਡੇਟਾ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ, ਇਸਨੂੰ ਡੰਪ ਦੁਆਰਾ ਚਲਾਉਣਾ ਕਾਫ਼ੀ ਹੈ, ਪਰ ਇਹ ਬਿਹਤਰ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਬਣਾਉਂਦੇ ਸਮੇਂ ਤੁਹਾਡੇ ਕੋਲ ਚੈੱਕਸਮ ਸਮਰਥਿਤ ਹਨ (ਡਾਟਾ ਚੈੱਕਸਮ):

#!/bin/bash

if ! su - postgres -c 'pg_dumpall > /dev/null'
then
    echo 'pg_dumpall failed'
    exit 125
fi

ਸੂਚਕਾਂਕ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ - ਮੌਜੂਦ ਹੈ amcheck ਮੋਡੀਊਲ, ਆਓ ਇਸਦੇ ਲਈ sql ਪੁੱਛਗਿੱਛ ਲਈਏ WAL-G ਟੈਸਟ ਅਤੇ ਇਸਦੇ ਆਲੇ ਦੁਆਲੇ ਥੋੜਾ ਜਿਹਾ ਤਰਕ ਬਣਾਓ:

#!/bin/bash

# добавляем sql-запрос для проверки в файл во временной директории
cat > /tmp/amcheck.sql << EOF
CREATE EXTENSION IF NOT EXISTS amcheck;
SELECT bt_index_check(c.oid), c.relname, c.relpages
FROM pg_index i
JOIN pg_opclass op ON i.indclass[0] = op.oid
JOIN pg_am am ON op.opcmethod = am.oid
JOIN pg_class c ON i.indexrelid = c.oid
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE am.amname = 'btree'
AND c.relpersistence != 't'
AND i.indisready AND i.indisvalid;
EOF
chown postgres: /tmp/amcheck.sql

# добавляем скрипт для запуска проверок всех доступных баз в кластере
# (обратите внимание что переменные и запуск команд – экранированы)
cat > /tmp/run_amcheck.sh << EOF
for DBNAME in $(su - postgres -c 'psql -q -A -t -c "SELECT datname FROM pg_database WHERE datistemplate = false;" ')
do
    echo "Database: ${DBNAME}"
    su - postgres -c "psql -f /tmp/amcheck.sql -v 'ON_ERROR_STOP=1' ${DBNAME}" && EXIT_STATUS=$? || EXIT_STATUS=$?
    if [ "${EXIT_STATUS}" -ne 0 ]
    then
        echo "amcheck failed on DB: ${DBNAME}"
        exit 125
    fi
done
EOF
chmod +x /tmp/run_amcheck.sh

# запускаем скрипт
/tmp/run_amcheck.sh > /tmp/amcheck.log

# для проверки что всё прошло успешно можно проверить exit code или grep’нуть ошибку
if grep 'amcheck failed' "/tmp/amcheck.log"
then
    echo 'amcheck failed: '
    cat /tmp/amcheck.log
    exit 125
fi

ਸੰਖੇਪ ਕਰਨ ਲਈ

ਮੈਂ ਪ੍ਰਕਾਸ਼ਨ ਨੂੰ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਲਈ ਐਂਡਰੀ ਬੋਰੋਡਿਨ ਦਾ ਧੰਨਵਾਦ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ ਅਤੇ WAL-G ਦੇ ਵਿਕਾਸ ਵਿੱਚ ਉਸਦੇ ਯੋਗਦਾਨ ਲਈ ਵਿਸ਼ੇਸ਼ ਧੰਨਵਾਦ!

ਇਹ ਇਸ ਨੋਟ ਨੂੰ ਸਮਾਪਤ ਕਰਦਾ ਹੈ. ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਮੈਂ ਸੈੱਟਅੱਪ ਦੀ ਸੌਖ ਅਤੇ ਤੁਹਾਡੀ ਕੰਪਨੀ ਵਿੱਚ ਇਸ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਵੱਡੀ ਸੰਭਾਵਨਾ ਨੂੰ ਦੱਸਣ ਦੇ ਯੋਗ ਸੀ। ਮੈਂ WAL-G ਬਾਰੇ ਬਹੁਤ ਕੁਝ ਸੁਣਿਆ ਹੈ, ਪਰ ਕਦੇ ਵੀ ਬੈਠਣ ਅਤੇ ਇਸਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਇੰਨਾ ਸਮਾਂ ਨਹੀਂ ਸੀ. ਅਤੇ ਮੈਂ ਇਸਨੂੰ ਘਰ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਇਹ ਲੇਖ ਮੇਰੇ ਤੋਂ ਬਾਹਰ ਆਇਆ.

ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ WAL-G ਹੇਠਾਂ ਦਿੱਤੇ DBMS ਨਾਲ ਵੀ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ:

• MySQL / ਮਾਰੀਏਡਾਬੀ;
• MongoDB;
• ਫਾਊਂਡੇਸ਼ਨ ਡੀ.ਬੀ;
• ਅਤੇ ਕਮਿਟਾਂ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ, ਕਈ ਹੋਰ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ!

ਸਰੋਤ: www.habr.com