שכפול מאסטר-עבד: ביטול צוואר הבקבוק של מסד הנתונים

שכפול Master-Slave: ביטול צוואר הבקבוק של מסד הנתונים

האם אפליקציית האינטרנט שלך איטית בדוחות? מסד הנתונים לא עומד בעומס המשתמשים, ושרת יחיד הוא נקודת כשל אחת. ראינו את זה עשרות פעמים: שאילתות SELECT חוסמות INSERT, דוחות אנליטיים מפילים את מערכת הייצור, וגיבויים על מסד נתונים חי גורמים להשבתה. כל בעיה כזו עולה זמן וכסף. הפתרון הוא הקמת שכפול Master-Slave מוכן לשימוש. אנו מבטיחים סובלנות לתקלות ופריקת עומס מהשרת הראשי, כפי שהוכח ביותר מ-100 פרויקטים.

שכפול (Master-Slave או Primary-Replica) הוא העברת נתונים אסינכרונית או סינכרונית מהשרת הראשי לרפליקה אחת או יותר. זה מאפשר קנה מידה לפעולות קריאה: עד 80% מהשאילתות יכולות להיות מופנות לרפליקות, ולהשאיר את ה-Master לכתיבה בלבד. זה מפחית את זמן ההשהיה ומבטל תחרות על משאבים. עם הניסיון שלנו בהגדרת 50+ פרויקטים, אנו מיישמים ארכיטקטורה זו תוך 1–3 ימים.

מדוע שכפול Master-Slave קריטי לאפליקציה שלך?

ללא שכפול, אתה מסתכן ב:

• השבתה: במקרה של כשל ב-Master, הנתונים לא זמינים עד לשחזור. זמן השבתה ידני ממוצע: 2–4 שעות.
• התדרדרות: שאילתות אנליטיות חוסמות כתיבה, ומגדילות את ה-TTFB פי 3–5.
• גיבויים יקרים: פריקת Master חי נועלת טבלאות וגורמת להשבתה.

בהשוואה למסד נתונים יחיד, ארכיטקטורה עם רפליקה אחת מטפלת בפי 5 יותר שאילתות קריאה. עם ProxySQL, השיפור יכול להגיע לפי 10. לדוגמה, פרויקט מסחר אלקטרוני לאחר שכפול הפחית את זמן התגובה של שאילתות דוחות מ-12 שניות ל-0.8 שניות—פי 15 מהר יותר.

מתי כדאי להשתמש בשכפול סינכרוני?

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

כיצד אנו מגדירים שכפול ב-PostgreSQL וב-MySQL

אנו משתמשים רק בגישות מוכחות: שכפול סטרימינג עבור PostgreSQL ושכפול מבוסס GTID עבור MySQL. ההבדלים המרכזיים מוצגים להלן:

טעויות הגדרה אופייניות: wal_level שגוי (צריך להיות replica או logical), max_wal_senders לא מספק עבור מספר רפליקות, התעלמות מפיגור שכפול (ללא ניטור), וכתיבה לרפליקה במצב קריאה בלבד—לעתים קרובות גורמת לחוסר התאמה בנתונים.

דוגמה לתצורת Master ב-PostgreSQL:

# postgresql.conf
wal_level = replica
max_wal_senders = 10
wal_keep_size = 1GB
synchronous_commit = on
synchronous_standby_names = 'replica1'

אתחול הרפליקה:

pg_basebackup -h master -U replication -D /var/lib/postgresql/14/main -P -Xs -R 

דוגמה לתצורת Master ב-MySQL:

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON

התחלת רפליקת MySQL עם GTID:

CHANGE MASTER TO MASTER_HOST='192.168.1.10', MASTER_USER='replication', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=1;
START SLAVE;

ניתוב קריאות דרך ProxySQL:

INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (10, 'master', 3306);
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (20, 'replica', 3306);
INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup) VALUES (1, 1, '^SELECT', 20), (2, 1, '.*', 10);
LOAD MYSQL SERVERS TO RUNTIME;
LOAD MYSQL QUERY RULES TO RUNTIME;

מה כולל תהליך הגדרת השכפול?

1. ביקורת על העומס והארכיטקטורה הנוכחיים: מדידת RPS שיא, זמן השהיה, גודל מסד נתונים.
2. בחירת טופולוגיה: רפליקה אחת או מרובות, אסינכרונית או סינכרונית.
3. הגדרת Master: CHANGE MASTER TO MASTER_HOST='192.168.1.10', MASTER_USER='replication', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=1; START SLAVE; , INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (10, 'master', 3306); INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (20, 'replica', 3306); INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup) VALUES (1, 1, '^SELECT', 20), (2, 1, '.*', 10); LOAD MYSQL SERVERS TO RUNTIME; LOAD MYSQL QUERY RULES TO RUNTIME; , wal_level.
4. אתחול רפליקות דרך replica או max_wal_senders.
5. הגדרת ניתוב (ProxySQL / pgBouncer) ופיצול שאילתות קריאה/כתיבה.
6. ניטור פיגור: Prometheus + Grafana עם התראות ב->60 שניות.
7. תיעוד תצורה ונהלי failover, והדרכת הצוות.

השוואה בין שכפול אסינכרוני לסינכרוני

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

• תיעוד מלא של התצורה ונהלי failover.
• גיבויים וסקריפטים לשחזור מהיר.
• גישה לניטור (Grafana, התראות Telegram).
• הדרכת צוות: כיצד לבדוק סטטוס שכפול ולבצע switchover.

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

לוחות הזמנים תלויים במורכבות:

• רפליקה אחת + ניטור בסיסי: יום אחד.
• שכפול עם ProxySQL ו-failover: 2–3 ימים.

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