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

כדי לשדרג אשכול של AlloyDB ל-PostgreSQL לגרסה ראשית חדשה יותר של PostgreSQL, תוך שמירה על שמות המכונות, כתובות ה-IP ומחרוזות החיבור הקיימים, אתם יכולים לתכנן, לאמת ולהריץ שדרוג במקום של הגרסה הראשית. במאמר סקירה כללית על שדרוג גרסה ראשית של מסד נתונים במקום מוסבר על תרחישי שימוש, שלבים בתהליך העבודה וגיבויים אוטומטיים.

תכנון שדרוג של גרסה ראשית של מסד נתונים

כדי לתכנן שדרוג של גרסת מסד נתונים ראשית:

1. מוצאים את הגרסה הראשית הנוכחית של מסד הנתונים.

   המסוף

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

      כניסה לדף Clusters

   2. בוחרים אשכול מהרשימה. הדף Overview ייפתח.

   3. מאתרים את הגרסה הראשית של מסד הנתונים בשדה Version.

   gcloud

   במאמר התקנת ה-CLI של gcloud מוסבר איך מתקינים את ה-CLI של gcloud ומתחילים להשתמש בו. למידע על הפעלת Cloud Shell, קראו את המאמר שימוש ב-Cloud Shell.

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

   gcloud alloydb clusters describe CLUSTER_ID --region=REGION

   מחליפים את הפרטים הבאים:

   • ‫CLUSTER_ID: מזהה האשכול
   • ‫REGION: המיקום או האזור של האשכול

   ‫REST v1beta

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

   GET https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID

   מחליפים את הפרטים הבאים:

   • ‫CLUSTER_ID: מזהה האשכול
   • ‫PROJECT_ID: מזהה הפרויקט
   • ‫REGION: המיקום או האזור של האשכול

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

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

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

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

      curl -X GET \
            -H "Authorization: Bearer $(gcloud auth print-access-token)" \
            -H "Content-Type: application/json; charset=utf-8" \
            "https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID"
      

   ‎PowerShell (Windows)

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

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

      $cred = gcloud auth print-access-token
      $headers = @{ "Authorization" = "Bearer $cred" }
   
      Invoke-WebRequest `
        -Method GET `
        -Headers $headers `
        -Uri "https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID| Select-Object -Expand Content
      

2. בוחרים גרסה ראשית של מסד נתונים לטירגוט מהטבלה הבאה. במאמר הזה מפורטות כל גרסאות מסדי הנתונים שנתמכות ב-AlloyDB.

   הגרסה הראשית של המקור	גרסאות עיקריות נתמכות של מערכת ההפעלה
   POSTGRES_14	POSTGRES_15 POSTGRES_16 POSTGRES_17 POSTGRES_18
   POSTGRES_15	POSTGRES_16 POSTGRES_17 POSTGRES_18
   POSTGRES_16	POSTGRES_17 POSTGRES_18
   POSTGRES_17	POSTGRES_18

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

   • PostgreSQL 18
   • ‫PostgreSQL בגרסה 17
   • PostgreSQL 16
   • PostgreSQL 15
   • PostgreSQL 14

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

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

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

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

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

• AlloyDB Studio
• psql
• שיטות חיבור אחרות

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

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

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

      • אם משתמשים ב-pglogical, מריצים את הפקודה הבאה:

        SELECT * FROM
        pglogical.alter_subscription_disable(SUBSCRIPTION_NAME, immediate);
        

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

        לדוגמה:

        postgres=> SELECT * FROM pglogical.alter_subscription_disable('test_sub',true);
        alter_subscription_disable
        ----------------------------
        t
        (1 row)
        

      • אם אתם משתמשים בתוסף אחר, ולא ב-pglogical, הריצו את הפקודה הבאה:

        ALTER SUBSCRIPTION SUBSCRIPTION_NAME DISABLE;
        

   2. מריצים את הפקודה הבאה כדי למחוק את כל משבצות השכפול הלוגי במכונה הראשית של AlloyDB:

      SELECT pg_drop_replication_slot(REPLICATION_SLOT_NAME) FROM pg_replication_slots WHERE slot_type = 'logical';
      

      מחליפים את REPLICATION_SLOT_NAME בשאילתה בשם של משבצת הרפליקציה.

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

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

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

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

   2. משדרגים את PostGIS ואת התוספים הקשורים (address_standardizer,‏ address_standardizer_data_us,‏ postgis_raster,‏ postgis_sfcgal,‏ postgis_tiger_geocoder ו-postgis_topology) לגרסה נתמכת בגרסת היעד של PostgreSQL. מידע נוסף זמין במאמר תוספי PostGIS. בטבלה הבאה מפורטות הגרסאות המינימליות הנתמכות של תוסף PostGIS לכל גרסה ראשית של PostgreSQL:

      גרסת PostgreSQL	הגרסה המינימלית הנתמכת של PostGIS
      PG14	‫3.1
      PG15	‫3.2
      PG16	3.4
      PG17	3.5
      PG18	3.6

      לדוגמה, אם גרסת PostGIS היא 3.1.x ואתם רוצים לשדרג מ-POSTGRES 14 ל-POSTGRES 16, השתמשו בפקודה הבאה כדי לשדרג את התוסף של PostGIS:

      ALTER EXTENSION postgis UPDATE TO '3.4.0';
      SELECT PostGIS_Version();
      

3. מוודאים שהאשכולות לא מכילים חברויות בתפקידים מיותמים. כשמשדרגים גרסאות ראשיות במקום, לא נשמרת החברות בתפקידים שבהם הגורם המקורי שהעניק את התפקיד כבר לא קיים. אם באשכול כלשהו יש חברויות מיותמות בקטלוג pg_auth_members, החברויות האלה בתפקידים יאבדו אחרי השדרוג.

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

   SELECT roleid::regrole, member::regrole, grantor::regrole
   FROM pg_auth_members
   WHERE grantor::regrole::text ~ '^[0-9]+$';
   

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

   מריצים את בלוק הטרנזקציה הבא לכל מינוי מיותם:

   BEGIN;
   REVOKE ROLE_NAME FROM MEMBER_NAME;
   GRANT ROLE_NAME TO MEMBER_NAME;
   COMMIT;
   

   מחליפים את ROLE_NAME ואת MEMBER_NAME בתפקידים מתוצאות השאילתה.

4. כדי לוודא שהחיבורים מותרים לכל מסד נתונים, חוץ מ-template0, מריצים את השאילתה הבאה ובודקים את השדה datallowconn בכל מסד נתונים:

   SELECT datname,datallowconn from pg_database;
   

   הערך t בשדה datallowconn מציין שהחיבור מותר. הערך f מציין שלא ניתן ליצור חיבור. מסד הנתונים של template0 לא יכול לאפשר חיבורים.

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

   ALTER DATABASE DATABASE_NAME WITH ALLOW_CONNECTIONS = true;
   

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

   SELECT datname, datistemplate FROM pg_database WHERE datname = 'template1';
   

   אם הערך של datistemplate הוא f, משנים אותו ל-true באמצעות הפקודה הבאה:

   ALTER DATABASE template1 WITH IS_TEMPLATE true;
   

שדרוג הגרסה הראשית של האשכול במקום

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

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

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

המסוף

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

   כניסה לדף Clusters

2. בוחרים אשכול מהרשימה. הדף Overview ייפתח.

3. כדי להתחיל את תהליך השדרוג של הגרסה הראשית של מסד הנתונים, לוחצים על Upgrade.

4. בשלב Choose database version, בוחרים אחת מהגרסאות הראשיות הזמינות של מסד הנתונים בתור גרסת היעד הראשית.

5. לוחצים על Continue.

6. בשלב Upgrade cluster, בשדה Cluster ID מזינים את שם האשכול.

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

gcloud

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

gcloud alloydb clusters upgrade CLUSTER_ID --region=REGION --version=DATABASE_VERSION --async

הנה פקודה לדוגמה:

gcloud alloydb clusters upgrade my-cluster --region=us-central1 --version=POSTGRES_16 --async

‫REST v1beta

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

PATCH https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID:upgrade

תוכן בקשת JSON:

{
  "version": "DATABASE_VERSION"
}

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

גוף בקשת JSON לדוגמה:

{
"version": "POSTGRES_16"
}

* { Terraform }

Warning: To keep your Terraform state consistent, update configurations directly in your Terraform files. If you make manual changes using the Google Cloud console, gcloud CLI, or REST API, the following issues can occur:


  
API errors
  
Perpetual diffs
  
Overwritten changes during terraform apply




To upgrade an instance within your database cluster to a PostgreSQL version, use a [Terraform resource](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/alloydb_instance) and set the `database_version` to a [supported target major version](/alloydb/docs/upgrade-db-inplace-major-version#plan-upgrade).

```none
resource "google_alloydb_instance" "default" {
cluster       = google_alloydb_cluster.default.name
instance_id   = "alloydb-instance"
instance_type = "PRIMARY"

machine_config {
  cpu_count = 2
}

depends_on = [google_service_networking_connection.vpc_connection]
}

