בדף הזה מוסבר על תוכנית התאוששות מאסון (DR) ב-Cloud SQL.
סקירה כללית
ב- Google Cloud, התאוששות מאסון (DR) במסד נתונים היא תהליך שמטרתו לספק המשכיות של העיבוד, במיוחד כשאזור נכשל או הופך ללא זמין. Cloud SQL הוא שירות אזורי (כאשר Cloud SQL מוגדר לזמינות גבוהה (HA)). לכן, אם אזור Google Cloud שמארח מסד נתונים של Cloud SQL הופך ללא זמין, גם מסד הנתונים של Cloud SQL הופך ללא זמין.
כדי להמשיך את העיבוד, עליך להפוך את מסד הנתונים לזמין באזור משני בהקדם האפשרי. בתוכנית ה-DR צריך להגדיר העתק לקריאה בין אזורים ב-Cloud SQL. אפשר גם לבצע מעבר לגיבוי בעקבות כשל על סמך ייצוא/ייבוא או גיבוי/שחזור, אבל הגישה הזו אורכת זמן רב יותר, במיוחד במסדי נתונים גדולים.
התרחישים העסקיים הבאים הם דוגמאות למצבים שבהם כדאי להגדיר תצורת יתירות כשל בין אזורים:
- הסכם רמת השירות של האפליקציה העסקית גבוה יותר מהסכם רמת השירות האזורי של Cloud SQL (זמינות של 99.99% בהתאם למהדורת Cloud SQL). מעבר לאזור אחר יכול לצמצם את ההשפעה של הפסקת שירות.
- כל הרמות של האפליקציה העסקית כבר פועלות במספר אזורים, ויכולות להמשיך לעבד נתונים כשמתרחש הפסקת חשמל באזור מסוים. הגדרת מעבר אוטומטי לגיבוי באזור אחר עוזרת לשמור על זמינות רציפה של מסד נתונים.
- היעד הנדרש להתאוששות (RTO) והיעד להתאוששות מאסון (RPO) הם בדקות ולא בשעות. מעבר לגיבוי באזור אחר מהיר יותר מיצירה מחדש של מסד נתונים.
באופן כללי, יש שתי גרסאות לתהליך DR:
- מסד נתונים עובר לגיבוי באזור משני. אחרי שמסד הנתונים מוכן ומשמש אפליקציה, הוא הופך למסד הנתונים הראשי החדש ונשאר ככזה.
- מסד נתונים עובר לאזור משני אבל חוזר לאזור הראשי אחרי שהאזור הראשי משתקם מהכשל.
במאמר הזה Google Cloud יש סקירה כללית על התאוששות מאסון (DR) של מסד נתונים של SQL. הוא מתאר את האפשרות השנייה – שחזור של מסד נתונים שנכשל וחזרה לאזור הראשי. הגרסה הזו של תהליך DR רלוונטית במיוחד למסדי נתונים שצריכים לפעול באזור הראשי בגלל השהיית רשת, או בגלל שחלק מהמשאבים זמינים רק באזור הראשי. בגרסה הזו, מסד הנתונים פועל באזור המשני רק למשך ההשבתה באזור הראשי.
ארכיטקטורה של תוכנית התאוששות מאסון (DR)
התרשים הבא מציג את הארכיטקטורה המינימלית שתומכת ב-DR של מסד נתונים עבור מופע Cloud SQL עם זמינות גבוהה:
כך פועלת הארכיטקטורה:
- שתי מכונות Cloud SQL (מכונה ראשית ומכונה במצב המתנה) ממוקמות בשני אזורים נפרדים באותו אזור (האזור הראשי). הסנכרון בין המופעים מתבצע באמצעות דיסקים לאחסון מתמיד אזורי.
- מופע אחד של Cloud SQL (הרפליקה לקריאה בין אזורים) נמצא באזור שני (האזור המשני). לצורך DR, העותק לקריאה בין-אזורי מוגדר לסנכרון (באמצעות שכפול אסינכרוני) עם המופע הראשי באמצעות הגדרת עותק לקריאה.
למכונות הראשיות ולמכונות ההמתנה יש אותו דיסק אזורי, ולכן המצבים שלהן זהים.
מכיוון שההגדרה הזו משתמשת ברפליקציה אסינכרונית, יכול להיות שהרפליקה לקריאה בין אזורים תהיה מאחורי המופע הראשי. כתוצאה מכך, כשמתרחש יתירות כשל, סביר להניח שערך ה-RPO של רפליקה לקריאה בין אזורים יהיה שונה מאפס.
תהליך התאוששות מאסון (DR)
תהליך ההתאוששות מאסון (DR) מתחיל כשהאזור הראשי הופך ללא זמין. כדי להמשיך את העיבוד באזור משני, מפעילים מעבר לגיבוי (failover) של המופע הראשי על ידי קידום של רפליקה לקריאה חוצת-אזורים. תהליך ה-DR קובע את השלבים התפעוליים שצריך לבצע, באופן ידני או אוטומטי, כדי לצמצם את ההשפעה של הכשל באזור וליצור מופע ראשי פעיל באזור משני.
בתרשים הבא מוצג תהליך ה-DR:
תהליך ה-DR כולל את השלבים הבאים:
- האזור הראשי (R1), שבו פועל המופע הראשי, הופך ללא זמין.
- צוות התפעול מזהה את האסון ומאשר אותו באופן רשמי, ומחליט אם נדרשת יתירות כשל.
- אם נדרש יתירות כשל, אפשר להעלות בדרגה את הרפליקה לקריאה בין אזורים באזור המשני (R2) להיות המכונה הראשית החדשה.
- החיבורים של הלקוחות מוגדרים מחדש כדי להמשיך את העיבוד במופע הראשי החדש ולגשת למופע הראשי ב-R2.
התהליך הראשוני הזה יוצר שוב מסד נתונים ראשי תקין. עם זאת, הוא לא יוצר ארכיטקטורת DR מלאה, שבה למופע הראשי החדש יש מופע המתנה ועותק לקריאה חוצה אזורים.
תהליך DR מלא מבטיח שהמופע היחיד, המופע הראשי החדש, מופעל ל-HA ויש לו העתק לקריאה חוצה אזורים. תהליך מלא של DR מספק גם חזרה לפריסה המקורית באזור הראשי המקורי.
מעבר אוטומטי לאזור משני
תהליך DR מלא מרחיב את תהליך ה-DR הבסיסי על ידי הוספת שלבים ליצירת ארכיטקטורת DR מלאה אחרי יתירות כשל. התרשים הבא מציג ארכיטקטורה מלאה של DR למסד נתונים אחרי המעבר לגיבוי:
תהליך ה-DR המלא של מסד הנתונים כולל את השלבים הבאים:
- האזור הראשי (R1), שבו פועל מסד הנתונים הראשי, לא זמין.
- צוות התפעול מזהה את האסון ומאשר אותו באופן רשמי, ומחליט אם נדרשת יתירות כשל.
- אם נדרש יתירות כשל, אפשר להעלות בדרגה את הרפליקה לקריאה בלבד באזור המשני (R2) למופע הראשי החדש.
- החיבורים של הלקוחות מוגדרים מחדש כדי לגשת למופע הראשי החדש (R2) ולעבד בו.
- מופע חדש של מצב המתנה נוצר ומופעל ב-R2, ונוסף למופע הראשי. מופע הגיבוי נמצא באזור אחר מזה של המופע הראשי. המופע הראשי זמין עכשיו ברמה גבוהה כי נוצר עבורו מופע בהמתנה.
- באזור שלישי (R3), נוצר העתק קריאה חדש בין אזורים ומצורף למופע הראשי. בשלב הזה, ארכיטקטורה מלאה של התאוששות מאסון נוצרת מחדש ומופעלת.
אם האזור הראשי המקורי (R1) יהפוך לזמין לפני שמיישמים את שלב 6, אפשר להציב את העותק לקריאה בכמה אזורים באזור R1 באופן מיידי, במקום באזור R3. במקרה הזה, החזרה לאזור הראשי המקורי (R1) פשוטה יותר ודורשת פחות שלבים.
איך נמנעים ממצב של פיצול מוח
אם יש כשל באזור הראשי (R1), זה לא אומר שהמכונה הראשית המקורית ומכונה במצב המתנה שלה מושבתות אוטומטית, מוסרות או הופכות ללא נגישות כש-R1 הופך שוב לזמין. אם R1 יהיה זמין, יכול להיות שהלקוחות יקראו ויכתבו נתונים (גם בטעות) במופע הראשי המקורי. במקרה כזה, יכול להתפתח מצב של פיצול נתונים, שבו חלק מהלקוחות ניגשים לנתונים לא עדכניים במסד הנתונים הראשי הישן, ולקוחות אחרים ניגשים לנתונים עדכניים במסד הנתונים הראשי החדש, מה שמוביל לבעיות בעסק.
כדי להימנע ממצב של פיצול מוח, צריך לוודא שהלקוחות לא יוכלו יותר לגשת למופע הראשי המקורי אחרי ש-R1 יהיה זמין. מומלץ להפוך את המופע הראשי המקורי ללא נגיש לפני שהלקוחות מתחילים להשתמש במופע הראשי החדש, ואז למחוק את המופע הראשי המקורי מיד אחרי שהופך ללא נגיש.
יצירת גיבוי ראשוני אחרי מעבר לגיבוי בעקבות כשל
כשמקדמים את העותק לקריאה בין אזורים להיות העותק הראשי החדש במעבר לגיבוי, יכול להיות שהעסקאות בעותק הראשי החדש לא יהיו מסונכרנות באופן מלא עם העסקאות מהעותק הראשי המקורי. לכן, העסקאות האלה לא זמינות במופע החדש.
מומלץ לגבות מיד את המכונה הראשית החדשה בתחילת יתירות הכשל, ולפני שלקוחות ניגשים למסד הנתונים. הגיבוי הזה מייצג מצב עקבי וידוע בנקודת המעבר לגיבוי. גיבויים כאלה יכולים להיות חשובים למטרות רגולטוריות או לשחזור למצב מוכר אם לקוחות נתקלים בבעיות בגישה לשרת הראשי החדש.
חזרה לאזור הראשי המקורי
כמו שצוין קודם, במאמר הזה מפורטים השלבים לחזרה לאזור המקורי (R1). יש שתי גרסאות שונות של תהליך הגיבוי.
- אם יצרתם את העותק החדש לקריאה בין אזורים באזור משני (R3), אתם צריכים ליצור עוד עותק (שני) לקריאה בין אזורים באזור הראשי (R1).
- אם יצרתם את העותק החדש לקריאה בין אזורים באזור הראשי (R1), אתם לא צריכים ליצור עוד עותק לקריאה בין אזורים ב-R1.
אחרי שנוצר העתק לקריאה בין-אזורי באזור R1, מופעלת חזרה אוטומטית של מופע Cloud SQL לאזור R1. מכיוון שהמעבר לגיבוי הזה מופעל באופן ידני ולא מבוסס על הפסקת שירות, אתם יכולים לבחור את היום והשעה המתאימים לפעילות התחזוקה הזו.
לכן, כדי להשיג DR מלא עם רפליקה לקריאה ראשית, רפליקה לקריאה במצב המתנה ורפליקה לקריאה חוצה אזורים, צריך לבצע שני מעברים אוטומטיים לשירות גיבוי (failover). המעבר לגיבוי הראשון מופעל בגלל ההשבתה (מעבר לגיבוי אמיתי), והמעבר לגיבוי השני מחזיר את הפריסה למצב ההתחלתי (חזרה למצב הקודם).
החזרה לאזור הראשי המקורי (R1) כוללת את השלבים הבאים:
- קידום הרפליקה החדשה שנוצרה באזור הראשי המקורי (R1).
- מגדירים מחדש את האפליקציות כך שיתחברו למופע הראשי החדש.
- יוצרים עותק משוכפל חוצה אזורים למופע הראשי החדש באזור DR (R2).
- (אופציונלי) כדי להימנע מהפעלת כמה מופעים ראשיים עצמאיים, מנקים את המופע הראשי באזור DR (R2).
עותקים שניתן להעביר אותם
בעזרת Cloud SQL אפשר ליצור רפליקות לתרחישי בדיקה ושחזור של התאוששות מאסון (DR) בין אזורים. אפשר ליצור העתק באמצעות הדגל cascadable-replica באזור שונה מהאזור של המופע הראשי. אם מתרחש אסון באזור של המופע הראשי, צריך להפעיל מעבר לגיבוי כשל אל העותק המשוכפל שניתן להעברה.
אחרי שהמופע הראשי המקורי חוזר למצב אונליין ופועל כעותק תקין, אפשר להשתמש בפעולת המעבר כדי לחזור למופע הראשי המקורי.
לשכפול מדורג יש שתי יכולות נוספות שאין לשכפולים אחרים לקריאה:
- אפשר לצרף רפליקות נוספות לקריאה (רפליקות מדורגות) לרפליקה לקריאה שאפשר לצרף אליה רפליקות. Cloud SQL שולח תעבורת נתונים בזמן שכפול בין אזורים רק פעם אחת לרפליקה שאפשר להעביר ממנה נתונים, ואז הרפליקה שאפשר להעביר ממנה נתונים מעבירה את התעבורה לרפליקות שלה באזור. הארכיטקטורה הזו יכולה לחסוך בעלויות של העברת נתונים ברשת בין אזורים, כשצריך כמה עותקים משוכפלים באזור אחר.
- אתם יכולים להשתמש בעותק לקריאה שניתן להעברה כיעד לפעולות של מעבר לגיבוי ולמעבר לגיבוי במקרה של כשל בתרחישים של התאוששות מאסון בין אזורים. הפעולות האלה מגדירות מחדש את העותק המשוכפל שניתן להעברה כך שיהיה המופע הראשי באשכול.
אפשר לבדוק את תוכנית ההתאוששות מאסון (DR) באחת משתי הדרכים הבאות:
- קידום הרפליקה
- תוכנית התאוששות מאסון (DR) מתקדמת
תוכנית התאוששות מאסון (DR) מתקדמת
אם אתם משתמשים במהדורת Cloud SQL Enterprise Plus, תוכלו ליהנות מ-DR מתקדם. DR מתקדם מפשט את השחזור והחזרה למצב הקודם אחרי יתירות כשל חוצה אזורים. כפי שמתואר בתהליך ההתאוששות מאסון, כשמבצעים DR, מסירים את החיבור בין האזור שנכשל במופע הראשי הישן לבין האזור התפעולי במופע הראשי החדש. כדי לשחזר את החיבורים לאזור הפריסה המקורי ולחזור למופע הראשי הישן, צריך לבצע סדרה של שלבי חזרה ידניים.
ב-DR מתקדם, כשמתרחש כשל באזור, אפשר להפעיל מעבר לגיבוי (failover) של העותק המשוכפל.
במעבר אוטומטי לגיבוי (failover) של רפליקה, מקדמים רפליקה לקריאה באזור אחר, בדומה לביצוע שחזור רגיל מאסון, אלא שמקדמים את הרפליקה שיועדה לשחזור מאסון (DR).
ב-Cloud SQL ל-SQL Server, יוצרים רפליקה של DR על ידי יצירת רפליקה חוצה-אזורים של המכונה הראשית עם הדגל cascadable-replica. הקידום של העותק המשוכפל לצורך התאוששות מאסון מתבצע באופן מיידי.
בנוסף, כשיוצרים מכונה ראשית חדשה או מציינים רפליקה לשחזור מאסון (DR) למכונה ראשית קיימת, Cloud SQL יוצר נקודת קצה לכתיבה.
נקודת קצה לכתיבה היא שם DNS שמפוענח לכתובת ה-IP של המופע הראשי.
כשמשדרגים את העותק המשוכפל של DR, נקודת הקצה של הכתיבה מתעדכנת כך שתצביע על המופע הראשי החדש ששודרג. כך מובטח שכל האפליקציות שמנסות להתחבר באמצעות נקודת הקצה לכתיבה יופנו למופע המקודם.
במקום להסיר את המכונה הראשית הישנה, המכונה נשארת חלק מטופולוגיית השכפול האסינכרוני של Cloud SQL. בסופו של דבר, המופע הראשי הישן (מופע א') הופך לעותק של העותק שלו לשחזור לאחר אסון (מופע ב'), אחרי שהעותק לשחזור לאחר אסון קודם למופע הראשי החדש.
אחרי שהמופע הראשי הישן (A) הפך למופע משוכפל, אפשר לבצע את השלב האחרון של התאוששות מתקדמת מאסון. אפשר להחזיר את הפריסה של Cloud SQL למצב המקורי ולשחזר את המופע הראשי הישן (A) לתפקיד הקודם שלו כמופע הראשי ללא אובדן נתונים. כדי לבצע שחזור ללא אובדן נתונים של המופע הראשי הישן (A), אפשר להשתמש בפעולת המעבר. כשמבצעים מעבר לגיבוי, לא מתרחש אובדן נתונים כי המופע הראשי (B) נשאר במצב קריאה בלבד עד שהרפליקה המיועדת להתאוששות מאסון (A) מתעדכנת בהתאם למופע הראשי (B). אחרי שעותק השחזור (A) מקבל את כל עדכוני השכפול שלו, הוא מקבל את התפקיד של המופע הראשי, והמופע הראשי הקודם (B) מוגדר מחדש באופן אוטומטי כעותק השחזור של המופע הראשי הנוכחי (A). המופעים חוזרים לתפקידים המקוריים שלהם, וכך הטופולוגיה חוזרת למצב המקורי שלה לפני ה-DR והמעבר האוטומטי של העותק המשוכפל.
במהלך DR מתקדם, כל המופעים שמשתתפים בפעולות של מעבר לגיבוי (failover) ומעבר חזרה (switchover) של העתקים משוכפלים שומרים על כתובות ה-IP שלהם.
אפשר גם להשתמש בפעולת המעבר של DR מתקדם כדי לבצע תרגילי DR שגרתיים לבדיקה ולהכנה של טופולוגיית Cloud SQL למעבר לגיבוי בעקבות כשל לפני שמתרחש אסון. אם מתרחש אסון בפועל, אפשר לבצע את המעבר לגיבוי האזורי שכבר נבדק.
עותק משוכפל של תוכנית התאוששות מאסון (DR)
כחלק חובה מפתרון מתקדם להתאוששות מאסון, העותק המשוכפל להתאוששות מאסון כולל את המאפיינים הבאים:
- שכפול DR הוא שכפול לקריאה באזור אחר שמחובר ישירות.
- אפשר לשנות את ההגדרה של העותק המשוכפל לצורך התאוששות מאסון כמה פעמים.
- עותק DR הוא עותק שניתן להעברה, שיוצרים באמצעות הדגל
cascadable-replica. כדי לשמש כרפליקת DR, הרפליקה הניתנת להעברה צריכה להיות באזור נפרד מהמופע הראשי. - אי אפשר להחזיק יותר מרפליקה אחת של DR באזור.
- אפשר לשנות את ייעוד העותק המשוכפל של DR בכל שלב, למעט במהלך פעולת מעבר או פעולת מעבר לגיבוי.
בנוסף, כדי לצמצם את זמן ההשבתה אחרי שימוש ב-DR מתקדם, מומלץ:
- מגדירים את העותק המשוכפל של DR באותו גודל כמו המופע הראשי.
- אם HA מופעל במופע הראשי, מומלץ להפעיל HA גם בשכפול DR. כדי לעשות זאת, קודם צריך לוודא שהזמינות הגבוהה מופעלת בשרת הראשי. לאחר מכן, מבצעים את המעבר לגיבוי לשחזור (DR). אחרי שפעולת המעבר מסתיימת, מפעילים את הזמינות הגבוהה במופע הראשי החדש. אחר כך תוכלו לחזור למופע הראשי הישן. ההגדרה של זמינות גבוהה (HA) נשמרת בעותק המשוכפל של DR גם אחרי שהוא הופך שוב לעותק משוכפל.
מעבר אוטומטי לגיבוי (failover) של רפליקה
לסיכום, יתירות כשל של רפליקה כוללת את האירועים הבאים:
- יוצרים ומקצים עותק משוכפל של DR.
- האזור הראשי לא זמין.
- מבצעים מעבר לגיבוי במקרה של כשל ברפליקה לרפליקת ה-DR.
- נקודת הקצה של הכתיבה מתעדכנת ומתחילה להצביע על המופע הראשי החדש.
- כשהמופע הראשי המקורי חוזר למצב אונליין, הוא הופך לעותק לקריאה של המופע הראשי החדש.
- אתם יכולים להשתמש בפעולת המעבר כדי לשחזר את הפריסה לטופולוגיה המקורית שלה.
כדי לראות את הפרטים והתרשימים של פעולת מעבר לגיבוי (failover) של העתק, לוחצים על הכרטיסיות הבאות.
הקצאת רפליקת DR
לפני שמבצעים יתירות כשל של רפליקה, צריך להקצות רפליקת DR למופע הראשי, ואולי גם לבדוק את התהליך על ידי ביצוע מעבר.
מתרחשת הפסקה זמנית בשירות
האזור הראשי, שבו פועל מסד הנתונים הראשי, הופך ללא זמין.
מעבר אוטומטי לגיבוי (failover) של רפליקה
אחרי שקובעים שנדרש שחזור אחרי אסון, מבצעים מעבר לגיבוי בעותק משוכפל של הגיבוי לשחזור אחרי אסון.
העותק המשוכפל של DR הופך באופן מיידי למופע הראשי ומתחיל לקבל קריאות וכתיבות נכנסות. נקודת הקצה של הכתיבה מתעדכנת ומתחילה להצביע על המופע הראשי החדש.
השרת הראשי המקורי הופך לשרת משוכפל
אחרי שהשכפול יקודם, Cloud SQL יבדוק מעת לעת אם המופע הראשי המקורי חזר למצב אונליין. אם המכונה המקורית הראשית מחוברת לאינטרנט, Cloud SQL יוצר מחדש את המכונה הראשית הישנה כרפליקה של המכונה שודרגה. כתובת ה-IP של המכונה הראשית הישנה נשמרת.
אם השרת הראשי הישן לא פעיל במשך 24 שעות, Cloud SQL מסיר אותו מטופולוגיית השכפול כדי להבטיח שיומן העסקאות במופע הראשי החדש ובשאר העותקים שלו לא יגדל ללא הגבלה.
חזרה לגרסה המקורית
אחרי שמבצעים מעבר לגיבוי במקרה של כשל בשכפול, אפשר לשחזר את המופע הראשי באזור המקורי על ידי ביצוע פעולת המעבר לגיבוי במקרה של כשל בשכפול, והיפוך של אותו זוג של מופע ראשי ומופע משוכפל לשחזור.
החלפה
לסיכום, פעולת מעבר כוללת את האירועים הבאים:
- יוצרים ומקצים עותק משוכפל של DR.
- אתם מתחילים את תהליך המעבר.
- כשפיגור הרפליקציה יורד לאפס, המופעים הראשיים החדשים מתחילים לקבל חיבורים נכנסים.
- המופע הראשי הישן הופך למופע משני לקריאה בלבד.
- אם נעשה שימוש בנקודת קצה לכתיבת DNS, נקודת הקצה לכתיבת DNS מתעדכנת כך שתפנה למופע הראשי החדש.
כדי לראות את הפרטים והדיאגרמות של פעולת מעבר, לוחצים על הכרטיסיות הבאות.
הקצאת רפליקת DR
לפני שמתחילים את פעולת ה *החלפה*, צריך להקצות עותק משוכפל של DR למופע הראשי.
מוודאים שהמופע הראשי תקין. אפשר לבצע מעבר לגיבוי רק אם גם המופע הראשי וגם העותק המשוכפל של ה-DR מחוברים לאינטרנט.
התחלת המעבר
אתם מתחילים את המעבר. כשמפעילים מעבר לגיבוי, הרפליקציה לגיבוי לשחזור מאסון עוברת למצב סינכרוני. הרפליקה של DR מתעדכנת בהתאם למופע הראשי ומשנה את הסטטוס שלה ל'מסונכרן'. כשההשהיה של הרפליקציה יורדת לאפס, העותק המשוכפל של DR מקודם כמופע הראשי החדש. המופע הראשי החדש מתחיל לקבל חיבורים נכנסים, כולל קריאות וכתיבות של אפליקציות.
נקודת הקצה עודכנה
אחרי שמשדרגים את העותק המשוכפל של DR למופע הראשי החדש, נקודת הקצה של כתיבת ה-DNS מתעדכנת ומתחילה להצביע על המופע הראשי החדש.
המופע הראשי הישן מוגדר מחדש כרפליקה לקריאה.
כתיבה של נקודות קצה
נקודת קצה לכתיבה היא שם גלובלי של שירות שמות דומיין (DNS) שמקבל באופן אוטומטי את כתובת ה-IP של המופע הראשי הנוכחי. נקודת הקצה הזו מפנה אוטומטית חיבורים נכנסים למופע הראשי החדש במקרה של יתירות כשל או מעבר לגיבוי פעיל של רפליקה. אפשר להשתמש בנקודת הקצה לכתיבה במחרוזת חיבור SQL במקום בכתובת IP. אם משתמשים בנקודת קצה לכתיבה, לא צריך לבצע שינויים בחיבור האפליקציה כשמתרחש הפסקת חשמל באזור.
כדי להשתמש בנקודת קצה לכתיבה, צריך להפעיל את Cloud DNS API בפרויקט שבו יוצרים את המכונה הראשית של Cloud SQL Enterprise Plus או שבו היא קיימת.
כשיוצרים מכונה במהדורת Cloud SQL Enterprise Plus עם כתובת IP פרטית ורשתות מאושרות, מערכת Cloud SQL יוצרת באופן אוטומטי נקודת קצה (endpoint) לכתיבה עבור המכונה. אם כבר יש לכם מכונה ראשית במהדורת Cloud SQL Enterprise Plus, מערכת Cloud SQL יוצרת את נקודת הקצה לכתיבה כשאתם יוצרים את רפליקת ה-DR (רפליקה חוצת אזורים שאתם יוצרים באמצעות דגל cascadable-replica). אם המכונה הראשית משתנה בגלל פעולת מעבר או יתירות כשל של רפליקה, מערכת Cloud SQL מקצה את נקודת הקצה לכתיבה לרפליקת ה-DR כשרפליקת ה-DR הופכת למכונה הראשית החדשה.
מידע נוסף על שימוש בנקודת קצה לכתיבה כדי להתחבר למופע זמין במאמר התחברות למופע באמצעות נקודת קצה לכתיבה.
המאמרים הבאים
- שימוש בתכונות מתקדמות של התאוששות מאסון (DR).
- כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים, מדריכים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.