Mengupgrade versi utama database yang sudah diterapkan

Halaman ini menjelaskan cara mengupgrade versi utama database dengan mengupgrade instance Cloud SQL sebagai gantinya, bukan memigrasi data.

Pengantar

Penyedia software database secara berkala merilis versi utama baru yang berisi fitur, peningkatan performa, serta peningkatan keamanan yang baru. Cloud SQL menerima versi baru setelah versi baru tersebut dirilis. Setelah Cloud SQL menawarkan dukungan untuk versi utama yang baru, Anda dapat mengupgrade instance untuk menjaga database Anda terus terupdate.

Anda dapat mengupgrade versi database dari instance secara langsung atau dengan memigrasikan data. Upgrade secara langsung adalah cara yang lebih mudah untuk mengupgrade versi utama instance Anda. Anda tidak perlu memigrasikan data atau mengubah string koneksi aplikasi. Dengan upgrade secara langsung, Anda dapat mempertahankan nama, alamat IP, dan setelan lain dari instance saat ini setelah upgrade. Upgrade secara langsung tidak mengharuskan Anda memindahkan file data dan dapat diselesaikan lebih cepat. Dalam beberapa kasus, periode nonaktif lebih singkat daripada yang diperlukan untuk memigrasikan data Anda.

Operasi upgrade secara langsung Cloud SQL untuk PostgreSQL menggunakan pg_upgrade aplikasi utilitas.

Merencanakan upgrade versi utama

  1. Pilih versi utama target.

    gcloud

    Untuk mengetahui informasi tentang menginstal dan memulai gcloud CLI, lihat Menginstal gcloud CLI. Untuk mengetahui informasi tentang cara memulai Cloud Shell, lihat Menggunakan Cloud Shell.

    Untuk memeriksa versi database yang dapat Anda targetkan untuk upgrade langsung di instance, lakukan hal berikut:

    1. Jalankan perintah berikut.
    2. gcloud sql instances describe INSTANCE_NAME
         

      Ganti INSTANCE_NAME dengan nama instance.

    3. Di output perintah, cari bagian yang berlabel upgradableDatabaseVersions.
    4. Setiap subbagian menampilkan versi database yang tersedia untuk upgrade. Di setiap subbagian, tinjau kolom berikut.
      • majorVersion: versi utama yang dapat Anda targetkan untuk upgrade di tempat.
      • name: string versi database yang menyertakan versi utama.
      • displayName: nama tampilan untuk versi database.

    REST v1

    Untuk memeriksa versi database target yang tersedia untuk upgrade versi utama secara langsung, gunakan metode instances.get Cloud SQL Admin API.

    Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

    • INSTANCE_NAME: Nama instance.

    Metode HTTP dan URL:

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

    Untuk mengirim permintaan, perluas salah satu opsi berikut:

    Anda akan menerima respons JSON seperti berikut:

    
    upgradableDatabaseVersions:
    
    {
      major_version: "POSTGRES_15_0"
      name: "POSTGRES_15_0"
      display_name: "PostgreSQL 15.0"
    }
    
    

    REST v1beta4

    Untuk memeriksa versi database target yang tersedia untuk upgrade versi utama secara langsung pada instance, gunakan metode instances.get Cloud SQL Admin API.

    Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

    • INSTANCE_NAME: Nama instance.

    Metode HTTP dan URL:

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

    Untuk mengirim permintaan, perluas salah satu opsi berikut:

    Anda akan melihat respons JSON seperti berikut:

    
    upgradableDatabaseVersions:
    
    {
      major_version: "POSTGRES_15_0"
      name: "POSTGRES_15_0"
      display_name: "PostgreSQL 15.0"
    }
    
    

    Untuk mengetahui daftar lengkap versi database yang didukung Cloud SQL, lihat Kebijakan versi dan versi database.

  2. Pertimbangkan fitur yang ditawarkan di setiap versi utama database dan atasi ketidaksesuaian.

    Versi utama yang baru memperkenalkan perubahan yang tidak kompatibel yang mungkin mengharuskan Anda mengubah kode aplikasi, skema, atau setelan database. Sebelum mengupgrade instance database, tinjau catatan rilis versi utama target untuk menentukan inkompatibilitas yang harus Anda atasi.

  3. Uji upgrade dengan uji coba.

    Jalankan uji coba proses upgrade menyeluruh di lingkungan pengujian sebelum Anda mengupgrade database produksi. Anda dapat meng-clone instance untuk membuat salinan data identik yang akan digunakan untuk menguji proses upgrade.

    Selain memvalidasi bahwa upgrade berhasil diselesaikan, jalankan pengujian untuk memastikan aplikasi berperilaku seperti yang diharapkan pada database yang telah diupgrade.

  4. Tentukan waktu untuk mengupgrade.

    Upgrade mengharuskan instance menjadi tidak tersedia selama beberapa waktu. Rencanakan untuk melakukan upgrade saat aktivitas database rendah.

Mempersiapkan untuk upgrade versi utama

