🥇WAL-G: د PostgreSQL DBMS بیک اپ او بیا رغونه

دا له ډیرې مودې راهیسې پیژندل شوي چې د SQL ډمپونو کې بیک اپ رامینځته کول (په کارولو سره pg_dump او یا pg_dumpall) ښه نظر نه دی. د PostgreSQL DBMS بیک اپ کولو لپاره، دا غوره ده چې کمانډ وکاروئ پاڼه، کوم چې د WAL لاګونو بائنری کاپي جوړوي. مګر کله چې تاسو د کاپي رامینځته کولو او بیا رغولو ټول پروسې مطالعه پیل کړئ ، نو تاسو به پوه شئ چې تاسو اړتیا لرئ لږترلږه یو څو ټرایسیکلونه ولیکئ ترڅو دا ټول کار وکړي او تاسو ته پورته او لاندې دواړه درد ونه کړي. د درد کمولو لپاره، WAL-G رامینځته شوی.

وال-جي یوه وسیله ده چې په Go کې د 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 تنظیم کول

د بیک اپ ذخیره کولو مثال لپاره، ایمیزون 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 - د بشپړ بیک اپ رامینځته کولو دمخه د "ډیلټا" شمیر (دوی وخت او د ډاونلوډ شوي ډیټا اندازه خوندي کوي ، مګر کولی شي د بیا رغونې پروسه یو څه ورو کړي ، نو د لوی ارزښتونو کارولو مشوره نده)؛
PGDATA - ستاسو د ډیټابیس ډیټا سره لارښود ته لاره (تاسو کولی شئ د کمانډ په چلولو سره ومومئ pg_lsclusters);
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 لاګونو کې لیکل کیږي، "نقل" - هرڅه ولیکئ؛
archive_mode - د پیرامیټر څخه د کمانډ په کارولو سره د 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_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 ورځو لپاره کاپي وي، مګر لږترلږه یو بیک اپ پریږدي پورې ټاکل شوې نیټه نو هر ټکی после نیټې په PITR کې شاملې وې.

د بیک اپ څخه بیرته راګرځول

دا هیڅ راز پټ نه دی چې د سالم ډیټابیس کلیدي دوره ایز بیا رغونه او دننه د معلوماتو بشپړتیا تایید کول دي. زه به تاسو ته ووایم چې څنګه پدې برخه کې د WAL-G په کارولو سره بیرته ترلاسه کول، او موږ به وروسته د چکونو په اړه وغږیږو.

دا باید په جلا توګه یادونه وشي دا چې د ازموینې چاپیریال کې د بیرته راګرځولو لپاره (هر هغه څه چې تولید نه وي) تاسو اړتیا لرئ په S3 کې یوازې د لوستلو حساب وکاروئ ترڅو په ناڅاپي ډول بیک اپونه له سره لیکل نه شي. د WAL-G په حالت کې، تاسو اړتیا لرئ چې د S3 کاروونکي لپاره لاندې حقونه په ګروپ پالیسۍ کې تنظیم کړئ (اثر: اجازه ورکړئ): s3:GetObject, s3: ListBucket, s3:GetBucketLocation. او البته، تنظیم کول مه هیروئ آرشیف_موډ = بند د ترتیباتو فایل کې 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، etc.) بیرته پیل کړئ.

د بیا رغونې وروسته د معلوماتو چک کول

دا اړینه ده چې د بیا رغولو وروسته د ډیټابیس بشپړتیا وڅیړئ، ترڅو د مات شوي / کریډ بیک اپ سره وضعیت رامینځته نشي. او دا غوره ده چې دا د هر رامینځته شوي آرشیف سره ترسره کړئ ، مګر چیرې او څنګه یوازې ستاسو په تصور پورې اړه لري (تاسو کولی شئ په یو ساعت کې انفرادي سرورونه لوړ کړئ یا په 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;
MongoDB;
FoundationDB;
او د ژمنو په واسطه قضاوت کول، ډیری نور تمه کیږي!

سرچینه: www.habr.com

WAL-G: د PostgreSQL DBMS بیک اپ او بیا رغونه