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

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

  • יתירות כשל (failover) של רפליקה מאפשרת לכם לעבור מהמכונה הראשית לרפליקת 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, וצריכה להיות לו רפליקה ייעודית של DR.

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

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

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

העתק הקריאה הייעודי לצורך התאוששות מאסון צריך לעמוד בדרישות הבאות:

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

  • חייב להיות באזור נפרד מהמופע הראשי

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

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

    • 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

  • אי אפשר להגדיר את הדגל cloudsql.logical_decoding, ואי אפשר להגדיר משבצות לוגיות או שכפול לוגי

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

  • לא יכול להיות עותק משוכפל חיצוני

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

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

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

יצירת עותק כדי לעמוד בדרישות של עותק לשחזור מאסון

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

המסוף

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

    כניסה לדף Cloud SQL Instances

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

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

gcloud

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

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: השם של העותק המשוכפל של DR.
  • ‫PRIMARY_INSTANCE_NAME: השם של המכונה הראשית.
  • ‫REPLICA_REGION_NAME: מציינים אזור ששונה מהאזור של המכונה הראשית.
  • ‫DATABASE_VERSION: מציינים את מחרוזת הגרסה שתואמת לגרסה הראשית ולגרסה המשנית של מסד הנתונים של המופע הראשי, לדוגמה POSTGRES_16.

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

  • ‫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: המזהה או מספר הפרויקט של Cloud de Confiance הפרויקט של המופע הראשי וההעתק לשחזור מאסון.
  • מחרוזת גרסה DATABASE_VERSION: שתואמת לגרסת מסד הנתונים של המופע הראשי, לדוגמה POSTGRES_16. גרסת מסד הנתונים חייבת להיות זהה גם בשרת הראשי וגם בעותק המשוכפל של DR.
  • ‫REPLICA_NAME: השם של מכונת הרפליקה של DR שאתם יוצרים.
  • ‫ REPLICA_REGION: האזור של מכונת הרפליקה של DR. האזור של העותק חייב להיות שונה מהאזור של המופע הראשי.
  • ‫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: המזהה או מספר הפרויקט של Cloud de Confiance הפרויקט של המופע הראשי וההעתק לשחזור מאסון.
  • מחרוזת גרסה DATABASE_VERSION: שתואמת לגרסת מסד הנתונים של המופע הראשי, לדוגמה POSTGRES_16. גרסת מסד הנתונים חייבת להיות זהה גם בשרת הראשי וגם בעותק המשוכפל של DR.
  • ‫REPLICA_NAME: השם של מכונת הרפליקה של DR שאתם יוצרים.
  • ‫ REPLICA_REGION: האזור של מכונת הרפליקה של DR. האזור של העותק חייב להיות שונה מהאזור של המופע הראשי.
  • ‫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 במסוף Cloud de Confiance .

    כניסה לדף Cloud SQL Instances

  2. מוצאים את המופע הראשי ובוחרים אותו. יופיע הדף סקירה כללית של המופע הראשי.
  3. בתפריט הניווט, לוחצים על Replicas (עותקים).
  4. ברשימת העותקים לקריאה, מוצאים את העותק לקריאה בין אזורים שרוצים להגדיר כעותק לשחזור מאסון.
  5. במקרה של העותק, לוחצים על הלחצן more_vert פעולות ובוחרים באפשרות הגדרת העותק כעותק לשחזור מאסון.
  6. לוחצים על אישור.

gcloud

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

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

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

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

Terraform

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

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

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

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

תוכן בקשת JSON: 

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

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

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

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

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

המסוף

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

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

    כניסה לדף Cloud SQL Instances

  2. מוצאים את המופע הראשי ובוחרים אותו. יופיע הדף סקירה כללית של המופע הראשי.
  3. בתפריט הניווט, לוחצים על Replicas (עותקים).
  4. ברשימת העותקים לקריאה, מוצאים את העותק לקריאה בין-אזורי שרוצים להגדיר כעותק החדש לשחזור מאסון.
  5. במקרה של העותק, לוחצים על הלחצן more_vert פעולות ובוחרים באפשרות הגדרת העותק כעותק לשחזור מאסון.

