Lakukan peningkatan versi utama menggunakan mode tanpa downtime - ApsaraDB RDS

Gunakan mode zero-downtime untuk meningkatkan versi mesin utama instans ApsaraDB RDS for PostgreSQL sambil menjaga database tetap beroperasi penuh. Instans menerima operasi baca dan tulis sepanjang proses. Selama alih bencana akhir, instans masuk ke mode read-only hanya selama beberapa detik—durasi pastinya bergantung pada jumlah sequences dan volume transaksi besar yang ditulis.

Untuk pendekatan peningkatan lainnya, lihat Pengenalan solusi peningkatan versi utama.

Cara kerja

Mode zero-downtime menjalankan pg_upgrade untuk meningkatkan snapshot instans Anda ke versi target, lalu menggunakan replikasi logis native untuk menyinkronkan perubahan inkremental dari sumber. Anda memverifikasi instans tujuan sebelum memicu alih bencana. Saat Anda memulai alih bencana, instans menjadi read-only sebentar selagi sequences disinkronkan, lalu trafik dialihkan ke versi baru.

Penagihan

Tanpa biaya.

Prasyarat

Sebelum memulai, pastikan bahwa:

Instans menjalankan ApsaraDB RDS for PostgreSQL 16 atau versi sebelumnya.
Jenis penyimpanan adalah cloud disk. Instans dengan disk lokal berkinerja tinggi hanya dapat menggunakan mode penyebaran biru-hijau.
Metode penagihan adalah pay-as-you-go atau subscription. Instans Serverless hanya dapat menggunakan mode penyebaran biru-hijau.
Instans bukan read-only instance atau dedicated cluster instance.
Parameter wal_level diatur ke logical. Peningkatan zero-downtime mengandalkan replikasi logis, sehingga jika wal_level bernilai replica atau minimal, pemeriksaan pra-peningkatan akan gagal. Jika tidak, modifikasi parameter instans sebelum melanjutkan.
Babelfish tidak diaktifkan. Nomor versi mesin minor tidak boleh diakhiri dengan babelfish.

Catatan penggunaan

Tinjau hal-hal berikut sebelum memulai peningkatan.

Dampak bisnis

Operasi DDL (Data Definition Language) dilarang sejak peningkatan dimulai hingga alih bencana selesai. Waktu downtime untuk instans sumber diukur dalam hitungan detik dan bergantung pada jumlah sequences serta volume transaksi besar yang ditulis.

Replication slots

Jika instans sumber memiliki publication (ujung penerbit replication slot), replication slot tersebut akan hilang setelah peningkatan.
Jika instans sumber memiliki subscriber (ujung pelanggan replication slot), peningkatan dapat menyebabkan masalah sinkronisasi data akibat preemption replication slot. Lihat bagian FAQ untuk detailnya.

Perubahan parameter

Parameter yang tidak didukung oleh versi tujuan akan dihapus secara otomatis.
Parameter yang nilainya berada di luar rentang valid untuk versi tujuan akan diatur ulang ke nilai default template parameter versi tujuan.
statement_timeout sementara diatur ke 0 selama peningkatan dan dikembalikan ke nilai aslinya setelah peningkatan selesai.

Tugas DTS

Jika instans merupakan sumber atau tujuan Data Transmission Service (DTS), buat ulang tugas DTS setelah peningkatan.

Kompatibilitas plugin

Peningkatan secara otomatis memperbarui instans ke versi mesin minor terbaru, yang dapat menyebabkan masalah kompatibilitas plugin.

Backup

Cadangan penuh dilakukan baik sebelum maupun sesudah peningkatan untuk mendukung pemulihan berbasis kloning.

Dampak pada berbagai tahap peningkatan

Tahap peningkatan	Dampak
Mulai peningkatan versi utama	Operasi DDL dilarang.
Buat replication slots dan publications	Operasi DDL dilarang. Log WAL mulai menumpuk.
Mulai subscriber dan bangun hubungan replikasi logis	Operasi DDL dilarang. Log WAL mulai dikonsumsi dan tidak lagi menumpuk. Replikasi logis menghasilkan muatan resource tertentu; muatan ini berkaitan erat dengan jumlah database dan traffic.
Mulai alih bencana	Operasi DDL dilarang. Replikasi logis menghasilkan muatan resource tertentu; muatan ini berkaitan erat dengan jumlah database dan traffic. Instans dalam mode read-only; durasi read-only terkait dengan jumlah sequences.
Selesaikan peralihan (upgrade selesai)	Slot replikasi logis dihapus dan muatan resource yang dihasilkan oleh replikasi logis dihilangkan. Instans kembali ke operasi baca-tulis normal.