Sebelum mengupgrade, selesaikan langkah-langkah berikut.

  1. Periksa nilai LC_COLLATE untuk database template dan postgres. Himpunan karakter untuk setiap database harus en_US.UTF8.

    Jika nilai LC_COLLATE untuk database template dan postgres bukan en_US.UTF8, maka upgrade versi utama gagal. Untuk memperbaiki masalah tersebut, jika salah satu database memiliki himpunan karakter selain en_US.UTF8, ubah nilai LC_COLLATE menjadi en_US.UTF8 sebelum Anda melakukan upgrade.

    Untuk mengubah encoding database:

    1. Hapus database Anda.
    2. Lepas database Anda.
    3. Buat database baru dengan encoding yang berbeda (untuk contoh ini, en_US.UTF8).
    4. Muat ulang data Anda.

    Opsi lainnya adalah mengganti nama database:

    1. Tutup semua koneksi ke database.
    2. Ganti nama database.
    3. Perbarui konfigurasi aplikasi Anda untuk menggunakan nama database baru.
    4. Buat database baru yang kosong dengan encoding default.

    Sebaiknya lakukan langkah-langkah ini pada instance yang di-clone sebelum menerapkannya ke instance produksi.

  2. Kelola replika baca Anda.

    Cloud SQL untuk PostgreSQL tidak mendukung replikasi lintas versi, yang berarti Anda tidak dapat mengupgrade instance utama saat instance sedang direplikasi ke replika baca. Sebelum mengupgrade, nonaktifkan replikasi untuk setiap replika baca atau hapus replika baca.

  3. Jika Cloud SQL adalah sumber replikasi logis, nonaktifkan replikasi ekstensi pglogical sebagai berikut. Anda dapat mengaktifkannya setelah proses upgrade. Jika Cloud SQL adalah target replikasi logis, langkah-langkah ini tidak diperlukan.
    1. Nonaktifkan langganan dan putuskan koneksi replika dari penyedia menggunakan perintah berikut:
      SELECT * FROM pglogical.alter_subscription_disable(subscription_name name, immediate bool);

      Ganti name dengan nama langganan yang sudah ada.

      Tetapkan nilai parameter immediate ke true jika langganan perlu segera dinonaktifkan. Secara default, nilainya adalah false dan langganan dinonaktifkan hanya setelah transaksi saat ini berakhir.

      Contoh:

      postgres=> SELECT * FROM pglogical.alter_subscription_disable('test_sub', true);
       alter_subscription_disable
      ----------------------------
       t
      (1 row)
    2. Lepas slot replikasi dengan menghubungkan ke penayang atau instance utama Cloud SQL dan jalankan perintah berikut:
      SELECT pg_drop_replication_slot(slot_name) FROM pg_replication_slots
        WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);

      Contoh:

      postgres=> SELECT pg_drop_replication_slot(slot_name) FROM pg_replication_slots
      postgres->    WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);
      -[ RECORD 1 ]------------+-
      pg_drop_replication_slot |
      
      postgres=>
  4. Kelola ekstensi PostgreSQL Anda yang tersisa.

    Sebagian besar ekstensi berfungsi pada versi utama database yang telah diupgrade. Lepas semua ekstensi yang tidak lagi didukung di versi target Anda. Misalnya, lepaskan ekstensi chkpass jika Anda mengupgrade ke PostgreSQL 11 atau versi yang lebih baru.

    Anda dapat mengupgrade PostGIS dan ekstensi terkaitnya secara manual ke versi terbaru yang didukung.

    Terkadang, mengupgrade dari PostGIS versi 2.x dapat menciptakan situasi di mana ada objek database yang tersisa yang tidak terkait dengan ekstensi PostGIS. Hal ini dapat memblokir operasi upgrade. Untuk informasi tentang cara menyelesaikan masalah ini, lihat Memperbaiki penginstalan raster postgis yang rusak.

    Terkadang, upgrade ke PostGIS versi 3.1.7 atau yang lebih baru tidak dapat diselesaikan karena objek menggunakan fungsi yang tidak digunakan lagi. Hal ini dapat memblokir operasi upgrade. Untuk memeriksa status upgrade, jalankan SELECT PostGIS_full_version();. Jika ada peringatan, hapus objek apa pun yang menggunakan fungsi yang tidak digunakan lagi dan update ekstensi PostGIS ke versi menengah atau yang lebih tinggi. Setelah Anda menyelesaikan tindakan ini, jalankan kembali perintah SELECT PostGIS_full_version();. Pastikan tidak ada peringatan yang muncul. Kemudian, lanjutkan operasi upgrade.

    Untuk mempelajari lebih lanjut tentang mengupgrade ekstensi PostGIS Anda, lihat Mengupgrade PostGIS. Untuk masalah yang terkait dengan mengupgrade PostGIS, lihat Memeriksa versi instance PostgreSQL Anda.
  5. Kelola flag database kustom Anda. Periksa nama setiap flag database kustom yang dikonfigurasi untuk instance PostgreSQL Anda. Untuk masalah terkait flag ini, lihat Memeriksa flag kustom untuk instance PostgreSQL Anda.
  6. Saat melakukan upgrade dari satu versi utama ke versi utama lainnya, cobalah terhubung ke setiap database untuk melihat apakah ada masalah kompatibilitas. Pastikan bahwa database Anda dapat terhubung satu sama lain. Periksa kolom datallowconn untuk setiap database guna memastikan bahwa koneksi diizinkan. Nilai t berarti diizinkan, dan nilai f menunjukkan bahwa koneksi tidak dapat dibuat.
  7. Jika Anda menggunakan penginstalan Datadog untuk mengupgrade instance Cloud SQL ke PostgreSQL 10 atau versi yang lebih baru, sebelum melakukan upgrade, hapus fungsi pg_stat_activity().

Batasan umum