gcloud

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

REST

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

הצגת הסיווג של העותק לשחזור מאסון

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

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

המסוף

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

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

    כניסה לדף Cloud SQL Instances

  2. מוצאים את המופע הראשי ובוחרים אותו. יופיע הדף סקירה כללית של המופע הראשי.
  3. בתפריט הניווט, לוחצים על Replicas (עותקים).
  4. ברשימת העותקים לקריאה, מוודאים שהסמל PostgreSQL disaster recovery replica מופיע בעמודה Type של העותק הייעודי לשחזור מאסון.

gcloud

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

gcloud sql instances describe PRIMARY_INSTANCE_NAME

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

  • ‫PRIMARY_INSTANCE_NAME: השם של המופע הראשי

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

REST v1

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

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

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

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

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

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

REST v1beta4

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

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

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

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

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

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

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

המסוף

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

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

    כניסה לדף Cloud SQL Instances

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

gcloud

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

gcloud sql instances describe REPLICA_NAME

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

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

אם העותק המשוכפל הוא עותק משוכפל של DR, הפלט של הפקודה יכיל את השדה drReplica=true.

REST v1

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

  • ‫PROJECT_ID: המזהה או מספר הפרויקט של Cloud de Confiance הפרויקט שמכיל את המופע.
  • ‫REPLICA_NAME: השם של העותק המשוכפל.

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

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

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

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

REST v1beta4

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

  • ‫PROJECT_ID: המזהה או מספר הפרויקט של Cloud de Confiance הפרויקט שמכיל את המופע.
  • ‫REPLICA_NAME: השם של העותק המשוכפל.

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

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

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

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

הסרת העותק המשוכפל של DR

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

המסוף

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

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

    כניסה לדף Cloud SQL Instances

  2. מוצאים את המופע הראשי ובוחרים אותו. יופיע הדף סקירה כללית של המופע הראשי.
  3. בתפריט הניווט, לוחצים על Replicas (עותקים).
  4. ברשימת העותקים לקריאה, מוצאים את העותק לקריאה בין אזורים שרוצים להסיר.
  5. במקרה של העתק, לוחצים על הלחצן more_vert Actions ובוחרים באפשרות 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: המזהה או מספר הפרויקט של Cloud de Confiance הפרויקט של המופע הראשי וההעתק לשחזור מאסון.
  • ‫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: המזהה או מספר הפרויקט של Cloud de Confiance הפרויקט של המופע הראשי וההעתק לשחזור מאסון.
  • ‫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 שדומה לזו:

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

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

    כניסה לדף Cloud SQL Instances

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

gcloud

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

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

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

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

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

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

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

Terraform

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

#
# 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.
}

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

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

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

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

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

REST v1beta4

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

  • ‫PROJECT_ID: המזהה או מספר הפרויקט של Cloud de Confiance הפרויקט של המופע הראשי ושל העותק המשוכפל לצורך התאוששות מאסון.
  • ‫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 במופע הראשי החדש כדי שהשירות ימשיך לפעול אחרי פעולות של מעבר לגיבוי בעותק משוכפל.

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

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

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

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

המסוף

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

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

    כניסה לדף Cloud SQL Instances

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

gcloud

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

gcloud sql instances promote-replica \
   REPLICA_NAME --failover

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

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

REST v1

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

  • ‫PROJECT_ID: המזהה או מספר הפרויקט של Cloud de Confiance הפרויקט של המופע הראשי וההעתק לשחזור מאסון.
  • ‫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: המזהה או מספר הפרויקט של Cloud de Confiance הפרויקט של המופע הראשי וההעתק לשחזור מאסון.
  • ‫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 במסוף Cloud de Confiance .

      כניסה לדף Cloud SQL Instances

    2. מאתרים את השם של העותק המשוכפל של DR שקידמתם.
    3. מוודאים ש-PostgreSQL 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

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

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

כיסוי PITR למופעים במהלך מעבר הגיבוי לשחזור ומעבר הגיבוי לשחזור של העתק

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

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

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

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

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

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

פתרון בעיות

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

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