שימוש בפתרון מתקדם להתאוששות מאסון (DR)

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

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

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

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

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

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

הגדרת רפליקה של DR

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

הדרישות לגבי המכונה הראשית

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

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

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

הדרישות לגבי העתק DR

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

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

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

המסוף

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

    כניסה לדף 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

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

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

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

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

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

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

תוכן בקשת JSON: 

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

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

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

REST v1beta4

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

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

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

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

תוכן בקשת JSON: 

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

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

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

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

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

המסוף

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

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

    כניסה לדף Cloud SQL Instances

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

המסוף

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

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

    כניסה לדף Cloud SQL Instances

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

gcloud

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

REST

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

הצגת סיווג רפליקת DR

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

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

המסוף

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

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

    כניסה לדף 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: המזהה או מספר הפרויקט של Google Cloud הפרויקט שמכיל את המכונה.
  • ‫PRIMARY_INSTANCE_NAME: השם של המכונה הראשית.

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

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

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

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

REST v1beta4

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

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

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

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

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

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

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

המסוף

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

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

    כניסה לדף 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: המזהה או מספר הפרויקט של Google Cloud הפרויקט שמכיל את המופע.
  • ‫REPLICA_NAME: השם של הרפליקה.

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

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

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

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

REST v1beta4

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

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

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

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

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

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

הסרת רפליקת DR

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

המסוף

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

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

    כניסה לדף Cloud SQL Instances

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

gcloud

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

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

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

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

REST v1

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

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

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

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

תוכן בקשת JSON: 

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

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

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

REST v1beta4

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

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

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

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

תוכן בקשת JSON: 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

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

    כניסה לדף Cloud SQL Instances

  2. מאתרים את רפליקת ה-DR המוגדרת של המופע הראשי.
  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: השם של רפליקת ה-DR המיועדת שרוצים שהמופע הראשי יחליף איתה תפקידים.
  • ‫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: המזהה או מספר הפרויקט של Google Cloud הפרויקט של המופע הראשי ושל העותק המשוכפל לצורך התאוששות מאסון.
  • ‫REPLICA_NAME: השם של רפליקת DR.

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

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

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

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

REST v1beta4

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

  • ‫PROJECT_ID: המזהה או מספר הפרויקט של Google Cloud הפרויקט של המופע הראשי ושל העותק המשוכפל לצורך התאוששות מאסון.
  • ‫REPLICA_NAME: השם של רפליקת DR.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

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

    כניסה לדף Cloud SQL Instances

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

gcloud

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

gcloud sql instances promote-replica \
   REPLICA_NAME --failover

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

  • ‫REPLICA_NAME: השם של הרפליקה של DR

REST v1

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

  • ‫PROJECT_ID: המזהה או מספר הפרויקט של Google Cloud הפרויקט של המופע הראשי וההעתק לשחזור מאסון.
  • ‫REPLICA_NAME: השם של רפליקת DR.
  • ‫ENABLE_REPLICA_FAILOVER: צריך להגדיר את הערך true כדי להשתמש במעבר אוטומטי לגיבוי של רפליקה. אם מגדירים את הערך false, ה-API משתמש בשיטה הרגילה promoteReplica ללא מעבר לגיבוי בעת כשל.

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

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

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

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

REST v1beta4

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

  • ‫PROJECT_ID: המזהה או מספר הפרויקט של Google Cloud הפרויקט של המופע הראשי וההעתק לשחזור מאסון.
  • ‫REPLICA_NAME: השם של רפליקת DR.
  • ‫ENABLE_REPLICA_FAILOVER: צריך להגדיר את הערך true כדי להשתמש במעבר אוטומטי לגיבוי של רפליקה. אם מגדירים את הערך false, ה-API משתמש בשיטה הרגילה promoteReplica ללא מעבר לגיבוי בעת כשל.

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

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

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

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

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

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

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

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

    המסוף

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

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

      כניסה לדף Cloud SQL Instances

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

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

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

פתרון בעיות

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

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