שכפול MySQL עבור Bitrix: מהירות וסובלנות לתקלות

בעומס שיא — מבצע או השקת קמפיין פרסום — מסד הנתונים של Bitrix לא מצליח להתמודד עם שאילתות SELECT. עמוד הקטלוג נטען תוך 10 שניות, מנהלים לא מצליחים לטעון את רשימת ההזמנות. הפתרון הוא שכפול MySQL (Replication): ה-master מטפל בכתיבות, וה-replicas משרתות קריאות. ללא שכפול, מסד הנתונים הוא נקודת כשל יחידה. אנו מגדירים שכפול עמיד לתקלות עם תוצאה מובטחת. הניסיון שלנו: מעל 5 שנים ו-50 פרויקטים מוצלחים. החיסכון בתשתיות לאחר היישום מגיע ל-30% על ידי הפחתת העומס על ה-master. עלות התמיכה הממוצעת יורדת ב-40%. לפי הנתונים שלנו, בפרויקטים עם 10,000+ מבקרים ייחודיים ביום, זמן התגובה של MySQL בעומסי שיא גדל פי 3-5. השכפול מקצר את זמן טעינת עמוד הקטלוג ב-40-60% ומבטל לחלוטין השבתות במהלך גיבויים. צרו קשר להערכה ראשונית של הפרויקט שלכם.

בעיות שהשכפול פותר

• קנה מידה לקריאות: שאילתות SELECT לקטלוג, חיפוש ורשימות מבוצעות על ה-replicas. העומס על ה-master יורד ב-70-90%.
• גיבוי ללא עומס: mysqldump על replica לא חוסם את ה-master, אפילו עם מסדי נתונים בגודל טרה-בייט.
• מעבר חירום (Failover): במקרה של כשל ב-master, replica הופך ל-master תוך דקות. זמן ההשבתה אינו עולה על 5 דקות עם מעבר ידני.

הגדרת שכפול עבור Bitrix

הגדרת Master

/etc/mysql/conf.d/master.cnf:

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_format = ROW
binlog_row_image = MINIMAL
expire_logs_days = 7
max_binlog_size = 100M
gtid_mode = ON
enforce_gtid_consistency = ON
log_slave_updates = ON
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1

[mysqld] server-id = 1 log_bin = /var/log/mysql/mysql-bin.log binlog_format = ROW binlog_row_image = MINIMAL expire_logs_days = 7 max_binlog_size = 100M gtid_mode = ON enforce_gtid_consistency = ON log_slave_updates = ON sync_binlog = 1 innodb_flush_log_at_trx_commit = 1 — שכפול מבוסס שורות. אמין יותר מ-STATEMENT עבור Bitrix, שבו מופיעות פונקציות לא דטרמיניסטיות (NOW(), RAND()).

binlog_format = ROW — רק עמודות ששונו נכתבות ל-binlog. מקטין את נפח ה-binlog ב-60-80% עבור טבלאות Bitrix רחבות.

צרו את משתמש השכפול: binlog_row_image = MINIMAL.

הגדרת Replica

GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'10.0.0.%' IDENTIFIED BY 'strong_password':

[mysqld]
server-id = 2
relay_log = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log
log_slave_updates = ON
gtid_mode = ON
enforce_gtid_consistency = ON
read_only = ON
super_read_only = ON
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 4

/etc/mysql/conf.d/replica.cnf — מונע כתיבות אפילו ממשתמשים עם הרשאת SUPER. מונע כתיבות מקריות שישברו את השכפול.

אתחלו שכפול עם GTID: [mysqld] server-id = 2 relay_log = /var/log/mysql/mysql-relay-bin.log log_bin = /var/log/mysql/mysql-bin.log log_slave_updates = ON gtid_mode = ON enforce_gtid_consistency = ON read_only = ON super_read_only = ON slave_parallel_type = LOGICAL_CLOCK slave_parallel_workers = 4 , ולאחר מכן טענו את ה-dump על ה-replica. התחילו שכפול:

CHANGE MASTER TO MASTER_HOST = '10.0.0.10', MASTER_USER = 'replicator', MASTER_PASSWORD = 'strong_password', MASTER_AUTO_POSITION = 1;
START SLAVE;
SHOW SLAVE STATUS\G

בדקו את super_read_only = ON, mysqldump --single-transaction --master-data=2 --gtid, CHANGE MASTER TO MASTER_HOST = '10.0.0.10', MASTER_USER = 'replicator', MASTER_PASSWORD = 'strong_password', MASTER_AUTO_POSITION = 1; START SLAVE; SHOW SLAVE STATUS\G .

