WAL-G: גיבויים ושחזור של PostgreSQL DBMS

זה זמן רב ידוע שביצוע גיבויים ל-SQL dumps (באמצעות pg_dump או pg_dumpall) זה לא רעיון טוב. כדי לגבות את PostgreSQL DBMS, עדיף להשתמש בפקודה pg_basebackup, אשר יוצר עותק בינארי של יומני WAL. אבל כשתתחיל ללמוד את כל התהליך של יצירת העתקה ושחזור, תבין שאתה צריך לכתוב לפחות כמה תלת אופן כדי שזה יעבוד ולא יגרום לך לכאבים גם למעלה וגם למטה. כדי להקל על הסבל פותח WAL-G.

WAL-G הוא כלי שנכתב ב-Go לגיבוי ושחזור מסדי נתונים של PostgreSQL (ולאחרונה MySQL/MariaDB, MongoDB ו-FoundationDB). הוא תומך בעבודה עם אחסון Amazon S3 (ואנלוגים, למשל, Yandex Object Storage), כמו גם Google Cloud Storage, Azure Storage, Swift Object Storage ופשוט עם מערכת הקבצים. ההגדרה כולה מסתכמת בצעדים פשוטים, אבל בשל העובדה שמאמרים על זה מפוזרים ברחבי האינטרנט, אין מדריך הוראות שלם שיכלול את כל השלבים מתחילתו ועד סופו (יש כמה פוסטים על Habré, אבל הרבה נקודות מחמיצות שם).

מאמר זה נכתב בעיקר כדי לסדר את הידע שלי. אני לא DBA ואני יכול להתבטא בשפת הדיוטות איפשהו, אז כל תיקון יתקבל בברכה!

בנפרד, אני מציין שכל מה למטה רלוונטי ונבדק עבור PostgreSQL 12.3 ב-Ubuntu 18.04, כל הפקודות חייבות להתבצע כמשתמש מיוחס.

התקנה

בזמן כתיבת מאמר זה, הגרסה היציבה של WAL-G היא v0.2.15 (מרץ 2020). זה מה שנשתמש (אבל אם אתה רוצה לבנות אותו בעצמך מהענף הראשי, אז למאגר github יש את כל ההוראות לכך). כדי להוריד ולהתקין אתה צריך לעשות:

#!/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 בספריית הבית של משתמש postgres. כדי ליצור אותו, הפעל את סקריפט ה-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 - מספר ה"deltas" לפני יצירת גיבוי מלא (הם חוסכים זמן וגודל הנתונים שהורדו, אך יכולים להאט מעט את תהליך השחזור, ולכן לא מומלץ להשתמש בערכים גדולים);
• 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, "רפליקה" - לכתוב הכל;
• מצב_ארכיון - אפשר הורדה של יומני WAL באמצעות הפקודה מהפרמטר פקודה_ארכיון;
• פקודה_ארכיון - פקודה לארכיון יומן WAL שהושלם;
• פסק זמן_ארכיון – ארכיון של יומנים מתבצע רק כשהוא הושלם, אבל אם השרת שלך משנה/מוסיף מעט נתונים למסד הנתונים, אז הגיוני להגדיר כאן מגבלה תוך שניות, ולאחר מכן פקודת הארכיון תיקרא בכוח (אני כותב באופן אינטנסיבי לבסיס הנתונים כל שנייה, אז החלטתי לא להגדיר את הפרמטר הזה בייצור);
• restore_command – הפקודה לשחזור יומן WAL מגיבוי תשמש אם "הגיבוי המלא" (גיבוי הבסיס) חסר את השינויים האחרונים במסד הנתונים.

תוכל לקרוא עוד על כל הפרמטרים הללו בתרגום התיעוד הרשמי: https://postgrespro.ru/docs/postgresql/12/runtime-config-wal.

הגדרת לוח זמנים לגיבוי

מה שיגידו, הדרך הנוחה ביותר להפעיל אותו היא cron. זה מה שנקבע ליצירת גיבויים. נתחיל עם הפקודה ליצירת גיבוי מלא: ב-wal-g זהו ארגומנט ההשקה גיבוי-דחיפה. אבל ראשית, עדיף להפעיל את הפקודה הזו באופן ידני מהמשתמש postgres כדי לוודא שהכל בסדר (ואין שגיאות גישה):

#!/bin/bash

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

ארגומנטי ההשקה מציינים את הנתיב לספריית הנתונים - אני מזכיר לך שאתה יכול לגלות זאת על ידי הפעלה pg_lsclusters.

אם הכל הלך ללא שגיאות והנתונים נטענו לאחסון S3, לאחר מכן תוכל להגדיר הפעלה תקופתית ב-crontab:

#!/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). אנו נעשה זאת באמצעות משימת cron:

#!/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

Cron יריץ את המשימה הזו כל יום בשעה 6:30 בבוקר, ימחק הכל (גיבויים מלאים, deltas ו-WALs) מלבד עותקים של 10 הימים האחרונים, אך ישאיר לפחות גיבוי אחד до תאריך מוגדר כך שכל נקודה לאחר תאריכים נכללו ב-PITR.

שחזור מגיבוי

זה לא סוד שהמפתח למסד נתונים בריא הוא שחזור ואימות תקופתי של תקינות הנתונים בפנים. אני אגיד לך כיצד לשחזר באמצעות WAL-G בסעיף זה, ונדבר על המחאות מאוחר יותר.

יש לציין זאת בנפרד שכדי לשחזר בסביבת בדיקה (כל מה שהוא לא ייצור) צריך להשתמש בחשבון Read Only ב-S3 כדי לא לדרוס בטעות גיבויים. במקרה של WAL-G, עליך להגדיר את הזכויות הבאות עבור משתמש S3 במדיניות קבוצתית (השפעה: אפשר): s3:GetObject, s3:ListBucket, s3:GetBucketLocation. וכמובן, אל תשכח להגדיר archive_mode=כבוי בקובץ ההגדרות 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 בדיקות עם פסק זמן של 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 וכו').

בדיקת נתונים לאחר השחזור

חובה לבדוק את תקינות בסיס הנתונים לאחר השחזור, כדי שלא ייווצר מצב של גיבוי שבור/עקום. ועדיף לעשות זאת עם כל ארכיון שנוצר, אבל איפה ואיך תלוי רק בדמיון שלך (אתה יכול להעלות שרתים בודדים על בסיס שעתי או להפעיל צ'ק ב-CI). אבל לכל הפחות, יש צורך לבדוק את הנתונים והאינדקסים במסד הנתונים.

כדי לבדוק את הנתונים, מספיק להריץ אותם דרך dump, אבל עדיף שביצירת מסד הנתונים תפעילו סכימי בדיקה (סכומי בדיקת נתונים):

#!/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;
• קרן DB;
• ואם לשפוט לפי המתחייבים, צפויים עוד כמה!

מקור: www.habr.com