Setelah tugas peningkatan dimulai, buka tab Upgrade History. Di kolom Upgrade Log pada tugas peningkatan target, klik View Information untuk melihat proses peningkatan secara detail.

Langkah 1: Jalankan pemeriksaan pra-peningkatan

Masuk ke Konsol ApsaraDB RDS. Di bilah navigasi atas, pilih wilayah tempat instans berada, temukan instans tersebut, lalu klik ID-nya.
Di panel navigasi kiri, klik Major Version Upgrade.

Jika Major Version Upgrade tidak muncul, periksa versi dan konfigurasi instans Anda. Untuk detailnya, lihat Prasyarat.
Di tab Upgrade Check, klik Create upgrade check report.
Pilih versi tujuan, atur Upgrade Mode ke Zero Downtime, lalu klik OK. Status instans berubah menjadi Maintaining Instance. Setelah pemeriksaan selesai, status kembali menjadi Running.
Tinjau hasil pemeriksaan: Untuk bantuan menafsirkan hasil pemeriksaan, lihat Menafsirkan laporan pemeriksaan peningkatan versi utama ApsaraDB RDS for PostgreSQL.
- Success atau Warning: lanjutkan ke Langkah 2.
- Failed: klik View Information, perbaiki masalah yang dilaporkan, lalu jalankan pemeriksaan lagi.
Penting
- Jika hasilnya Warning, perbaiki semua masalah yang dilaporkan dan jalankan ulang pemeriksaan hingga hasilnya Success. - Jika Anda membuat plugin pada instans utama setelah pemeriksaan berhasil, jalankan ulang pemeriksaan sebelum melakukan peningkatan.

Langkah 2: Mulai peningkatan

Sebelum melakukan langkah ini, pastikan Anda telah menyelesaikan Langkah 1: Jalankan pemeriksaan pra-peningkatan: di tab Upgrade Check, buat laporan pemeriksaan peningkatan, dan pastikan hasil pemeriksaan adalah Success atau Warning sebelum membuat tugas peningkatan.

Klik tab Upgrade Instance, baca peringatan, pilih versi dari Select The Destination Version, lalu klik Create Upgrade Task.
Di kotak dialog, baca prompt lalu klik OK.
Di bagian Create Major Engine Version Upgrade Task, atur Upgrade Mode ke Zero Downtime lalu klik Create.

Saat status instans berubah menjadi Migrating, tugas peningkatan telah dimulai.

Waktu yang dibutuhkan bergantung pada jumlah objek database dalam instans — semakin banyak objek, semakin lama waktu yang dibutuhkan. Lacak progres di Task Hub.

Penting

Tugas peningkatan tidak dapat dimodifikasi atau dihapus setelah dibuat.
Selama instans berada dalam status Migrating, tugas O&M (operasi dan pemeliharaan) seperti memodifikasi parameter, me-restart, atau melepas instans tidak didukung.

Langkah 3: Verifikasi dan alih bencana

Verifikasi instans tujuan

Saat status instans berubah dari Migrating menjadi Migrating Data Out, replikasi logis telah dibangun dan instans tujuan siap diverifikasi.

Buka tab Upgrade History dan gunakan Later Version Verification URL dari catatan peningkatan untuk menghubungkan ke instans tujuan dan memverifikasi data.

Instans tujuan dalam mode read-only selama fase ini. Operasi tulis tidak didukung.

Beralih ke versi baru

Setelah memastikan data sesuai harapan dan Upgrade Result menunjukkan Synchronizing, klik Switchover di kolom Upgrade Log.

- Jika Upgrade Result menunjukkan status berbeda, lihat Deskripsi hasil peningkatan. - Untuk membatalkan peningkatan, klik Cancel di kolom Upgrade Log. Tindakan ini akan menghapus slot replikasi logis, menghilangkan beban replikasi dari instans sumber, dan mengaktifkan kembali operasi DDL.
Di kotak dialog Switchover, atur Write Downtime Tolerance (dalam detik) lalu klik OK. Pengaturan ini memberi tahu sistem untuk menunggu replikasi lag selesai sebelum menyelesaikan alih bencana, yang menjamin konsistensi data. Selama menunggu ini, Upgrade Result menunjukkan Read-only. Jika periode toleransi terlampaui, sistem kembali ke Synchronizing dan menghapus batasan read-only. Saat Upgrade Result berubah menjadi Read-only, alih bencana sedang berlangsung dan status instans adalah Migrating. Untuk membatalkan alih bencana yang telah dimulai, klik Interrupted di kolom Upgrade Log.
Saat Upgrade Result berubah menjadi Succeeded, alih bencana selesai dan status instans menjadi Running. Verifikasi versi saat ini di halaman Basic Information instans.