חיבור Bitrix ל-Replica

הגדרה דרך מודול הקלאסטר או ידנית ב-Slave_IO_Running: Yes:

'connections' => [ 'value' => [ 'default' => [ 'className' => '\Bitrix\Main\DB\MysqlConnection', 'host' => '10.0.0.10', 'database' => 'bitrix', 'login' => 'bitrix', 'password' => 'pass', ], 'replica' => [ 'className' => '\Bitrix\Main\DB\MysqlConnection', 'host' => '10.0.0.11', 'database' => 'bitrix', 'login' => 'bitrix_ro', 'password' => 'pass_ro', 'options' => ['slave' => true], ], ], ], 

רכיבי קטלוג, חיפוש ורשימות שולחים SELECT ל-replica. עגלת קניות, הזמנות ואימות נשלחים תמיד ל-master.

איך לבחור סוג שכפול?

השוואה בין שכפול אסינכרוני, חצי-סינכרוני וסינכרוני:

עבור 95% מפרויקטי Bitrix, שכפול אסינכרוני עם GTID מספיק. שכפול חצי-סינכרוני משמש כאשר אובדן של כל עסקה הוא קריטי (לדוגמה, חנויות מקוונות עם תשלומים).

מתי יש צורך ב-Failover אוטומטי?

אם השבתת האתר היא קריטית (יותר מ-5 דקות לא מקובל), הגדירו failover אוטומטי דרך Orchestrator או ProxySQL. כלים אלה עוקבים אחר בריאות ה-master וה-replica, מקדמים אוטומטית replica במקרה של כשל, ומנתבים מחדש את התעבורה. זמן ההתאוששות יורד לשניות. הזמינו הגדרת failover יחד עם השכפול.

ניטור שכפול

בדקו סטטוס עם Slave_SQL_Running: Yes. פרמטר מפתח: Seconds_Behind_Master: 0. אם הפיגור עולה על 30 שניות, ייתכן שהנתונים מיושנים. סיבות: עסקאות כבדות, עובדים מקבילים לא מספיקים, צוואר בקבוק ב-I/O.

מדריך שלב-אחר-שלב להגדרת שכפול

1. הגדירו master (server-id, binlog, GTID).
2. הגדירו replica (server-id, relay log, read_only, שכפול מקבילי).
3. צרו משתמש שכפול עם הרשאות REPLICATION SLAVE.
4. צרו dump עקבי מה-master עם מיקום GTID.
5. טענו את ה-dump על ה-replica.
6. התחילו שכפול עם CHANGE MASTER ו-START SLAVE.
7. אמתו סטטוס (Slave_IO_Running, Slave_SQL_Running, Seconds_Behind_Master).
8. הגדירו חיבור replica עבור Bitrix.
9. הקימו ניטור ובמידת הצורך failover אוטומטי.
10. בצעו בדיקות עומס.

ביצוע Failover במקרה של כשל Master

Failover ידני: קידום replica ל-master.

STOP SLAVE; RESET SLAVE ALL; SET GLOBAL read_only = OFF; SET GLOBAL super_read_only = OFF; 

שנו את Seconds_Behind_Master ב-Seconds_Behind_Master לכתובת ה-IP של צומת ה-master החדש.

GTID (מזהי עסקאות גלובליים) מפשטים את המעבר — אין צורך למצוא מיקום binlog. פרטים נוספים בתיעוד MySQL ובויקיפדיה: GTID.

תהליך העבודה שלנו להגדרת שכפול

מה כלול בעבודה

• הגדרת master.cnf ו-replica.cnf מותאמים לחומרה שלכם.
• יצירת משתמשי שכפול עם הרשאות מוגבלות.
• העברת נתונים מ-master ל-replica ללא השבתה.
• הגדרת חיבור Bitrix (מודול קלאסטר או .settings.php).
• ניטור (פיגור, שגיאות, סטטוס).
• תיעוד: דיאגרמת טופולוגיה, הוראות failover, סקריפטי ניטור.
• הדרכה: כיצד לבדוק סטטוס ופעולות בשגיאות.
• תמיכה: שבועיים לאחר השחרור.

לוח זמנים: 1 עד 3 ימים בהתאם למורכבות. התמחור נקבע לאחר ניתוח — צרו קשר לקבלת הערכה תוך יום עסקים אחד. קבלו ייעוץ על הגדרת שכפול ו-Bitrix עמיד לתקלות.