הגדרת ארכיון WAL של PostgreSQL: WAL-G, pgBackRest, PITR

הגדרת ארכיון WAL של PostgreSQL: WAL-G, pgBackRest, PITR

תארו לעצמכם: שרת עם PostgreSQL 15 קורס עקב תקלת מערך דיסקים. ללא הגדרת ארכיון WAL, שחזור לשנייה האחרונה הוא בלתי אפשרי — אתם מאבדים שעות של עסקאות. אנו מגדירים ארכיון WAL כך ש-RPO לא יעלה על דקה אחת, ו-RTO יהיה מתחת ל-30 דקות גם עבור מסדי נתונים בגודל טרה-בייט.

צוות מהנדסי ה-DevOps שלנו סיפק למעלה מ-50 פרויקטים של גיבוי PostgreSQL לחברות פינטק וקמעונאות. במאמר זה, אנו מפרקים כיצד להגדיר ארכיון WAL בצורה נכונה ולהימנע מאובדן נתונים.

מדוע ארכיון WAL הוא קריטי

WAL (יומן כתיבה מראש) הוא יומן הכתיבה המוקדמת. ללא הארכיון שלו, נקודת השחזור (RPO) שווה למרווח בין גיבויים מלאים — שעות או ימים. עבור מערכות קריטיות, זה בלתי מתקבל על הדעת. ארכיון WAL מאפשר שחזור לנקודת זמן (PITR) לכל רגע, דבר חיוני כאשר מתרחשות פעולות DROP מקריות או תקלות.

בעיות שאנו פותרים

חוסר סובלנות לתקלות. ללא ארכיון WAL, RPO יכול להיות שעות או אפילו ימים אם גיבויים מלאים נלקחים פעם ביום. לאחר קריסה, כל השינויים מאז הגיבוי האחרון אובדים. לדוגמה, אם הדיסק המכיל את PGDATA נכשל, אינכם יכולים לשחזר לשנייה שלפני הקריסה — רק לגיבוי המלא האחרון.

חוסר יכולת לבצע PITR. גם עם גיבוי מלא, ללא ארכיון WAL אינכם יכולים לשחזר את מסד הנתונים לנקודת זמן שרירותית. זה קריטי לחזרה מפעולות שגויות (DROP TABLE, DELETE ללא WHERE) או לניתוח מצב מסד הנתונים בעבר.

אתגרי ניטור. רבים שוכחים לבדוק אם מקטעי WAL מועתקים בהצלחה. כתוצאה מכך, הארכיון עלול להיות ריק או פגום, ורק מתגלה במהלך אסון. יש צורך בניטור: pg_stat_archiver מציג את מספר ניסיונות הארכיון שנכשלו. אם failed_count גדל — הגיע הזמן להפעיל אזעקה.

כיצד אנו מגדירים ארכיון WAL

לפי התיעוד הרשמי של PostgreSQL, יש להפעיל את postgresql.conf ולהגדיר את wal_level = replica # минимум для архивирования archive_mode = on archive_command = 'wal-g wal-push %p' archive_timeout = 300 # принудительно архивировать каждые 5 минут (для PITR с малым RPO) ל-%p ומעלה.

בחירת הכלי: WAL-G לעומת pgBackRest

pgBackRest מהיר פי 2-3 בשחזור על מסדי נתונים גדולים, אך WAL-G פשוט פי 3 להגדרה. עבור מערכות קריטיות עם טרה-בייטים של נתונים, אנו בוחרים ב-pgBackRest; עבור פרויקטים קטנים יותר, WAL-G. במבחני ביצועים, pgBackRest הפחית את זמן השחזור ב-40% עבור מסד נתונים של 500GB בהשוואה ל-WAL-G.

הגדרת פרמטרים מרכזיים

ב-%f:

wal_level = replica # минимум для архивирования
archive_mode = on
archive_command = 'wal-g wal-push %p'
archive_timeout = 300 # принудительно архивировать каждые 5 минут (для PITR с малым RPO)

archive_command הוא הנתיב המלא לקובץ WAL, wal-g הוא שם הקובץ בלבד. # Установка wget https://github.com/wal-g/wal-g/releases/latest/download/wal-g-pg-ubuntu-20.04-amd64.tar.gz tar -xzf wal-g-pg-ubuntu-20.04-amd64.tar.gz mv wal-g /usr/local/bin/ # Переменные окружения (в /etc/postgresql/16/main/environment или systemd unit) WALG_S3_PREFIX=s3://my-pg-backups/wal AWS_REGION=eu-central-1 AWS_ACCESS_KEY_ID=AKIA... AWS_SECRET_ACCESS_KEY=... WALG_COMPRESSION_METHOD=brotli WALG_DELTA_MAX_STEPS=6 # delta backup до 6 шагов חייב להחזיר 0 על הצלחה. ודאו שהנתיב ל-# postgresql.conf archive_command = 'wal-g wal-push %p' restore_command = 'wal-g wal-fetch %f %p' נגיש למשתמש postgres.

הגדרת ארכיון ל-S3 עם WAL-G

# Установка
wget https://github.com/wal-g/wal-g/releases/latest/download/wal-g-pg-ubuntu-20.04-amd64.tar.gz
tar -xzf wal-g-pg-ubuntu-20.04-amd64.tar.gz
mv wal-g /usr/local/bin/

