שימוש בתוכנית התאוששות מאסון (DR) מתקדמת

בדף הזה מוסבר איך משתמשים בתוכנית התאוששות מאסון (DR) מתקדמת. התכונה "התאוששות מאסון מתקדמת" מספקת שתי יכולות עיקריות:

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

התכונה "התאוששות מתקדמת מאסון" נתמכת רק במכונות של Cloud SQL Enterprise Plus.

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

אם אתם מתכוונים להשתמש ב-Google Cloud SDK, אתם צריכים להשתמש בגרסה 502.0.0 ואילך. כדי לבדוק את הגרסה של Google Cloud SDK, מריצים את הפקודה gcloud --version. כדי לעדכן את Google Cloud SDK, מריצים את הפקודה gcloud components update.

כדי להתקין את Google Cloud SDK, קראו את המאמר התקנת ה-CLI של gcloud.

יצירת רפליקה של DR

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

ביצוע מעבר

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

  • המופע הראשי נמצא בשימוש פעיל.
  • מתבצעות פעולות ניהול, כמו גיבוי אוטומטי או הפעלה או השבתה של זמינות גבוהה (HA).

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

כשהמעבר מסתיים, הפעולה יוצרת גיבוי של המכונה הראשית החדשה (הרפליקה הקודמת של ה-DR) ברגע שהמכונה הראשית החדשה מקודמת. הגיבוי יכול להימשך בין 5 ל-15 דקות, בהתאם לגודל הדיסק. אחרי שהגיבוי מסתיים, אם רוצים להשתמש ב-PITR במכונה שקודמה, צריך להפעיל את PITR באופן ידני. למידע נוסף על השיקולים לשימוש ב-PITR עם התאוששות מתקדמת מאסון, ראו שימוש ב-PITR עם התאוששות מתקדמת מאסון.

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

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

אם מגדירים קישוריות יוצאת של Private Service Connect ברפליקה של תוכנית התאוששות מאסון (DR), אחרי פעולת המעבר, כשהרפליקה של ה-DR מקודמת למכונה הראשית, הקישוריות היוצאת ממשיכה לפעול במכונה הראשית החדשה שנוצרה. אם לא מגדירים קישוריות יוצאת ברפליקה של תוכנית התאוששות מאסון (DR), כדי שהשירות ימשיך לפעול אחרי פעולות המעבר, צריך להפעיל קישוריות יוצאת של Private Service Connect במכונה הראשית החדשה.

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

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

  • אם עדיין לא עשיתם את זה, צרו רפליקה של DR.
  • משתמשים בפרוצדורה המאוחסנת sp_help_revlogin כדי להעביר את כל פרטי הכניסה ל-SQL Server שנוצרו במכונה הראשית אחרי שנוצרה הרפליקה של ה-DR. סנכרון פרטי הכניסה מבטיח שהאפליקציות יוכלו להתחבר מחדש מיד אחרי שפעולת המעבר מסתיימת.
  • מוודאים שהמכונה הראשית והרפליקה של ה-DR מחוברות לאינטרנט.
  • אם אתם משתמשים בנקודת קצה לכתיבה ב-DNS, ודאו שהגדרת ה-SSL של המכונה הראשית ושל הרפליקה להתאוששות מאסון זהה. לדוגמה, אם הרפליקה של ה-DR מוגדרת לאכוף הצפנת SSL, אבל המכונה הראשית מאפשרת חיבורים לא מוצפנים, הלקוחות לא יוכלו להתחבר למכונה הראשית החדשה אחרי השלמת פעולת המעבר.
  • מבצעים גיבוי לפי דרישה של המכונה הראשית. הגיבוי הזה הוא אמצעי זהירות למקרה שתצטרכו לשחזר את הנתונים בגלל כשלים בלתי צפויים.

ביצוע פעולת המעבר

gcloud

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

gcloud sql instances switchover REPLICA_NAME

מחליפים את המשתנים הבאים:

  • ‫REPLICA_NAME: השם של רפליקת ה-DR שרוצים להחליף את התפקיד שלה עם המכונה הראשית.

Terraform

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

resource "google_sql_database_instance" "original-primary" {
  name             = "sqlserver-primary-instance-name"
  region           = "us-east1"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  instance_type    = "CLOUD_SQL_INSTANCE"
  root_password    = "INSERT-PASSWORD-HERE"
  replica_names    = ["sqlserver-replica-instance-name"]
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled = "true"
    }
  }
}

