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

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

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

‫DR מתקדם נתמך רק במכונות של מהדורת Cloud SQL Enterprise Plus.

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

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

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

יצירת עותק משוכפל לצורך התאוששות מאסון

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

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

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

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

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

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

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

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

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

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

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

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

gcloud

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

gcloud sql instances promote-replica \
   REPLICA_NAME --failover

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

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

REST v1

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

  • PROJECT_ID: המזהה או מספר הפרויקט של הפרויקט Google Cloud של המופע הראשי והעתק של DR.
  • 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 של המופע הראשי והעתק של DR.
  • 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) של רפליקה

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

לדוגמה, אם המופע מוגדר לגיבויים אוטומטיים יומיים ולשמירת 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.

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

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

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

פתרון בעיות

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

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