מעבר אוטומטי לגיבוי של מופע ראשי או משני באופן ידני

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

תרחישים נפוצים לדוגמה להפעלה ידנית של יתירות כשל:

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

זמינות גבוהה במכונות ראשיות ומשניות

‫AlloyDB ל-PostgreSQL תומך בזמינות גבוהה גם במכונות ראשיות וגם במכונות משניות.

זמינות גבוהה במכונות ראשיות

כדי להבטיח זמינות גבוהה (HA), לכל מכונה ראשית ב-AlloyDB יש צומת פעיל וצומת במצב המתנה, שנמצאים באזורים שונים. אם הצומת הפעיל לא זמין, AlloyDB מעביר אוטומטית את המכונה הראשית לצומת ההמתנה, שהופך לצומת הפעיל החדש.

אתם יכולים להעביר ידנית את המכונה הראשית לצומת הגיבוי בכל שלב, גם אם הצומת הפעיל פועל כצפוי. כשמפעילים ידנית את יתירות הכשל, AlloyDB מבצע את הפעולות הבאות:

  1. העברת הצומת הראשי למצב אופליין.

  2. הפיכת הצומת במצב המתנה לצומת הפעיל החדש.

  3. הפעלת הצומת הפעיל הקודם כצומת ההמתנה החדש.

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

לדוגמה, נניח שיש לכם מכונה ראשית שהצמתים הפעילים והצמתים במצב המתנה שלה נמצאים באזורים us-central1-a ו-us-central1-b, בהתאמה. הפסקה בשירות ב-us-central1-a מפעילה יתירות כשל אוטומטית, וכתוצאה מכך האזור us-central1-b מארח את הצומת הפעיל. אם אתם מעדיפים שהצומת הפעיל יישאר באזור us-central1-a, אתם יכולים להפעיל יתירות כשל ידנית כדי לגרום ל-AlloyDB להחליף את הצמתים של המכונה הראשית בחזרה למיקומים שלהם לפני ההפסקה.

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

זמינות גבוהה במכונות משניות

ב-AlloyDB יש זמינות גבוהה במכונות משניות כדי לתמוך בתוכנית התאוששות מאסון (DR) ולצמצם את זמן ההשבתה כשהמכונה המשנית לא זמינה.

כברירת מחדל, זמינות גבוהה מוגדרת במכונה משנית.

מכונה משנית של AlloyDB כוללת את הצמתים הבאים:

  • צומת משני פעיל שמגיב לבקשות
  • צומת משני במצב המתנה

הצמתים הפעילים והצמתים במצב המתנה נמצאים בשני אזורים שונים באותו מחוז. אם המערכת של AlloyDB מזהה שהצומת הפעיל לא זמין, הצומת הפעיל עובר לצומת ההמתנה כדי לפעול כצומת הפעיל החדש. לאחר מכן, הנתונים שלכם מנותבים מחדש לצומת הפעיל החדש. התהליך הזה נקרא יתירות כשל.

לפני שמתחילים

  • Google Cloud לפרויקט שבו אתם משתמשים צריכה להיות גישה ל-AlloyDB.
  • בפרויקט ב- Google Cloud שבו אתם משתמשים, צריך להיות לכם אחד מתפקידי ה-IAM הבאים:
    • ‫roles/alloydb.admin (תפקיד IAM מוגדר מראש של אדמין ב-AlloyDB)
    • ‫roles/owner (תפקיד ה-IAM הבסיסי "בעלים")
    • ‫roles/editor (תפקיד העריכה הבסיסי ב-IAM)

    אם לא הוקצו לכם התפקידים האלה, פנו לאדמין הארגוני כדי לבקש גישה.

ביצוע ידני של מעבר למצב של יתירות כשל במכונה ראשית

המסוף

  1. נכנסים לדף Clusters.

כניסה לדף Clusters

  1. בעמודה Resource Name, לוחצים על שם האשכול.

  2. בקטע Instances in your cluster, פותחים את תפריט הפעולות של המכונה הראשית .

  3. לוחצים על Failover.

  4. בתיבת הדו-שיח שמופיעה, מזינים את מזהה המכונה.

  5. לוחצים על Trigger failover.

gcloud

מריצים את הפקודה gcloud alloydb instances failover:

gcloud alloydb instances failover INSTANCE_ID \
    --region=REGION_ID \
    --cluster=CLUSTER_ID \
    --project=PROJECT_ID

מחליפים את מה שכתוב בשדות הבאים:

  • ‫INSTANCE_ID: המזהה של המכונה.
  • ‫REGION_ID: האזור שבו נמצאת המכונה.
  • ‫CLUSTER_ID: המזהה של האשכול שבו נמצא המכונה.
  • ‫PROJECT_ID: מזהה הפרויקט שבו נמצא האשכול.

כדי לוודא שיתירות הכשל פעלה, מבצעים את השלבים הבאים:

  1. לפני שמבצעים את יתירות הכשל, שימו לב לאזורים של הצמתים של המכונה הראשית.

  2. אחרי שמריצים את יתירות הכשל, שימו לב לאזורים החדשים של שני הצמתים.

  3. מוודאים שהאזורים של הצמתים הפעילים והצמתים במצב המתנה החליפו מקומות.

ביצוע מעבר ידני לגיבוי בעת כשל במכונה משנית

העברה ידנית של מכונה משנית למצב של מעבר לגיבוי בעת כשל דומה לשלבים של העברה ידנית של המכונה הראשית למצב של מעבר לגיבוי בעת כשל.

כדי להעביר אשכול משני באופן ידני, פועלים לפי השלבים הבאים:

המסוף

  1. נכנסים לדף Clusters במסוף Google Cloud .

    כניסה לדף Clusters

  2. בעמודה Resource Name, לוחצים על השם של אשכול משני.

  3. בדף Overview, עוברים לקטע Instances in your cluster, בוחרים את המכונה המשנית ולוחצים על Failover.

  4. בתיבת הדו-שיח שמופיעה, מזינים את מזהה המכונה ולוחצים על Trigger failover.

gcloud

כדי להשתמש ב-CLI של gcloud, אתם יכולים להתקין ולהפעיל את Google Cloud CLI או להשתמש ב-Cloud Shell.

משתמשים בפקודה gcloud alloydb instances failover כדי לאלץ מכונה משנית להעביר את הגיבוי למצב המתנה.

 gcloud alloydb instances failover SECONDARY_INSTANCE_ID \
 --cluster=SECONDARY_CLUSTER_ID \
 --region=REGION_ID \
 --project=PROJECT_ID

מחליפים את מה שכתוב בשדות הבאים:

  • ‫SECONDARY_INSTANCE_ID: המזהה של המכונה המשנית שרוצים להעביר אליה את הגיבוי במקרה של כשל.
  • ‫SECONDARY_CLUSTER_ID: המזהה של האשכול המשני שהמכונה המשנית משויכת אליו.
  • ‫REGION_ID: המזהה של האזור של המכונה המשנית, לדוגמה us-central1.
  • ‫PROJECT_ID: מזהה הפרויקט של האשכול המשני.

המאמרים הבאים