Batasan berikut memengaruhi upgrade versi utama secara langsung untuk Cloud SQL untuk PostgreSQL:

  • Anda tidak dapat melakukan upgrade versi utama di tempat pada replika eksternal.
  • Mengupgrade instance yang memiliki lebih dari 1,000 database dari satu versi ke versi lainnya mungkin memerlukan waktu dan waktu yang lama.
  • Menggunakan pernyataan select * from pg_largeobject_metadata; untuk mengkueri jumlah objek besar di setiap database PostgreSQL dari instance Cloud SQL Anda. Jika hasil dari semua database Anda lebih dari 10 juta objek besar, upgrade dinyatakan gagal. Cloud SQL melakukan roll back ke versi database sebelumnya.
  • Sebelum Anda melakukan upgrade versi utama secara langsung ke PostgreSQL 16 dan yang lebih baru, upgrade ekstensi PostGIS untuk semua database Anda ke versi 3.4.0.
  • Jika Anda menggunakan PostgreSQL versi 9.6, 10, 11, atau 12, ekstensi PostGIS versi 3.4.0 tidak didukung. Oleh karena itu, untuk melakukan upgrade versi utama secara langsung ke PostgreSQL 16 dan yang lebih baru, Anda harus mengupgrade ke versi PostgreSQL perantara terlebih dahulu (versi 13, 14, atau 15).
  • Jika menginstal ekstensi pgRouting dan pg_squeeze untuk instance, Anda tidak dapat melakukan upgrade versi utama. Untuk memperbaikinya, uninstal ekstensi ini, lalu lakukan upgrade. Untuk mengetahui informasi selengkapnya tentang ekstensi, lihat Mengonfigurasi ekstensi PostgreSQL.

  • Jika mengaktifkan flag vacuum_defer_cleanup_age dan force_parallel_mode, Anda tidak dapat melakukan upgrade versi utama. Untuk memperbaikinya, hapus flag ini, lalu lakukan upgrade. Untuk informasi selengkapnya tentang flag, termasuk cara menghapusnya, lihat Mengonfigurasi flag database.

Mengupgrade versi utama database yang sudah diterapkan

Saat Anda memulai operasi upgrade, Cloud SQL akan memeriksa konfigurasi instance Anda terlebih dahulu untuk memastikan kompatibilitasnya dengan upgrade. Setelah memverifikasi konfigurasi Anda, Cloud SQL akan membuat instance Anda tidak tersedia, membuat cadangan pra-upgrade, melakukan upgrade, menyediakan instance dan membuat cadangan pasca-upgrade.

Konsol

  1. Di konsol Google Cloud, buka halaman Instance Cloud SQL.

    Buka Instance Cloud SQL

  2. Untuk membuka halaman Ringkasan instance, klik nama instance.
  3. Klik Edit.
  4. Di bagian Info instance, klik tombol Upgrade dan konfirmasi bahwa Anda ingin membuka halaman upgrade.
  5. Di halaman Memilih versi database, klik daftar Versi database untuk upgrade dan pilih salah satu versi utama database yang tersedia.
  6. Klik Lanjutkan.
  7. Di kotak ID Instance, masukkan nama instance, lalu klik tombol Mulai upgrade.
Operasi ini memerlukan waktu beberapa menit hingga selesai.

Pastikan versi utama database yang telah diupgrade muncul di bawah nama instance pada halaman Ringkasan instance.

gcloud

  1. Mulai upgrade.

    Gunakan perintah gcloud sql instances patch dengan flag --database-version.

    Sebelum menjalankan perintah, ganti variabel berikut:

    • INSTANCE_NAME: nama instance
    • DATABASE_VERSION: Enum untuk versi utama database, yang harus lebih baru dari versi saat ini. Tentukan versi database untuk versi utama yang tersedia sebagai target upgrade untuk instance. Anda bisa mendapatkan enum ini sebagai langkah pertama Merencanakan upgrade. Jika Anda memerlukan daftar lengkap enum versi database, lihat SqlDatabaseEnums.
    gcloud sql instances patch INSTANCE_NAME \
    --database-version=DATABASE_VERSION

    Upgrade versi utama memerlukan waktu beberapa menit untuk diselesaikan. Anda mungkin melihat pesan yang menunjukkan bahwa operasi memerlukan waktu lebih lama dari yang diperkirakan. Anda dapat mengabaikan pesan ini atau menjalankan perintah gcloud sql operations wait untuk menutup pesan.

  2. Dapatkan nama operasi upgrade.

    Gunakan perintah gcloud sql operations list dengan flag --instance.

    Sebelum menjalankan perintah, ganti variabel INSTANCE_NAME dengan nama instance.

    gcloud sql operations list --instance=INSTANCE_NAME
  3. Pantau status upgrade.

    Gunakan perintah gcloud sql operations describe.

    Sebelum menjalankan perintah, ganti variabel OPERATION dengan nama operasi upgrade yang diambil di langkah sebelumnya.

    gcloud sql operations describe OPERATION

REST v1

  1. Mulai upgrade secara langsung.

    Gunakan permintaan PATCH dengan metode instances:patch.

    Sebelum menggunakan data permintaan apa pun, ganti variabel berikut:

    • PROJECT_ID: ID project.
    • INSTANCE_NAME: Nama instance.

    Metode HTTP dan URL:

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

    Meminta isi JSON:

    {
      "databaseVersion": DATABASE_VERSION
    }

    Ganti DATABASE_VERSION dengan enum untuk versi utama database, yang harus lebih baru dari versi saat ini. Tentukan versi database untuk versi utama yang tersedia sebagai target upgrade untuk instance. Anda bisa mendapatkan enum ini sebagai langkah pertama Merencanakan upgrade. Jika Anda memerlukan daftar lengkap enum versi database, lihat SqlDatabaseVersion.

  2. Dapatkan nama operasi upgrade.

    Gunakan permintaan GET dengan metode operations.list setelah mengganti PROJECT_ID dengan ID project.

    Metode HTTP dan URL:

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations
  3. Pantau status upgrade.

    Gunakan permintaan GET dengan metode operations.get setelah mengganti variabel berikut:

    • PROJECT_ID: ID project.
    • OPERATION_NAME: Nama operasi upgrade yang diambil di langkah sebelumnya.

    Metode HTTP dan URL:

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

