הגדרת שכפול מאסטר-מאסטר ליישומי אינטרנט

דמיינו שחנות המסחר האלקטרוני שלכם פועלת באירופה ובאסיה. כתיבה למסד הנתונים מאסיה דרך אירופה אורכת מעל 100 אלפיות השנייה — קריטי לביצועי הקטלוג ועגלת הקניות. נתקלנו בכך עם קמעונאית מקוונת עם 500,000 מוצרים ופתרנו זאת על ידי יישום שכפול Master-Master. כעת הכתיבה מקומית בכל אזור, והנתונים מסונכרנים בין הצמתים ללא אובדן. עם למעלה מ-5 שנות ניסיון בכיוונון שכפול ו-30+ פרויקטים במורכבות גבוהה, אנו מספקים פתרונות חזקים.

למה Master-Master על פני Master-Slave?

Master-Slave הוא ההתקנה הקלאסית: צומת אחד כותב, האחרים קוראים. אך כאשר היישום פועל בסביבה מבוזרת, זמן ההשהיה בכתיבה הופך לצוואר בקבוק. Master-Master מסיר מגבלה זו: כל צומת יכול לקבל כתיבות. לפי תיעוד Galera, שכפול סינכרוני multi-master מבטיח עקביות חזקה וזמן failover אפסי. Galera Cluster עובר תוך <1 שנייה — פי 10 מהר יותר מאשר failover ידני של Master-Slave.

מתי יש צורך ב-Master-Master?

• יישומים באזורים שונים חייבים לכתוב מקומית עם סנכרון.
• נדרשת סובלנות לתקלות ללא נקודת כשל יחידה.
• זמן השהיית כתיבה דרך master יחיד עולה על 50 אלפיות השנייה הסבירות.
• החזר השקעה (ROI) של 2–3 חודשים בעומסים של מעל 10,000 בקשות בשנייה.

כיצד להקים Galera Cluster על שלושה צמתים

1. התקינו Galera על כל הצמתים (לדוגמה, Ubuntu 22.04).
2. הגדירו את /etc/mysql/conf.d/galera.cnf כפי שמוצג להלן.
3. אתחלו את הצומת הראשון עם galera_new_cluster.
4. הפעילו את MySQL על הצמתים האחרים — הם מצטרפים אוטומטית.
5. בדקו את הסטטוס: SHOW STATUS LIKE 'wsrep_cluster_size'; — אמור להחזיר 3.

# /etc/mysql/conf.d/galera.cnf
[mysqld]
binlog_format = ROW
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
bind-address = 0.0.0.0

# Galera Provider
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = "production_cluster"
wsrep_cluster_address = "gcomm://192.168.1.10,192.168.1.11,192.168.1.12"
wsrep_sst_method = rsync

# Уникально для каждого узла
wsrep_node_address = "192.168.1.10"
wsrep_node_name = "node1"

כיצד למנוע אובדן נתונים במהלך שכפול?

אובדן נתונים ב-multi-master יכול להתרחש אם צומת נכשל לפני הסנכרון. כדי למזער סיכונים, השתמשו בשכפול סינכרוני (Galera) עם שחזור אוטומטי לאחר תקלה. ב-BDR, הגדירו replication slots עם עיכוב של לא יותר משנייה אחת. גיבויים קבועים עם # /etc/mysql/conf.d/galera.cnf [mysqld] binlog_format = ROW default_storage_engine = InnoDB innodb_autoinc_lock_mode = 2 bind-address = 0.0.0.0 # Galera Provider wsrep_on = ON wsrep_provider = /usr/lib/galera/libgalera_smm.so wsrep_cluster_name = "production_cluster" wsrep_cluster_address = "gcomm://192.168.1.10,192.168.1.11,192.168.1.12" wsrep_sst_method = rsync # Уникально для каждого узла wsrep_node_address = "192.168.1.10" wsrep_node_name = "node1" או xtrabackup מצמצמים את האובדן לפחות מדקה אחת במקרה של כשל מוחלט של הקלאסטר.

הגדרת PostgreSQL BDR

BDR (Bi-Directional Replication) הוא הרחבה לשכפול multi-master אסינכרוני ב-PostgreSQL. הוא מתאים למשימות שבהן עקביות סופית (eventual consistency) מקובלת (עיכוב סנכרון של עד 1–2 שניות).

-- Подключение расширения
CREATE EXTENSION bdr;
-- Инициализация первого узла
SELECT bdr.bdr_group_create(
    local_node_name := 'node1',
    node_external_dsn := 'host=192.168.1.10 port=5432 dbname=myapp'
);
-- Присоединение второго узла
SELECT bdr.bdr_group_join(
    local_node_name := 'node2',
    node_external_dsn := 'host=192.168.1.11 port=5432 dbname=myapp',
    join_using_dsn := 'host=192.168.1.10 port=5432 dbname=myapp'
);

השוואה: Galera מול BDR

פתרון קונפליקטי כתיבה

קונפליקטים נוצרים כאשר שני צמתים משנים את אותו רשומה בו-זמנית. בפרויקט הקמעונאי, יישמנו חלוקה אזורית (regional partitioning) — כל טבלה מטפלת בפלח גיאוגרפי משלה. זה ביטל חפיפות והפחית קונפליקטים ב-95%.

איזון עומסים וניטור

אנו משתמשים ב-ProxySQL לחלוקת בקשות אחידה. הגדרה פשוטה:

INSERT INTO mysql_servers(hostgroup_id, hostname, port, weight) VALUES (10, '192.168.1.10', 3306, 1), (10, '192.168.1.11', 3306, 1), (10, '192.168.1.12', 3306, 1); 

הניטור מתבצע באמצעות Prometheus + Grafana. מדדים מרכזיים: pg_dump (תור יישום העסקאות צריך להיות <1) ו--- Подключение расширения CREATE EXTENSION bdr; -- Инициализация первого узла SELECT bdr.bdr_group_create( local_node_name := 'node1', node_external_dsn := 'host=192.168.1.10 port=5432 dbname=myapp' ); -- Присоединение второго узла SELECT bdr.bdr_group_join( local_node_name := 'node2', node_external_dsn := 'host=192.168.1.11 port=5432 dbname=myapp', join_using_dsn := 'host=192.168.1.10 port=5432 dbname=myapp' ); (קונפליקטי אישור קרובים לאפס).

מגבלות ומלכודות

• Galera אינו תומך בטבלאות MyISAM או MEMORY.
• AUTO_INCREMENT דורש INSERT INTO mysql_servers(hostgroup_id, hostname, port, weight) VALUES (10, '192.168.1.10', 3306, 1), (10, '192.168.1.11', 3306, 1), (10, '192.168.1.12', 3306, 1); .
• DDL נועל את הקלאסטר — השתמשו ב-wsrep_local_recv_queue_avg.
• השהיה בין צמתים >5 אלפיות השנייה מפחיתה את ביצועי הכתיבה ב-30–40%. עבור רשתות עם השהיה נמוכה, השתמשו בקישורים ייעודיים.

הקמה מקיפה במפתח פתוח

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

לוח זמנים: 3–4 ימי עבודה עבור קלאסטר של שלושה צמתים. התמחור נקבע באופן אישי לפי מורכבות ומספר צמתים.

הזמינו ביקורת שכפול — נזהה צווארי בקבוק ונציע אופטימיזציות. צרו קשר לייעוץ על הארכיטקטורה שלכם.

קריאה נוספת: Galera Cluster.