resource "google_sql_database_instance" "dr_replica" {
  name = "sqlserver-replica-instance-name"
  # Remove or comment out the master_instance_name
  # master_instance_name = google_sql_database_instance.original-primary.name
  region           = "us-west2"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "READ_REPLICA_INSTANCE" to "CLOUD_SQL_INSTANCE".
  instance_type = "CLOUD_SQL_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Add the original primary to the replica_names list
  replica_names = ["sqlserver-primary-instance-name"]
  # Remove or comment out the replica_configuration section
  # replica_configuration {
  #  cascadable_replica = true
  # }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }
}

אחרי שמבצעים את השינויים, מעדכנים את הרפליקה הראשית ואת רפליקת ה-DR באמצעות הפעלת terraform plan. מוודאים שהפלט כולל את השורה Plan: 0 to add, 1 to change, 0 to destroy. To perform the switchover, run terraform apply.

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

resource "google_sql_database_instance" "original-primary" {
  name = "sqlserver-primary-instance-name"
  # Set master_instance_name to the new primary instance, the original DR replica.
  master_instance_name = "sqlserver-replica-instance-name"
  region               = "us-east1"
  database_version     = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "CLOUD_SQL_INSTANCE" to "READ_REPLICA_INSTANCE".
  instance_type = "READ_REPLICA_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Remove  values from the replica_names field, but don't remove the field itself.
  replica_names = []
  # Add replica_configuration section and set cascadable_replica to true.
  replica_configuration {
    cascadable_replica = true
  }
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled = "true"
    }
  }
}

resource "google_sql_database_instance" "dr_replica" {
  name             = "sqlserver-replica-instance-name"
  region           = "us-west2"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "READ_REPLICA_INSTANCE" to "CLOUD_SQL_INSTANCE".
  instance_type = "CLOUD_SQL_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Add the original primary to the replica_names list
  replica_names = ["sqlserver-primary-instance-name"]
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }
}

אם מצב Terraform מתעדכן בהצלחה, כשמריצים את terraform plan מול הדוגמה השנייה, מופיעה הודעה דומה לזו:

No changes. Your infrastructure matches the configuration.

אם מריצים את הפקודה terraform apply, מקבלים הודעה שדומה לזו:

Resources: 0 added, 0 changed, 0 destroyed.

REST v1

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

  • ‫PROJECT_ID: המזהה או מספר הפרויקט של הפרויקט ב- Google Cloud של המכונה הראשית והרפליקה להתאוששות מאסון.
  • ‫REPLICA_NAME: השם של הרפליקה להתאוששות מאסון.

ה-method של ה-HTTP וכתובת ה-URL: 

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

אתם אמורים לקבל תגובת JSON שדומה לזו:

REST v1beta4

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

  • ‫PROJECT_ID: המזהה או מספר הפרויקט של הפרויקט ב- Google Cloud של המכונה הראשית והרפליקה להתאוששות מאסון.
  • ‫REPLICA_NAME: השם של הרפליקה להתאוששות מאסון.

ה-method של ה-HTTP וכתובת ה-URL: 

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

אתם אמורים לקבל תגובת JSON שדומה לזו:

ביצוע DR באמצעות הפעלת יתירות כשל של רפליקה

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

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

כחלק מתהליך העלאה בדרגה, יתירות כשל של רפליקה יוצרת גיבוי של המכונה הראשית החדשה (הרפליקה הקודמת של ה-DR) מיד אחרי שהרפליקה של ה-DR הופכת למכונה הראשית החדשה. אחרי שהגיבוי מסתיים, התכונה "שחזור מערכת מנקודה מסוימת בזמן (PITR)" מופעלת באופן מלא במכונה הראשית החדשה. הגיבוי יכול להימשך בין 5 ל-15 דקות, בהתאם לגודל הדיסק של המכונה הראשית החדשה (והישנה). במהלך תקופת הגיבוי הזו, אי אפשר להשתמש ב-PITR.

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

למידע נוסף על השיקולים לשימוש ב-PITR עם התאוששות מאסון מתקדמת, ראו שימוש ב-PITR עם התאוששות מאסון מתקדמת.

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

