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

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

  • יתירות כשל של רפליקה מאפשרת לכם להעביר את המכונה הראשית לרפליקת ה-DR באופן מיידי במקרה של כשל באזור. ב-Cloud SQL ל-SQL Server, הרפליקה של ה-DR היא רפליקה מדורגת.
  • מעבר מאפשר להפוך את התפקידים של המכונה הראשית ושל הרפליקה של ה-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 מחוברות לאינטרנט.
  • אם אתם משתמשים בנקודת קצה (endpoint) לכתיבה ב-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 שדומה לזו:

התנהגות משופרת של הגיבוי במהלך המעבר

אם המכונה הראשית משתמשת בגיבויים משופרים (שירות Backup and DR), השיוך של תוכנית הגיבוי נשאר ללא שינוי בפעולות המעבר הבאות:

  • המכונה שקודמה (המכונה הראשית החדשה): כשמקַדמים את הרפליקה הקודמת של ה-DR, היא עוברת למצב של גיבוי פעיל. ‫Cloud SQL מפעיל גיבוי תפעולי ראשוני של Backup and DR. בנוסף, מתחילה העלאת יומן של שחזור מערכת מנקודה מסוימת בזמן (PITR), והגיבויים המתוזמנים ממשיכים לפי תוכנית הגיבוי המשויכת.
  • מכונה שהורדה בדרגה (המכונה הראשית הקודמת): כשמורידים בדרגה את המכונה הראשית הקודמת לתפקיד של רפליקה, השיוך שלה לתוכנית הגיבוי עובר באופן אוטומטי למצב השהיה. בזמן שהשיוך מושהה, מתרחשות הפעולות הבאות:
    • כדי למנוע שגיאות של גיבויים שנכשלו במכונות של רפליקות, Cloud SQL מדלג באופן אוטומטי על גיבויים מתוזמנים.
    • ‫Cloud SQL חוסם גיבויים על פי דרישה.
    • אתם לא מחויבים על ניהול הגיבוי, אבל אתם ממשיכים לצבור חיובים על אחסון של גיבויים קיימים שמאוחסנים בכספת הגיבוי.
  • חזרה למצב תקין: אם משחזרים את המכונה הראשית המקורית ומקדמים אותה בחזרה לתפקיד הראשי, תוכנית הגיבוי שלה מחדשת באופן אוטומטי את ההגנה הפעילה, והגיבויים המתוזמנים ממשיכים לפעול בכספת הגיבוי.

ביצוע 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. מוודאים שבעמודה Type של המכונה הראשית החדשה מופיע הערך SQL Server VERSION.

    gcloud

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

    gcloud sql instances describe DR_REPLICA_NAME

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

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

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

    instanceType: CLOUD_SQL_INSTANCE

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

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

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

שימוש ב-PITR עם DR מתקדם

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

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

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

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

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

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

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

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

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

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

התנהגות משופרת של הגיבוי במהלך יתירות כשל

אם במכונה הראשית משתמשים בגיבויים משופרים (Backup and DR), השיוך של תוכנית הגיבוי נשאר ללא שינוי בפעולות של מעבר לעותק חלופי במקרה כשל:

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

המלצות ל-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) לקריאה בלבד.

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