🥇WAL-G: PostgreSQL DBMS کا بیک اپ اور ریکوری

یہ طویل عرصے سے جانا جاتا ہے کہ ایس کیو ایل ڈمپ میں بیک اپ بنانا (استعمال کرتے ہوئے pg_dump یا pg_dumpall) اچھا خیال نہیں ہے۔ PostgreSQL DBMS کا بیک اپ لینے کے لیے، کمانڈ استعمال کرنا بہتر ہے۔ pg_bbackbackup، جو WAL لاگز کی بائنری کاپی بناتا ہے۔ لیکن جب آپ کاپی بنانے اور بحال کرنے کے پورے عمل کا مطالعہ شروع کریں گے، تو آپ سمجھ جائیں گے کہ اس کے کام کرنے کے لیے آپ کو کم از کم ایک دو ٹرائی سائیکلیں لکھنی ہوں گی اور آپ کو اوپر اور نیچے دونوں طرح سے تکلیف نہیں ہوگی۔ مصائب کو دور کرنے کے لیے، WAL-G تیار کیا گیا تھا۔

وال-جی PostgreSQL ڈیٹا بیسز کو بیک اپ اور بحال کرنے کے لیے Go میں لکھا ہوا ایک ٹول ہے (اور حال ہی میں MySQL/MariaDB، MongoDB اور FoundationDB)۔ یہ Amazon S3 سٹوریج (اور analogues، مثال کے طور پر Yandex Object Storage) کے ساتھ ساتھ Google Cloud Storage، Azure Storage، Swift Object Storage اور صرف فائل سسٹم کے ساتھ کام کرنے کی حمایت کرتا ہے۔ پورا سیٹ اپ آسان مراحل پر آتا ہے، لیکن اس حقیقت کی وجہ سے کہ اس کے بارے میں مضامین انٹرنیٹ پر بکھرے ہوئے ہیں، کوئی مکمل طریقہ کار نہیں ہے جس میں شروع سے لے کر ختم تک تمام مراحل شامل ہوں گے (Habré پر کئی پوسٹس ہیں، لیکن وہاں بہت سے پوائنٹس چھوٹ گئے ہیں)۔

یہ مضمون بنیادی طور پر میرے علم کو منظم کرنے کے لیے لکھا گیا تھا۔ میں ڈی بی اے نہیں ہوں اور میں کہیں بھی عام آدمی کی زبان میں اپنا اظہار کرسکتا ہوں، اس لیے کسی بھی اصلاح کا خیرمقدم کیا جائے گا!

الگ سے، میں نوٹ کرتا ہوں کہ نیچے دی گئی ہر چیز متعلقہ ہے اور Ubuntu 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 فائل پوسٹگریس صارف کی ہوم ڈائرکٹری میں۔ اسے بنانے کے لیے درج ذیل bash اسکرپٹ کو چلائیں:

#!/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 - مکمل بیک اپ بنانے سے پہلے "ڈیلٹا" کی تعداد (وہ وقت اور ڈاؤن لوڈ کردہ ڈیٹا کے سائز کی بچت کرتے ہیں، لیکن بحالی کے عمل کو قدرے سست کر سکتے ہیں، اس لیے بڑی قدروں کو استعمال کرنا مناسب نہیں ہے)؛
پی جی ڈیٹا - آپ کے ڈیٹا بیس ڈیٹا کے ساتھ ڈائریکٹری کا راستہ (آپ کمانڈ چلا کر معلوم کر سکتے ہیں۔ pg_lsclusters);
پی جی ایچ او ایس ٹی - ڈیٹا بیس سے جڑنا، مقامی بیک اپ کے ساتھ یونکس ساکٹ کے ذریعے کرنا بہتر ہے جیسا کہ اس مثال میں ہے۔

دیگر پیرامیٹرز دستاویزات میں مل سکتے ہیں: 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 لاگز میں کتنی معلومات لکھنی ہیں، "replica" - سب کچھ لکھیں۔
آرکائیو_موڈ - پیرامیٹر سے کمانڈ کا استعمال کرتے ہوئے WAL لاگز کو ڈاؤن لوڈ کرنے کو فعال کریں۔ آرکائیو_کمانڈ;
آرکائیو_کمانڈ - مکمل شدہ 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_lsclusters.

