תוכנית התאוששות מאסון (DR) מתקדמת עם משבצת לגיבוי לוגי

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

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

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

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

• גרסה 17 ואילך של PostgreSQL
• מהדורת Cloud SQL Enterprise Plus

• גישה לשירותים פרטיים

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

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

• מתקינים את ה-CLI של gcloud.

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

• יוצרים Google Cloud פרויקט או בוחרים פרויקט קיים.

• נותנים את התפקידים וההרשאות הנדרשים בניהול זהויות והרשאות גישה (IAM).

  • כדי ליצור פרויקט: Project Creator (roles/resourcemanager.projectCreator)

  • כדי ליצור ולנהל מכונות Cloud SQL: Cloud SQL Admin (roles/cloudsql.admin)

  • כדי ליצור מכונות וירטואליות ב-Compute Engine ולנהל אותן: Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1) וצפייה ב-Compute (roles/compute.networkViewer)

  • כדי ליצור רשתות VPC: אדמין רשתות (roles/compute.networkAdmin)

  לדף IAM

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

  במאמר ניהול הגישה לפרויקטים, לתיקיות ולארגונים מוסבר איך מקצים תפקידים והרשאות ב-IAM.

הגדרה של תוכנית התאוששות מאסון (DR) מתקדמת באמצעות שכפול לוגי

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

1. הגדרת משתני סביבה ומכונת וירטואלית מסוג Bastion.
2. יצירה והגדרה של המכונה הראשית.
3. יצירה והקצאה של רפליקה של DR.
4. יצירה והגדרה של מכונה לוגית של מנויים.
5. יצירת מינוי לשכפול לוגי
6. ביצוע מעבר אוטומטי או יתירות כשל של רפליקה.
7. אימות השכפול.
8. ניקוי משבצת שכפול יתומה בעותק החדש.
9. אופציונלי: מעבר חזרה לגרסה הקודמת.

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

1. מגדירים את משתני הסביבה הבאים.

   # Project
   export PROJECT="PROJECT_ID"
   
   # Instance names
   export PRIMARY_INSTANCE_NAME="PRIMARY_INSTANCE"
   export DR_REPLICA_NAME="DR_REPLICA"
   export SUBSCRIBER_INSTANCE_NAME="SUBSCRIBER_INSTANCE"
   export BASTION_VM_NAME="BASTION_VM"
   
   # Regions and zones
   export PRIMARY_REGION="PRIMARY_REGION"
   export REPLICA_REGION="REPLICA_REGION"
   export SUBSCRIBER_REGION="SUBSCRIBER_REGION"
   export VM_ZONE="VM_ZONE"
   
   # Network
   export NETWORK_NAME="NETWORK"
   
   # Credentials
   export POSTGRES_PASSWORD="PASSWORD"
   
   # Set gcloud project
   gcloud config set project PROJECT_ID
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫PROJECT_ID: מזהה הפרויקט.
   • ‫PRIMARY_INSTANCE: השם של מכונת Cloud SQL הראשית.
   • ‫DR_REPLICA: השם של העותק המשוכפל.
   • ‫SUBSCRIBER_INSTANCE: השם של מכונת המנוי.
   • ‫BASTION_VM: השם של מכונת ה-VM של היעד המבוצר.
   • ‫PRIMARY_REGION: האזור שבו נמצאת המכונה הראשית.
   • ‫REPLICA_REGION: האזור שבו נמצאת הרפליקה. העותק צריך להיות באזור שונה מזה של המופע הראשי.
   • ‫SUBSCRIBER_REGION: האזור שבו נמצא המנוי.
   • ‫VM_ZONE: האזור שבו נמצאת מכונת ה-VM של ה-bastion.
   • ‫NETWORK: השם של רשת ה-VPC
   • ‫PASSWORD: הסיסמה של המשתמש postgres.

2. יוצרים מכונת וירטואלית מסוג Bastion ב-Compute Engine.

   מכונות Cloud SQL משתמשות בכתובת IP פרטית. לכן, צריך ליצור מכונת VM של מארח Bastion ב-Compute Engine ברשת ה-VPC.

   gcloud compute instances create $BASTION_VM_NAME \
     --zone=$VM_ZONE \
     --machine-type=e2-small \
     --network=projects/$PROJECT_ID/global/networks/$NETWORK_NAME \
     --image-project=debian-cloud \
     --image-family=debian-11 \
     --project=$PROJECT
   

3. מתחברים למכונת ה-bastion הווירטואלית.

   gcloud compute ssh $BASTION_VM_NAME \
     --zone=$VM_ZONE \
     --project=$PROJECT
   