אם מגדירים קישוריות יוצאת של Private Service Connect ברפליקה של תוכנית התאוששות מאסון (DR), אחרי פעולות של יתירות כשל ברפליקה, כשהרפליקה של ה-DR מקודמת למכונה הראשית, הקישוריות היוצאת ממשיכה לפעול במכונה הראשית החדשה שנוצרה. אם לא מגדירים קישוריות יוצאת ברפליקה של תוכנית התאוששות מאסון (DR), כדי שהשירות ימשיך לפעול אחרי פעולות של יתירות כשל ברפליקה, צריך להפעיל את הקישוריות היוצאת של Private Service Connect במכונה הראשית החדשה.

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

לפני שתוכלו לבצע מעבר לגיבוי בעת כשל של רפליקה, צריך לבצע את הפעולות הבאות:

  • אם עדיין לא עשיתם זאת, צרו רפליקה של DR.
  • אם עדיין אפשר לגשת למכונה הראשית, משתמשים בפרוצדורה המאוחסנת sp_help_revlogin כדי להעביר את פרטי ההתחברות הלא מסונכרנים של SQL Server לרפליקה של ה-DR. סנכרון שגרתי של פרטי ההתחברות מבטיח שהאפליקציות יוכלו להתחבר מחדש מיד אחרי יתירות כשל.
  • מוודאים שהרפליקה של ה-DR מחוברת לאינטרנט ופועלת בצורה תקינה.

ביצוע פעולת יתירות כשל של הרפליקה

gcloud

כדי להפעיל מעבר של רפליקה לגיבוי במקרה של כשל לרפליקה של התאוששות מאסון, משתמשים בפקודה הבאה:

gcloud sql instances promote-replica \
   REPLICA_NAME --failover

מחליפים את המשתנה הבא:

  • ‫REPLICA_NAME: השם של הרפליקה להתאוששות מאסון

REST v1

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

  • ‫PROJECT_ID: המזהה או מספר הפרויקט של הפרויקט ב- Google Cloud של המכונה הראשית והרפליקה להתאוששות מאסון.
  • ‫REPLICA_NAME: השם של הרפליקה להתאוששות מאסון.
  • ‫ENABLE_REPLICA_FAILOVER: צריך להגדיר את הערך true כדי להשתמש ביתירות כשל של רפליקה. אם מגדירים את הערך false, ה-API משתמש ב-method הרגילה promoteReplica בלי יתירות כשל של רפליקה.

ה-method של ה-HTTP וכתובת ה-URL: 

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

אתם אמורים לקבל תגובת JSON שדומה לזו:

REST v1beta4

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

  • ‫PROJECT_ID: המזהה או מספר הפרויקט של הפרויקט ב- Google Cloud של המכונה הראשית והרפליקה להתאוששות מאסון.
  • ‫REPLICA_NAME: השם של הרפליקה להתאוששות מאסון.
  • ‫ENABLE_REPLICA_FAILOVER: צריך להגדיר את הערך true כדי להשתמש ביתירות כשל של רפליקה. אם מגדירים את הערך false, ה-API משתמש ב-method הרגילה promoteReplica בלי יתירות כשל של רפליקה.

ה-method של ה-HTTP וכתובת ה-URL: 

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

אתם אמורים לקבל תגובת JSON שדומה לזו:

בדיקת הסטטוס של מעבר לגיבוי בעת כשל של רפליקה

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

כדי לבדוק את הסטטוס של יתירות כשל ברפליקה, בודקים את הסטטוס של כל שלב.

  1. בודקים את הסטטוס של השלב הראשון.

    המסוף

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

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

      כניסה לדף Cloud SQL Instances

    2. מוצאים את השם של הרפליקה ל-DR שקידמתם.
    3. מוודאים ש- SQL Server VERSION מופיע בעמודה Type של המכונה הראשית החדשה.

    gcloud

    כדי לבדוק את הסטטוס, מריצים את הפקודה הבאה:

    gcloud sql instances describe DR_REPLICA_NAME

    מחליפים את המשתנה הבא:

    • ‫DR_REPLICA_NAME: השם של הרפליקה של ה-DR שקודמה

    בפלט, בודקים שהשדה הבא מופיע ושהרפליקה הפכה למכונה ראשית עצמאית ב-Cloud SQL:

    instanceType: CLOUD_SQL_INSTANCE

  2. כדי לוודא שהשלב השני הסתיים, בודקים אם ההודעה RECONFIGURE_OLD_PRIMARY מופיעה ביומן הפעולות של המכונה.

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

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

