Peningkatan versi utama di Azure Database for PostgreSQL

Instans server fleksibel Azure Database for PostgreSQL Anda mendukung PostgreSQL versi 18, 17, 16, 15, 14, 13, 12, 11. Komunitas Postgres merilis versi utama baru yang berisi fitur baru sekitar setahun sekali. Selain itu, setiap versi utama menerima perbaikan bug berkala dalam bentuk rilis minor. Pembaruan versi minor mencakup perubahan yang mudah disesuaikan dengan versi sebelumnya dari aplikasi yang ada. Instans server Azure Database for PostgreSQL fleksibel secara berkala memperbarui versi minor selama jendela pemeliharaan pelanggan.

Peningkatan versi utama lebih rumit daripada peningkatan versi minor. Mereka dapat menyertakan perubahan internal dan fitur baru yang mungkin tidak kompatibel dengan versi sebelumnya dari aplikasi yang ada.

Instans server fleksibel Azure Database for PostgreSQL Anda memiliki fitur yang melakukan peningkatan versi utama server di tempat hanya dengan sekali klik. Fitur ini menyederhanakan proses peningkatan dengan meminimalkan gangguan pada pengguna dan aplikasi yang mengakses server.

Peningkatan di tempat mempertahankan nama server dan pengaturan lain dari server saat ini setelah peningkatan ke versi utama yang lebih baru. Mereka tidak memerlukan migrasi data atau perubahan pada string koneksi aplikasi. Peningkatan di tempat lebih cepat dan melibatkan waktu henti yang lebih singkat daripada migrasi data.

Nota

Azure Database for PostgreSQL mendukung peningkatan versi utama secara langsung hanya ke versi PostgreSQL yang didukung saat ini. Versi target harus didukung secara resmi oleh Azure pada saat peningkatan. Portal Azure mencegah pemilihan versi yang tidak didukung, tetapi panggilan API atau CLI yang menargetkan versi yang tidak digunakan lagi akan gagal. Selalu lihat Azure kebijakan penerapan versi PostgreSQL dan panduan cara upgrade sebelum memulai peningkatan versi utama.

Proses Peningkatan

Berikut adalah beberapa pertimbangan penting untuk peningkatan versi utama in-place:

  • Sebelum memulai peningkatan, pastikan server Anda memiliki setidaknya 10-20% penyimpanan gratis yang tersedia. Selama proses peningkatan, file log sementara dan operasi metadata dapat meningkatkan penggunaan disk. Ruang kosong yang tidak mencukupi dapat mengakibatkan kegagalan pemutakhiran atau masalah rollback.
  • Selama proses peningkatan versi utama di tempat, instans server fleksibel Azure Database for PostgreSQL Anda menjalankan prosedur pra-pemeriksaan untuk mengidentifikasi potensi masalah yang dapat menyebabkan peningkatan gagal.
    • Jika pra-pemeriksaan menemukan ketidaksesuaian, akan dibuat peristiwa log yang menunjukkan bahwa pra-pemeriksaan peningkatan gagal, disertai dengan pesan kesalahan.
    • Jika precheck berhasil, instans server fleksibel Azure Database for PostgreSQL menghentikan layanan dan mengambil cadangan implisit tepat sebelum memulai peningkatan. Layanan ini dapat menggunakan cadangan ini untuk memulihkan instans database ke versi sebelumnya jika ada kesalahan peningkatan.
  • Instans server fleksibel Azure Database for PostgreSQL menggunakan alat pg_upgrade untuk melakukan peningkatan versi utama di tempat. Layanan ini memberikan fleksibilitas untuk melewati versi dan meningkatkan langsung ke versi yang lebih baru.
  • Selama peningkatan versi utama server yang mendukung high availability (HA), layanan menonaktifkan HA, melakukan peningkatan pada server utama, dan kemudian mengaktifkan kembali HA setelah peningkatan selesai. Mengaktifkan kembali HA memerlukan kapasitas yang memadai untuk menyediakan instans siaga baru.
  • Sebagian besar ekstensi secara otomatis ditingkatkan ke versi yang lebih baru selama peningkatan versi utama di tempat, dengan beberapa pengecualian.
  • Proses peningkatan versi utama lokal untuk instance server yang fleksibel Azure Database for PostgreSQL secara otomatis mengimplementasikan versi minor terbaru yang didukung.
  • Durasi peningkatan tergantung pada ukuran dan kompleksitas database Anda, termasuk jumlah objek (tabel, indeks, skema), objek besar, dan ekstensi. Beban kerja yang lebih besar atau lebih kompleks mungkin mengalami waktu peningkatan yang lebih lama.
  • Transaksi jangka panjang atau beban kerja tinggi sebelum peningkatan dapat meningkatkan waktu yang diperlukan untuk mematikan database dan meningkatkan waktu peningkatan.
  • Setelah peningkatan versi utama di tempat berhasil, tidak ada cara otomatis untuk kembali ke versi sebelumnya. Anda dapat melakukan pemulihan point-in-time (PITR) ke waktu sebelum peningkatan untuk memulihkan versi sebelumnya di server baru.
  • Instans server fleksibel Azure Database for PostgreSQL Anda mengambil rekam jepret database Anda selama peningkatan. Rekam jepret diambil sebelum peningkatan dimulai. Jika peningkatan gagal, sistem secara otomatis memulihkan database Anda ke statusnya dari rekam jepret.
  • PostgreSQL 16 memperkenalkan langkah-langkah keamanan berbasis peran. Setelah peningkatan versi utama pada instans server fleksibel Azure Database for PostgreSQL, pengguna pertama yang dibuat di server—yang diberikan opsi ADMIN—sekarang akan memiliki hak administratif atas peran lain untuk operasi pemeliharaan penting.

