בדף הזה מובאת סקירה כללית על הגדרת זמינות גבוהה (HA) למופעי Cloud SQL. כדי להגדיר מכונה חדשה לזמינות גבוהה או להפעיל זמינות גבוהה במכונה קיימת, אפשר לעיין במאמר הפעלה והשבתה של זמינות גבוהה במכונה.
סקירה כללית על הגדרת HA
המטרה של הגדרת זמינות גבוהה היא לצמצם את זמן ההשבתה כשאזור או אירוע הופכים ללא זמינים. זה יכול לקרות במהלך הפסקת חשמל אזורית, או כשיש בעיה בחומרה. בזמינות גבוהה, הנתונים שלכם ממשיכים להיות זמינים לאפליקציות לקוח.
הגדרת HA מספקת יתירות נתונים. מופע Cloud SQL שהוגדר לזמינות גבוהה נקרא גם מופע אזורי, ויש לו אזור ראשי ואזור משני באזור שהוגדר*. בתוך מכונה אזורית, ההגדרה מורכבת ממכונה ראשית וממכונה במצב המתנה. באמצעות שכפול סינכרוני לדיסק הקבוע של כל אזור, כל פעולות הכתיבה שמתבצעות במופע הראשי משוכפלות לדיסקים בשני האזורים לפני שדיווח על טרנזקציה מתבצע כמאושר. במקרה של כשל במכונה או בתחום (zone), מכונה במצב המתנה הופכת למכונה הראשית החדשה. לאחר מכן המשתמשים מנותבים מחדש למופע הראשי החדש. התהליך הזה נקרא מעבר לגיבוי (failover).
אחרי מעבר לגיבוי, המופע שקיבל את הגיבוי ממשיך להיות המופע הראשי, גם אחרי שהמופע המקורי חוזר למצב אונליין. אחרי שהאזור או המופע שחוו הפסקה זמנית בשירות חוזרים להיות זמינים, המופע הראשי המקורי מושמד ונוצר מחדש. אחר כך היא הופכת למכונה במצב המתנה החדשה. אם בעתיד יתרחש מעבר לגיבוי, השרת הראשי החדש יעבור לגיבוי למופע המקורי באזור המקורי.
אם אתם צריכים שהמופע הראשי יהיה באזור שבו הייתה ההשבתה, אתם יכולים לבצע מעבר חזרה. במעבר חזרה מתבצעים אותם שלבים כמו ביתירות כשל, רק בכיוון ההפוך, כדי לשנות מסלול את תעבורת הנתונים בחזרה למכונה המקורית. כדי לבצע מעבר חזרה, משתמשים בהליך שבמאמר הפעלת מעבר לגיבוי (failover).
תמיכה בדיסק מתמשך אזורי להגדרת זמינות גבוהה ב-Cloud SQL עם לפחות מעבד ייעודי אחד, מכוסה באופן מלא על ידי הסכם רמת השירות (SLA). מופע עם הגדרת HA עולה פי שניים ממופע עצמאי. המחיר הזה כולל מעבד, זיכרון RAM ואחסון. מידע נוסף זמין בדף התמחור.
* למידע נוסף על שיקולים ספציפיים לאזור, אפשר לעיין במאמר מיקום גיאוגרפי ואזורים.
סקירה כללית על מעבר לגיבוי בעת כשל
אם מכונה שהוגדרה לזמינות גבוהה לא מגיבה, Cloud SQL עובר אוטומטית להצגת נתונים מהמכונה במצב המתנה. כדי לראות אם בוצע מעבר לגיבוי, בודקים את היסטוריית המעברים לגיבוי ביומן הפעולות.
איך יוצרים שאילתות ב-Logs Explorer אם אתם צריכים מידע מפורט יותר על פעולה מסוימת, כמו המשתמש שביצע את הפעולה, אתם צריכים להפעיל את רישום הפעולות ביומן הביקורת.
לוחצים על הכרטיסיות כדי לראות איך מעבר לגיבוי (failover) משפיע על המופע.
רגילה
יתירות כשל
אחרי מעבר לשירות גיבוי
חזרה למצב תקין
תהליך
התהליך הבא מתרחש:
המופע הראשי או האזור נכשלים.
מערכת הדופק בודקת בכל שנייה אם המופע הראשי תקין. אם לא מזוהים כמה פעימות לב, מתחיל מעבר לגיבוי.
המופע במצב המתנה מציג עכשיו נתונים אחרי החיבור מחדש.
באמצעות כתובת IP סטטית משותפת עם המופע הראשי, מופע ההמתנה מציג עכשיו נתונים מהאזור המשני.
דרישות
כדי ש-Cloud SQL יאפשר מעבר לגיבוי בעת כשל, התצורה צריכה לעמוד בדרישות הבאות:
- המכונה הראשית צריכה להיות במצב פעולה רגיל (לא במצב עצירה, לא בתחזוקה ולא במהלך פעולה ארוכה של מכונת Cloud SQL, כמו פעולת גיבוי).
- התחום המשני ומופע ההמתנה צריכים להיות במצב תקין. כשמופע ההמתנה לא מגיב, פעולות המעבר לגיבוי חסומות. אחרי ש-Cloud SQL מתקן את מכונת ה-standby והאזור המשני זמין, Cloud SQL מאפשר מעבר לגיבוי בענן.
גיבוי ושחזור
מומלץ מאוד להשתמש בגיבויים אוטומטיים כדי ליצור זמינות גבוהה.
אפשרויות שחזור למופעים עצמאיים
מכונות עצמאיות ב-Cloud SQL לא משוחזרות אוטומטית אחרי הפסקת חשמל אזורית. כדי להקים מחדש מכונה שלא הוגדרה לזמינות גבוהה באזור תקין, צריך לשחזר באופן ידני את כל המכונות באזור. אפשר לשחזר באופן ידני מופע עצמאי מהפסקת חשמל אזורית באמצעות אחת מהאפשרויות הבאות:
מבצעים שחזור מערכת מנקודה מסוימת בזמן (PITR) במכונה למכונה חדשה שיוצרים. כדי להשתמש באפשרות הזו, צריך להפעיל PITR במופע האזורי לפני ההשבתה האזורית. יומני העסקאות של המופע צריכים להיות מאוחסנים ב-Cloud Storage. אם יומני העסקאות מאוחסנים בדיסק, אפשר להעביר אותם ל-Cloud Storage. כדי להשתמש באפשרות הזו, פועלים לפי השלבים במאמר ביצוע PITR במופע לא זמין.
אם למופע יש העתק לקריאה באזור אחר, אפשר להפוך את ההעתק הזה למופע הראשי כדי להחליף את המופע העצמאי שחווה הפסקת חשמל אזורית. כדי להשתמש באפשרות הזו, פועלים לפי השלבים במאמר קידום של העתק.
לגבי שתי האפשרויות, חשוב לזכור את הנקודות הבאות:
יכול להיות שעסקאות מהזמן האחרון שבוצעו במופע הראשי לא יופיעו במופע החדש ששוחזר. המרווח שבו יכול להיות שהעסקאות אבדו הוא היעד להתאוששות מאסון (RPO).
- במקרה של שחזור PITR, ה-RPO הוא בדרך כלל חמש דקות או פחות.
- בקידום של עותק לקריאה, ה-RPO משתנה בהתאם לעומס העבודה של מסד הנתונים. מידע נוסף על מעקב אחרי השהיית רפליקציה ועל צמצום שלה זמין במאמר השהיית רפליקציה.
אחרי שמבצעים אחת מאפשרויות השחזור, צריך להגדיר מחדש את כל הלקוחות של המכונות שחוו את ההפסקות האזוריות, כי למכונות המשוחזרות יהיו כתובות IP ושמות חיבור שונים.
אפליקציות ומופעים
אין הבדל בין עבודה עם מופעים ללא זמינות גבוהה לבין מופעים עם זמינות גבוהה, ולכן אין צורך להגדיר את האפליקציה בצורה מסוימת. כשמתרחש יתירות כשל, כל החיבורים הקיימים למופע הראשי ולרפליקות לקריאה נסגרים, ויחלפו כ-60 שניות עד שהחיבורים למופע הראשי יתחדשו. האפליקציה מתחברת מחדש באמצעות אותו מחרוזת חיבור או כתובת IP, כך שלא צריך לעדכן את האפליקציה אחרי מעבר לגיבוי.
כדי לראות בדיוק איך המעבר לגיבוי משפיע על האפליקציות שלכם, מפעילים מעבר לגיבוי באופן ידני.
זמן השבתה לצורך תחזוקה
אירועי תחזוקה משפיעים על מכונות מרכזיות שהוגדרו עם זמינות גבוהה (HA) באותו אופן כמו על מכונות אחרות. צפוי שיהיה זמן השבתה קצר של המופעים הראשיים. מידע נוסף על ההשפעה של תחזוקה על מקרים של זמינות גבוהה זמין במאמר איך תחזוקה פועלת. כדי למזער את ההשפעה על השירות, אפשר לשנות את הגדרות התחזוקה כדי לקבוע מתי תהיה השבתה.
המאמרים הבאים
- הפעלה והשבתה של זמינות גבוהה במופע.
- הפעלת מעבר לגיבוי (failover).
- מידע נוסף על ניהול קישורים למסדי נתונים
- מידע נוסף על אזורים ואזורי זמינות ב-Cloud SQL