הגדרת מעבר אוטומטי למצב גיבוי עבור 1C-Bitrix

שרת מסד הנתונים הראשי קרס ב-3 לפנות בוקר. מהנדס התורן אינו זמין. ללא מעבר אוטומטי (failover), האתר נשאר מושבת עד הבוקר. עם מעבר אוטומטי מוגדר כראוי, התעבורה עוברת לעותק המשני תוך 30–60 שניות, והמשתמשים לא מבחינים בכלום. אנו מגדירים מעבר אוטומטי מוכן לשימוש, המכסה את כל השכבות — ממסד הנתונים ועד תצורת Bitrix. תוך 2–3 ימים, האשכול שלך משיג רמת סובלנות תקלות ברמת ייצור. אנו עובדים עם חברות המטפלות מ-10,000 מבקרים ביום — יותר מ-50 פרויקטים ב-5 השנים האחרונות. הערך את החיסכון: זמן השבתה לאתר עם תעבורה גבוהה יכול להיות יקר. המעבר האוטומטי מחזיר את עצמו באירוע בודד.

רכיבי המעבר האוטומטי

מעבר אוטומטי עבור Bitrix מורכב משלוש שכבות עצמאיות שחייבות לפעול יחד:

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

למה Patroni הוא התקן למעבר אוטומטי של PostgreSQL

Patroni הוא התקן דה פקטו למעבר אוטומטי של PostgreSQL. ארכיטקטורה: סוכן Patroni על כל צומת, etcd/Consul כ-DCS (מאגר תצורה מבוזר), HAProxy או pgBouncer מול האשכול.

Patroni עוקב אחר בריאות הצומת, ואם הראשי הופך ללא זמין, הוא מקיים בחירה למנהיג חדש דרך DCS. העותק המשני עם הפיגור הקטן ביותר (פיגור LSN הנמוך ביותר) הופך לראשי החדש. התהליך כולו אורך 10–30 שניות.

קריטי עבור Bitrix: היישום מתחבר למסד הנתונים לא ישירות לכתובת ה-IP של השרת אלא דרך HAProxy או דרך IP וירטואלי (VIP) המנוהל על ידי Patroni:

# /bitrix/.settings.php — подключение через HAProxy 'dsn' => 'pgsql:host=haproxy.internal;port=5432;dbname=bitrix', 

HAProxy בודק את REST API של Patroni (# /bitrix/.settings.php — подключение через HAProxy 'dsn' => 'pgsql:host=haproxy.internal;port=5432;dbname=bitrix', ) ומנתב תעבורה רק לראשי הנוכחי.

השוואה בין Patroni ו-Orchestrator:

מעבר MySQL דרך Orchestrator

עבור התקנות Bitrix מבוססות MySQL, האנלוגי של Patroni הוא Orchestrator. הוא עוקב אחר טופולוגיית השכפול, מזהה כשל ב-master, ומקדם אוטומטית את העותק המשני המעודכן ביותר. לאחר הקידום, Orchestrator קורא לסקריפט hook שמעדכן DNS או מודיע ל-HAProxy.

מה לעשות עם מטמון Bitrix לאחר מעבר אוטומטי?

לאחר המעבר האוטומטי, הראשי החדש הוא עותק משני לשעבר לקריאה. לפני המעבר, Bitrix עשוי היה להיות מוגדר לפיצול קריאה/כתיבה:

// /bitrix/.settings.php 'connections' => [ 'default' => [ 'host' => 'primary.db', 'port' => '5432', // ... write-соединение ], 'replica' => [ 'host' => 'replica.db', 'port' => '5432', 'readonly' => true, // ... read-соединение ], ], 

לאחר המעבר, העותק המשני הפך לראשי — אין להשתמש עוד במחרוזת http://patroni-node:8008/master עבור חיבורי קריאה בלבד (כעת הוא מקבל גם כתיבות). HAProxy עם בדיקות בריאות של Patroni API מטפל בכך אוטומטית: שני הפורטים (כתיבה 5432, קריאה 5433) נבדקים בנפרד.

עבור memcached/Redis, אין בעיות מטמון. עבור מטמון קבצים, אנו מבצעים איוולידציה דרך // /bitrix/.settings.php 'connections' => [ 'default' => [ 'host' => 'primary.db', 'port' => '5432', // ... write-соединение ], 'replica' => [ 'host' => 'replica.db', 'port' => '5432', 'readonly' => true, // ... read-соединение ], ], או דרך לוח הניהול. ההתקנה שלנו כוללת hook לאחר מעבר שעושה זאת אוטומטית.

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

ניטור מצב

# Patroni — текущий лидер curl http://patroni-node1:8008/cluster | jq '.members[] | {name, role, lag}' # Задержка репликации (PostgreSQL) SELECT client_addr, pg_wal_lsn_diff(sent_lsn, replay_lsn) AS lag_bytes FROM pg_stat_replication; 

התראה: אם replica, השכפול מפגר, מה שמגביר את הסיכון לאובדן נתונים במהלך מעבר אוטומטי.

שלבים להגדרת מעבר אוטומטי עבור Bitrix

1. ביקורת על תוכנית השכפול הנוכחית והתשתית.
2. התקנה ותצורה של Patroni (PostgreSQL) או Orchestrator (MySQL) עם DCS (etcd/Consul).
3. הגדרת HAProxy עם בדיקות בריאות דרך REST API של Patroni.
4. שינוי חיבור Bitrix דרך HAProxy (לא ישירות ל-IP של מסד הנתונים).
5. כתיבת סקריפט hook לאחר מעבר לאיוולידציית מטמון והתראות.
6. הגדרת ניטור פיגור שכפול עם התראה כאשר הסף נחצה.
7. בדיקת מעבר אוטומטי על סביבת עומס עם סימולציית תקלות.
8. תיעוד והדרכת צוות התורן.

#!/bin/bash # post_failover.sh # Очистка файлового кеша Битрикс bx-site /path/to/site bx:clear_cache --full # Уведомление в Telegram или Slack curl -X POST -H "Content-Type: application/json" -d '{"text":"Failover completed"}' https://hooks.slack.com/...