שימוש ב-PITR עם התאוששות מאסון מתקדמת

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

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

מידע נוסף זמין במאמר שימוש ב-PITR.

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

פיצול מוח במהלך מעבר לגיבוי בעת כשל של רפליקה

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

מחיקת גיבויים ויומני עסקאות ברפליקות

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

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

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

המלצות ל-VPC Service Controls ול-DR מתקדם

אם אתם משתמשים ב-VPC Service Controls, ודאו שגבולות הגזרה לשירות מאפשרים את התקשורת הנדרשת לכל פעולות השחזור, כמו פעולות שחזור מנקודה מסוימת בזמן (PITR), במיוחד כשאתם משתמשים ב-CMEK עם מפתחות בפרויקט אחר.

פעולות מתקדמות של התאוששות מאסון, כמו מעבר בין שרתים ויתירות כשל של רפליקה, יכולות להפעיל או להגדיר מחדש תכונות כמו PITR. אם גבולות הגזרה לשירות לא מוגדרים בצורה נכונה ל-CMEK ולגישה למפתחות בין פרויקטים, יכול להיות ש-VPC Service Controls יחסום את הפעולות האלה.

  • השארת הפרויקט של מפתח ה-KMS באותו היקף של המכונה: כשיטה מומלצת, כדאי לכלול את הפרויקט שמכיל את מפתח ה-KMS באותו היקף של VPC Service Controls כמו המכונות של Cloud SQL.
  • שימוש בגבולות גזרה מגושרים: כאפשרות משנית (פחות מומלצת), אתם יכולים להשתמש בגבולות גזרה מגושרים כדי לחבר פרויקטים בגבולות גזרה שונים.
  • בדיקה: משתמשים במצב פרימטר לבדיקות של VPC Service Controls כדי לבדוק את תהליכי ה-DR (כמו מעבר למערכת הגיבוי) ולזהות הפרות פוטנציאליות של VPC Service Controls בלי אכיפה.

מידע נוסף זמין במאמר הגדרת VPC Service Controls.

מגבלות

  • אי אפשר להגדיר מכונה של רפליקה לקריאה בלבד של Cloud SQL Enterprise Plus כרפליקה להתאוששות מאסון, אם המכונה הראשית מאחסנת את יומני העסקאות שלה לשחזור מערכת מנקודה מסוימת בזמן (PITR) בדיסק. כדי לבדוק איפה מאוחסנים היומנים של המכונה ל-PITR, קראו את המאמר בדיקת מיקום האחסון של יומני הטרנזקציות שמשמשים ל-PITR.

  • אי אפשר להגדיר רפליקה חיצונית כרפליקה של DR.

  • אי אפשר להשתמש ב-Terraform לפעולות של יתירות כשל ברפליקות.

  • אי אפשר להשתמש במסוף Google Cloud כדי לבצע פעולות של מעבר לגיבוי בעת כשל או החלפה של רפליקה.

פתרון בעיות

שגיאה פתרון בעיות
פעולת המעבר נכשלה.
    מוודאים שהמכונה עומדת בכל הדרישות של רפליקת DR (רפליקה מדורגת).
  • בודקים את נפח העסקאות במסד הנתונים. אם נפח העסקאות גבוה, יכול להיות שהפעולה תסתיים בגלל זמן קצוב לתפוגה. כדאי לנסות שוב את הפעולה כשהעומס על הטרנזקציות נמוך יותר.
פעולת המעבר נכשלה והמכונה הראשית תקועה במצב קריאה בלבד. מפעילים מחדש את מסד הנתונים כדי להחזיר את המכונה הראשית למצב כתיבה.
פעולת המעבר הושלמה, אבל במסוף Google Cloud לא מוצגים התפקידים ההפוכים החדשים של המכונות. מרעננים את הדפדפן כדי להציג את הטופולוגיה המעודכנת.
פעולת יתירות הכשל של הרפליקה נכשלה.
  • מוודאים שיצרתם רפליקת DR למכונה הראשית ושהרפליקה אונליין.
  • אם מעבר לגיבוי בעת כשל לרפליקה של DR נכשל, צריך לקדם לרפליקה רגילה (לא DR) לקריאה בלבד.

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