Terraform

Untuk memperbarui versi database, gunakan resource Terraform dan penyedia Terraform untuk Google Cloud, versi 4.34.0 atau yang lebih baru.

resource "google_sql_database_instance" "instance" {
  name             = "postgres-instance"
  region           = "us-central1"
  database_version = "POSTGRES_14"
  settings {
    tier = "db-custom-2-7680"
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

Menerapkan perubahan

Untuk menerapkan konfigurasi Terraform di project Google Cloud, selesaikan langkah-langkah di bagian berikut.

Menyiapkan Cloud Shell

  1. Luncurkan Cloud Shell.
  2. Tetapkan project Google Cloud default tempat Anda ingin menerapkan konfigurasi Terraform.

    Anda hanya perlu menjalankan perintah ini sekali per project, dan dapat dijalankan di direktori mana pun.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    Variabel lingkungan akan diganti jika Anda menetapkan nilai eksplisit dalam file konfigurasi Terraform.

Menyiapkan direktori

Setiap file konfigurasi Terraform harus memiliki direktorinya sendiri (juga disebut modul root).

  1. Di Cloud Shell, buat direktori dan file baru di dalam direktori tersebut. Nama file harus memiliki ekstensi .tf—misalnya main.tf. Dalam tutorial ini, file ini disebut sebagai main.tf.
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf
  2. Jika mengikuti tutorial, Anda dapat menyalin kode contoh di setiap bagian atau langkah.

    Salin kode contoh ke dalam main.tf yang baru dibuat.

    Atau, salin kode dari GitHub. Tindakan ini direkomendasikan jika cuplikan Terraform adalah bagian dari solusi menyeluruh.

  3. Tinjau dan ubah contoh parameter untuk diterapkan pada lingkungan Anda.
  4. Simpan perubahan Anda.
  5. Lakukan inisialisasi Terraform. Anda hanya perlu melakukan ini sekali per direktori.
    terraform init

    Secara opsional, untuk menggunakan versi penyedia Google terbaru, sertakan opsi -upgrade:

    terraform init -upgrade

Menerapkan perubahan

  1. Tinjau konfigurasi dan pastikan resource yang akan dibuat atau diupdate oleh Terraform sesuai yang Anda inginkan:
    terraform plan

    Koreksi konfigurasi jika diperlukan.

  2. Terapkan konfigurasi Terraform dengan menjalankan perintah berikut dan memasukkan yes pada prompt:
    terraform apply

    Tunggu hingga Terraform menampilkan pesan "Apply complete!".

  3. Buka project Google Cloud Anda untuk melihat hasilnya. Di Konsol Google Cloud, buka resource Anda di UI untuk memastikan bahwa Terraform telah membuat atau mengupdatenya.

Menghapus perubahan

Untuk menghapus perubahan Anda, lakukan langkah-langkah berikut:

  1. Untuk menonaktifkan perlindungan penghapusan, di file konfigurasi Terraform Anda, tetapkan argumen deletion_protection ke false.
    deletion_protection =  "false"
  2. Terapkan konfigurasi Terraform dengan menjalankan perintah berikut dan memasukkan yes pada prompt:
    terraform apply
  1. Hapus resource yang sebelumnya diterapkan dengan konfigurasi Terraform Anda dengan menjalankan perintah berikut dan memasukkan yes pada prompt:

    terraform destroy

Saat Anda mengajukan permintaan upgrade secara langsung, Cloud SQL akan melakukan pemeriksaan upgrade awal terlebih dahulu. Jika Cloud SQL menentukan bahwa instance Anda belum siap untuk diupgrade, permintaan upgrade Anda akan gagal dengan pesan yang menyarankan cara mengatasi masalah tersebut. Lihat juga Memecahkan masalah upgrade versi utama.

Cadangan upgrade otomatis

Saat Anda melakukan upgrade versi utama, Cloud SQL secara otomatis membuat dua pencadangan on-demand, yang disebut cadangan upgrade:

  • Cadangan upgrade pertama adalah cadangan pra-upgrade, yang segera dibuat sebelum memulai upgrade. Anda dapat menggunakan cadangan ini untuk memulihkan instance database ke statusnya pada versi sebelumnya.
  • Cadangan upgrade kedua adalah cadangan pasca-upgrade, yang segera dibuat setelah penulisan baru diizinkan ke instance database yang diupgrade.

Saat Anda melihat daftar cadangan, cadangan upgrade akan dicantumkan dengan jenis On-demand. Cadangan upgrade diberi label agar Anda dapat mengidentifikasinya dengan cepat. Misalnya, jika Anda mengupgrade dari PostgreSQL 14 ke PostgreSQL 15, cadangan pra-upgrade Anda akan diberi label Pre-upgrade backup, POSTGRES_14 to POSTGRES_15. dan cadangan pasca-upgrade Anda diberi label Post-upgrade backup, POSTGRES_14 to POSTGRES_15.

Seperti pencadangan on demand lainnya, cadangan upgrade akan tetap ada hingga Anda menghapusnya atau menghapus instance. Jika PITR diaktifkan, Anda tidak dapat menghapus cadangan upgrade saat cadangan upgrade berada di periode retensi. Jika perlu menghapus cadangan upgrade, Anda harus menonaktifkan PITR atau menunggu hingga cadangan upgrade tidak lagi berada dalam periode retensi.

Menyelesaikan upgrade versi utama

Setelah selesai mengupgrade instance utama, lakukan langkah-langkah berikut untuk menyelesaikan upgrade:

  1. Aktifkan replikasi pglogical jika instance Anda menggunakannya sebelum proses upgrade. Tindakan tersebut akan otomatis membuat slot replikasi yang diperlukan.
    1. Lepaskan langganan pglogical pada replika tujuan dengan menggunakan perintah berikut:
      select pglogical.drop_subscription(subscription_name name);

      Ganti name dengan nama langganan yang sudah ada.

      Contoh:

      postgres=> select pglogical.drop_subscription(subscription_name := 'test_sub');
      -[ RECORD 1 ]-----+--
      drop_subscription | 1
    2. Buat ulang langganan pglogical pada tujuan (replika) dengan memberikan detail koneksi seperti berikut ke instance utama Cloud SQL:
      SELECT pglogical.create_subscription(
          subscription_name := 'test_sub',
          provider_dsn := 'host=primary-ip port=5432 dbname=postgres user=replication_user password=replicapassword'
      ); 

      Contoh:

      postgres=> SELECT pglogical.create_subscription(
      postgres(>     subscription_name := 'test_sub',
      postgres(>     provider_dsn := 'host=10.58.64.90 port=5432 dbname=postgres user=postgres password=postgres'
      postgres(> );
      -[ RECORD 1 ]-------+-----------
      create_subscription | 2769129391
    3. Periksa status langganan menggunakan perintah berikut:
      SELECT * FROM pglogical.show_subscription_status('test_sub');
    4. Uji replikasi dengan melakukan transaksi tulis dan memverifikasi bahwa perubahan tersebut terlihat di tujuan.
  2. Upgrade replika baca.

    Jika Anda menghentikan replikasi ke replika baca, upgrade replika baca satu per satu. Anda dapat menggunakan salah satu metode yang digunakan untuk mengupgrade instance utama. Saat Anda mengupgrade replika, Cloud SQL akan membuat ulang replika tersebut dengan mempertahankan alamat IP, memuat ulang replika dengan data terbaru dari instance utama, dan memulai ulang replika.

    Jika menghapus replika baca sebelum mengupgrade instance utama, Anda dapat membuat replika baca baru yang disediakan otomatis pada versi database yang telah diupgrade.

  3. Muat ulang statistik database.

    Jalankan ANALYZE pada instance utama untuk memperbarui statistik sistem setelah proses upgrade. Statistik yang akurat memastikan bahwa perencana kueri PostgreSQL memproses kueri secara optimal. Tidak adanya statistik dapat menyebabkan rencana kueri yang buruk, yang pada akhirnya dapat menurunkan performa dan menggunakan memori terlalu banyak.

  4. Lakukan pengujian penerimaan.

    Anda harus menjalankan pengujian untuk memastikan sistem yang diupgrade berjalan seperti yang diharapkan.

Memecahkan masalah upgrade versi utama

Cloud SQL menampilkan pesan error jika Anda mencoba perintah upgrade yang tidak valid, misalnya, jika instance Anda berisi flag database tidak valid untuk versi baru.

Jika permintaan upgrade gagal, periksa sintaksis permintaan upgrade Anda. Jika permintaan memiliki struktur yang valid, coba lihat saran berikut.

Melihat kegagalan pemeriksaan pra-upgrade

Kegagalan pemeriksaan pra-upgrade adalah masalah atau error yang terdeteksi oleh Cloud SQL selama proses verifikasi atau validasi pra-upgrade. Kegagalan ini terjadi sebelum proses upgrade yang sebenarnya dimulai dan dimaksudkan untuk mengidentifikasi potensi masalah atau inkompatibilitas yang dapat memengaruhi keberhasilan upgrade.

Kegagalan pemeriksaan pra-upgrade ditampilkan untuk kategori berikut:

  • Ekstensi yang tidak kompatibel: mendeteksi ekstensi PostgreSQL yang tidak kompatibel dengan versi tujuan instance.
  • Dependensi yang tidak didukung: mengidentifikasi dependensi yang tidak lagi didukung atau perlu diupdate.
  • Inkompatibilitas format data: memverifikasi inkonsistensi data yang muncul dari berbagai faktor, termasuk perbedaan dalam struktur data khusus versi, perubahan dalam encoding dan pengurutan, modifikasi pada jenis data, dan penyesuaian pada katalog sistem.

Tabel berikut mencantumkan kegagalan pemeriksaan pra-upgrade dan pesan errornya:

Kegagalan pemeriksaan pra-upgrade Pesan error
Cloud SQL mendeteksi jenis data yang tidak dikenal. Please remove the following usages of 'Unknown' data types before attempting an upgrade: (database: db_name, relation: rel_name, attribute: attr_name)
Saat mengupgrade ke PostgreSQL 12 atau versi yang lebih baru, Cloud SQL akan mendeteksi jenis data 'sql_identifier'. Please remove the following usages of 'sql_identifier' data types before attempting an upgrade: (database: db_name, relation: rel_name, attribute: attr_name)
Cloud SQL mendeteksi jenis data reg*. Please remove the following usages of 'reg*' data types before attempting an upgrade: (database: db_name, relation: rel_name, attribute: attr_name)
Cloud SQL mendeteksi bahwa nilai
LC_COLLATE untuk database postgres adalah kumpulan karakter yang bukan en_US.UTF8.
Please change the 'LC_COLLATE' value of the postgres database to 'en_US.UTF8' before attempting an upgrade
Cloud SQL mendeteksi tabel yang memiliki ID objek (OID). Please remove the following usages of tables with OIDs before attempting an upgrade: (database: db_name, relation: rel_name)
Cloud SQL mendeteksi jenis data komposit. Please remove the following usages of 'composite' data types before attempting an upgrade: (database: db_name, relation: rel_name, attribute: attr_name)
Cloud SQL mendeteksi operator akhiran yang ditentukan pengguna. Please remove the following usages of 'postfix operators' before attempting an upgrade: (database: db_name, operation id: op_id, operation namespace: op_namespace, operation name: op_name, type namespace: type_namespace, type name: type_name)
Cloud SQL mendeteksi fungsi polimorfik yang tidak kompatibel. Please remove the following usages of 'incompatible polymorphic' functions before attempting an upgrade: (database: db_name, object kind: obj_kind, object name: obj_name)
Cloud SQL mendeteksi konversi encoding yang ditentukan pengguna. Please remove the following usages of user-defined encoding conversions before attempting an upgrade: (database: db_name, namespace name: namespace_name, encoding conversions name: encod_name)
Cloud SQL mendeteksi jalur penelusuran kosong untuk fungsi ll_to_earth Please update the search path of the 'll_to_earth' function
Cloud SQL mendeteksi keberadaan file raster PostGIS yang diekstrak. PostGIS version upgrade has not been completed, unpackaged raster files present. Follow the steps at https://postgis.net/documentation/tips/tip-removing-raster-from-2-3/ to fix before major version upgrade.

Memperbaiki masalah jalur penelusuran kosong

Hal ini terjadi karena ekstensi earthdistance menggunakan jenis bumi dan kubus tanpa menentukan jalur penelusuran fungsi. Anda harus menentukan jalur ini yang diperlukan selama proses upgrade.

Untuk mengatasi masalah ini, perbaiki jalur penelusuran untuk fungsi ll_to_earth dengan menjalankan kueri ini: ALTER FUNCTION ll_to_earth SET search_path = public;

Lihat log upgrade

Jika terjadi masalah dengan permintaan upgrade yang valid, Cloud SQL akan menayangkan log error ke projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fpostgres-upgrade.log. Setiap entri log berisi label dengan ID instance untuk membantu Anda mengidentifikasi instance dengan error upgrade. Cari error upgrade tersebut dan selesaikan error tersebut.

Untuk melihat log error, ikuti langkah-langkah berikut:

  1. Di Konsol Google Cloud, buka halaman Instance Cloud SQL.

    Buka Instance Cloud SQL

  2. Untuk membuka halaman Ringkasan instance, klik nama instance.
  3. Di panel Operasi dan log di halaman RIngkasan, klik link Melihat log error PostgreSQL.

    Halaman Logs Explorer akan terbuka.

  4. Lihat log sebagai berikut:

    • Untuk mencantumkan semua log in error dalam sebuah project, pilih nama log dalam filter log Nama log.

    Untuk informasi selengkapnya tentang filter kueri, lihat Kueri lanjutan

    • Guna memfilter log error upgrade untuk satu instance, masukkan kueri berikut di kotak Masukkan semua kolom, setelah mengganti DATABASE_ID

    dengan project ID yang diikuti dengan nama instance dalam format ini: project_id:instance_name.

    resource.type="cloudsql_database"
    resource.labels.database_id="DATABASE_ID"
    logName : "projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fpostgres-upgrade.log"

    Misalnya, untuk memfilter log error upgrade berdasarkan instance bernama shopping-db yang berjalan di project buylots, gunakan filter kueri berikut:

     resource.type="cloudsql_database"
     resource.labels.database_id="buylots:shopping-db"
     logName : "projects/buylots/logs/cloudsql.googleapis.com%2Fpostgres-upgrade.log"

Entri log dengan awalan pg_upgrade_dump menunjukkan bahwa telah terjadi error upgrade. Contoh:

pg_upgrade_dump: error: query failed: ERROR: out of shared memory
HINT: You might need to increase max_locks_per_transaction.

Selain itu, entri log yang diberi label dengan nama file kedua .txt mungkin mencantumkan error lain yang mungkin ingin Anda selesaikan sebelum mencoba mengupgrade lagi.

Semua nama file ditemukan dalam file postgres-upgrade.log. Untuk menemukan nama file, lihat kolom labels.FILE_NAME.

Nama file yang mungkin berisi error yang perlu diselesaikan meliputi:

  • tables_with_oids.txt: File ini berisi tabel yang dicantumkan dengan ID objek (OID). Hapus atau ubah tabel agar tidak menggunakan OID.
  • tables_using_composite.txt: File ini berisi tabel yang dicantumkan menggunakan jenis komposit yang ditentukan sistem. Hapus atau ubah tabel agar tidak menggunakan jenis komposit ini.
  • tables_using_unknown.txt: File ini berisi tabel yang dicantumkan menggunakan jenis data UNKNOWN. Hapus atau ubah tabel agar tidak menggunakan jenis data ini.
  • tables_using_sql_identifier.txt: File ini berisi tabel yang dicantumkan menggunakan jenis data SQL_IDENTIFIER. Hapus atau ubah tabel agar tidak menggunakan jenis data ini.
  • tables_using_reg.txt: File ini berisi tabel yang dicantumkan menggunakan jenis data REG* (misalnya, REGCOLLATION atau REGNAMESPACE). Hapus atau ubah tabel agar tidak menggunakan jenis data ini.
  • postfix_ops.txt: File ini berisi tabel yang dicantumkan menggunakan operator akhiran (unary yang berada di sebelah kanan). Hapus atau ubah tabel agar tidak menggunakan operator ini.

Memeriksa memori

Jika instance tidak memiliki memori bersama yang cukup, Anda mungkin akan melihat pesan error: ERROR: out of shared memory. Error ini kemungkinan besar terjadi jika Anda memiliki lebih dari 10,000 tabel.

Sebelum mencoba mengupgrade, tetapkan nilai flag max_locks_per_transaction menjadi sekitar dua kali lipat jumlah tabel dalam instance. Instance dimulai ulang saat Anda mengubah nilai flag ini.

Memeriksa kapasitas koneksi

Jika instance tidak memiliki kapasitas koneksi yang cukup, Anda mungkin akan melihat pesan error ini: ERROR: Insufficient connections.

Cloud SQL merekomendasikan agar Anda meningkatkan nilai flag max_connections dengan jumlah database dalam instance Anda. Instance dimulai ulang saat Anda mengubah nilai flag ini.

Memeriksa referensi kolom yang ambigu

Jika memiliki referensi kolom yang ambigu dalam tampilan, Anda mungkin akan melihat pesan error ini: ERROR: column reference "<column_name>" is ambiguous. Masalah ini terjadi saat versi PostgreSQL baru memperkenalkan perubahan pada struktur tampilan katalog sistem seperti pg_stat_activity dan pg_stat_replication. Hal ini dapat mengganggu tampilan kustom yang mengandalkan urutan kolom.

Untuk memeriksa pesan error ini, tambahkan kueri ini ke editor kueri: textPayload =~ "ERROR: column reference .+ is ambiguous at character \d+"

Anda dapat mengatasi masalah ini dengan cara berikut:

  1. Sesuaikan tampilan kustom Anda.

    Perbarui referensi kolom di tampilan kustom Anda agar selaras dengan definisi tampilan katalog sistem baru (seperti pg_stat_activity dan pg_stat_replication) di versi PostgreSQL target.

  2. Buat ulang tampilan Anda.

    Hapus tampilan kustom Anda sebelum melakukan upgrade versi utama. Buat ulang tampilan setelah upgrade selesai, pastikan tampilan tersebut kompatibel dengan struktur baru.

Untuk contoh masalah yang lebih mendetail dan insight lebih lanjut, lihat diskusi stack overflow ini

Memeriksa SRF dalam pernyataan CASE

Jika mengupgrade instance dari versi 9.6 dan menggunakan fungsi yang menampilkan set dalam pernyataan CASE, Anda mungkin melihat pesan error ini ERROR: set-returning functions are not allowed in CASE. Masalah ini terjadi karena mulai versi 10 dan seterusnya, penggunaan fungsi yang menampilkan set dalam pernyataan CASE tidak diizinkan.

Untuk mengatasi masalah ini dan berhasil mengupgrade instance, pastikan bahwa pernyataan CASE yang menggunakan fungsi yang menampilkan set diubah untuk menghindari penggunaannya sebelum mencoba lagi upgrade. Beberapa SRF yang umum digunakan mencakup:

  • unnest()
  • generate_series()
  • array_agg()
  • regexp_split_to_table()
  • jsonb_array_elements()
  • json_array_elements()
  • sonb_each()
  • json_each()

Memeriksa tampilan yang dibuat di transmisi kustom

Jika Anda memiliki tampilan yang dibuat di transmisi kustom, pesan error yang mirip dengan berikut akan muncul: ERROR: cannot cast type <type_1> to <type_2>. Masalah ini terjadi karena masalah izin pada transmisi yang dibuat secara kustom.

Untuk mengatasi masalah ini, update instance Anda ke [PostgreSQL version].R20240910.01_02

Untuk mengetahui informasi selengkapnya, lihat Pemeliharaan mandiri.

Memeriksa kepemilikan pemicu peristiwa

Jika pemicu peristiwa dimiliki oleh pengguna yang tidak memiliki peran cloudsqlsuperuser, Anda mungkin mendapatkan pesan error seperti ERROR: permission denied to change owner of event trigger "<trigger_name>". Masalah ini disebabkan oleh masalah izin saat mencoba membuat ulang pemicu ini selama upgrade. Anda dapat menggunakan tambahkan kueri berikut di editor kueri untuk memeriksa pesan error ini textPayload =~ "ERROR: permission denied to change owner of event trigger .+ "

Untuk mengatasi hal ini, verifikasi kepemilikan semua pemicu peristiwa dalam instance Anda. Pastikan pemilik setiap pemicu adalah cloudsqlsuperuser. Jika pemicu apa pun dimiliki oleh pengguna lain, perbarui kepemilikannya ke cloudsqlsuperuser sebelum mencoba upgrade lagi. Anda dapat menggunakan kueri berikut untuk mengubah kepemilikan ALTER EVENT TRIGGER <trigger_name> OWNER TO <cloudsqlsuperuser>;

Anda dapat menggunakan kueri berikut untuk mendapatkan daftar pemicu peristiwa dan detail pemiliknya SELECT evtname AS trigger_name, evtowner::regrole AS owner FROM pg_event_trigger;

Memeriksa kolom yang dihasilkan dari tabel yang tidak dicatat

Jika memiliki tabel yang tidak dicatat dalam log dan telah membuat kolom, Anda mungkin akan melihat pesan error ERROR: unexpected request for new relfilenumber in binary upgrade mode. Masalah ini terjadi karena perbedaan karakteristik persistensi antara tabel dan urutan untuk kolom yang dihasilkan.

Untuk mengatasi masalah ini, lakukan hal berikut:

  1. Hapus tabel yang tidak dicatat: jika memungkinkan, hapus tabel yang tidak dicatat yang ditautkan ke kolom yang dihasilkan. Pastikan bahwa kebocoran data dapat dimitigasi dengan aman sebelum melanjutkan.
  2. Konversi ke tabel permanen: untuk sementara, konversi tabel yang tidak dicatat ke dalam log menjadi tabel permanen menggunakan langkah-langkah berikut:
    1. Konversi tabel ke tabel yang dicatat ke dalam log ALTER TABLE SET LOGGED;
    2. Melakukan upgrade versi utama
    3. Konversikan tabel kembali ke tabel yang tidak dicatat ke dalam log ALTER TABLE SET UNLOGGED

Anda dapat mengidentifikasi semua tabel tersebut menggunakan kueri berikut :

SELECT
  relnamespace::regnamespace,
  c.relname AS table_name,
  a.attname AS column_name,
  a.attidentity AS identity_type
FROM
  pg_catalog.pg_class c
  JOIN pg_catalog.pg_attribute a ON a.attrelid = c.oid
WHERE
  a.attidentity IN ('a', 'd') AND c.relkind = 'r' AND c.relpersistence = 'u'
ORDER BY c.relname, a.attname;

Memeriksa flag kustom untuk instance PostgreSQL

Jika Anda melakukan upgrade ke instance PostgreSQL, versi 14 atau yang lebih baru, periksa nama flag database kustom yang Anda konfigurasi untuk instance tersebut. Hal ini karena PostgreSQL memberlakukan batasan tambahan pada nama yang diizinkan untuk parameter kustom.

Karakter pertama flag database kustom harus alfabetis (A-Z atau a-z). Semua karakter berikutnya dapat berupa alfanumerik, karakter khusus garis bawah (_), atau karakter khusus tanda dolar ($).

Menghapus ekstensi

Jika Anda mengupgrade instance Cloud SQL, Anda mungkin akan melihat pesan error ini: pg_restore: error: could not execute query: ERROR: role "16447" does not exist.

Untuk menyelesaikan masalah ini, ikuti langkah berikut:

  1. Hapus ekstensi pg_stat_statements dan pgstattuple.
  2. Lakukan upgrade.
  3. Instal ulang ekstensi.

Memulihkan ke versi utama sebelumnya

Jika sistem database yang telah diupgrade tidak berfungsi seperti yang diharapkan, Anda mungkin perlu memulihkan instance ke versi sebelumnya. Anda melakukannya dengan memulihkan cadangan pra-upgrade ke instance pemulihan Cloud SQL, yang merupakan instance baru yang menjalankan versi upgrade.

Untuk memulihkan ke versi sebelumnya, lakukan langkah-langkah berikut:

  1. Identifikasi cadangan pra-upgrade Anda.

    Lihat Cadangan upgrade otomatis.

  2. Buat instance pemulihan.

    Buat instance Cloud SQL baru menggunakan veri utama yang dijalankan Cloud SQL saat cadangan pra-upgrade dibuat. Tetapkan flag dansetelan instance yang sama dengan yang digunakan instance asli.

  3. Pulihkan cadangan pra-upgrade Anda.

    Pulihkan cadangan pra-upgrade Anda ke instance pemulihan. Mungkin memerlukan waktu beberapa menit untuk menyelesaikan proses.

  4. Tambahkan replika baca Anda.

    Jika Anda menggunakan replika baca, tambahkan satu per satu.

  5. Hubungkan aplikasi Anda.

    Setelah memulihkan sistem database Anda, perbarui aplikasi Anda dengan detail mengenai instance pemulihan dan replika bacanya. Anda dapat melanjutkan penyaluran traffic pada versi pra-upgrade database Anda.

FAQ

Pertanyaan berikut mungkin muncul saat mengupgrade versi utama database.

Apakah instance saya tidak tersedia selama upgrade?
Tentu saja. Instance Anda tetap tidak tersedia selama beberapa waktu saat Cloud SQL melakukan upgrade.
Berapa lama waktu yang diperlukan untuk melakukan upgrade?

Proses upgrade satu instance biasanya memerlukan waktu kurang dari 10 menit. Jika konfigurasi instance Anda menggunakan sejumlah kecil vCPU atau memori, upgrade mungkin memerlukan waktu lebih lama.

Jika instance Anda menghosting terlalu banyak database atau tabel, atau database Anda berukuran sangat besar, upgrade mungkin memerlukan waktu berjam-jam atau bahkan waktu habis, karena waktu upgrade sesuai dengan jumlah objek dalam database Anda. Jika Anda memiliki beberapa instance yang perlu diupgrade, total waktu upgrade Anda akan meningkat secara proporsional.

Dapatkah saya memantau setiap langkah dalam proses upgrade?
Saat Cloud SQL mengizinkan Anda untuk memantau apakah operasi upgrade masih berlangsung, Anda tidak dapat melacak setiap langkah di setiap upgrade.
Dapatkah saya membatalkan upgrade setelah memulainya?
Tidak, Anda tidak dapat membatalkan upgrade setelah dimulai. Jika upgrade gagal, Cloud SQL akan otomatis memulihkan instance Anda di versi sebelumnya.
Apa yang terjadi dengan setelan saya selama upgrade?

Saat Anda melakukan upgrade versi tama secara langsung, Cloud SQL menyimpan setelan database Anda, termasuk nama instance, alamat IP, nilai flag yang dikonfigurasi secara eksplisit, dan data pengguna. Namun, nilai default variabel sistem mungkin berubah. Misalnya, nilai default flag password_encryption di PostgreSQL 13 dan sebelumnya adalah md5. Saat Anda mengupgrade ke PostgreSQL 14, nilai default flag ini berubah menjadi scram-sha-256.

Untuk mempelajari lebih lanjut, lihat Mengonfigurasi flag database. Jika flag atau nilai tertentu tidak lagi didukung dalam versi target Anda, Cloud SQL secara otomatis akan menghapus flag tersebut selama proses upgrade.

Langkah berikutnya