4. ב-VM של שרת הבאסטיונים, מתקינים את לקוח PostgreSQL.

   sudo apt-get update
   sudo apt-get install -y postgresql-client
   exit
   

צריך להריץ את פקודות PostgreSQL בשלבים הבאים ממכונת ה-VM של ה-bastion.

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

1. יוצרים את המכונה הראשית של Cloud SQL.

   gcloud sql instances create $PRIMARY_INSTANCE_NAME \
     --database-version=POSTGRES_17 \
     --edition=ENTERPRISE_PLUS \
     --region=$PRIMARY_REGION \
     --tier=db-perf-optimized-N-2 \
     --no-assign-ip \
     --network=projects/$PROJECT/global/networks/$NETWORK_NAME \
     --project=$PROJECT
   

2. הפעלת פענוח קוד לוגי.

   gcloud sql instances patch $PRIMARY_INSTANCE_NAME \
     --database-flags=cloudsql.logical_decoding=on \
     --project=$PROJECT
   

3. מגדירים סיסמה למשתמש postgres בשרת הראשי.

   gcloud sql users set-password postgres \
     --instance=$PRIMARY_INSTANCE_NAME \
     --password="$POSTGRES_PASSWORD" \
     --project=$PROJECT
   

4. מתחברים למופע הראשי ממכונת ה-VM של ה-bastion.

   1. מאחזרים את כתובת ה-IP הפרטית של המופע הראשי.

      gcloud sql instances describe $PRIMARY_INSTANCE_NAME \
        --format="value(ipAddresses[0].ipAddress)" \
        --project=$PROJECT
      

      מעתיקים ושומרים את כתובת ה-IP הפרטית של המופע הראשי.

   2. מתחברים באמצעות SSH למכונת ה-bastion הווירטואלית.

      gcloud compute ssh $BASTION_VM_NAME --zone=$VM_ZONE --project=$PROJECT
      

   3. ממכונת ה-VM של ה-bastion, מתחברים למופע הראשי.

      psql -h PRIMARY_PRIVATE_IP -U postgres
      

      מחליפים את PRIMARY_PRIVATE_IP בכתובת ה-IP הפרטית של המופע הראשי שאוחזרה בשלב 4.א בהליך הזה.

   4. כשמוצגת בקשה להזנת סיסמה, מזינים את המשתנה $POSTGRES_PASSWORD.

      מכונת ה-VM של ה-bastion מחוברת עכשיו למופע הראשי דרך PostgreSQL.

5. נותנים הרשאות ויוצרים פרסום.

   1. הענקת הרשאה REPLICATION למשתמש postgres.

      ALTER USER postgres WITH REPLICATION;
      

   2. מעניקים את ההרשאות הנדרשות בסכימה ובטבלאות הציבוריות.

      GRANT SELECT ON ALL TABLES IN SCHEMA public TO postgres;
      

   3. ליצור את הפרסום לכל הטבלאות.

      CREATE PUBLICATION my_publication FOR ALL TABLES;
      

   4. מקלידים exit כדי לצאת מ-PostgreSQL, ואז מקלידים exit שוב כדי לסגור את סשן ה-SSH של מכונת ה-VM של ה-bastion.

יצירה והגדרה של עותק משוכפל לשחזור מאסון (DR)

1. יוצרים רפליקה של DR.

   gcloud sql instances create $DR_REPLICA_NAME \
     --master-instance-name=$PRIMARY_INSTANCE_NAME \
     --edition=ENTERPRISE_PLUS \
     --tier=db-perf-optimized-N-2 \
     --region=$REPLICA_REGION \
     --no-assign-ip \
     --network=projects/$PROJECT/global/networks/$NETWORK_NAME \
     --project=$PROJECT
   

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

   gcloud sql instances patch $PRIMARY_INSTANCE_NAME \
     --failover-dr-replica-name=$DR_REPLICA_NAME \
     --project=$PROJECT
   

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

   gcloud sql instances patch $DR_REPLICA_NAME \
     --database-flags="^:^cloudsql.logical_decoding=on:hot_standby_feedback=on:sync_replication_slots=on:cloudsql.logical_slot_sync_dbname=postgres" \
     --project=$PROJECT
   

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

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

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

   gcloud sql instances patch $PRIMARY_INSTANCE_NAME \
     --database-flags="^:^cloudsql.logical_decoding=on:cloudsql.synchronized_standby_replicas=$DR_REPLICA_NAME" \
     --project=$PROJECT
   

   הערה: --database-flags="^:^cloudsql.logical_decoding=on:cloudsql.synchronized_standby_replicas=$DR_REPLICA_NAME" חיוני להגנה מפני אובדן נתונים במהלך יתירות כשל לא צפויה של רפליקה. לפעולת המעבר המתוכננת יש מנגנונים משלה כדי לוודא שהעותק משוכפל באופן מלא לפני שהוא מקודם. גם אם לא חובה להשתמש בדגל הזה כדי לעבור לגיבוי, הוא מספק שכבת אבטחה נוספת לכל תרחישי השחזור מאסון.

