יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

‫MySQL | PostgreSQL | SQL Server

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

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

כניסה לדף Cloud SQL Instances
מאתרים את המופע הראשי.
בעמודה פעולות, לוחצים על תפריט פעולות נוספות.
לוחצים על יצירת עותק לקריאה.
בשדה Instance ID (מזהה מופע), מזינים שם לשכפול DR.
בשדה Database version (גרסת מסד הנתונים), הגרסה הראשית של המופע הראשי מסומנת בשבילכם.
בקטע Choose a region and zonal availability בדף, מבצעים את הפעולות הבאות:
- בוחרים אזור _שונה_ מהאזור של המופע הראשי.
- זה שינוי אופציונלי. בוחרים באפשרות אזורים מרובים עבור העותק המשוכפל של DR.
- זה שינוי אופציונלי. בוחרים את האזורים הראשיים והאזורים המשניים עבור העותק המשוכפל של DR.
בקטע Customize your instance (התאמה אישית של המופע) בדף, אפשר לעדכן את ההגדרות של העותק המשוכפל של DR. מידע נוסף על כל הגדרה זמין במאמר מידע על הגדרות של מופע.
בשדה Machine shapes, בוחרים את אותו סוג מכונה כמו המכונה הראשית.
בקטע Flags (דגלים), מגדירים את הדגלים שנדרשים למסד הנתונים.
לוחצים על יצירת העתק.

‫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. גרסת מסד הנתונים צריכה להיות זהה גם בעותק הראשי וגם בעותק הגיבוי.
‫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",
  }
}

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

‫Curl (Linux,‏ macOS או Cloud Shell)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login, או באמצעות Cloud Shell שמחבר אתכם אוטומטית ל-CLI של gcloud. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances"

‎PowerShell (Windows)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances" | Select-Object -Expand Content

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

תשובה

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "CREATE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

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

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

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

‫Curl (Linux,‏ macOS או Cloud Shell)

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances"

‎PowerShell (Windows)

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances" | Select-Object -Expand Content

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

תשובה

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "CREATE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_UD/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

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

המסוף

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

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

כניסה לדף Cloud SQL Instances
מוצאים את המופע הראשי ובוחרים אותו. יופיע הדף סקירה כללית של המופע הראשי.
בתפריט הניווט, לוחצים על Replicas (רפליקות).
ברשימת העותקים לקריאה, מוצאים את העותק לקריאה בין אזורים שרוצים להגדיר כעותק לשחזור מאסון.
במקרה של העותק, לוחצים על הלחצן more_vert פעולות ובוחרים באפשרות הגדרת העותק כעותק לשחזור מאסון.
לוחצים על אישור.

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

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

‫Curl (Linux,‏ macOS או Cloud Shell)

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME"

‎PowerShell (Windows)

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME" | Select-Object -Expand Content

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

תשובה

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T21:30:35.667Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

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

‫Curl (Linux,‏ macOS או Cloud Shell)

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME"

‎PowerShell (Windows)

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME" | Select-Object -Expand Content

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

תשובה

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T21:30:35.667Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

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

המסוף

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

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

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

gcloud

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

REST

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

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

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

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

המסוף

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

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

כניסה לדף Cloud SQL Instances
מוצאים את המופע הראשי ובוחרים אותו. יופיע הדף סקירה כללית של המופע הראשי.
בתפריט הניווט, לוחצים על Replicas (רפליקות).
ברשימת העותקים לקריאה, מוודאים שהסמל 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

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

‫Curl (Linux,‏ macOS או Cloud Shell)

מריצים את הפקודה הבאה:

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME"

‎PowerShell (Windows)

מריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method GET `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME" | Select-Object -Expand Content

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

תשובה

{
  "kind": "sql#instance",
  "state": "RUNNABLE",
  "databaseVersion": "POSTGRES_16",
  "settings": {
  . . .
  "replicaNames": [
    "my-instance-replica"
  ],
  "ipAddresses": [
    {
      "type": "PRIMARY",
      "ipAddress": "192.5.4.1"
    }
  ],
  "instanceType": "CLOUD_SQL_INSTANCE",
   . . .
  "connectionName": "my-project:us-east1:my-instance",
  "name": "my-instance",
  "region": "us-east1",
  "gceZone": "us-east1-c",
  "secondaryGceZone": "us-east1-b",
  "databaseInstalledVersion": "POSTGRES_16",
  "maintenanceVersion": "POSTGRES_16_3.R20240205.00_07",
  "replicationCluster" {
       "failoverDrReplicaName": "my-project:my-instance-replica"
   },
  "createTime": "2024-03-15T18:11:03.596Z",
  "sqlNetworkArchitecture": "NEW_NETWORK_ARCHITECTURE"
}
}

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

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

‫Curl (Linux,‏ macOS או Cloud Shell)

מריצים את הפקודה הבאה:

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME"

‎PowerShell (Windows)

מריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method GET `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME" | Select-Object -Expand Content

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

תשובה

{
  "kind": "sql#instance",
  "state": "RUNNABLE",
  "databaseVersion": "POSTGRES_16",
  "settings": {
  . . .
  "replicaNames": [
    "my-instance-replica"
  ],
  "ipAddresses": [
    {
      "type": "PRIMARY",
      "ipAddress": "192.5.4.1"
    }
  ],
  "instanceType": "CLOUD_SQL_INSTANCE",
   . . .
  "connectionName": "my-project:us-east1:my-instance",
  "name": "my-instance",
  "region": "us-east1",
  "gceZone": "us-east1-c",
  "secondaryGceZone": "us-east1-b",
  "databaseInstalledVersion": "POSTGRES_16",
  "maintenanceVersion": "POSTGRES_16_3.R20240205.00_07",
  "replicationCluster" {
       "failoverDrReplicaName": "my-project:my-instance-replica"
   },
  "createTime": "2024-03-15T18:11:03.596Z",
  "sqlNetworkArchitecture": "NEW_NETWORK_ARCHITECTURE"
}
}

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

המסוף

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

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

כניסה לדף Cloud SQL Instances
מאתרים את מופע הרפליקה.
מוודאים שהסמל 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

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

‫Curl (Linux,‏ macOS או Cloud Shell)

מריצים את הפקודה הבאה:

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME"

‎PowerShell (Windows)

מריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method GET `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME" | Select-Object -Expand Content

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

תשובה

{
  "kind": "sql#instance",
  "state": "RUNNABLE",
  "databaseVersion": "POSTGRES_16",
  "settings": {
    "authorizedGaeApplications": [],
    "tier": "db-perf-optimized-N-8",
    "kind": "sql#settings",
    "availabilityType": "REGIONAL",
    "pricingPlan": "PER_USE",
    "replicationType": "SYNCHRONOUS",
    . . .
    },
  "masterInstanceName": "my-project:my-instance",
  "ipAddresses": [
    {
      "type": "PRIMARY",
      "ipAddress": "192.3.2.1"
    }
  ],
  . . .
  "instanceType": "READ_REPLICA_INSTANCE",
  . . .
"connectionName": "my-project:us-east4:my-instance-replica",
  "name": "my-instance-replica",
  "region": "us-east4",
  "gceZone": "us-east4-b",
  "secondaryGceZone": "us-east4-c",
  "databaseInstalledVersion": "POSTGRES_16",
  "maintenanceVersion": "POSTGRES_16_3.R20240205.00_07",
  "replicationCluster" {
       "drReplica": true
  },
  "createTime": "2024-03-15T18:17:44.655Z",
  "sqlNetworkArchitecture": "NEW_NETWORK_ARCHITECTURE"
}

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

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

‫Curl (Linux,‏ macOS או Cloud Shell)

מריצים את הפקודה הבאה:

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME"

‎PowerShell (Windows)

מריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method GET `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME" | Select-Object -Expand Content

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

