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

הדרישות לגבי המופע הראשי

המכונה הראשית חייבת להיות מכונה של Cloud SQL Enterprise Plus, עם רפליקה ייעודית להתאוששות מאסון.

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

אם אתם יוצרים את מכונת Cloud SQL עם נקודת קצה (endpoint) לכתיבה ב-DNS, למכונה הראשית צריכה להיות אותה הגדרת SSL כמו לרפליקה הייעודית להתאוששות מאסון (DR), לפני שמפעילים את פעולת המעבר או את פעולת יתירות הכשל של הרפליקה. לדוגמה, אם מגדירים את הרפליקה של ה-DR לאכוף הצפנת SSL, אבל המכונה הראשית מאפשרת חיבורים לא מוצפנים, הלקוחות לא יוכלו להתחבר למכונה הראשית החדשה אחרי שהמעבר או יתירות הכשל יושלמו.

דרישות לגבי רפליקות של DR

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

  • המכונה חייבת להיות של Cloud SQL Enterprise Plus
  • חייבת להיות אותה גרסה של מסד הנתונים כמו במכונה הראשית, עם PostgreSQL בגרסה 12 ואילך.

  • חייב להיות באזור שונה מהמכונה הראשית

  • חייבת להיות רפליקה לקריאה ישירה, ולא רפליקה מדורגת

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

    • max_connections
    • max_worker_processes
    • max_wal_senders
    • max_prepared_transactions
    • max_parallel_workers
    • max_locks_per_transaction
    • max_parallel_maintenance_workers
    • max_parallel_workers_per_gather

  • חובה לאחסן ב-Cloud Storage את יומני העסקאות שמשמשים ל-PITR

  • אי אפשר להשתמש ברפליקה חיצונית

המלצות לגבי רפליקות של DR

בקטע הזה מפורטות המלצות לגבי הרפליקה להתאוששות מאסון. ההמלצות הבאות יכולות לעזור לכם להימנע מבעיות בביצועים בפריסה:

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

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

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

המסוף

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

    כניסה לדף Cloud SQL Instances

  2. מוצאים את המופע הראשי.
  3. בעמודה פעולות, לוחצים על התפריט פעולות נוספות.
  4. לוחצים על Create read replica.
  5. בשדה Instance ID, מזינים שם ל-DR replica.
  6. בשדה Database version, הגרסה הראשית של המכונה הראשית נבחרת בשבילכם.
  7. בקטע Choose a region and zonal availability בדף, מבצעים את הפעולות הבאות:
    • בוחרים אזור _שונה_ מהאזור של המכונה הראשית.
    • זה שינוי אופציונלי. בוחרים באפשרות Multiple zones לרפליקה של ה-DR.
    • זה שינוי אופציונלי. בוחרים את Primary ו-Secondary zones לרפליקה של ה-DR.
  8. בקטע Customize your instance בדף, אתם יכולים לעדכן את ההגדרות של הרפליקה להתאוששות מאסון. מידע נוסף על כל הגדרה זמין בדף מידע על הגדרות המכונה.
  9. בשדה Machine shapes, בוחרים את אותו סוג מכונה כמו של המכונה הראשית.
  10. בקטע Flags, מגדירים את הדגלים שנדרשים למסד הנתונים.
  11. לוחצים על Create replica.

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

gcloud

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

gcloud sql instances create REPLICA_NAME \
   --master-instance-name=PRIMARY_INSTANCE_NAME \
   --region=REPLICA_REGION_NAME \
   --database-version=DATABASE_VERSION \
   --tier=MACHINE_TYPE \
   --availability-type=AVAILABILITY_TYPE
   --edition="ENTERPRISE_PLUS"

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

  • ‫REPLICA_NAME: השם של הרפליקה להתאוששות מאסון.
  • ‫PRIMARY_INSTANCE_NAME: השם של המכונה הראשית.
  • ‫REPLICA_REGION_NAME: מציינים אזור שונה מהאזור של המכונה הראשית.
  • ‫DATABASE_VERSION: מציינים את מחרוזת הגרסה שתואמת לגרסה הראשית והמשנית של מסד הנתונים של המכונה הראשית, לדוגמה POSTGRES_16.

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

  • ‫MACHINE_TYPE: מציינים את אותו סוג מכונה כמו במכונה הראשית. מומלץ שסוג המכונה יהיה זהה לסוג המכונה של המכונה הראשית.
  • ‫AVAILABILITY_TYPE: אם המכונה הראשית מוגדרת לזמינות גבוהה, מומלץ לציין את REGIONAL כדי להפעיל זמינות גבוהה.
  • ‫EDITION: צריך לציין ENTERPRISE_PLUS.