Pertimbangan dan Batasan Peningkatan

Jika operasi pra-pemeriksaan gagal selama peningkatan versi utama di tempat, peningkatan diblokir dengan pesan kesalahan terperinci. Di bawah ini adalah batasan yang diketahui yang dapat menyebabkan peningkatan gagal atau berperilaku tidak terduga:

Konfigurasi Server yang Tidak Didukung

  • Replika baca tidak didukung selama peningkatan di lokasi. Anda harus menghapus replika baca (termasuk replika baca bertingkat) sebelum memutakhirkan server utama. Setelah peningkatan, Anda dapat membuat ulang replika tersebut.
  • Aturan lalu lintas jaringan dapat memblokir operasi peningkatan.
    • Pastikan instans server fleksibel Anda dapat mengirim/menerima lalu lintas pada port 5432 dan 6432 dalam jaringan virtualnya dan ke Azure Storage (untuk pengarsipan log).
    • Jika Kelompok Keamanan Jaringan (NSG) membatasi lalu lintas ini, HA tidak akan mengaktifkan kembali secara otomatis pasca-peningkatan. Anda mungkin perlu memperbarui aturan NSG secara manual dan mengaktifkan kembali HA.
  • Slot replikasi logis harus dihapus sebelum melakukan peningkatan versi utama langsung di lokasi. Anda dapat membuatnya kembali setelah peningkatan selesai.
  • Tampilan bergantung pada pg_stat_activity tidak didukung selama pembaruan versi utama.
  • Jika Anda melakukan peningkatan dari PG11 ke versi yang lebih tinggi, Anda harus terlebih dahulu mengonfigurasi server fleksibel Anda untuk menggunakan autentikasi SCRAM dengan mengaktifkan SCRAM dan mengatur ulang semua kata sandi peran masuk.

Batasan Ekstensi

Peningkatan versi utama di tempat tidak mendukung semua ekstensi PostgreSQL. Peningkatan akan gagal selama pemeriksaan awal jika ekstensi yang tidak didukung ditemukan.

  • Ekstensi berikut didukung untuk penggunaan reguler, tetapi akan memblokir peningkatan versi utama di tempat jika ada. Hapus sebelum peningkatan dan aktifkan kembali setelahnya, jika didukung pada versi target: timescaledb, , postgres_fdwsession_variable, pg_hint_plan, plv8.
  • Ekstensi berikut adalah ekstensi utilitas non-persisten dan perlu dihilangkan dan dibuat ulang setelah peningkatan berdasarkan desain: pg_repack, hypopg.
  • Saat meningkatkan ke PostgreSQL 17 ke atas, ekstensi berikut tidak didukung dan harus dihapus sebelum peningkatan. Anda dapat mengaktifkannya kembali hanya jika didukung pada versi target: age, , azure_aihll, pg_diskann, pgrouting.

Pertimbangan PostGIS-Specific