Untuk melihat durasi read-only pasti setelah peningkatan, buka tab Upgrade History lalu klik View Information di kolom Upgrade Log. Waktu read-only adalah interval antara Switching time dan Switching completion time, dan tidak mencakup waktu ketika instans tidak dapat dijangkau akibat propagasi Cache DNS.

Deskripsi hasil peningkatan

Kolom Upgrade Result di tab Upgrade History menampilkan salah satu nilai berikut selama peningkatan.

Hasil peningkatan	Status instans	Deskripsi	Aksi yang tersedia
Running	Migrating	Tugas peningkatan sedang berjalan.	Tidak ada.
Synchronizing	Migrating Data Out	Replikasi logis normal.	Alih ke versi baru, atau batalkan peningkatan.
Replication Interrupted	Migrating Data Out	Replikasi logis tidak normal.	Lihat log peningkatan untuk menentukan penyebabnya, atau batalkan peningkatan.
Read-only	Migrating	Alih bencana sedang berlangsung. Instans dalam mode read-only selagi sequences disinkronkan.	Break: batalkan alih bencana.
Peralihan	Migrasi	Sinkronisasi sequence selesai; menyelesaikan alih bencana.	Tidak ada.
Cancel	Running	Tugas peningkatan dibatalkan.	Tidak ada.
Succeeded	Running	Tugas peningkatan berhasil diselesaikan.	Tidak ada.

Referensi API

Operasi API	Deskripsi
UpgradeDBInstanceMajorVersionPrecheck	Menjalankan pemeriksaan pra-peningkatan untuk peningkatan versi utama.
DescribeUpgradeMajorVersionPrecheckTask	Mengkueri laporan pemeriksaan pra-peningkatan.
UpgradeDBInstanceMajorVersion	Meningkatkan versi mesin utama.
DescribeUpgradeMajorVersionTask	Mengkueri riwayat tugas peningkatan versi utama.

FAQ

Apakah saya dapat memodifikasi instans selama peningkatan versi utama?

Tidak. Modifikasi instans — termasuk mengubah tipe instans — tidak didukung selama peningkatan. Lakukan operasi lain hanya setelah peningkatan selesai.

Apakah peningkatan versi utama otomatis didukung?

Tidak. Peningkatan otomatis ke versi mesin utama tidak didukung.

Apakah penurunan versi utama didukung?

Tidak. Menurunkan ke versi utama yang lebih rendah setelah peningkatan tidak didukung. Untuk menjalankan versi yang lebih rendah, beli instans baru yang menjalankan versi tersebut dan gunakan DTS untuk melakukan migrasi data.

Setelah peningkatan versi utama, muncul konflik `raster_overviews` saat saya membuat view `raster_overviews` pada instans tujuan. Bagaimana cara memperbaikinya?

Konflik ini dapat terjadi ketika versi PostGIS lebih awal dari 2.5.2 dan instans sumber menjalankan PostgreSQL 10 atau 11, lalu Anda meningkatkan ke PostgreSQL 12.

Langkah 1: Tingkatkan plugin PostGIS pada instans sumber.

Jalankan perintah berikut dua kali untuk memastikan keberhasilannya.

SELECT PostGIS_Extensions_Upgrade();
SELECT PostGIS_Extensions_Upgrade();

Langkah 2: Pilih solusi berdasarkan apakah Anda menggunakan plugin PostGIS Raster.

Jika plugin PostGIS Raster sedang digunakan:

Jalankan perintah berikut pada instans sumber untuk melepas view raster_overviews dari ekstensi:

ALTER EXTENSION PostGIS_Raster DROP VIEW raster_overviews;
CREATE OR REPLACE VIEW raster_overviews AS SELECT 1;

Tingkatkan instans PostgreSQL ke minimal PostgreSQL 12.

Setelah peningkatan, buat ulang view pada instans tujuan:

CREATE OR REPLACE VIEW raster_overviews AS
SELECT
  current_database() AS o_table_catalog,
  n.nspname AS o_table_schema,
  c.relname AS o_table_name,
  a.attname AS o_raster_column,
  current_database() AS r_table_catalog,
  split_part(split_part(s.consrc, '''::name', 1), '''', 2)::name AS r_table_schema,
  split_part(split_part(s.consrc, '''::name', 2), '''', 2)::name AS r_table_name,
  split_part(split_part(s.consrc, '''::name', 3), '''', 2)::name AS r_raster_column,
  trim(both from split_part(s.consrc, ',', 2))::integer AS overview_factor
FROM
  pg_class c,
  pg_attribute a,
  pg_type t,
  pg_namespace n,
  (SELECT connamespace, conrelid, conkey, pg_get_constraintdef(oid) AS consrc FROM pg_constraint) AS s
WHERE
  t.typname = 'raster'::name
  AND a.attisdropped = false
  AND a.atttypid = t.oid
  AND a.attrelid = c.oid
  AND c.relnamespace = n.oid
  AND c.relkind = ANY(ARRAY['r'::char, 'v'::char, 'm'::char, 'f'::char])
  AND s.connamespace = n.oid
  AND s.conrelid = c.oid
  AND s.consrc LIKE '%_overview_constraint(%'
  AND NOT pg_is_other_temp_schema(c.relnamespace)
  AND has_table_privilege(c.oid, 'SELECT'::text);
ALTER EXTENSION PostGIS_Raster ADD VIEW raster_overviews;

Jika plugin PostGIS Raster tidak digunakan:

Letakkan plugin pada instance sumber:
```
DROP EXTENSION PostGIS_Raster;
```
Tingkatkan instans PostgreSQL ke minimal PostgreSQL 12.

Bagaimana cara mencegah masalah sinkronisasi data akibat preemption replication slot?

Untuk menyimpan data subscription pada instans sumber: pastikan instans sumber tidak mati akibat beban berlebih selama peningkatan. Jika mati, instans tujuan mungkin melakukan preemption replication slot, menyebabkan inkonsistensi data. Setelah peningkatan selesai, nonaktifkan subscription pada database tujuan:

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Untuk menyimpan data subscription pada instans tujuan: nonaktifkan subscription pada instans sumber sebelum peningkatan, lalu aktifkan kembali pada instans tujuan setelah peningkatan selesai.

Pada instans sumber (sebelum peningkatan):

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Pada instans tujuan (setelah peningkatan):

\c your_database
ALTER SUBSCRIPTION your_subscription_name ENABLE;

Untuk informasi lebih lanjut tentang penggunaan replication slots untuk subscription data, lihat Logical subscription dan Change tracking. Jika data subscription sudah tidak konsisten, lihat FAQ berikutnya.

Bagaimana menangani inkonsistensi data subscription setelah peningkatan?

Setelah peningkatan berhasil, hapus data tabel pada instans tujuan (yang menjalankan versi lebih tinggi), lalu buat ulang subscription dengan copy_data=true. Untuk detailnya, lihat ALTER SUBSCRIPTION.

Alternatifnya, gunakan klausa ON CONFLICT untuk menggabungkan data yang dikonsumsi oleh instans sumber ke instans tujuan. Contoh berikut menunjukkan cara menangani konflik berdasarkan timestamp:

CREATE TABLE my_tbl(id INT PRIMARY KEY, t TIMESTAMP, val TEXT);

INSERT INTO my_tbl VALUES (1, CURRENT_TIMESTAMP, 'a');
INSERT INTO my_tbl VALUES (2, CURRENT_TIMESTAMP, 'b');
INSERT INTO my_tbl VALUES (3, CURRENT_TIMESTAMP, 'c');

-- Perbarui jika baris masuk memiliki timestamp lebih baru
INSERT INTO my_tbl VALUES (1, CURRENT_TIMESTAMP, 'd')
ON CONFLICT(id) DO UPDATE
  SET t = excluded.t, val = excluded.val
  WHERE my_tbl.t < excluded.t;

-- Lewati jika baris masuk memiliki timestamp lebih lama
INSERT INTO my_tbl VALUES (2, CURRENT_TIMESTAMP - '10 hours'::interval, 'e')
ON CONFLICT(id) DO UPDATE
  SET t = excluded.t, val = excluded.val
  WHERE my_tbl.t < excluded.t;

-- Masukkan baris baru secara normal
INSERT INTO my_tbl VALUES (5, CURRENT_TIMESTAMP - '10 hours'::interval, 'f')
ON CONFLICT(id) DO UPDATE
  SET t = excluded.t, val = excluded.val
  WHERE my_tbl.t < excluded.t;

Mengapa fase migrasi data memakan waktu lebih lama dari yang diharapkan?

Fase migrasi data (saat status instans Migrating) membutuhkan waktu yang bergantung pada volume data, jumlah objek database, spesifikasi instans, dan bandwidth jaringan. Jika memakan waktu lebih lama dari yang diharapkan, periksa hal berikut:

Beban CPU dan I/O instans di Cloud Monitor.
Lag replikasi di view pg_stat_replication.
Apakah bandwidth jaringan telah mencapai batasnya.

ApsaraDB RDS:Lakukan peningkatan versi utama menggunakan mode tanpa downtime