resource "google_alloydb_cluster" "default" {
  cluster_id = "alloydb-cluster"
  location   = "us-central1"
  network_config {
    network = google_compute_network.default.id
  }
  database_version = "POSTGRES_16"

  initial_user {
    password = "alloydb-cluster"
  }
}

data "google_project" "project" {}

resource "google_compute_network" "default" {
  name = "alloydb-network"
}

resource "google_compute_global_address" "private_ip_alloc" {
  name          =  "alloydb-cluster"
  address_type  = "INTERNAL"
  purpose       = "VPC_PEERING"
  prefix_length = 16
  network       = google_compute_network.default.id
}

resource "google_service_networking_connection" "vpc_connection" {
  network                 = google_compute_network.default.id
  service                 = "servicenetworking.googleapis.com"
  reserved_peering_ranges = [google_compute_global_address.private_ip_alloc.name]
}
```

To learn how to apply or remove a Terraform configuration, see [Basic Terraform commands](/docs/terraform/basic-commands).

מעקב אחרי השדרוג של הגרסה הראשית של האשכול

אחרי שמתחיל השדרוג של גרסת מסד הנתונים הראשית, אפשר לעקוב אחרי סטטוס השדרוג באמצעות מסוף Google Cloud , ה-CLI של gcloud או ה-API בארכיטקטורת REST.

המסוף

כדי לבדוק את סטטוס השדרוג במסוף Google Cloud :

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

   כניסה לדף Clusters

2. בוחרים את האשכול שמשדרגים. הדף Overview ייפתח.

3. פותחים את הדף סקירה כללית.

4. לוחצים על סטטוס השדרוג. מופיע הדף Upgrade Status, שבו אפשר לבדוק את סטטוס השדרוג.

gcloud

כדי לבדוק את סטטוס השדרוג ב-CLI של gcloud:

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

   gcloud alloydb operations list --cluster=CLUSTER_ID --region=REGION_ID --filter=metadata.verb:upgrade

   הקריאה ל-CLI של gcloud שמשמשת להפעלת שדרוג של גרסה ראשית. alloydb beta clusters upgrade, מחזירה את מזהה הפעולה כתגובה סינכרונית. אפשר גם להשתמש בפקודה gcloud alloydb operations list עם הדגל --cluster.

   הנה פקודה לדוגמה:

   gcloud alloydb operations list --cluster=my-cluster --region=us-central1 --filter=metadata.verb:upgrade

2. כדי לעקוב אחרי סטטוס השדרוג, מריצים את הפקודה gcloud alloydb operations describe:

   gcloud alloydb operations describe OPERATION_ID
   --region=REGION

‫REST v1beta

כדי לבדוק את סטטוס השדרוג ב-API בארכיטקטורת REST:

1. משיגים את מזהה פעולת השדרוג.

   כדי להציג את כל פעולות השדרוג ולמצוא את הפעולה שמתאימה לאשכול היעד, משתמשים בבקשת GET הבאה עם ה-method‏ operations.list:

   GET https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/operations/filter=metadata.verb:upgrade

   הקריאה ל-API בארכיטקטורת REST מחזירה את מזהה הפעולה כתגובה סינכרונית.

2. עוקבים אחרי סטטוס השדרוג.

   משתמשים בבקשת GET עם השיטה operations.get:

     GET https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID

   מחליפים את הפרטים הבאים:

   • ‫PROJECT_ID: מזהה הפרויקט
   • ‫REGION: המיקום או האזור של האשכול
   • ‫OPERATION_ID: מזהה פעולת השדרוג, שאוחזר בשלב הקודם.

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

   {
   "name": "projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID",
   "metadata": {
   "@type": "type.googleapis.com/google.cloud.alloydb.v1.OperationMetadata",
   "createTime": "2024-09-16T23:17:39.727319438Z",
   "target": "projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID",
   "verb": "upgrade",
   "requestedCancellation": false,
   "apiVersion": "v1",
   "upgradeClusterStatus": {
      "state": "IN_PROGRESS",
      "cancellable": true,
      "stages": [
       {
         "stage": "ALLOYDB_PRECHECK",
         "state": "IN_PROGRESS"
       },
       {
         "stage": "PG_UPGRADE_CHECK",
         "state": "IN_PROGRESS"
       },
       {
         "stage": "PREPARE_FOR_UPGRADE",
         "state": "NOT_STARTED"
       },
       {
         "stage": "PRIMARY_INSTANCE_UPGRADE",
         "state": "NOT_STARTED"
       },
       {
         "stage": "CLEANUP",
         "state": "NOT_STARTED"
       }
      ]
    }
   },
   "done":false
   }
   

   הדוגמה הבאה היא של תשובה כשהפעולה מסתיימת:

   {
   "operations": [
   {
    "metadata": {
    "@type": "type.googleapis.com/google.cloud.alloydb.v1betaalpha.OperationMetadata",
    "createTime": "2024-09-16T21:52:17.303861317Z",
    "endTime": "2024-09-16T22:29:13.947527949Z",
    "target": "projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID",
    "verb": "upgrade",
    "requestedCancellation": false,
    "apiVersion": "v1beta",
    "upgradeClusterStatus": {
     "state": "SUCCESS",
     "stages": [
       {
         "stage": "ALLOYDB_PRECHECK",
         "state": "SUCCESS"
       },
       {
         "stage": "PG_UPGRADE_CHECK",
         "state": "SUCCESS"
       },
       {
         "stage": "PREPARE_FOR_UPGRADE",
         "state": "SUCCESS"
       },
       {
         "stage": "PRIMARY_INSTANCE_UPGRADE",
         "state": "SUCCESS"
       },
       {
         "stage": "CLEANUP",
         "state": SUCCESS"
       }
      ]
    }
   },
   "response": {
        …
   },
   "name":  "projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID",
   "done": true
   }
   ]
   }
   

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

תגובה לפעולת השדרוג

התגובה לפעולה UpgradeCluster כוללת את הפרטים הבאים:

• ‫status: הסטטוס של פעולת השדרוג הכוללת. הערכים האפשריים הם SUCCESS,‏ FAILED ו-PARTIAL_SUCCESS.
• ‫message: סיכום קצר של תוצאת פעולת השדרוג.
• ‫clusterUpgradeDetails: פרטי השדרוג של האשכולות שמשודרגים. השדה הזה הוא מערך. ב-AlloyDB אפשר לשדרג רק אשכול אחד, ולכן הוא כולל רק רשומה אחת.
  • ‫name: השם המלא של האשכול.
  • ‫upgradeStatus: הסטטוס של שדרוג האשכול. הערכים האפשריים הם SUCCESS, ‏ FAILED, ‏ PARTIAL_SUCCESS. ‫PARTIAL_SUCCESS: אי אפשר לשדרג מכונה אחת או יותר במאגר לקריאה בלבד.
  • ‫clusterType: סוג האשכול. ב-AlloyDB אפשר לשדרג רק אשכול PRIMARY אחד. הסוג הזה תמיד צריך להיות PRIMARY.
  • ‫databaseVersion: גרסת מסד הנתונים הנוכחית של האשכול.
  • ‫stageInfo: מידע על שלבי השדרוג העיקריים.
    • status: ‏ SUCCESS או FAILED
    • ‫logs_url: קישור ליומנים שנוצרו בשלב. השדה ריק בשלבים שלא יוצרים יומנים.
  • ‫instanceUpgradeDetails: פרטי השדרוג של כל המכונות באשכול.
    • ‫name: השם המלא של המכונה
    • upgradeStatus: ‏ SUCCESS או FAILED
    • instanceType: ‏ PRIMARY או READ_POOL

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

"response": {
  "@type": "type.googleapis.com/google.cloud.alloydb.v1alpha.UpgradeClusterResponse",
  "status": "SUCCESS",
  "message": "Cluster upgraded successfully.",
  "clusterUpgradeDetails": [
    {
      "name": "projects/1234/locations/us-central1/clusters/abc",
      "upgradeStatus": "SUCCESS",
      "clusterType": "PRIMARY",
      "databaseVersion": "POSTGRES_16",
      "stageInfo": [
        {
          "stage": "ALLOYDB_PRECHECK",
          "status": "SUCCESS",
          "logsUrl": "https://console.cloud.google.com/logs/query..."
        },
        {
          "stage": "PG_UPGRADE_CHECK",
          "status": "SUCCESS",
          "logsUrl": "https://console.cloud.google.com/logs/query..."
        },
        {
          "stage": "PRIMARY_INSTANCE_UPGRADE",
          "status": "SUCCESS",
          "logsUrl": "https://console.cloud.google.com/logs/query..."
        },
        {
          "stage": "READ_POOL_INSTANCES_UPGRADE",
          "status": "SUCCESS",
        }
      ],
      "instanceUpgradeDetails": [
        {
          "name": "projects/1234/locations/us-central1/clusters/abc/instances/primary",
          "upgradeStatus": "SUCCESS",
          "instanceType": "PRIMARY",
        },
        {
          "name": "projects/1234/locations/us-central1/clusters/abc/instances/read1",
          "upgradeStatus": "SUCCESS",
          "instanceType": "READ_POOL",
        },
        {
          "name": "projects/1234/locations/us-central1/clusters/abc/instances/read2",
          "upgradeStatus": "SUCCESS",
          "instanceType": "READ_POOL",
        }
      ]
    }
  ]
}

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

‫AlloyDB מפרסם את כל יומני השדרוג בשם היומן postgres_upgrade.

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

1. נכנסים לדף Logs Explorer ב-segment במסוף Google Cloud :

   נכנסים לדף Logs Explorer.

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

2. בוחרים באפשרות alloydb.googleapis.com/postgres_upgrade כשם היומן. השאילתה שמתאימה לזה היא "logName="projects/PROJECT_ID/logs/alloydb.googleapis.com%2Fpostgres_upgrade".

3. כדי לסנן את היומנים, משתמשים בתוויות הבאות:

   תווית	תיאור
   LOG_TYPE	שלב השדרוג שבו נוצר היומן. הערכים האפשריים הם ALLOYDB_PRECHECK,‏ PG_UPGRADE_CHECK ו-PG_UPGRADE.
   OPERATION_NAME	שם הפעולה המלא של פעולת השדרוג.
   FILE_NAME	מאוכלס רק ביומני pg_upgrade_check ו-pg_upgrade, ותואם לקובצי היומן שנוצרו על ידי הכלי pg_upgrade.

השאילתה הבאה לדוגמה מחזירה את יומני השדרוג של הבדיקה המקדימה של AlloyDB לפעולה נתונה:

logName="projects/project1234/logs/alloydb.googleapis.com%2Fpostgres_upgrade"
labels.LOG_TYPE="ALLOYDB_PRECHECK"
labels.OPERATION_NAME="projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID"

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

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

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

1. נכנסים לדף Logs Explorer ב-segment במסוף Google Cloud :

   נכנסים לדף Logs Explorer.

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

2. שולחים שאילתה ליומני הבדיקה המקדימה של AlloyDB באשכול.

   logName="projects/PROJECT_ID/logs/alloydb.googleapis.com%2Fpostgres_upgrade"
   labels.LOG_TYPE="ALLOYDB_PRECHECK"
   resource.labels.cluster_id=CLUSTER_ID
   

3. מאתרים את Operation_ID בתווית היומן OPERATION_NAME.

   בדוגמה הבאה, Operation_ID מ-OPERATION_NAME הוא operation-1728225968201-623cff6ed1e02-e34b7191-3cd92013.

   labels.OPERATION_NAME="projects/myproject/locations/us-central1/operations/operation-1728225968201-623cff6ed1e02-e34b7191-3cd92013"
   

4. שאילתה לכל היומנים של postgres_upgrade לפעולה ספציפית.

   logName="projects/production-1/logs/alloydb.googleapis.com%2Fpostgres_upgrade"
   labels.OPERATION_NAME="operation-1728225968201-623cff6ed1e02-e34b7191-3cd92013"
   

ביטול השדרוג של הגרסה הראשית של מסד הנתונים במקום

אפשר לבטל פעולת שדרוג של גרסה ראשית שנמצאת בתהליך דרך מסוף Google Cloud , ה-CLI של gcloud או ה-API בארכיטקטורת REST.

איך מוצאים את מזהה הפעולה

כדי לבטל את פעולת השדרוג של הגרסה הראשית באמצעות ה-CLI של gcloud או ה-API בארכיטקטורת REST, צריך את מזהה הפעולה. צריך לציין את המזהה הזה בפקודה של ה-CLI של gcloud או של ה-API בארכיטקטורת REST, כדי ש-AlloyDB ידע איזו פעולה לבטל.

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

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

אפשר גם למצוא את מזהה הפעולה באמצעות קריאה ל-operations.list באשכול AlloyDB.

ביטול השדרוג

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

המסוף

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

   כניסה לדף Clusters

2. בוחרים אשכול מהרשימה. הדף Overview ייפתח.

3. לוחצים על סטטוס השדרוג.

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

gcloud

משתמשים בפקודה gcloud alloydb operations cancel כדי לבטל את הפעולה:

gcloud alloydb operations cancel OPERATION_ID

מחליפים את המשתנה OPERATION_ID במזהה הפעולה.

אם הערך של cancellable הוא false בפלט של הפקודה gcloud alloydb operations cancel, בקשת הביטול של UpgradeClusterStatus לא תתקבל והשדרוג ימשיך. במקרה כזה, ה-API לא מחזיר שגיאה, אלא תשובה ריקה. למידע נוסף על סטטוס השדרוג, קראו את המאמר מעקב אחרי שדרוג הגרסה הראשית של האשכול.

‫REST v1beta

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

POST https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/operations/OPERATION_ID:cancel

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

• ‫PROJECT_ID: מזהה הפרויקט.
• ‫OPERATION_ID: המזהה של פעולת הייבוא או הייצוא.

אם הערך של cancellable ב-UpgradeClusterStatus הוא false, אי אפשר לבטל את השדרוג.

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

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

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

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

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

‎PowerShell (Windows)

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

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

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

       Invoke-WebRequest `
         -Method POST `
         -Headers $headers `
         -Uri "https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/operations/OPERATION_ID:cancel"| Select-Object -Expand Content
    

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