اگر سب کچھ غلطیوں کے بغیر ہوا اور ڈیٹا 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 بجے شروع ہوتا ہے۔

پرانے بیک اپ کو حذف کرنا

زیادہ تر امکان ہے کہ، آپ کو Mesozoic دور کے تمام بیک اپ رکھنے کی ضرورت نہیں ہے، اس لیے وقتاً فوقتاً اپنے اسٹوریج کو "کلین اپ" کرنا ("مکمل بیک اپ" اور 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 دنوں کی کاپیوں کے علاوہ ہر چیز (مکمل بیک اپ، ڈیلٹا اور WALs) کو حذف کر دے گا، لیکن کم از کم ایک بیک اپ چھوڑے گا۔ پر مخصوص تاریخ تاکہ کسی بھی نقطہ کے بعد تاریخیں PITR میں شامل تھیں۔

بیک اپ سے بحال ہو رہا ہے۔

یہ کوئی راز نہیں ہے کہ صحت مند ڈیٹا بیس کی کلید وقتاً فوقتاً بحالی اور اندر موجود ڈیٹا کی سالمیت کی تصدیق ہے۔ میں آپ کو اس سیکشن میں WAL-G کا استعمال کرکے بازیافت کرنے کا طریقہ بتاؤں گا، اور ہم بعد میں چیک کے بارے میں بات کریں گے۔

الگ سے ، یہ قابل توجہ ہے جسے ٹیسٹ ماحول میں بحال کرنے کے لیے (ہر وہ چیز جو پروڈکشن نہیں ہے) آپ کو S3 میں صرف پڑھنے کا اکاؤنٹ استعمال کرنے کی ضرورت ہے تاکہ غلطی سے بیک اپ کو اوور رائٹ نہ کر دیا جائے۔ WAL-G کے معاملے میں، آپ کو گروپ پالیسی میں S3 صارف کے لیے درج ذیل حقوق متعین کرنے ہوں گے (اثر: اجازت دیں۔): s3: GetObject, s3: لسٹ بکٹ, 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

ان لوگوں کے لیے جو ریکوری کے عمل کو چیک کرنا چاہتے ہیں، ذیل میں bash جادو کا ایک چھوٹا سا ٹکڑا تیار کیا گیا ہے، تاکہ ریکوری میں دشواری کی صورت میں، اسکرپٹ غیر صفر ایگزٹ کوڈ کے ساتھ کریش ہوجائے۔ اس مثال میں، یہ معلوم کرنے کے لیے کہ آیا سگنل فائل کو ڈیلیٹ کر دیا گیا تھا یا نہیں (اس کا مطلب یہ ہوگا کہ ریکوری کامیاب تھی) کے ٹائم آؤٹ کے ساتھ 120 چیک کیے جاتے ہیں:

#!/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، وغیرہ)۔

ریکوری کے بعد ڈیٹا چیک کر رہا ہے۔

بحالی کے بعد ڈیٹا بیس کی سالمیت کو چیک کرنا ضروری ہے، تاکہ ٹوٹے/ٹیڑھے بیک اپ والی صورت حال پیدا نہ ہو۔ اور یہ ہر تخلیق شدہ آرکائیو کے ساتھ کرنا بہتر ہے، لیکن کہاں اور کیسے صرف آپ کی تخیل پر منحصر ہے (آپ انفرادی سرورز کو فی گھنٹہ کی بنیاد پر بڑھا سکتے ہیں یا CI میں چیک چلا سکتے ہیں)۔ لیکن کم از کم، ڈیٹا بیس میں ڈیٹا اور اشاریہ جات کو چیک کرنا ضروری ہے۔

ڈیٹا کو چیک کرنے کے لیے اسے ڈمپ کے ذریعے چلانا کافی ہے، لیکن یہ بہتر ہے کہ ڈیٹا بیس بناتے وقت آپ نے چیک سمز کو فعال کیا ہو (ڈیٹا چیکسم):

#!/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 / MariaDB;
منگو ڈی بی;
فاؤنڈیشن ڈی بی;
اور وعدوں کے مطابق، کئی اور متوقع ہیں!

ماخذ: www.habr.com

WAL-G: پوسٹگری ایس کیو ایل ڈی بی ایم ایس کا بیک اپ اور ریکوری