יצירה והגדרה של מופע לוגי של מנוי

1. יוצרים מכונה של מנוי.

   gcloud sql instances create $SUBSCRIBER_INSTANCE_NAME \
     --database-version=POSTGRES_17 \
     --tier=db-perf-optimized-N-2 \
     --region=$SUBSCRIBER_REGION \
     --no-assign-ip \
     --network=projects/$PROJECT/global/networks/$NETWORK_NAME \
     --project=$PROJECT
   

2. הפעלת פענוח לוגי במנוי.

   gcloud sql instances patch $SUBSCRIBER_INSTANCE_NAME \
     --database-flags=cloudsql.logical_decoding=on \
     --project=$PROJECT
   

יצירת מינוי לשכפול לוגי

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

   gcloud sql instances describe $PRIMARY_INSTANCE_NAME \
     --format="value(replicationCluster.psaWriteEndpoint)" \
     --project=$PROJECT
   

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

2. מתחברים למכונה של המינוי.

   1. מעדכנים את הסיסמה של המשתמש postgres במופע של המינוי.

      gcloud sql users set-password postgres \
        --instance=$SUBSCRIBER_INSTANCE_NAME \
        --password="$POSTGRES_PASSWORD" \
        --project=$PROJECT
      

   2. אחזור של כתובת ה-IP הפרטית של מופע המנוי.

      gcloud sql instances describe $SUBSCRIBER_INSTANCE_NAME \
        --format="value(ipAddresses[0].ipAddress)" \
        --project=$PROJECT
      

      מעתיקים ושומרים את כתובת ה-IP הפרטית.

   3. מתחברים ב-SSH למכונת ה-bastion.

      gcloud compute ssh $BASTION_VM_NAME \
        --zone=$VM_ZONE \
        --project=$PROJECT
      

   4. מהמכונה הווירטואלית של שרת הבאסטיונים, מתחברים למופע של המנוי דרך PostgreSQL.

      psql -h SUBSCRIBER_PRIVATE_IP -U postgres
      

      מחליפים את SUBSCRIBER_PRIVATE_IP בכתובת ה-IP הפרטית של מופע המינוי שהעתקתם בשלב 2.ב בתהליך הזה.

   5. כשמוצגת בקשה להזנת סיסמה, מזינים את המשתנה $POSTGRES_PASSWORD.

3. יוצרים מינוי.

   CREATE SUBSCRIPTION my_subscription
   CONNECTION 'host=DR_CLUSTER_PSA_DNS_WRITE_ENDPOINT port=5432 dbname=postgres user=postgres password=PASSWORD'
   PUBLICATION my_publication
   WITH (failover = true);
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫DR_CLUSTER_PSA_DNS_WRITE_ENDPOINT: נקודת הקצה של הגישה לשירותים פרטיים שהעתקתם בשלב 1 של התהליך הזה.
   • ‫PASSWORD: הערך של המשתנה ${POSTGRES_PASSWORD}.

4. יוצאים מ-PostgreSQL ומסשן ה-SSH של מכונת ה-bastion.

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

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

   1. מקבלים את כתובת ה-IP הפרטית של העותק המשוכפל של DR.

      gcloud sql instances describe $DR_REPLICA_NAME \
        --format="value(ipAddresses[0].ipAddress)" \
        --project=$PROJECT
      

      מעתיקים ושומרים את כתובת ה-IP הפרטית של העותק המשוכפל של DR.

   2. מתחברים באמצעות SSH למכונת ה-bastion הווירטואלית.

      gcloud compute ssh $BASTION_VM_NAME \
        --zone=$VM_ZONE \
        --project=$PROJECT
      

   3. מהמכונה הווירטואלית של ה-bastion, מתחברים לרפליקה של DR.

      psql -h DR_REPLICA_PRIVATE_IP -U postgres
      

      מחליפים את DR_REPLICA_PRIVATE_IP בכתובת ה-IP הפרטית של העותק המשוכפל של DR שאוחזרה בשלב 5.א בתהליך הזה.

   4. כשמוצגת בקשה להזנת סיסמה, מזינים את המשתנה $POSTGRES_PASSWORD.

   5. בודקים את סטטוס המשבצת.

      SELECT slot_name, slot_type, temporary, failover, synced
      FROM pg_replication_slots
      WHERE slot_type = 'logical' AND failover = true;
      

      מחכים שהעמודה temporary תהפוך ל-f. בדרך כלל התהליך נמשך פחות מדקה.

   6. יוצאים מ-PostgreSQL ומסשן ה-SSH של מכונת ה-bastion.

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

