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

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

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

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

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

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

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

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

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

ביצוע מעבר לגיבוי

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

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

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

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

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

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

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

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

  • אם עדיין לא עשיתם זאת, צרו העתק 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.

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

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

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

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

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

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

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

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

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

פתרון בעיות

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

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