תגובה

הקריאה הזו ל-API בארכיטקטורת REST לא מחזירה תשובה.

השלמת השדרוג של הגרסה הראשית במקום

כדי להשלים את השדרוג של הגרסה הראשית, מתחברים למכונה של AlloyDB באמצעות AlloyDB Studio, ‏psql או שיטות חיבור אחרות.

אם אתם משתמשים במערכת שהיא לא AlloyDB, עיינו בהוראות החיבור במסמכי התיעוד של המערכת.

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

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

   1. מבטלים את המינוי pglogical ברפליקה של היעד באמצעות הפקודה הבאה:

        select pglogical.drop_subscription(subscription_name name);
      

      מחליפים את name בשם של המינוי הקיים. לדוגמה:

      postgres=> select pglogical.drop_subscription(subscription_name:= 'test_sub');
      -[ RECORD 1 ]-----+--
      drop_subscription |1
      

   2. צריך ליצור מחדש את המינוי pglogical ביעד או ברפליקה, על ידי הזנת פרטי החיבור הבאים למכונה הראשית של AlloyDB:

        SELECT pglogical.create_subscription(
        subscription_name :='test_sub',<br>
        provider_dsn := 'host=primary-ip port=5432 dbname=postgres user=replication_user password=replicapassword'
        );
      

   3. כדי לבדוק את סטטוס המינוי, משתמשים בפקודה הבאה:

        SELECT * FROM pglogical.show_subscription_status('test_sub');
      

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