# Переменные окружения (в /etc/postgresql/16/main/environment или systemd unit)
WALG_S3_PREFIX=s3://my-pg-backups/wal
AWS_REGION=eu-central-1
AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=...
WALG_COMPRESSION_METHOD=brotli
WALG_DELTA_MAX_STEPS=6 # delta backup до 6 шагов

# postgresql.conf archive_command = 'wal-g wal-push %p' restore_command = 'wal-g wal-fetch %f %p' 

אימות:

# Список загруженных WAL сегментов
sudo -u postgres wal-g wal-verify integrity
# Ручная загрузка базового бэкапа
sudo -u postgres wal-g backup-push $PGDATA

קביעת RPO ו-RTO עבור מסד הנתונים שלכם

הגדרת RPO ו-RTO היא בקשה נפוצה של לקוחות. RPO (יעד נקודת שחזור) הוא אובדן הנתונים המקסימלי המקובל. עבור מערכות קריטיות, RPO צריך להיות ≤ דקה אחת. זה מושג על ידי הגדרת # Список загруженных WAL сегментов sudo -u postgres wal-g wal-verify integrity # Ручная загрузка базового бэкапа sudo -u postgres wal-g backup-push $PGDATA וניטור תור ה-WAL. RTO (יעד זמן שחזור) הוא הזמן הנדרש לשחזור מסד הנתונים. עבור מסד נתונים של 1 TB עם pgBackRest, RTO הוא כ-30 דקות עם שחזור מקבילי. עם WAL-G, עד שעתיים.

בפרויקט לחברת פינטק עם מסד נתונים PostgreSQL של 1TB, הפחתנו את RPO לדקה אחת על ידי הגדרת archive_timeout = 60 וייעלנו את השחזור עם pgBackRest, והשגנו RTO מתחת ל-30 דקות. זה חסך ללקוח 50,000 דולר באובדן הכנסות פוטנציאלי לשעת השבתה.

טיפול בכשלי archive_command

שגיאות ארכיון נפוצות. סיבות: בעיות רשת, בעיות מפתח IAM, הצפת דלי. תוכנית פעולה:

• בדקו את pg_stat_archiver ו-postgresql.log לאיתור שגיאות.
• ודאו ש-archive_command נכון על ידי ביצועו כמשתמש postgres: sudo -u postgres wal-g wal-push /path/to/wal.
• הגדירו התראות על ניסיונות שנכשלו (לדוגמה, דרך Prometheus על archive_mode = off). אנו מגדירים התראת Prometheus: # 1. Восстановить полный бэкап sudo -u postgres wal-g backup-fetch /tmp/restore LATEST # 2. Создать recovery.conf (PG <12) или recovery.signal (PG >=12) с restore_command restore_command = 'wal-g wal-fetch %f %p' # 3. Запустить PostgreSQL и проверить данные מפעיל את PagerDuty.
• גיבוי: השבתה זמנית של הארכיון (archive_mode = off) וצבירת קבצי WAL מקומית, ולאחר מכן העלאה ידנית.

בדיקת שחזור (PITR)

בצעו שחזור בדיקה על שרת נפרד באופן קבוע. שחזור PITR:

# 1. Восстановить полный бэкап
sudo -u postgres wal-g backup-fetch /tmp/restore LATEST

# 2. Создать recovery.conf (PG <12) или recovery.signal (PG >=12) с restore_command
restore_command = 'wal-g wal-fetch %f %p'

# 3. Запустить PostgreSQL и проверить данные

בדקו שחזור לפחות פעם בחודש. זה יגלה בעיות ארכיון לפני אסון.

מה כלול בעבודה שלנו (תוצרים)

• ניתוח תשתית נוכחית: גרסת PostgreSQL, עומס, אחסון זמין
• בחירת כלי (WAL-G / pgBackRest) עם נימוק
• הגדרת שרת ארכיון ודלי S3
• הגדרת postgresql.conf וסקריפטים של ארכיון
• הגדרת ניטור למצב ארכיון (Prometheus + Grafana)
• בדיקת שחזור PITR עם מדידת RTO
• תיעוד: מדריך שחזור, אנשי קשר אחראיים
• הכשרת הצוות שלכם על נהלי שחזור ידניים

תהליך העבודה בפרויקט

1. הערכה: ניתוח תשתית נוכחית (גרסת PG, עומס, אחסון).
2. תכנון: תכנון סכמת ארכיון: בחירת כלי, דלי S3, מדיניות שמירה.
3. יישום: הגדרת שרת, התקנה והגדרה של WAL-G או pgBackRest.
4. בדיקות: שחזור PITR, בדיקת שלמות ארכיון.
5. עלייה לייצור ותיעוד: מדריך שחזור, סקריפטים לניטור.

לוחות זמנים ועלות

לוח זמנים טיפוסי: בין יום ל-3 ימי עסקים בהתאם למורכבות התשתית. עלות השירות נעה בין 1,500 ל-3,000 דולר. עלות אחסון S3 החודשית עבור מסד נתונים של 1TB היא כ-23 דולר. הגדרה זו יכולה לחסוך 50,000 דולר לשעת השבתה שנמנעה.

בקשו ביקורת על סכמת הגיבוי הנוכחית שלכם — נזהה צווארי בקבוק ונציע אופטימיזציות. קבלו ייעוץ מהמהנדס שלנו על הגדרת ארכיון WAL.