במאמר הזה מתוארות כמה ארכיטקטורות שמספקות זמינות גבוהה (HA) לפריסות של MySQL ב- Google Cloud. זמינות גבוהה היא מדד לעמידות המערכת בתגובה לכשל בתשתית הבסיסית. במסמך הזה, המונח 'זמינות גבוהה' מתייחס לזמינות של אשכולות MySQL בתוך אזור יחיד בענן.
המסמך הזה מיועד לאדמינים של מסדי נתונים, למומחי Cloud Architect ולמהנדסי DevOps שרוצים ללמוד איך לשפר את האמינות של שכבת הנתונים ב-MySQL על ידי שיפור זמן הפעולה הכולל של המערכת. המסמך הזה מיועד למי שמריץ MySQL ב-Compute Engine. אם אתם משתמשים ב-Cloud SQL ל-MySQL, המאמר הזה לא מיועד לכם.
במערכת או באפליקציה שנדרש בהן מצב מתמשך כדי לטפל בבקשות או בעסקאות, שכבת שמירת הנתונים צריכה להיות זמינה כדי לטפל בהצלחה בבקשות לשאילתות נתונים או לשינויים בנתונים. אם האפליקציה צריכה לבצע אינטראקציה עם שכבת הנתונים כדי לטפל בבקשות, כל השבתה בשכבת הנתונים מונעת מהאפליקציה לבצע את המשימות הנדרשות.
יכול להיות שתצטרכו טופולוגיה ארכיטקטונית שתספק רמת זמינות גבוהה יותר, בהתאם ליעדים למדידת רמת השירות (SLO) של המערכת. יש יותר מדרך אחת להשיג זמינות גבוהה, אבל באופן כללי, אתם מקצים תשתית מיותרת שאפשר להפוך במהירות לנגישה לאפליקציה שלכם.
במסמך הזה מפורטים הנושאים הבאים:
- הגדרת מונחים שיעזרו לכם להבין את המושגים שקשורים למסדי נתונים עם זמינות גבוהה.
- עוזרות לכם להבין כמה אפשרויות לטופולוגיות של HA MySQL.
- כדי לעזור לכם להבין מה צריך לקחת בחשבון בכל אחת מהאפשרויות, אנחנו מספקים מידע הקשרי.
הסברים על המונחים
יש כמה מונחים ומושגים שהם סטנדרטיים בתעשייה וחשוב להכיר אותם למטרות שחורגות מההיקף של המסמך הזה.
שכפול. התהליך שבו עסקאות כתיבה (INSERT, UPDATE או DELETE) נרשמות באופן מהימן ביומן, ואז מוחלות באופן סדרתי על כל צמתי מסד הנתונים בטופולוגיה.
שכפול סינכרוני. שיטה לשכפול נתונים שמבטיחה עקביות של נתונים בזמן אמת על ידי כתיבה בו-זמנית למסדי נתונים ראשיים ולמסדי נתונים משוכפלים.
שכפול חצי-סינכרוני. שיטה לשכפול נתונים שמבטיחה מידה מוגבלת של עקביות בנתונים על ידי כתיבה בו-זמנית למסד הנתונים הראשי ולפחות למסד נתונים משוכפל אחד נוסף.
שכפול אסינכרוני. שיטה לשכפול נתונים שמאפשרת השהיה בין העדכונים של המקור והרפליקה, ונותנת עדיפות לביצועים על פני עקביות מיידית.
צומת המקור. כל פעולות הכתיבה במסד הנתונים צריכות להיות מופנות לצומת מקור. צומת המקור מספק קריאה עם המצב העדכני ביותר של הנתונים שנשמרו.
צומת Replica. עותק אונליין של צומת מסד הנתונים של המקור. השינויים משוכפלים כמעט באופן סינכרוני לצמתי העתקים מצומת המקור. אפשר לקרוא מתוך צמתי רפליקה, אבל צריך להבין שהנתונים עשויים להתעדכן באיחור קל בגלל פרק הזמן מהחשיפה להמרה.
השהיית שכפול. מדד זמן שמבטא את ההבדל בין המועד שבו העסקה מוחלת על הרפליקה לבין המועד שבו היא מוחלת על צומת המקור.
זמן פעולה תקינה. אחוז הזמן שבו מקור מידע פועל ויכול לספק תשובה לבקשה.
זיהוי כשלים. התהליך של זיהוי כשל בתשתית.
מעבר לגיבוי. התהליך שבו מקדמים את תשתית הגיבוי (במקרה הזה, צומת הרפליקה) כדי שתהפוך לתשתית הראשית (צומת המקור).
יעד משך ההתאוששות (RTO). משך הזמן, בזמן אמת שחלף, שמקובל, מנקודת מבט עסקית, שבו שכבת הנתונים יכולה להיות במצב אופליין עד שתהליך היתירות כשל מסתיים.
יעד להתאוששות מאסון (RPO). משך הזמן, בזמן שחלף בפועל, שבו מותר לאבד נתונים עד להשלמת תהליך היתירות כשל, מנקודת מבט עסקית.
Fallback. התהליך להחזרת צומת המקור הקודם אחרי מעבר לגיבוי.
תיקון עצמי. היכולת של מערכת לפתור בעיות בלי פעולות חיצוניות של מפעיל אנושי.
חלוקת משאבי רשת למחיצות. מצב שבו שני צמתים בטופולוגיה, למשל צומת המקור וצומת העותק, לא יכולים לתקשר אחד עם השני ברשת.
פיצול המוח. מצב שבו שני צמתים מאמינים בו-זמנית שהם צומת המקור.
קבוצת צמתים. קבוצה של משימות משאבי מחשוב שמספקות שירות. במסמך הזה, השירות הזה הוא שכבת העמידות של הנתונים.
צומת עדים או צומת קוורום. משאב נפרד של מחשוב שעוזר לקבוצת צמתים לקבוע מה לעשות כשמתרחש מצב של פיצול מוח.
בחירת מקור או בחירת מנהיג. התהליך שבו קבוצה של צמתים עם מודעות לעמיתים, כולל צמתים של עדים, קובעת איזה צומת צריך להיות צומת המקור.
קבוצת צמתים. קבוצה של משימות משאבי מחשוב שמספקות שירות. במסמך הזה, השירות הזה הוא שכבת העמידות של הנתונים.
המתנה פעילה. צומת שמייצג עותק כמעט זהה של צומת מקור אחר, ויכול להפוך לצומת המקור החדש עם זמן השבתה מינימלי.
מתי כדאי לשקול ארכיטקטורת HA
ארכיטקטורות HA מספקות הגנה משופרת מפני השבתה של שכבת הנתונים. כדי לבחור את האפשרות המתאימה לתרחיש לדוגמה של העסק שלכם, חשוב להבין מהי הסבילות שלכם להשבתה, ואת היתרונות והחסרונות של הארכיטקטורות השונות.
כדאי להשתמש בטופולוגיה של זמינות גבוהה כשרוצים לספק זמן פעולה משופר של שכבת הנתונים כדי לעמוד בדרישות המהימנות של עומסי העבודה והשירותים. בסביבות שבהן יש סובלנות להשבתה מסוימת, טופולוגיה של זמינות גבוהה מוסיפה עלויות ומורכבות שלא לצורך. לדוגמה, בסביבות פיתוח או בדיקה לא תמיד נדרשת זמינות גבוהה של רמת מסד הנתונים.
הגדרת הדרישות לזמינות גבוהה
העלות היא שיקול חשוב, כי כדי לספק זמינות גבוהה, עלויות האחסון והתשתית של המחשוב צפויות לגדול לפחות פי שניים. חשוב להעריך היטב את העלות הזו בהשוואה להשפעה הפיננסית הפוטנציאלית של זמן ההשבתה. כשמעריכים את האפשרויות האפשריות לזמינות גבוהה של MySQL, כדאי לשקול את השאלות הבאות:
- אילו שירותים או לקוחות מסתמכים על רמת הנתונים שלכם?
- מה התקציב התפעולי שלך?
- מה העלות לעסק במקרה של השבתה בשכבת העמידות של הנתונים?
- עד כמה התהליך צריך להיות אוטומטי?
- מה רמת הזמינות שאתם רוצים להשיג: 99.5%, 99.9% או 99.99%?
- באיזו מהירות צריך לבצע מעבר לגיבוי? מהם יעדי הזמן לשחזור (RTO) ויעדי נקודת השחזור (RPO) שלכם?
הגורמים הבאים משפיעים על זמן השחזור, ולכן חשוב לקחת אותם בחשבון כשקובעים את ה-RTO ואת ה-RPO:
- זיהוי הפסקה זמנית בשירות
- מוכנות של מכונה וירטואלית (VM) משנית
- סוג השכפול ותדירות הגיבוי
- מעבר לגיבוי במקרה של כשל באחסון
- זמן השחזור של מסד הנתונים
- זמן השחזור של האפליקציה
ארכיטקטורות של MySQL HA
ברמה הבסיסית ביותר, זמינות גבוהה בשכבת הנתונים מורכבת מהרכיבים הבאים:
- מנגנון לזיהוי של כשל בצומת המקור.
- תהליך לביצוע יתירות כשל שבו צומת הרפליקה מקודם להיות צומת מקור.
- תהליך לשינוי ניתוב השאילתות כך שבקשות האפליקציה יגיעו לצומת המקור החדש.
- אפשרות: שיטה לחזרה לטופולוגיה המקורית באמצעות צמתים של מקור ועותק.
במסמך הזה מתוארות שלוש ארכיטקטורות של זמינות גבוהה:
בנוסף לכשל בתשתית, כל אחת מהארכיטקטורות האלה יכולה לעזור למזער את זמן ההשבתה במקרה הלא סביר של הפסקה זמנית בשירות אזורית. אתם משתמשים בארכיטקטורות האלה עם שינויים במערכת שמות הדומיין (DNS) כדי לספק זמינות גבוהה (HA) באזורים רבים, כדי להגן מפני הפרעות בשירותים אזוריים, אבל במסמך הזה נדון בהפסקות חשמל אזוריות.
זמינות גבוהה עם דיסקים לאחסון מתמיד אזורי
זמינות גבוהה בשכבת הנתונים תמיד מסתמכת על סוג מסוים של שכפול נתונים. השכפול הפשוט ביותר הוא שכפול שלא צריך לנהל.
בעזרת אפשרות האחסון דיסק לאחסון מתמיד של אזור מ-Compute Engine, אתם יכולים להקצות מכשיר לאחסון בלוקים שמספק שכפול נתונים סינכרוני בין שני אזורים באזור. דיסקים לאחסון מתמיד של אזור מספקים אבן בניין חזקה ליישום שירותים של זמינות גבוהה ב-Compute Engine.
התרשים הבא מדגים את הארכיטקטורה של זמינות גבוהה עם Persistent Disks אזוריים.
אם המכונה הווירטואלית של צומת המקור הופכת ללא זמינה בגלל כשל בתשתית או הפסקה זמנית בשירות באזור, אפשר לכפות את החיבור של דיסק האחסון המתמיד האזורי למכונה וירטואלית באזור הגיבוי באותו אזור.
כדי לבצע את המשימה הזו, צריך לבצע אחת מהפעולות הבאות:
- מפעילים מכונה וירטואלית נוספת באזור הגיבוי שבו יש גישה לדיסק אחסון מתמיד אזורי משותף.
- תחזוקה של מופע VM פעיל בהמתנה באזור הגיבוי. מכונה וירטואלית במצב המתנה פעיל היא מכונה וירטואלית שפועלת וזהה למכונה שבה אתם משתמשים. אחרי שמצרפים את הדיסק לאחסון מתמיד האזורי, אפשר להפעיל את המנוע של מסד הנתונים.
אם מזהים במהירות את ההפסקה הזמנית בשירות הנתונים, פעולת הצירוף הכפוי בדרך כלל מסתיימת תוך פחות מדקה, כך שאפשר להשיג RTO שנמדד בדקות, עם RPO של אפס.
אם העסק שלכם יכול לסבול את זמן ההשבתה הנוסף שנדרש כדי לזהות הפסקה זמנית בשירות ולדווח עליה, וכדי לבצע את יתירות הכשל ידנית, אין צורך להפוך את התהליך לפעולות אוטומטיות.
אם סף הטולרנס שלכם ל-RTO נמוך יותר, אתם יכולים להפוך את תהליך הזיהוי והמעבר לגיבוי אוטומטי. אם תפעילו אוטומציה של הארכיטקטורה הזו, המערכת תהיה מורכבת יותר כי יש כמה מקרים קיצוניים בתהליך המעבר לגיבוי והחזרה לגיבוי הקודם שצריך לקחת בחשבון. למידע נוסף על הטמעה אוטומטית מלאה של הארכיטקטורה הזו, אפשר לעיין במאמר בנושא הגדרת זמינות גבוהה ב-Cloud SQL.
יתרונות
יש כמה יתרונות להשגת זמינות גבוהה באמצעות דיסקים קשיחים אזוריים, בגלל התכונות הבאות:
הארכיטקטורה הזו מספקת הגנה בו-זמנית מפני כמה מצבי כשל: כשל בתשתית של אזור שרת המקור, ירידה בביצועים של אחסון בלוקים באזור יחיד או הפסקת חשמל מלאה באזור.
אין צורך בשכפול של שכבת האפליקציה או מסד הנתונים, כי דיסקים קשיחים אזוריים מספקים שכפול נתונים רציף וסינכרוני ברמת הבלוק, שמנוהל באופן מלא על ידי Google Cloud. Persistent Disk אזורי מזהה באופן אוטומטי שגיאות והאטה, מחליף את מצב השכפול ומבצע השלמה של נתונים שמשוכפלים רק לאזור אחד.
אם יש בעיות באחסון באזור ראשי, קריאות מתבצעות באופן אוטומטי מאזור משני באמצעות Persistent Disk אזורי. הפעולה הזו עלולה להוביל לעלייה בזמן האחזור של הקריאה, אבל האפליקציה יכולה להמשיך לפעול בלי שתידרש פעולה ידנית.
לתשומת ליבכם
המגבלות של הארכיטקטורה הזו קשורות לאופי החד-אזורי של הטופולוגיה הזו ולחלק מהמגבלות המובנות הבאות של דיסקים קשיחים קבועים אזוריים:
- אפשר לצרף דיסק לאחסון מתמיד אזורי רק למסד נתונים אחד. גם אם המכונה הווירטואלית של מסד הנתונים במצב המתנה פועלת, אי אפשר להשתמש בה כדי להציג קריאות של מסד הנתונים. עם זאת, עם Hyperdisk Balanced High Availability של Google Cloud במצב multi-writer, כמה מופעים יכולים לקרוא ולכתוב לאותו דיסק. מידע נוסף על Hyperdisk זמין במאמר מידע על Hyperdisk.
- הטכנולוגיה הבסיסית שמאחורי הארכיטקטורה הזו מאפשרת שכפול רק בין אזורים באותו אזור . לכן, מעבר לגיבוי אזורי הוא לא אפשרות כשמשתמשים רק בארכיטקטורה הזו.
- תפוקת הכתיבה של דיסקים לאחסון מתמיד אזורי נמוכה בחצי בהשוואה לדיסקים לאחסון מתמיד של תחום. חשוב לוודא שמגבלות התפוקה הן במסגרת הסבילות הנדרשת.
- זמן האחזור של כתיבה בדיסק לאחסון מתמיד אזורי מעט גבוה יותר מזמן האחזור של כתיבה בדיסק לאחסון מתמיד אזורי. מומלץ לבדוק את עומס העבודה כדי לוודא שביצועי הכתיבה עומדים בדרישות שלכם.
- במהלך אירוע כשל והמעבר שנובע ממנו, צריך לכפות על Persistent Disk האזורי להתחבר למכונת ה-VM באזור ההמתנה. הפעולה force-attach מתבצעת בדרך כלל תוך פחות מדקה, ולכן צריך לקחת את הזמן הזה בחשבון כשמעריכים את זמן ההתאוששות (RTO).
- ההערכה של RTO צריכה לכלול את הזמן שנדרש לחיבור הכפוי של דיסק האחסון המתמיד האזורי ולזיהוי של מערכת הקבצים של מכונת ה-VM של הדיסק שמחובר בזמן ההפעלה.
זמינות גבוהה עם המתנה פעילה וצומת עֵד
אם רוצים מעבר אוטומטי לגיבוי במקרה של כשל, צריך ארכיטקטורה שונה. אפשרות אחת היא לפרוס קבוצה של שני צמתים לפחות של מסד נתונים, להגדיר שכפול אסינכרוני של מסד הנתונים ולהפעיל צמתים של עדים כדי להבטיח שאפשר יהיה להגיע לקוורום במהלך בחירה של צומת מקור.
צומת מסד הנתונים של המקור מעבד עסקאות כתיבה ומשרת שאילתות קריאה. תהליך השכפול של מסד הנתונים מעביר שינויים לצומת הרפליקה של הגיבוי הפעיל אונליין.
מכיוון שצומת העד יכול להיות מכונה וירטואלית קטנה, הוא מספק מנגנון בעלות נמוכה כדי לוודא שרוב הקבוצה זמין לבחירת צומת מקור.
צמתי קבוצה מעריכים באופן רציף את הסטטוס של צמתי הקבוצה האחרים. האותות שבודקים את הסטטוס האלה כל כמה שניות נקראים פעימות לב, כי הם משמשים להערכת תקינות הצמתים בקבוצה השנייה. חשוב לבצע הערכה בזמן של תקינות הצומת במסד הנתונים, כי צריך לזהות במהירות צומת לא תקין במסד הנתונים של המקור כדי להפעיל מעבר לגיבוי פעיל.
הקוורום של קבוצת הצמתים נקבע לפי מספר הרכיבים המצביעים שצריכים להיות חלק מחברות פעילה באשכול כדי שהאשכול יתחיל לפעול בצורה תקינה או ימשיך לפעול. כדי שקבוצת צמתים תגיע לקוורום בבחירות של צומת מסד נתונים של מקור, רוב הצמתים בקבוצה צריכים להשתתף. כדי למנוע מצב של פיצול מוח, דרישת הרוב מבטיחה שבמקרה של חלוקת רשת, לא יהיו בו-זמנית שתי קבוצות הצבעה עם מספיק צמתים להצבעה.
רוב בקבוצה מורכב מ-(n+1)/2 צמתים, כאשר n הוא המספר הכולל של הצמתים בקבוצה. לדוגמה, אם יש שלוש צמתים בקבוצה, לפחות שני צמתים צריכים לפעול כדי לבחור צומת מקור. אם יש חמישה צמתים בקבוצה, נדרשים לפחות שלושה צמתים.
גודל הקבוצות הוא מספר אי-זוגי של צמתים, למקרה של חלוקת רשת שמונעת תקשורת בין קבוצות משנה של קבוצת הצמתים. אם מספר החברים בקבוצה הוא זוגי, יש סיכוי גבוה יותר ששתי קבוצות המשנה יכללו פחות ממחצית החברים. אם גודל הקבוצה הוא מספר אי-זוגי, סביר יותר שאחת מקבוצות המשנה תהיה ברוב או שאף אחת מהקבוצות לא תהיה ברוב.
בתרשים הבא מוצגת השוואה בין קבוצת צמתים תקינה לבין קבוצת צמתים עם בעיות.
בתרשים מוצגות שתי קבוצות של צמתים – קבוצת צמתים פונקציונלית וקבוצת צמתים עם ביצועים ירודים. בקבוצת הצמתים שפועלת בצורה מלאה ותקינה יש שלושה חברים. במצב הזה, צומתי מסד הנתונים של המקור והרפליקה מספקים את המטרה הצפויה שלהם. הקבוצה הזו של הצמתים צריכה לכלול לפחות שני צמתים.
קבוצת הצמתים עם הביצועים הירודים מציגה את המצב שבו פעימות הלב של צומת המקור לא נשלחות יותר בגלל כשל בתשתית. יכול להיות שהמצב הזה הוא תוצאה של כשל במופע של צומת מסד הנתונים של המקור, או שהצומת של המקור עדיין פועל. לחלופין, יכול להיות שחלוקת הרשת תמנע תקשורת בין צומת המקור לבין הצמתים האחרים בקבוצה.
לא משנה מה הסיבה, התוצאה היא שגם הרפליקה וגם העד קובעים שצומת המקור כבר לא תקין. בשלב הזה, רוב הקבוצה בוחר צומת מקור, קובע שצומת הגיבוי הפעיל צריך להפוך לצומת המקור ומתחיל מעבר לגיבוי.
התרשים הבא מציג את תהליך העברת הנתונים של העסקה, השכפול והדופק במסד הנתונים בארכיטקטורת צומת העד.
בתרשים הקודם, ארכיטקטורת ה-HA הזו מסתמכת על צומת רפליקה במצב המתנה פעילה כדי להתחיל במהירות לעבד כתיבות של נתוני ייצור במקרה של מעבר לגיבוי. מנגנון יתירות הכשל – למשל, העלאה בדרגה של צומת מקור – מבוצע על ידי צמתי מסד הנתונים בקבוצה.
כדי להטמיע את הארכיטקטורה הזו, כדאי להשתמש בשני הפרויקטים הבאים:
- MySQL Group Replication הוא פלאגין קוד פתוח ל-MySQL שמקל על יצירת טופולוגיות של זמינות גבוהה (HA).
- Galera Cluster ו-Percona XtraDB Cluster הן אפשרויות נוספות של קוד פתוח שיכולות לספק זמינות גבוהה.
יתרונות
לארכיטקטורה של המתנה פעילה יש מעט חלקים נעים, היא פשוטה להטמעה ומספקת כמה יתרונות:
- עם צומת עדים אחד נוסף בעלות נמוכה, מתקבל מעבר גיבוי אוטומטי לחלוטין.
- הארכיטקטורה הזו יכולה לטפל ביעילות בכשלים בתשתית לטווח ארוך ובכשלים זמניים (לדוגמה, בגלל הפעלה מחדש של המערכת).
- זמינות גבוהה במספר אזורים מסופקת עם זמן אחזור מסוים שקשור לשכפול.
לתשומת ליבכם
המעבר לגיבוי אוטומטי, אבל הפעולות הבאות עדיין נדרשות:
- אתם מנהלים את הרפליקציה בין צומתי המקור והרפליקה.
- אתם מנהלים את צמתי העדים.
- חובה לפרוס ולנהל את ניתוב החיבור באמצעות איזון עומסים.
- בלי לבצע שינויים בלוגיקה של האפליקציה, שהם מעבר להיקף של המסמך הזה, אי אפשר להפנות קריאות לצומת המשוכפל.
HA עם Orchestrator ו-ProxySQL
אם משלבים את רכיבי הקוד הפתוח Orchestrator ו-ProxySQL, מקבלים ארכיטקטורה שיכולה לזהות הפסקות זמניות בשירות ולהעביר באופן אוטומטי את התנועה משרת מקור שנפגע לשכפול תקין שקודם לאחרונה.
בנוסף, אפשר להפנות שאילתות בצורה שקופה לצמתים המתאימים לקריאה או לקריאה ולכתיבה, כדי לשפר את הביצועים של שכבת הנתונים במצב יציב.
Orchestrator הוא מנהל טופולוגיה של רפליקציה של MySQL בקוד פתוח ופתרון ליתירות כשל. התוכנה מאפשרת לכם לזהות, לשאול ולבצע ארגון קוד מחדש של טופולוגיות רפליקציה מורכבות, ומספקת זיהוי אמין של כשלים, שחזור חכם והעלאה בדרגה.
ProxySQL הוא שרת proxy מבוסס קוד פתוח, בעל ביצועים גבוהים וזמינות גבוהה, שמודע לפרוטוקול של מסד נתונים של MySQL. ProxySQL יכול להתרחב למיליוני חיבורים במאות אלפי שרתים בקצה העורפי.
התרשים הבא מציג את הארכיטקטורה המשולבת של Orchestrator ו-ProxySQL.
בארכיטקטורה הזו, כפי שמוצג בתרשים הקודם, תנועה שמוגבלת למסד נתונים מנותבת על ידי מאזן עומסים פנימי למופעי ProxySQL מיותרים. המופעים האלה מעבירים תעבורה למופע מסד נתונים עם יכולת כתיבה או קריאה, על סמך ההגדרה של ProxySQL.
הכלי Orchestrator מספק את השלבים הבאים לזיהוי כשלים ולשחזור:
- הכלי Orchestrator קובע שצומת מסד הנתונים של המקור לא זמין.
- מתבצעת שאילתה בכל צמתי הרפליקה כדי לקבל חוות דעת שנייה לגבי הסטטוס של צומת המקור.
- אם הרפליקות מספקות הערכה עקבית שלפיה המקור לא זמין, יתירות הכשל תופעל.
- כפי שמוגדר בטופולוגיה, הצומת שקודם הופך לצומת המקור החדש במהלך המעבר לגיבוי.
- בסיום המעבר ליתירות כשל, Orchestrator עוזר לוודא שמספר הצמתים החדשים של הרפליקציה מוקצים בהתאם לטופולוגיה.
רפליקציה מתמשכת בין מסד הנתונים של המקור באזור א' לבין העותקים של מסד הנתונים באזורים חלופיים שומרת על העדכניות של העותקים בכל כתיבה שמופנית למקור. הכלי Orchestrator בודק את תקינות מסדי הנתונים של המקור והרפליקה על ידי שליחת פעימות לב באופן רציף. מצב האפליקציה של Orchestrator נשמר במסד נתונים נפרד של Cloud SQL. אם נדרשים שינויים בטופולוגיה, Orchestrator יכול גם לשלוח פקודות למסדי הנתונים.
ProxySQL מעביר את התנועה בצורה מתאימה לצומתי המקור והרפליקה החדשים כשהמעבר לגיבוי מלא הושלם. השירותים ממשיכים לפנות לרמת הנתונים באמצעות כתובת ה-IP של מאזן העומסים. כתובת ה-IP הווירטואלית מועברת בצורה חלקה מצומת המקור הקודם לצומת המקור החדש.
יתרונות
רכיבי הארכיטקטורה והאוטומציה מספקים את היתרונות הבאים:
- התוכנה שמשמשת בארכיטקטורה הזו מספקת תכונות שונות של יכולת צפייה, כולל גרפים של טופולוגיית השכפול ונתונים על תנועת השאילתות.
- ProxySQL ו-Orchestrator פועלים יחד כדי לספק קידום אוטומטי של רפליקות ויתירות כשל.
- אפשר להגדיר את מדיניות העלאה בדרגה של הרפליקה באופן מלא. בניגוד להגדרות אחרות של זמינות גבוהה, במקרה של יתירות כשל, אתם יכולים לבחור להעלות בדרגה צומת רפליקה ספציפי למקור.
- אחרי יתירות כשל, מוקצים רפליקות חדשות באופן הצהרתי בהתאם לטופולוגיה.
- ProxySQL מספק יתרון נוסף של איזון עומסים, כי הוא מנתב באופן שקוף בקשות קריאה וכתיבה לצמתים המתאימים של העותק והמקור על סמך המדיניות שהוגדרה.
לתשומת ליבכם
הארכיטקטורה הזו מגדילה את האחריות התפעולית וגוררת עלויות אירוח נוספות, בגלל השיקולים הבאים:
- צריך לפרוס ולתחזק גם את Orchestrator וגם את ProxySQL.
- ל-Orchestrator נדרש מסד נתונים נפרד כדי לשמור את המצב.
- צריך להגדיר את Orchestrator ואת ProxySQL לזמינות גבוהה, ולכן יש מורכבות נוספת בהגדרות ובפריסה.
בנוסף, Orchestrator לא תומך בשכפול ממקורות מרובים, לא תומך בכל סוגי השכפול המקבילי ולא ניתן לשלב אותו עם תוכנות לאשכולות כמו Galera או Percona XtraDB. מידע נוסף על המגבלות הנוכחיות זמין בשאלות הנפוצות בנושא Orchestrator.
המאמרים הבאים
- מידע על הגדרת זמינות גבוהה ב-Cloud SQL
- מידע נוסף על אפשרויות לזמינות גבוהה באמצעות דיסקים קבועים אזוריים
- כדאי לעיין במסמכי התיעוד בנושא שכפול קבוצתי של MySQL.
- מידע נוסף על Galera Cluster או על Percona XtraDB Cluster.
- כדאי לעיין במסמכי התיעוד של Orchestrator.
- ProxySQL
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.