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

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

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

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

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

   המסוף

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

      מעבר אל Clusters

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

   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)

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

      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)

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

      $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. מחיקה או קידום של רפליקות באזורים שונים. שדרוגים של גרסאות ראשיות של מסדי נתונים במקום לא תומכים ברפליקות באזורים שונים. מידע נוסף זמין במאמר בנושא שכפול באזורים שונים.

2. אם אשכול 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 בשאילתה בשם של משבצת השכפול.

3. ניהול התוספים של 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();
      

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

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

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

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

{
  "version": "DATABASE_VERSION"
}

{
"version": "POSTGRES_16"
}

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

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

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

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

התשובה של פעולת 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 log name.

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

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

   כניסה אל 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. במסוף Google Cloud , נכנסים לדף segment Logs Explorer:

   כניסה אל 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.

ביטול השדרוג

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

gcloud alloydb operations cancel OPERATION_ID

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

       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"
  

       $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
    

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

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

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

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

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

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

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

כדי לשחזר למצב שלפני השדרוג:

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

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

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

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

מגבלות

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

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

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

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