Jika Anda menggunakan PostGIS atau ekstensi dependen apa pun, Anda harus mengonfigurasi parameter server search_path untuk menyertakan:

  • Skema yang terkait dengan PostGIS
  • Ekstensi dependen, termasuk: postgis, , postgis_raster, postgis_sfcgal, postgis_tiger_geocoder, postgis_topology, address_standardizer, address_standardizer_data_us, fuzzystrmatch
  • Kegagalan untuk mengonfigurasi search_path dengan benar dapat menyebabkan kegagalan peningkatan atau objek rusak pasca-peningkatan.

Pertimbangan peningkatan lainnya

  • Pemicu peristiwa: Pemicu peristiwa diblokir oleh pemeriksaan peningkatan pra-upgrade karena mereka terhubung ke perintah DDL dan dapat mereferensikan katalog sistem yang berubah di antara versi utama—hapus semua EVENT TRIGGER sebelum proses peningkatan, dan buat ulang setelah peningkatan untuk memastikan peningkatan yang lancar.
  • Objek besar (LO): Database dengan jutaan objek besar (disimpan dalam pg_largeobject) dapat menyebabkan kegagalan peningkatan karena penggunaan memori atau volume log yang tinggi. Gunakan utilitas vacuumlo untuk membersihkan LO yang tidak digunakan, dan pertimbangkan untuk meningkatkan skala server Anda sebelum meningkatkan jika banyak LO yang masih digunakan.

Peringatan

Berhati-hatilah penggunaan penyedot debu. vacuumlo mengidentifikasi objek besar tanpa induk berdasarkan kolom referensi konvensional (oid, lo). Jika aplikasi Anda menggunakan jenis referensi kustom atau tidak langsung, objek besar yang valid mungkin salah dihapus. Selain itu, vacuumlo dapat mengonsumsi CPU, memori, dan IOPS yang signifikan, terutama dalam database dengan jutaan objek besar. Jalankan selama periode pemeliharaan dan uji terlebih dahulu pada lingkungan non-produksi.

Pasca peningkatan

Setelah peningkatan versi utama selesai, sebaiknya jalankan ANALYZE perintah di setiap database untuk me-refresh pg_statistic tabel. Statistik yang hilang atau basi dapat menyebabkan rencana kueri yang buruk, yang pada gilirannya dapat menurunkan performa dan mengambil memori yang berlebihan.

postgres=> analyze;
ANALYZE

Menampilkan log peningkatan

Gunakan PG_Upgrade_Logs untuk memantau kemajuan peningkatan dan memecahkan masalah.

Aktifkan log pembaruan menggunakan parameter log server:

  • Atur logfiles.download_enable ke AKTIF.
  • Konfigurasikan retensi dengan logfiles.retention_days.

Lihat Konfigurasi pengambilan log server PostgreSQL dan log peningkatan versi utama untuk memulai.

Akses PG_Upgrade_Logs dari UI log server.

  • Tinjau PG_Upgrade_Logs selama dan setelah peningkatan untuk memantau kemajuan dan mendiagnosis kegagalan atau penundaan.
  • Periksa kesalahan atau peringatan jika peningkatan gagal atau membutuhkan waktu lebih lama dari yang diharapkan.
  • Gunakan log untuk mengidentifikasi masalah pemblokiran dan mengambil tindakan korektif dengan cepat.

Manfaat menggunakan log peningkatan

  • Mendiagnosis masalah dengan cepat: Gunakan PG_Upgrade_Logs untuk meninjau setiap langkah peningkatan dan mengidentifikasi kesalahan atau peringatan.
  • Memecahkan masalah secara efisien: Menganalisis log untuk menentukan kegagalan, mengurangi waktu henti, dan mengambil tindakan korektif lebih cepat.

PG_Upgrade_Logs membantu Anda memahami apa yang terjadi selama peningkatan dan menyelesaikan masalah dengan percaya diri.

Nota

Peningkatan versi utama di tempat didukung pada server yang dimigrasikan secara otomatis. Setelah berhasil dilakukan Peningkatan Versi Utama di tempat pada server yang dimigrasikan secara otomatis, format nama pengguna username@servername tidak akan lagi didukung. Sebagai gantinya, Anda harus menggunakan format standar: nama pengguna. Untuk menghindari masalah autentikasi, tinjau dan perbarui dengan cermat semua string koneksi di aplikasi dan skrip Anda untuk memastikan mereka menggunakan format nama pengguna yang diperbarui setelah peningkatan.

Konten terkait

  • Last updated on