2. מעדכנים ידנית את התוספים של מסד הנתונים במסדי הנתונים המשודרגים.

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

3. מרעננים את הנתונים הסטטיסטיים של מסד הנתונים.

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

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

5. מוודאים שהגרסה הראשית של מסד הנתונים ששודרג מופיעה בדף Overview של האשכול במסוף Google Cloud .

שחזור לגרסה הראשית הקודמת

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

הערה: ב-AlloyDB אי אפשר להחזיר את אותו אשכול לגרסה שלפני השדרוג או לשדרג אותו לאחור.

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

1. מזהים גיבוי שנוצר לפני השדרוג ומשחזרים ממנו. במהלך תהליך השדרוג, AlloyDB יוצר באופן אוטומטי גיבוי לפני השדרוג עם הקידומת pre-upgrade-bkp. למידע נוסף, ראו הצגת רשימת גיבויים.

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

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

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

מגבלות

המגבלות הבאות משפיעות על שדרוגים במקום של גרסאות ראשיות ב-AlloyDB:

- אי אפשר לשדרג גרסה ראשית במקום באשכול משני. - כשמשדרגים גרסה ראשית במקום, חשוב לזכור ששדרוג מכונות עם יותר מ-1,000 מסדי נתונים או מיליון אובייקטים (כמו טבלאות ותצוגות) נמשך זמן רב, וייתכן שהזמן הקצוב לתפוגה של השדרוג יסתיים. המגבלה הזו לא קשורה לגודל הנתונים בפועל. - ב-AlloyDB אי אפשר לשדרג אשכולות שמשתמשים ב-pg_largeobject_metadata. אם הערך של select count(*) from pg_largeobject_metadata; הוא לא אפס, השדרוג נכשל. ‫- ב-AlloyDB לא נשמרות חברויות בתפקידים שבהם הגורם המקורי שהעניק את ההרשאות כבר לא קיים. אם מסד הנתונים מכיל את החברויות היתומות האלה, צריך לפתור אותן לפני השדרוג. מידע נוסף זמין במאמר הכנת האשכול. - יכול להיות שפעולת השדרוג של הגרסה הראשית במקום תושלם לפני הגיבוי שלפני השדרוג או לפני הגיבויים שאחרי השדרוג, במיוחד אם יש לכם מסד נתונים גדול עם פחות אובייקטים של סכימה. - יכול להיות שיהיה עיכוב קצר בין הזמן שבו פעולות הכתיבה מתחילות שוב במכונה המשודרגת לבין הזמן שבו נוצר הגיבוי שאחרי השדרוג. כלומר, יכול להיות שתוכן הגיבוי אחרי השדרוג לא יהיה זהה לתוכן של מסד הנתונים לפני השדרוג של הגרסה הראשית. - יכול להיות שעדיין ייווצרו גיבויים לפני השדרוג אם השדרוג של הגרסה הראשית במקום נכשל. - מכיוון שהגיבויים של השדרוג האוטומטי הם רציפים, אי אפשר למחוק אותם עד שהם מגיעים לתקופת השמירה המקסימלית של גיבויים ושחזורים רציפים. כשתקופת השמירה המקסימלית מסתיימת, הגיבויים נאספים כזבל. לחלופין, אתם יכולים להשתמש ב-CLI של gcloud כדי למחוק את הגיבויים באופן ידני. מידע נוסף זמין במאמר הגבלות על מחיקת גיבויים.

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

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