בוחרים את הפעולה שרוצים לבצע בהתאם לתרחיש:

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

  ‫

  gcloud sql instances switchover $DR_REPLICA_NAME \
    --project=$PROJECT
  

  הערה: הפעולה מסתיימת כשהפקודה מוחזרת.

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

  gcloud sql instances promote-replica $DR_REPLICA_NAME \
    --failover \
    --project=$PROJECT
  

  קידום המכירות של $DR_REPLICA_NAME מתבצע במהירות. עם זאת, המופע הראשי המקורי ($PRIMARY_INSTANCE_NAME) מוגדר מחדש כעותק של המופע הראשי החדש רק אחרי שהוא חוזר למצב אונליין. כדי לעקוב אחרי זה, מחפשים ביומן הפעולות את הפעולה RECONFIGURE_OLD_PRIMARY להשלמה ב-$PRIMARY_INSTANCE_NAME. מריצים את הפקודה הבאה:

  gcloud sql operations list --instance=$PRIMARY_INSTANCE_NAME --project=$PROJECT --limit=10`
  

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

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

ניהול סימונים

תהליכי העבודה של Cloud SQL מנהלים באופן אוטומטי את הדגלים הנדרשים של מסד הנתונים בשתי המכונות באשכול תוכנית התאוששות מאסון (DR), במהלך פעולות המעבר ופעולות היתירות כשל (failover) של הרפליקה, ואחריהן, כולל הפעולות הבאות:

• הדגלים של סנכרון המשבצות הלוגיות (cloudsql.logical_decoding, hot_standby_feedback, sync_replication_slots, cloudsql.logical_slot_sync_dbname) מוגדרים בצורה נכונה במופע שהופך לעותק החדש.
• הדגל cloudsql.synchronized_standby_replicas במכונה שהופכת למכונה הראשית החדשה מתעדכן אוטומטית כך שיצביע על השם של העותק החדש לשחזור מאסון.

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

אימות השכפול

1. בודקים את הסטטוס של המנוי.

   1. מריצים את הפקודה הבאה ממכונת ה-VM של ה-bastion.

      psql -h SUBSCRIBER_PRIVATE_IP -U postgres
      

      מחליפים את SUBSCRIBER_PRIVATE_IP בכתובת ה-IP הפרטית של מכונת המנוי.

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

      SELECT subname, pid IS NOT NULL AS is_active
      FROM pg_stat_subscription;
      

      הסטטוס צריך להיות streaming.

2. בודקים את הסטטוס של משבצת השכפול של השרת הראשי החדש. השרת הראשי החדש הוא העותק המשוכפל הקודם של DR‏ ($DR_REPLICA_NAME).

   1. מקבלים את כתובת ה-IP הפרטית של השרת הראשי החדש.

      gcloud sql instances describe $DR_REPLICA_NAME \
        --project=$PROJECT --format="value(ipAddresses[0].ipAddress)"
      

      מעתיקים ושומרים את כתובת ה-IP הפרטית של השרת הראשי החדש.

   2. מתחברים באמצעות SSH למכונת ה-bastion.

      psql -h NEW_PRIMARY_PRIVATE_IP -U postgres
      

      מחליפים את NEW_PRIMARY_PRIVATE_IP בכתובת ה-IP הפרטית של השרת הראשי החדש שהעתקתם בשלב הקודם.

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

      SELECT
          slot_name,
          slot_type,
          active,
          synced,
          active_pid,
          pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS replication_lag
      FROM pg_replication_slots
      WHERE slot_type = 'logical';
      

      המשבצת (לדוגמה, my_subscription) צריכה להיות active = t.

      SELECT
          application_name,
          state
      FROM pg_stat_replication;
      

      במכשיר pg_stat_replication אמור להופיע שהמנוי מחובר.

ניקוי של משבצת שכפול יתומה בעותק החדש

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

‫Cloud SQL לא מסיר אוטומטית את משבצת היתום הזו מהרפליקה החדשה. הסיבה לכך היא ש-Cloud SQL לא יכול לקבוע אם הוגדר למנוי שימוש בכתובת ה-IP של המופע במקום בנקודת הקצה (endpoint) של הגישה לשירותים פרטיים. יכול להיות שהמנוי עדיין ינסה להתחבר למקום הישן הזה בעותק החדש עד שהמינוי ישונה באופן ידני. הסרה אוטומטית של משבצת עלולה לשבור הגדרות כאלה.

הנוכחות של משבצת יתומה כזו בעותק החדש ($PRIMARY_INSTANCE_NAME) גורמת לתהליך העובד slotsync במופע הזה ליצור שגיאות ביומנים. יכול להיות שתופיע הודעת שגיאה כמו זו שמוצגת בpostgres.log של העותק החדש. השגיאה חוזרת שוב ושוב כי תהליך העבודה slotsync ממשיך לנסות.

ERROR: exiting from slot synchronization because same name slot "my_subscription" already exists on the standby

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

1. מאחזרים את כתובת ה-IP הפרטית של העותק החדש ($PRIMARY_INSTANCE_NAME).

   gcloud sql instances describe $PRIMARY_INSTANCE_NAME \
     --project=$PROJECT --format="value(ipAddresses[0].ipAddress)"
   

   מעתיקים ושומרים את כתובת ה-IP הפרטית של העותק החדש.

2. מתחברים באמצעות SSH למכונת ה-bastion.

   gcloud compute ssh $BASTION_VM_NAME \
     --zone=$VM_ZONE \
     --project=$PROJECT
   

3. מהמכונה הווירטואלית של ה-bastion, מתחברים לרפליקה החדשה.

   psql -h NEW_REPLICA_IP -U postgres
   

   מחליפים את NEW_REPLICA_IP בכתובת ה-IP של העותק החדש שהעתקתם בשלב 1 של התהליך הזה.

4. כשמוצגת בקשה להזנת סיסמה, מזינים את המשתנה $POSTGRES_PASSWORD.

5. במשבצת המשוכפלת החדשה ($PRIMARY_INSTANCE_NAME), משחררים את המשבצת היתומה.

   SELECT slot_name, slot_type, temporary, failover, synced, active
   FROM pg_replication_slots
   WHERE slot_name = 'my_subscription';
   

   מוודאים שהמשבצת קיימת עם synced = false ועם active = false, ואז משחררים אותה.

   SELECT pg_drop_replication_slot('my_subscription');
   

   המשבצת היתומה מוסרת.

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

אחרי שהמשבצת היתומה מושמטת, תהליך העובד slotsync ברפליקה החדשה ($PRIMARY_INSTANCE_NAME) מתחבר אוטומטית לשרת הראשי החדש ($DR_REPLICA_NAME) במחזור הבא שלו. נוצר משבצת מקומית חדשה my_subscription שמסונכרנת עם המשבצת הפעילה של השרת הראשי החדש.

אפשר לראות הודעות ב-postgres.log של העותק החדש שמציינות שהפעולה הצליחה, כמו ההודעה הבאה:

LOG: newly created slot "my_subscription" is sync-ready now

למשבצת החדשה שסונכרנה יש failover=true והיא הופכת בסופו של דבר לפרסיסטנטית (temporary=false), כך שאם תחזרו אחורה בהמשך, המופע הזה יהיה מוכן.

אופציונלי: מבצעים מעבר חזרה

1. עכשיו, חוזרים אחורה ומגדירים שוב את $PRIMARY_INSTANCE_NAME כאירוע הראשי.

   gcloud sql instances switchover $PRIMARY_INSTANCE_NAME \
     --project=$PROJECT
   

2. מבצעים אימות אחרי החזרה לגרסה הקודמת.

   1. בודקים את הסטטוס של מופע המנוי.

      SELECT subname, pid IS NOT NULL AS is_active
      FROM pg_stat_subscription;
      

      המינוי אמור להיות עדיין פעיל, כלומר is_active = t.

   2. בודקים את הסטטוס של המשבצת של הראשי החדש ($PRIMARY_INSTANCE_NAME).

      SELECT slot_name, active FROM pg_replication_slots WHERE slot_type = 'logical';
      SELECT * FROM pg_stat_replication;
      

      המשבצת צריכה להיות פעילה והמנוי צריך להיות מחובר.

פתרון בעיות

שגיאה	פתרון בעיות
שגיאה בעותק החדש (כלומר, המופע הראשי הישן) אחרי המעבר לגיבוי: "exiting from slot synchronization because same name slot already exists on the standby"	פועלים לפי השלבים במאמר ניקוי משבצת שכפול יתומה בעותק החדש.