בדף הזה מוסבר על תוכנית התאוששות מאסון (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 SQL database disaster recovery overview מתואר המקרה השני – כשמסד נתונים שנכשל משוחזר וחוזר לאזור הראשי. הגרסה הזו של תהליך DR רלוונטית במיוחד למסדי נתונים שצריכים לפעול באזור הראשי בגלל השהיית הרשת, או בגלל שחלק מהמשאבים זמינים רק באזור הראשי. בגרסה הזו, מסד הנתונים פועל באזור המשני רק למשך ההשבתה באזור הראשי.
ארכיטקטורה של תוכנית התאוששות מאסון (DR)
התרשים הבא מציג את הארכיטקטורה המינימלית שתומכת ב-DR של מסד נתונים עבור מופע Cloud SQL עם זמינות גבוהה:
הארכיטקטורה פועלת באופן הבא:
- שני מופעים של Cloud SQL (מופע ראשי ומכונה במצב המתנה) ממוקמים בשני אזורים נפרדים באותו אזור (האזור הראשי). הסנכרון בין המופעים מתבצע באמצעות דיסקים לאחסון מתמיד אזורי.
- מופע אחד של Cloud SQL (הרפליקה לקריאה בין אזורים) נמצא באזור שני (האזור המשני). לצורך DR, העותק לקריאה חוצה-אזורים מוגדר לסנכרון (באמצעות שכפול אסינכרוני) עם המופע הראשי באמצעות הגדרת עותק לקריאה.
למכונות הראשיות ולמכונות במצב המתנה יש אותו דיסק אזורי, ולכן המצבים שלהן זהים.
מכיוון שההגדרה הזו משתמשת ברפליקציה אסינכרונית, יכול להיות שרפליקת הקריאה בין האזורים תהיה מאחורי המופע הראשי. כתוצאה מכך, כשמתרחש מעבר לגיבוי (failover), סביר להניח שערך ה-RPO של העותק לקריאה בין אזורים יהיה שונה מאפס.
תהליך התאוששות מאסון (DR)
תהליך ההתאוששות מאסון (DR) מתחיל כשהאזור הראשי לא זמין. כדי להמשיך את העיבוד באזור משני, צריך להפעיל יתירות כשל של המופע הראשי על ידי קידום רפליקה לקריאה בין אזורים. תהליך ה-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 מלא עם רפליקה לקריאה ראשית, רפליקה לקריאה במצב המתנה ורפליקה לקריאה חוצה אזורים, צריך לבצע שני מעברים אוטומטיים לשירות גיבוי. המעבר הראשון ליתירות כשל מופעל בגלל ההפסקה (יתירות כשל אמיתית), והמעבר השני ליתירות כשל מחזיר את הפריסה למצב ההתחלתי (חזרה למצב הקודם).
החזרה לאזור הראשי המקורי (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, יוצרים רפליקה לשחזור מאסון על ידי יצירת רפליקה חוצה אזורים של המכונה הראשית עם הדגל cascadable-replica. הקידום של העותק המשוכפל של ה-DR מתבצע באופן מיידי.
בנוסף, כשיוצרים מופע ראשי חדש או מציינים רפליקת 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 כמה פעמים.
- עותק משוכפל של DR הוא עותק משוכפל שניתן להעברה, שיוצרים באמצעות הדגל
cascadable-replica. כדי לשמש כרפליקה של DR, הרפליקה הניתנת להעברה צריכה להיות באזור נפרד מהמופע הראשי. - אי אפשר להחזיק יותר מעותק אחד של DR באזור.
- אפשר לשנות את ייעוד העותק המשוכפל של DR בכל שלב, למעט במהלך פעולת מעבר או פעולת מעבר לגיבוי.
בנוסף, כדי לצמצם את זמן ההשבתה אחרי שימוש ב-DR מתקדם, מומלץ:
- מגדירים את העותק המשוכפל של DR באותו גודל כמו המכונה הראשית.
- אם מופעלת זמינות גבוהה במופע הראשי, מומלץ להפעיל זמינות גבוהה גם בעותק המשוכפל של DR. כדי לעשות זאת, קודם מוודאים שהאפשרות HA מופעלת בשרת הראשי. לאחר מכן, מבצעים את המעבר לגיבוי לשחזור (DR). אחרי שפעולת המעבר מסתיימת, מפעילים את הזמינות הגבוהה במופע הראשי החדש. אחר כך תוכלו לחזור למופע הראשי הקודם. ההגדרה של הזמינות הגבוהה נשמרת בעותק המשוכפל של DR גם אחרי שהוא הופך שוב לעותק משוכפל.
יתירות כשל של רפליקה
לסיכום, מעבר לגיבוי בעותק משוכפל מורכב מהאירועים הבאים:
- יוצרים ומקצים עותק משוכפל של DR.
- האזור הראשי לא זמין.
- מבצעים מעבר לגיבוי האוטומטי של העותק המשוכפל ל-DR.
- נקודת הקצה של הכתיבה מתעדכנת ומתחילה להצביע על המופע הראשי החדש.
- כשהמופע הראשי המקורי חוזר למצב אונליין, הוא הופך לעותק לקריאה של המופע הראשי החדש.
- אפשר להשתמש בפעולת המעבר כדי לשחזר את הפריסה לטופולוגיה המקורית שלה.
כדי לראות את הפרטים והתרשימים של פעולת מעבר לגיבוי (failover) של העתק, לוחצים על הכרטיסיות הבאות.
הקצאת עותק כפול לשחזור מאסון
לפני שמבצעים יתירות כשל של רפליקה, צריך להקצות רפליקה של DR למופע הראשי, ואולי גם לבדוק את התהליך על ידי ביצוע מעבר.
מתרחשת הפסקה זמנית בשירות
האזור הראשי שבו פועל מסד הנתונים הראשי הופך ללא זמין.
מעבר לגיבוי (failover) של עותק
אחרי שקובעים שנדרש שחזור אחרי אסון, מבצעים מעבר לגיבוי בעותק משוכפל של הגיבוי לשחזור אחרי אסון.
השכפול של DR הופך באופן מיידי למופע הראשי ומתחיל לקבל קריאות וכתיבות נכנסות. נקודת הקצה של הכתיבה מתעדכנת ומתחילה להצביע על המופע הראשי החדש.
השרת הראשי המקורי הופך לשרת משוכפל
אחרי שהשכפול קודם, Cloud SQL בודק מעת לעת אם המופע הראשי המקורי חזר למצב אונליין. אם המופע הראשי המקורי מחובר לאינטרנט, Cloud SQL יוצר מחדש את המופע הראשי הישן כרפליקה של המופע שקודם. כתובת ה-IP של המופע הראשי הישן נשמרת.
אם השרת הראשי הישן לא פעיל במשך 24 שעות, Cloud SQL מסיר אותו מטופולוגיית השכפול כדי להבטיח שיומן העסקאות במופע הראשי החדש ובשאר העותקים שלו לא יגדל ללא הגבלה.
חזרה לגרסה המקורית
אחרי שמבצעים יתירות כשל של רפליקה, אפשר לשחזר את המכונה הראשית באזור המקורי על ידי ביצוע פעולת המעבר, והיפוך של אותו רפליקה של DR וזוג מכונות ראשיות.
מעבר
לסיכום, פעולת מעבר כוללת את האירועים הבאים:
- יוצרים ומקצים עותק משוכפל של DR.
- אתם מתחילים את המעבר.
- כשפיגור הרפליקציה יורד לאפס, המופעים הראשיים החדשים מתחילים לקבל חיבורים נכנסים.
- המופע הראשי הישן הופך למופע משוכפל לקריאה בלבד.
- אם נעשה שימוש בנקודת קצה לכתיבת DNS, נקודת הקצה לכתיבת DNS מתעדכנת כך שתפנה למופע הראשי החדש.
כדי לראות את הפרטים והתרשימים של פעולת מעבר, לוחצים על הכרטיסיות הבאות.
הקצאת עותק כפול לשחזור מאסון
לפני שמתחילים את פעולת ה *החלפה*, צריך להקצות רפליקה של DR למופע הראשי.
מוודאים שהמופע הראשי תקין. אפשר לבצע מעבר לגיבוי (failover) רק אם גם המופע הראשי וגם העותק המשוכפל של ה-DR מחוברים לאינטרנט.
הפעלת מעבר
אתם מתחילים את המעבר. כשמתחילים מעבר לגיבוי, הרפליקציה של העותק המשוכפל של DR עוברת למצב סינכרוני. הרפליקה של DR מתעדכנת בהתאם למופע הראשי ומשנה את הסטטוס שלה ל'מסונכרן'. כשזמן ההשהיה של הרפליקציה יורד לאפס, העותק המשוכפל של DR מקודם כמופע הראשי החדש. המופע הראשי החדש מתחיל לקבל חיבורים נכנסים, כולל קריאות וכתיבות של אפליקציות.
נקודת הקצה עודכנה
אחרי שמשדרגים את העותק המשוכפל של DR למופע הראשי החדש, נקודת הקצה של כתיבת ה-DNS מתעדכנת ומתחילה להצביע על המופע הראשי החדש.
המופע הראשי הישן מוגדר מחדש כרפליקה לקריאה.
נקודת קצה לכתיבה
נקודת קצה לכתיבה היא שם גלובלי של Domain Name Service (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.