כאשר שרת PostgreSQL ראשי נכשל ללא standby של שכפול סטרימינג, המשבר נמשך שעות — במיוחד במסדי נתונים מ-500 GB עד 5 TB. שעת השבתה עבור שרת כזה יכולה לעלות $10,000 בהתאם לעסק, וה-RTO הופך לבלתי מקובל. מקרה טיפוסי: לקוח עם מסד נתונים של 2 TB, השרת הראשי נופל בשעות השיא. לפי הסטטיסטיקות שלנו, 70% מהתקלות מתרחשות בלילה כאשר המהנדס התורן לא מגיב מיד. ללא replica, ה-RTO הוא 8 שעות עם pg_restore. עם שכפול סטרימינג מוגדר, ה-failover אורך 2 דקות, וה-RPO הוא פחות משנייה אחת במצב סינכרוני.
אנחנו פותרים זאת על ידי הגדרת שכפול מבוסס WAL — אנו מקימים standby ששומר עותק מדויק של הנתונים עם השהיה של אלפיות שנייה. במשך 10 שנים, מעולם לא איבדנו עסקה אחת עם שכפול סינכרוני מוגדר כראוי. תוצאה: failover תוך דקות ויכולת לחלק שאילתות קריאה. להלן התצורה המעשית שבה אנו משתמשים בייצור.
בעיות שאנו פותרים
- אובדן נתונים בכשל של השרת הראשי: שכפול סטרימינג אסינכרוני ברירת מחדל עלול לאבד עסקאות אחרונות. אנו מגדירים מצב סינכרוני במקומות קריטיים.
- השהיית standby: ללא replication slots, הפסקה ממושכת של ה-standby דורשת pg_basebackup מלא — במסדי נתונים בגודל טרה-בייט, זה אומר שעות של השבתה. פתרון: replication slots + ניטור.
- קונפליקטים של שאילתות ב-standby: שאילתות קריאה ארוכות חוסמות את שחזור ה-WAL. אנו מפעילים hot_standby_feedback — ה-standby מודיע לשרת הראשי על השאילתות הפעילות שלו, כך שהשרת הראשי דוחה את ה-vacuum.
שכפול סטרימינג של PostgreSQL מהיר בערך פי 50 משחזור מגיבוי (דקות לעומת שעות). הגדרת שכפול נכונה מונעת הפסדים של עד $50,000 בשנה, והלקוחות שלנו בדרך כלל מחזירים את ההשקעה תוך שלושה חודשים.
איך אנחנו עושים זאת
אנו משתמשים בטכנולוגיות: PostgreSQL 16, Patroni ל-failover אוטומטי, Prometheus + Grafana לניטור. תצורה ראשית טיפוסית:
wal_level = replica max_wal_senders = 5 wal_keep_size = 1GB hot_standby = on track_commit_timestamp = on אתחול ה-standby באמצעות wal_level = replica max_wal_senders = 5 wal_keep_size = 1GB hot_standby = on track_commit_timestamp = on עם האפשרות pg_basebackup — העתקת הנתונים מתבצעת במקביל לקליטת ה-WAL, מה שמונע דה-סינכרון. לאחר יצירת standby.signal והגדרת primary_conninfo, ה-standby מוכן תוך 15-30 דקות בעומס טיפוסי. Patroni מחליף תפקידים אוטומטית בכשל של השרת הראשי, ומפחית את ה-RTO ל-2-5 דקות.
החשיבות של Replication Slots
Replication slots מבטיחים שהשרת הראשי לא מסיר WAL עד שה-standby מאשר קבלה, מה שחיוני להגדרות שכפול סטרימינג. אם ה-standby מתנתק לשעה, ה-slot שומר את ה-WAL, ולאחר התאוששות, השכפול ממשיך ללא pg_basebackup מלא. עם זאת, ניטור הוא חובה: אם ה-standby לא זמין לזמן ממושך, ה-WAL מצטבר ויכול למלא את הדיסק. אנו ממליצים לשלב slots עם wal_keep_size (לדוגמה, 2 GB) — זה מספק רשת ביטחון מפני הצפה פתאומית.
השוואה בין שכפול סינכרוני ואסינכרוני
| פרמטר | אסינכרוני | סינכרוני (FIRST 1) |
|---|---|---|
| אובדן נתונים | אפשרי (אלפיות שניות עד שניות) | אפס אובדן נתונים |
| השהיית COMMIT | מינימלית (ללא המתנה) | השהיה = RTT + fsync ב-standby |
| ביצועים | גבוהים | נמוכים ב-10-30% בהתאם לרשת |
| RPO | בדרך כלל < 1 שנייה | 0 (עם רשת תקינה) |
שכפול סינכרוני מבטיח אפס אובדן נתונים אך מאט כתיבה ב-10-30% בהשוואה לאסינכרוני.
ניטור השהיית שכפול
השיטה המדויקת ביותר היא השאילתה --wal-method=stream ב-standby. בייצור, אנו מגדירים התראות דרך Prometheus: אם ההשהיה עולה על 10 שניות, המהנדס התורן מקבל הודעת Telegram. אנו גם מנטרים את נפח ה-WAL ב-slots (השדה SELECT now() - pg_last_xact_replay_timestamp()). כאשר standby מושבת לזמן ממושך (יותר משעה), slot יכול לצבור עד 50 GB של WAL — איום על הדיסק. אנו ממליצים להגדיר התראות אוטומטיות כאשר ניצול ה-slot מגיע ל-80%. בשרתים עם SSD ורשת 10GbE, ההשהיה היא בדרך כלל < 1 אלפית שנייה.
תהליך העבודה
- ניתוח — ביקורת על התצורה הנוכחית, העומס וה-SLA עבור RPO/RTO.
- תכנון — בחירת מצב (async/sync), רשת, slots, ניטור.
- יישום — הגדרת postgresql.conf ו-pg_hba.conf בשרת הראשי, יצירת משתמש replication, ביצוע pg_basebackup, הגדרת standby.signal ו-recovery.conf, ולאחר מכן בדיקת קישוריות.
- בדיקות — אימות השהיה, failover וביצועים במצב סינכרוני.
- תיעוד — runbook, התראות, הוראות למהנדס התורן.
טעויות נפוצות והשלכותיהן
| טעות | השלכה | פתרון |
|---|---|---|
| חוסר ב-replication slots | pg_basebackup מלא בעת ניתוק | שימוש ב-replication slots |
| ללא ניטור דיסק WAL | הדיסק מתמלא, השירות קורס | התראות ב-80% ניצול slot |
| הגדרות סינכרוניות שגויות | בשירותים רגישים להשהיה, הביצועים יורדים ב-30% | בדיקת עומס |
מה כלול
- הגדרת השרת הראשי וה-standby המותאמת לחומרה שלך.
- יצירת replication slots וניטור השימוש שלהם.
- הגדרת התראות על השהיה (לדוגמה, כאשר העיכוב עולה על 10 שניות).
- אופציונלי: התקנת Patroni ל-failover אוטומטי.
- מסירת תיעוד והדרכה לצוות שלך.
לוח זמנים ועלות
הגדרת קלאסטר דו-צומתי עם שכפול סטרימינג של PostgreSQL אורכת 4-8 שעות עבודה. אם אתה צריך את החבילה המלאה עם ניטור, התראות ו-Patroni, לוח הזמנים מתארך ל-1-3 ימים. עלות טיפוסית להקמת קלאסטר דו-צומתי, כולל ניטור ותיעוד, היא $3,500. העלות מחושבת באופן אישי — אנו נעריך את הפרויקט לאחר בריף קצר. קבל ייעוץ ממהנדס — אנו נעזור לך לבחור את הסכימה האופטימלית ל-SLA שלך. הזמן ביקורת על תצורת PostgreSQL הנוכחית שלך. צור קשר להערכת עלות.
הגדרנו שכפול למסדי נתונים מ-500 GB עד 5 TB — בכל המקרים, השגנו השהיה < 1 שנייה במצב אסינכרוני. במשך יותר מ-10 שנות ניסיון, היו לנו אפס מקרי אובדן נתונים עם שכפול סינכרוני מוגדר כראוי.
פרטים נוספים בתיעוד PostgreSQL.