תשובה

{
  "kind": "sql#instance",
  "state": "RUNNABLE",
  "databaseVersion": "POSTGRES_16",
  "settings": {
    "authorizedGaeApplications": [],
    "tier": "db-perf-optimized-N-8",
    "kind": "sql#settings",
    "availabilityType": "REGIONAL",
    "pricingPlan": "PER_USE",
    "replicationType": "SYNCHRONOUS",
    . . .
    },
  "masterInstanceName": "my-project:my-instance",
  "ipAddresses": [
    {
      "type": "PRIMARY",
      "ipAddress": "192.3.2.1"
    }
  ],
  . . .
  "instanceType": "READ_REPLICA_INSTANCE",
  . . .
"connectionName": "my-project:us-east4:my-instance-replica",
  "name": "my-instance-replica",
  "region": "us-east4",
  "gceZone": "us-east4-b",
  "secondaryGceZone": "us-east4-c",
  "databaseInstalledVersion": "POSTGRES_16",
  "maintenanceVersion": "POSTGRES_16_3.R20240205.00_07",
  "replicationCluster" {
       "drReplica": true
  },
  "createTime": "2024-03-15T18:17:44.655Z",
  "sqlNetworkArchitecture": "NEW_NETWORK_ARCHITECTURE"
}

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

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

המסוף

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

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

כניסה לדף Cloud SQL Instances
מוצאים את המופע הראשי ובוחרים אותו. יופיע הדף סקירה כללית של המופע הראשי.
בתפריט הניווט, לוחצים על Replicas (רפליקות).
ברשימת העותקים לקריאה, מוצאים את העותק לקריאה בין אזורים שרוצים להסיר.
במקרה של העותק, לוחצים על הלחצן more_vert Actions ובוחרים באפשרות Remove as DR replica.
לוחצים על אישור.

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

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

‫Curl (Linux,‏ macOS או Cloud Shell)

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME"

‎PowerShell (Windows)

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME" | Select-Object -Expand Content

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

תשובה

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T21:30:35.667Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

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

‫Curl (Linux,‏ macOS או Cloud Shell)

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME"

‎PowerShell (Windows)

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME" | Select-Object -Expand Content

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

תשובה

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T21:30:35.667Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

ביצוע מעבר

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

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

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

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

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

‫Curl (Linux,‏ macOS או Cloud Shell)

מריצים את הפקודה הבאה:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover"

‎PowerShell (Windows)

מריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover" | Select-Object -Expand Content

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

תשובה

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "SWITCHOVER",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

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

‫Curl (Linux,‏ macOS או Cloud Shell)

מריצים את הפקודה הבאה:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover"

‎PowerShell (Windows)

מריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover" | Select-Object -Expand Content

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

תשובה

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "SWITCHOVER",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

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

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

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

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

‫Curl (Linux,‏ macOS או Cloud Shell)

מריצים את הפקודה הבאה:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER"

‎PowerShell (Windows)

מריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER" | Select-Object -Expand Content

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

תשובה

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

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

‫Curl (Linux,‏ macOS או Cloud Shell)

מריצים את הפקודה הבאה:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER"

‎PowerShell (Windows)

מריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER" | Select-Object -Expand Content

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

תשובה

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_NAME",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

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

כדי לבדוק את הסטטוס של יתירות כשל של רפליקה, בודקים את הסטטוס של כל שלב.

בודקים את הסטטוס של השלב הראשון.
המסוף

כדי לבדוק אם העותק המשוכפל של 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
```
כדי לוודא שהשלב השני הסתיים, בודקים את יומן הפעולות במופע ומחפשים את ההודעה RECONFIGURE_OLD_PRIMARY.

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

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

שימוש ב-PITR עם DR מתקדם

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

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

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

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

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

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

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

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

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

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

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

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

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

מחיקה של גיבויים ויומני טרנזקציות בעותקים משוכפלים

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

פתרון בעיות

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