Terraform

כדי ליצור רפליקה של DR, משתמשים במשאב של Terraform.

resource "google_sql_database_instance" "original-primary" {
  name   = "postgres-original-primary-instance"
  region = "us-east1"
  # Specify a database version that supports Cloud SQL Enterprise Plus edition.
  database_version = "POSTGRES_12"
  instance_type    = "CLOUD_SQL_INSTANCE"

  settings {
    # Specify a tier that supports Cloud SQL Enterprise Plus edition.
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      # You must enable automated backups and point-in-time-recovery (PITR).
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
}

resource "google_sql_database_instance" "dr-replica" {
  name = "postgres-dr-replica-instance"
  # DR replica must be in a different region than the region of the primary instance.
  region = "us-west2"
  # DR replica must be the same database version as the primary instance.
  database_version = "POSTGRES_12"
  instance_type    = "READ_REPLICA_INSTANCE"
  # Specify the primary instance as the master instance.
  master_instance_name = google_sql_database_instance.original-primary.name

  settings {
    # DR replica must be in the same tier as your primary instance and support Enterprise Plus edition.
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }

  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
}

REST v1

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

  • ‫PRIMARY_INSTANCE_NAME: השם של המכונה הראשית.
  • ‫PROJECT_ID: המזהה או מספר הפרויקט של הפרויקט ב- Google Cloud של המכונה הראשית והרפליקה להתאוששות מאסון.
  • ‫DATABASE_VERSION: מחרוזת גרסה שתואמת לגרסת מסד הנתונים של המכונה הראשית, לדוגמה POSTGRES_16. גרסת מסד הנתונים צריכה להיות זהה גם בראשי וגם ברפליקה של ה-DR.
  • ‫REPLICA_NAME: השם של מכונת הרפליקה להתאוששות מאסון שאתם יוצרים.
  • ‫ REPLICA_REGION: האזור של המכונה של הרפליקה להתאוששות מאסון. האזור של הרפליקה חייב להיות שונה מהאזור של המכונה הראשית.
  • ‫MACHINE_TYPE: מציינים את אותו סוג מכונה כמו במכונה הראשית. מומלץ לבחור את אותו סוג מכונה כמו במכונה הראשית.
  • ‫AVAILABILITY_TYPE: אם המכונה הראשית מוגדרת לזמינות גבוהה, מומלץ לציין את REGIONAL כדי להפעיל זמינות גבוהה.

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

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

תוכן בקשת JSON: 

{
  "masterInstanceName": "PRIMARY_INSTANCE_NAME",
  "project": "PROJECT_ID",
  "databaseVersion": "DATABASE_VERSION",
  "name": "REPLICA_NAME",
  "region": "REPLICA_REGION",
  "settings":
  {
    "tier": "MACHINE_TYPE",
    "availabilityType": "AVAILABILITY_TYPE",
    "settingsVersion": 0,
    "replicationType": "ASYNCHRONOUS",
  }
}

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

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

REST v1beta4

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

  • ‫PRIMARY_INSTANCE_NAME: השם של המכונה הראשית.
  • ‫PROJECT_ID: המזהה או מספר הפרויקט של הפרויקט ב- Google Cloud של המכונה הראשית והרפליקה להתאוששות מאסון.
  • ‫DATABASE_VERSION: מחרוזת גרסה שתואמת לגרסת מסד הנתונים של המכונה הראשית, לדוגמה POSTGRES_16. גרסת מסד הנתונים צריכה להיות זהה גם בראשי וגם ברפליקה של ה-DR.
  • ‫REPLICA_NAME: השם של מכונת הרפליקה להתאוששות מאסון שאתם יוצרים.
  • ‫ REPLICA_REGION: האזור של המכונה של הרפליקה להתאוששות מאסון. האזור של הרפליקה חייב להיות שונה מהאזור של המכונה הראשית.
  • ‫MACHINE_TYPE: מציינים את אותו סוג מכונה כמו במכונה הראשית. מומלץ שגודל הדיסק יהיה זהה לגודל הדיסק של המכונה הראשית.
  • ‫AVAILABILITY_TYPE: אם המכונה הראשית מוגדרת לזמינות גבוהה, מומלץ לציין את REGIONAL כדי להפעיל זמינות גבוהה.

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

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

תוכן בקשת JSON: 

{
  "masterInstanceName": "PRIMARY_INSTANCE_NAME",
  "project": "PROJECT_ID",
  "databaseVersion": "DATABASE_VERSION",
  "name": "REPLICA_NAME",
  "region": "REPLICA_REGION",
  "settings":
  {
    "tier": "MACHINE_TYPE",
    "availabilityType": "AVAILABILITY_TYPE",
    "settingsVersion": 0,
    "replicationType": "ASYNCHRONOUS",
  }
}

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

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

הגדרת הרפליקה של ה-DR למכונה הראשית

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

המסוף

כדי להגדיר רפליקת DR למכונה ראשית:

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

    כניסה לדף Cloud SQL Instances

  2. מוצאים את המכונה הראשית ובוחרים אותה. מופיע הדף Overview של המכונה הראשית.
  3. בתפריט הניווט, לוחצים על רפליקות.
  4. ברשימת הרפליקות לקריאה בלבד, מוצאים את הרפליקה לקריאה בלבד באזורים שונים שרוצים להגדיר כרפליקת DR.
  5. ברפליקה, לוחצים על הלחצן more_vert Actions ובוחרים באפשרות Designate as DR replica.
  6. לוחצים על אישור.

gcloud

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

gcloud sql instances patch PRIMARY_INSTANCE_NAME \
   --failover-dr-replica-name=REPLICA_NAME

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

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

Terraform

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

data "google_project" "default" {
}

resource "google_sql_database_instance" "original-primary" {
  name             = "postgres-original-primary-instance"
  region           = "us-east1"
  database_version = "POSTGRES_12"
  instance_type    = "CLOUD_SQL_INSTANCE"

  replication_cluster {
    # Designate the DR replica.
    # The format for setting the DR replica is `project-id:dr-replica-name`.
    failover_dr_replica_name = "${data.google_project.default.project_id}:postgres-dr-replica-instance"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

resource "google_sql_database_instance" "dr-replica" {
  name                 = "postgres-dr-replica-instance"
  region               = "us-west2"
  database_version     = "POSTGRES_12"
  instance_type        = "READ_REPLICA_INSTANCE"
  master_instance_name = google_sql_database_instance.original-primary.name

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

  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

REST v1

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

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

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

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

תוכן בקשת JSON: 

{
  "replicationCluster": {
     "failoverDrReplicaName": "REPLICA_NAME"
   }
}

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

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

REST v1beta4

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

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

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

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

תוכן בקשת JSON: 

{
  "replicationCluster": {
     "failoverDrReplicaName": "REPLICA_NAME"
   }
}

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

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

שינוי הייעוד של הרפליקה להתאוששות מאסון

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

המסוף

כדי לשנות את רפליקת ה-DR של מכונה ראשית:

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

    כניסה לדף Cloud SQL Instances

  2. מוצאים את המכונה הראשית ובוחרים אותה. מופיע הדף Overview של המכונה הראשית.
  3. בתפריט הניווט, לוחצים על רפליקות.
  4. ברשימת הרפליקות לקריאה בלבד, מוצאים את הרפליקה לקריאה בלבד באזור אחר שרוצים להגדיר כרפליקת ה-DR החדשה.
  5. ברפליקה, לוחצים על הלחצן more_vert Actions ובוחרים באפשרות Designate as DR replica.

gcloud

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

REST

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

הצגת הייעוד של הרפליקה להתאוששות מאסון

כדי לבדוק איזו רפליקת DR מוקצית למכונה הראשית, אתם יכולים להשתמש ב-ה-CLI של gcloud או ב-Cloud SQL Admin API. אפשר גם לבדוק אם רפליקה מסוימת היא רפליקת DR ייעודית.

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

המסוף

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

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

    כניסה לדף Cloud SQL Instances

  2. מוצאים את המכונה הראשית ובוחרים אותה. מופיע הדף Overview של המכונה הראשית.
  3. בתפריט הניווט, לוחצים על רפליקות.
  4. ברשימת הרפליקות לקריאה בלבד, מוודאים שמופיע הערך PostgreSQL disaster recovery replica בעמודה Type של הרפליקה שמיועדת ל-DR.

gcloud

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

gcloud sql instances describe PRIMARY_INSTANCE_NAME

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

  • ‫PRIMARY_INSTANCE_NAME: השם של המכונה הראשית

הפלט של הפקודה הזו מכיל את השדה שנקרא failoverDrReplica, שמזהה את הרפליקה הייעודית להתאוששות מאסון.

REST v1

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

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

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

GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

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

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

REST v1beta4

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

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

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

GET https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

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

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

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

המסוף

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

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

    כניסה לדף Cloud SQL Instances

  2. מאתרים את המכונה של הרפליקה.
  3. מוודאים שהערך PostgreSQL disaster recovery replica מופיע בעמודה Type של הרפליקה המיועדת ל-DR.

gcloud

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

gcloud sql instances describe REPLICA_NAME

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

  • ‫REPLICA_NAME: השם של הרפליקה לקריאה בלבד שרוצים לבדוק

אם הרפליקה היא להתאוששות מאסון, הפלט של הפקודה מכיל את השדה drReplica=true.

REST v1

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

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

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

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

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

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

REST v1beta4

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

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

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

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

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

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

הסרת הרפליקה של ה-DR

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

המסוף

כדי להסיר רפליקה ייעודית ל-DR ממכונה ראשית:

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

    כניסה לדף Cloud SQL Instances

  2. מוצאים את המכונה הראשית ובוחרים אותה. מופיע הדף Overview של המכונה הראשית.
  3. בתפריט הניווט, לוחצים על רפליקות.
  4. ברשימת העותקים לקריאה בלבד, מוצאים את העותק לקריאה בלבד באזורים שונים שרוצים להסיר.
  5. לוחצים על כפתור הפעולות more_vert של הרפליקה ובוחרים באפשרות Remove as DR replica.
  6. לוחצים על אישור.

gcloud

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

gcloud sql instances patch PRIMARY_INSTANCE_NAME \
  --clear-failover-dr-replica-name

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

  • ‫PRIMARY_INSTANCE_NAME: שם המכונה הראשית שממנה רוצים להסיר את הרפליקה הייעודית להתאוששות מאסון

REST v1

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

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

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

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

תוכן בקשת JSON: 

{
  "replicationCluster": {
     "failoverDrReplicaName": ""
   }
}

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

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

REST v1beta4

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

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

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

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

תוכן בקשת JSON: 

{
  "replicationCluster": {
     "failoverDrReplicaName": ""
   }
}

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

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

ביצוע מעבר

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

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

    כניסה לדף Cloud SQL Instances

  2. מאתרים את הרפליקה הייעודית להתאוששות מאסון של המכונה הראשית.
  3. לוחצים על המכונה של הרפליקה להתאוששות מאסון. מופיע הדף Overview של הרפליקה להתאוששות מאסון.
  4. לוחצים על הכפתור Switchover.
  5. בדף Perform switchover between the primary and DR replica, מזינים את שם המכונה הראשית בשדה Instance ID.
  6. לוחצים על Switchover.

gcloud

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

gcloud sql instances switchover REPLICA_NAME
   [--db-timeout=TIMEOUT_DURATION ]

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

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

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

    אפשר להגדיל את ערך הזמן הקצוב לתפוגה באמצעות הפרמטר --db-timeout. מחליפים את TIMEOUT_DURATION בתקופת זמן של עד 24 שעות, כולל סימון ראשוני של הפורמט. לדוגמה, כדי להגדיר 30 שניות, מציינים 30s. כדי לציין 24 שעות, צריך להזין 24h. אפשר גם לציין יחידות חלקיות של תקופת זמן באמצעות מספרים עשרוניים עד 9 ספרות. לדוגמה, כדי לציין 30.5 דקות, מזינים 30.5m.

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

Terraform

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

#
# This sample provides the first part of the switchover operation and turns the DR replica
# into the new primary instance.
data "google_project" "default" {
}

resource "google_sql_database_instance" "original-primary" {
  name             = "postgres-original-primary-instance"
  region           = "us-east1"
  database_version = "POSTGRES_12"
  instance_type    = "CLOUD_SQL_INSTANCE"

  replication_cluster {
    failover_dr_replica_name = "${data.google_project.default.project_id}:postgres-dr-replica-instance"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

resource "google_sql_database_instance" "dr-replica" {
  name             = "postgres-dr-replica-instance"
  region           = "us-west2"
  database_version = "POSTGRES_12"
  # Change the instance type from "READ_REPLICA_INSTANCE" to "CLOUD_SQL_INSTANCE".
  instance_type = "CLOUD_SQL_INSTANCE"
  # Remove or comment out the master_instance_name from the DR replica.
  # master_instance_name = google_sql_database_instance.original-primary.name
  # Add the original primary instance to a list of replicas for the new primary.
  replica_names = [google_sql_database_instance.original-primary.name]

  # Designate the original primary instance as the DR replica of the new primary instance.
  # The format for setting the DR replica is `project-id:dr-replica-name`.
  replication_cluster {
    failover_dr_replica_name = "${data.google_project.default.project_id}:${google_sql_database_instance.original-primary.name}"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      # Add a backup configuration section to enable automated backups and point-in-time-recovery (PITR) for the new primary instance.
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

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

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

# This sample provides the second part of the switchover operation and makes the original primary instance
# a replica of the new primary instance. After you run `terraform apply` for this sample, you'll see
# the following message:
#
# "No changes. Your infrastructure matches the configuration.
#
# Terraform has compared your real infrastructure against your configuration and found no differences,
# so no changes are needed.
#
# Apply complete! Resources: 0 added, 0 changed, 0 destroyed."
data "google_project" "default" {
}

resource "google_sql_database_instance" "original-primary" {
  name             = "postgres-original-primary-instance"
  region           = "us-east1"
  database_version = "POSTGRES_12"
  # Change instance type for the original primary from "CLOUD_SQL_INSTANCE" to "READ_REPLICA_INSTANCE".
  instance_type = "READ_REPLICA_INSTANCE"
  # Set master_instance_name to the the new primary instance, the old DR replica.
  master_instance_name = "postgres-dr-replica-instance"
  # replica_names = [] # If you previously defined a replica_names field in your template, then delete the DR replica
  # (new primary) from the list of replicas.  Don't delete the entire replica_names field.
  # Instead set the field to an empty string. For example, replica_names = [""].

  replication_cluster {
    # This instance no longer requires a designated DR replica since it's a replica.
    # Remove the DR replica designation by setting the field to an empty string.
    failover_dr_replica_name = ""
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      # Disable automated backups and PITR because this instance is now a replica.
      enabled                        = false
      point_in_time_recovery_enabled = false
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

resource "google_sql_database_instance" "dr-replica" {
  name             = "postgres-dr-replica-instance"
  region           = "us-west2"
  database_version = "POSTGRES_12"
  instance_type    = "CLOUD_SQL_INSTANCE"
  replica_names    = [google_sql_database_instance.original-primary.name]


  replication_cluster {
    failover_dr_replica_name = "${data.google_project.default.project_id}:${google_sql_database_instance.original-primary.name}"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

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

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

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

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

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

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

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

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

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

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

המסוף

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

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

    כניסה לדף Cloud SQL Instances

  2. לוחצים על המכונה של הרפליקה להתאוששות מאסון. מופיע הדף Overview של הרפליקה להתאוששות מאסון.
  3. לוחצים על הכפתור Replica Failover.
  4. בדף Perform replica failover between the primary and DR replica, מזינים את שם המכונה הראשית בשדה Instance ID כדי לאשר שרוצים להמשיך בפעולה.
  5. כדי להתחיל את יתירות הכשל של הרפליקה, לוחצים על Replica Failover.

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 של המכונה הראשית החדשה מופיע הערך PostgreSQL VERSION.

    gcloud

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

    gcloud sql instances describe DR_REPLICA_NAME

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

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

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

    instanceType: CLOUD_SQL_INSTANCE

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

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

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

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

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

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

  • המערכת יוצרת גיבוי חדש כדי לתמוך ב-PITR במכונה הראשית החדשה.

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

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

תחילת הכיסוי של PITR

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

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

כיסוי PITR למכונות במהלך מעבר ויתירות כשל של רפליקה

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

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

‫Cloud SQL מפעיל את ה-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 נכשל, צריך לקדם לרפליקה רגילה (לא DR) לקריאה בלבד.

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