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

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

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

ביצוע מעבר לגיבוי (failover)

אחרי שיוצרים העתק DR, אפשר לבצע את פעולת המעבר לגיבוי. עם זאת, מומלץ להימנע מביצוע פעולת המעבר בנסיבות הבאות:

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

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

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

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

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

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

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

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

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

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

gcloud

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

gcloud sql instances switchover REPLICA_NAME

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

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

Terraform

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

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"
  }
}

אחרי שמבצעים את השינויים, מעדכנים את העותק הראשי ואת העותק לשחזור מאסון על ידי הפעלת הפקודה terraform plan. מוודאים שהפלט כולל את השורה Plan: 0 to add, 1 to change, 0 to destroy. כדי לבצע את המעבר, מריצים את 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: השם של העותק המשוכפל של DR.

ה-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: השם של העותק המשוכפל של DR.

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

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

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

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

ביצוע DR על ידי הפעלת מעבר לגיבוי (failover) של העותק

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

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

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

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

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

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

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

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

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

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

ביצוע פעולת מעבר לגיבוי (failover) של העותק

gcloud

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

gcloud sql instances promote-replica \
   REPLICA_NAME --failover

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

  • ‫REPLICA_NAME: השם של העותק המשוכפל של ה-DR

REST v1

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

  • ‫PROJECT_ID: המזהה או מספר הפרויקט של Google Cloud הפרויקט של המופע הראשי וההעתק לשחזור מאסון.
  • ‫REPLICA_NAME: השם של העותק המשוכפל של DR.
  • ‫ENABLE_REPLICA_FAILOVER: אם הערך הוא true, נעשה שימוש במעבר אוטומטי לגיבוי. אם מגדירים את הערך false, ה-API משתמש בשיטה הרגילה 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: השם של העותק המשוכפל של DR.
  • ‫ENABLE_REPLICA_FAILOVER: אם הערך הוא true, נעשה שימוש במעבר אוטומטי לגיבוי. אם מגדירים את הערך false, ה-API משתמש בשיטה הרגילה promoteReplica בלי מעבר לגיבוי בעותק.

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

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

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

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

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

המעבר לגיבוי מתבצע בשני שלבים. השלב הראשון הוא קידום של העותק המשוכפל של 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 מתקדם

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

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

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

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

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

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

מחיקה של גיבויים ויומני עסקאות בעותקים משוכפלים

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

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

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

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

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

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

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

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

מגבלות

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

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

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

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

פתרון בעיות

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

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