הקמת מסד נתונים עם שחזור לנקודת זמן (PITR)
תארו לעצמכם: בשעה 14:37 מישהו מוחק בטעות את טבלת orders, או בשעה 09:15 עדכון המוני שגוי פוגע במיליון שורות. ללא PITR, השחזור אפשרי רק לגיבוי האחרון — כל הנתונים שאחריו אבודים. אנו פותרים זאת על ידי הגדרת שחזור לנקודת זמן עבור PostgreSQL ו-MySQL, כך שתוכלו לחזור אחורה לכל שנייה. גיבויים סטנדרטיים מגנים מפני כשל מוחלט, אך לא מפני שגיאות לוגיות. PITR מאפשר שחזור ברמת דיוק של טרנזקציה. מדדי מפתח: RPO (יעד נקודת שחזור) — אובדן נתונים מקסימלי. עם archive_timeout=300, RPO ≤ 5 דקות. RTO (יעד זמן שחזור) — זמן השחזור. עבור מסד נתונים של 100 GB, 15–40 דקות. ללא PITR, השחזור יכול לקחת ימים במקום שעות, ונתונים שאבדו לרוב אינם ניתנים לשחזור. לפי תיעוד PostgreSQL, ארכוב WAL הוא הבסיס ל-PITR. החיסכון מתקרית אחת של מחיקת נתונים יכול לעלות על $5,000.
למה PITR הוא הכרח, לא אופציה
ללא PITR, אתם מאבדים את כל השינויים לאחר הגיבוי האחרון. זה יכול לעלות בשעות עבודה ובפגיעה במוניטין. עם PITR, אתם משחזרים לרגע שלפני השגיאה, ומאבדים רק כמה דקות. חיסכון בזמן במהלך שחזור מהיר פי 10 מהזנת נתונים מחדש.
מסדי נתונים נתמכים
- PostgreSQL — pgBackRest עם שכפול ל-S3.
- MySQL — יומני בינאריים עם
binlog_format=ROW.
איך PITR עובד
נדרשים שני רכיבים: תמונת מצב בסיסית (גיבוי מלא) וזרם רציף של יומני טרנזקציות מתמונת המצב ועד לזמן הנוכחי (WAL עבור PostgreSQL, binlog עבור MySQL). שחזור = תמונת מצב בסיסית + הפעלה חוזרת של היומנים עד לנקודה הרצויה. עלות אחסון עבור ארכיוני WAL ב-S3 עבור מסד נתונים של 100 GB היא כ-$15 לחודש. כל קטע WAL הוא 16 MB ויש לו מספר רצף יומן ייחודי (LSN), המאפשר שחזור ממוקד במדויק.
הגדרת PITR עבור PostgreSQL
הגדרת ארכוב WAL
בתוך postgresql.conf:
wal_level = replica
archive_mode = on
archive_command = 'pgbackrest --stanza=myapp archive-push %p'
archive_timeout = 300נדרשת הפעלה מחדש של PostgreSQL לאחר שינוי wal_level = replica archive_mode = on archive_command = 'pgbackrest --stanza=myapp archive-push %p' archive_timeout = 300 .
pgBackRest: הגדרת PITR מלאה
# /etc/pgbackrest/pgbackrest.conf
[global]
repo1-path=/mnt/backup-storage/pgbackrest
repo1-retention-full=3
repo1-retention-archive=14
repo2-type=s3
repo2-path=/pgbackrest
repo2-s3-bucket=company-db-backups
repo2-s3-region=eu-west-1
repo2-retention-full=2
[myapp]
pg1-path=/var/lib/postgresql/14/main
pg1-port=5432
שחזור לנקודת זמן
systemctl stop postgresql
pgbackrest --stanza=myapp restore \
--target="YYYY-MM-DD HH:MM:SS" \
--target-action=promote \
--delta
systemctl start postgresqlהחליפו את wal_level בחותמת הזמן הרצויה. # /etc/pgbackrest/pgbackrest.conf [global] repo1-path=/mnt/backup-storage/pgbackrest repo1-retention-full=3 repo1-retention-archive=14 repo2-type=s3 repo2-path=/pgbackrest repo2-s3-bucket=company-db-backups repo2-s3-region=eu-west-1 repo2-retention-full=2 [myapp] pg1-path=/var/lib/postgresql/14/main pg1-port=5432 משחזר רק קבצים ששונו, ומאיץ את התהליך.
הגדרת PITR עבור MySQL באמצעות binlog
הגדרת יומן בינארי
# /etc/mysql/mysql.conf.d/mysqld.cnf
server_id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_format = ROW
expire_logs_days = 14
max_binlog_size = 500M
binlog_row_image = FULLשחזור באמצעות mysqlbinlog
mysql -u root myapp < full_backup_YYYYMMDD.sql
mysqlbinlog \
--stop-datetime="YYYY-MM-DD HH:MM:SS" \
/var/log/mysql/mysql-bin.000040 \
/var/log/mysql/mysql-bin.000041 \
/var/log/mysql/mysql-bin.000042 | mysql -u root myapp
כדי לדלג על טרנזקציה בעייתית, ציינו את systemctl stop postgresql pgbackrest --stanza=myapp restore \ --target="YYYY-MM-DD HH:MM:SS" \ --target-action=promote \ --delta systemctl start postgresql ו---target ב-mysqlbinlog כדי לא לכלול את האירוע הפגום.
בחירה בין PITR על PostgreSQL ו-MySQL
| פרמטר | PostgreSQL (pgBackRest) | MySQL (binlog) |
|---|---|---|
| RPO ברירת מחדל | 5 דקות | ≤ דקה אחת (ללא עיכוב) |
| RTO עבור 100 GB | 15–40 דקות | 10–30 דקות |
| שכפול מובנה | סטרימינג (ילידי) | אסינכרוני/סמי-סינכרוני (ילידי) |
| אחסון ארכיון | S3, מקומי, NFS | מערכת קבצים, S3 (באמצעות כלים) |
| שחזור מבוסס LSN | כן | לא (זמן/מיקום בלבד) |
PostgreSQL מציע גמישות רבה יותר (שחזור LSN, יישום מקבילי) אך דורש כוונון קפדני יותר. MySQL פשוט יותר להגדרה, אך קבצי binlog יכולים לצרוך מקום משמעותי עם פורמט --delta.
אחסון מקומי לעומת S3 עבור ארכיון WAL
| פרמטר | דיסק מקומי | S3 (ענן) |
|---|---|---|
| מהירות כתיבה | גבוהה (NVMe) | בינונית (תלוי ברוחב פס) |
| אמינות | מוגבלת (כשל דיסק) | גבוהה (שכפול 7×9) |
| עלות | חד-פעמית | חודשית (~$15 לחודש עבור 100 GB) |
| שחזור דרך האינטרנט | מקומי בלבד | מכל מקום |
| המלצה | למסדי נתונים < 50 GB | למסדי נתונים > 50 GB ולשחזור מאסון (DR) |
תהליך הגדרת PITR שלנו
- ביקורת תשתית קיימת — קביעת גודל מסד הנתונים, תדירות השינויים, דרישות RTO/RPO.
- הגדרת ארכוב — הגדרת WAL/binlog, בחירת מאגר (דיסק מקומי + S3).
- בדיקת שחזור — אימות שחזור לנקודה אקראית בסביבה מבודדת.
- תיעוד — תיעוד נהלים, יצירת runbook למהנדסי תורנות.
- הדרכה — עריכת סדנה לצוות שלכם על שחזור ידני ואוטומטי.
טעויות נפוצות וכיצד להימנע מהן
- קטע WAL חסר עקב
# /etc/mysql/mysql.conf.d/mysqld.cnf server_id = 1 log_bin = /var/log/mysql/mysql-bin.log binlog_format = ROW expire_logs_days = 14 max_binlog_size = 500M binlog_row_image = FULLשגוי — ודאו שהפקודה מסתיימת עם קוד 0. השתמשו ב-mysql -u root myapp < full_backup_YYYYMMDD.sql mysqlbinlog \ --stop-datetime="YYYY-MM-DD HH:MM:SS" \ /var/log/mysql/mysql-bin.000040 \ /var/log/mysql/mysql-bin.000041 \ /var/log/mysql/mysql-bin.000042 | mysql -u root myapp. - מרווח
--start-positionגדול מדי — מגדיל את RPO. שמרו על 5 דקות או פחות. - אין שכפול ארכיון — אנו משתמשים ב-S3 באזור אחר לשחזור מאסון.
- חוסר בתרגולים קבועים — שחזור ללא בדיקות יכול להיכשל ברגע קריטי.
תזמנו שחזור בדיקה לפחות פעם ברבעון. אנו נעזור בכך.
מה כלול
- הגדרת PITR מלאה עבור PostgreSQL ו/או MySQL.
- הגדרת pgBackRest או binlog עם גיבוי ענן.
- שחזור בדיקה ודוח תוצאות.
- תיעוד נהלי שחזור (runbook).
- הדרכה למהנדסים שלכם.
- אחריות שחזור לכל נקודת זמן בתוך התקופה המוגדרת.
לוח זמנים ועלות
זמן הגדרה: 2 עד 5 ימי עסקים בהתאם למורכבות התשתית (שכפול, S3, אשכולות). עלות החל מ-$2,500 עבור הגדרת מסד נתונים יחיד. הזמינו הגדרת PITR עכשיו — הגנו על הנתונים שלכם. לייעוץ, צרו קשר: המנהל האישי שלכם יעריך את המערכת תוך יום אחד.
יש לנו ניסיון של למעלה מ-10 שנים בניהול PostgreSQL ו-MySQL, וביצענו יותר מ-40 פרויקטי PITR. המהנדסים שלנו מוסמכים ועוברים הכשרות קבועות. אנו מתחייבים לשחזור נתונים במסגרת RTO/RPO המוסכמים. צרו קשר לייעוץ.
לקריאה נוספת: תיעוד רשמי של PostgreSQL על WAL ו-יומן בינארי של MySQL.