Lakukan Peningkatan Versi Utama Tanpa Downtime - ApsaraDB RDS

Topik ini menjelaskan cara melakukan peningkatan versi utama untuk instans ApsaraDB RDS for PostgreSQL tanpa downtime.

Prasyarat

Instans menjalankan ApsaraDB RDS for PostgreSQL 16 atau versi sebelumnya.
Tipe penyimpanan instans adalah disk.
Catatan
Jika instans menggunakan disk lokal berkinerja tinggi, Anda hanya dapat melakukan peningkatan versi utama dalam mode penyebaran biru-hijau.
Metode penagihan instans adalah bayar sesuai penggunaan atau langganan.
Catatan
Jika instans adalah instans tanpa server, Anda hanya dapat melakukan peningkatan versi utama dalam mode penyebaran biru-hijau.
Instans bukan merupakan instans hanya baca atau instans klaster khusus.
Parameter wal_level dari instans diatur ke logical. Jika tidak, modifikasi parameter instans.
Babelfish tidak diaktifkan untuk instans. Nomor versi mesin minor tidak diakhiri dengan babelfish.

Informasi latar belakang

Dalam mode tanpa downtime, sistem menggunakan pg_upgrade untuk meningkatkan instans sumber ke versi tujuan dan menerapkan pembaruan inkremental menggunakan replikasi logis asli. Anda dapat melakukan alih bencana aktif selama peningkatan dan memverifikasi instans tujuan sebelum alih bencana. Instans dapat melakukan operasi baca dan tulis normal dari awal peningkatan hingga alih bencana aktif. Selama alih bencana, instans berada dalam mode hanya baca selama beberapa detik saja.

Di Konsol ApsaraDB RDS, Anda dapat meningkatkan versi utama database menggunakan mode penyebaran biru-hijau atau mode peningkatan lokal. Untuk membandingkan kedua mode tersebut, lihat Pengenalan solusi peningkatan versi utama.

Biaya peningkatan

Gratis.

Peringatan

Dampak Bisnis: Dampak pada layanan Anda minimal. Waktu downtime untuk instans sumber diukur dalam detik. Durasi downtime tergantung pada jumlah urutan dan penulisan transaksi besar pada instans.
Slot Replikasi:
- Jika instans sumber memiliki ujung penerbitan slot replikasi, slot replikasi akan hilang setelah peningkatan.
- Jika instans sumber memiliki ujung berlangganan slot replikasi, peningkatan dapat menyebabkan masalah sinkronisasi data karena perebutan slot replikasi. Untuk solusi, lihat Bagaimana cara mencegah masalah sinkronisasi data yang disebabkan oleh perebutan slot replikasi selama peningkatan?
Perubahan Parameter:
- Jika instans sumber menggunakan parameter yang tidak didukung oleh versi tujuan, parameter tersebut akan otomatis dihapus di versi tujuan.
- Jika nilai parameter di instans sumber berada di luar rentang valid untuk parameter yang sesuai di versi tujuan, parameter tersebut akan diatur ke nilai default template parameter untuk versi tujuan.
- Selama peningkatan, sistem sementara mengubah nilai statement_timeout menjadi 0 dan mengembalikannya ke nilai awal setelah peningkatan selesai.
Tugas DTS: Jika instans yang akan ditingkatkan adalah instans sumber atau tujuan untuk Layanan Transmisi Data (DTS), Anda perlu membuat ulang tugas DTS setelah peningkatan.
Masalah Kompatibilitas Plugin: Saat Anda melakukan peningkatan versi utama, sistem secara otomatis memperbarui instans ke versi mesin minor terbaru. Ini dapat menyebabkan masalah kompatibilitas plugin.
Cadangan Instans: Cadangan penuh dilakukan pada instans sebelum dan sesudah peningkatan. Ini memungkinkan pemulihan berbasis kloning selanjutnya.

Dampak pada instans pada tahap peningkatan yang berbeda

Tahap peningkatan	Dampak
Mulai peningkatan versi utama	Operasi DDL dilarang.
Buat slot replikasi dan publikasi	Operasi DDL dilarang. Log WAL mulai menumpuk.
Mulai subscriber dan bentuk hubungan replikasi logis	Operasi DDL dilarang. Log WAL mulai dikonsumsi dan tidak lagi menumpuk. Replikasi logis menghasilkan beban sumber daya tertentu. Beban ini erat kaitannya dengan jumlah database dan lalu lintas.
Mulai alih bencana	Operasi DDL dilarang. Replikasi logis menghasilkan beban sumber daya tertentu. Beban ini erat kaitannya dengan jumlah database dan lalu lintas. Instans hanya baca. Durasi hanya baca terkait dengan jumlah urutan.
Selesaikan alih bencana (peningkatan selesai)	Slot replikasi logis dihapus, dan beban sumber daya yang dihasilkan oleh replikasi logis dihilangkan. Instans melanjutkan operasi baca dan tulis normal.

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

Langkah 1: Lakukan pemeriksaan pra-peningkatan

Masuk ke Konsol ApsaraDB RDS dan buka halaman Instans. Di bilah navigasi atas, pilih wilayah tempat instans RDS berada. Kemudian, temukan instans RDS dan klik ID instans tersebut.
Di panel navigasi di sebelah kiri, klik Major Version Upgrade.
Catatan
Jika Major Version Upgrade tidak muncul di panel navigasi di sebelah kiri, periksa versi dan konfigurasi instans ApsaraDB RDS for PostgreSQL Anda. Untuk informasi lebih lanjut, 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 pra-peningkatan selesai, status instans berubah menjadi Running.
Jika hasil laporan pemeriksaan peningkatan adalah Success atau Warning, Anda dapat melanjutkan dengan peningkatan versi utama. Jika hasilnya adalah Failed, klik View Information. Perbaiki item abnormal berdasarkan laporan. Lalu, lakukan pemeriksaan pra-peningkatan lagi. Untuk informasi lebih lanjut tentang kesalahan umum dan penyebabnya, lihat Interpretasi laporan pemeriksaan peningkatan versi utama ApsaraDB RDS for PostgreSQL.
Penting
- Untuk memastikan peningkatan berhasil, jika hasil pemeriksaan adalah Warning, kami sarankan Anda memperbaiki item abnormal berdasarkan laporan dan melakukan pemeriksaan pra-peningkatan lagi hingga hasilnya adalah Success.
- Setelah pemeriksaan pra-peningkatan berhasil, jika Anda membuat plugin pada instans utama, Anda harus melakukan pemeriksaan lagi.

Langkah 2: Tingkatkan versi utama

Klik tab Upgrade Instance dan baca peringatan. Lalu, pilih versi dari Select The Destination Version dan klik Create Upgrade Task.
Di kotak dialog yang muncul, baca prompt dan klik OK.
Di bagian Create Major Engine Version Upgrade Task, atur Upgrade Mode ke Zero Downtime.
Klik Create.
Ketika status instans berubah menjadi Migrating, tugas peningkatan telah dimulai.
Waktu yang diperlukan untuk peningkatan sangat terkait dengan jumlah objek database di instans. Semakin banyak objek database, semakin lama peningkatan berlangsung. Selama peningkatan versi utama, Anda dapat melihat kemajuan peningkatan di Hub Tugas.
Penting
- Anda tidak dapat memodifikasi atau menghapus tugas peningkatan setelah dibuat.
- Ketika instans sumber berada dalam status Migrating, tugas operasi dan pemeliharaan (O&M) seperti memodifikasi parameter, me-restart instans, atau melepaskan instans tidak didukung.

Langkah 3: Alih ke versi baru

Verifikasi instans tujuan.
Ketika status instans berubah dari Migrating menjadi Migrating Data Out, replikasi logis telah diatur dan pembuatan tugas peningkatan selesai. Anda kemudian dapat memverifikasi data pada instans tujuan.
Buka tab Upgrade History. Gunakan Later Version Verification URL dari catatan peningkatan target untuk terhubung ke instans tujuan dan verifikasi data yang ditingkatkan.
Catatan
Instans tujuan berada dalam mode hanya baca. Anda tidak dapat melakukan operasi tulis.
Alih ke instans tujuan.
Setelah Anda memastikan bahwa data pada instans tujuan sesuai dengan harapan Anda dan Upgrade Result menunjukkan status Synchronizing, pada kolom Upgrade Log, klik Switchover untuk memindahkan layanan Anda ke instans tujuan.
Catatan
- Jika Upgrade Result berada dalam status lain, lihat Deskripsi hasil peningkatan untuk informasi tentang cara melanjutkan.
- Jika Anda memutuskan untuk meninggalkan peningkatan ini, di kolom Upgrade Log, klik Cancel. Tindakan ini menghapus slot replikasi logis, membatalkan dampak replikasi logis pada instans sumber, dan memungkinkannya melakukan operasi Bahasa Definisi Data (DDL).
Di kotak dialog Switchover, atur Write Downtime Tolerance (dalam detik) dan klik OK.
Saat Upgrade Result berubah menjadi Read-only, alih bencana sedang berlangsung dan status instans adalah Migrating. Di tab Upgrade History pada halaman Major Version Upgrade, Anda dapat mengeklik tombol Interrupted di kolom Upgrade Log untuk membatalkan alih bencana.
Catatan
Anda dapat mengatur Write Downtime Tolerance selama alih bencana untuk secara aktif menunggu latensi replikasi dihilangkan. Ini memastikan konsistensi data. Selama proses ini, Upgrade Result berubah menjadi Read-only. Jika batas waktu terlampaui, sistem kembali ke status Synchronizing dan menghapus pembatasan hanya baca.
Lihat hasil alih bencana.
Ketika Upgrade Result berubah menjadi Succeeded, alih bencana berhasil. Status instans adalah Running.
Di halaman Basic Information instans, Anda dapat melihat informasi versi saat ini dari instans.
Catatan
Setelah peningkatan selesai, buka tab Upgrade History. Di kolom Upgrade Log tugas peningkatan target, klik View Information untuk melihat waktu hanya baca instans dan proses peningkatan rinci. Waktu hanya baca adalah periode antara Switching time dan Switching completion time. Periode ini tidak termasuk waktu ketika instans tidak dapat dijangkau karena cache DNS belum dibersihkan.

Deskripsi hasil peningkatan

Selama proses peningkatan, catatan peningkatan di tab Upgrade History menunjukkan salah satu nilai Upgrade Result berikut.

Hasil peningkatan	Status Instans	Deskripsi	Tindakan yang tersedia
Running	Migrating	Tugas peningkatan sedang berjalan.	Tidak ada.
Synchronizing	Migrating Data Out	Replikasi logis normal.	Alih: Alih ke instans versi baru. Batalkan: Tinggalkan peningkatan ini.
Replication Interrupted	Migrating Data Out	Replikasi logis abnormal.	Lihat log peningkatan untuk menentukan penyebab kegagalan replikasi. Batalkan: Tinggalkan peningkatan ini.
Read-only	Migrating	Alih bencana sedang berlangsung. Instans dalam mode hanya baca, dan urutan sedang disinkronkan.	Hentikan: Batalkan alih bencana ini.
Switchover	Migrating	Sinkronisasi urutan selesai. Menyelesaikan proses.	Tidak ada.
Cancel	Running	Tugas peningkatan dibatalkan.	Tidak ada.
Succeeded	Running	Tugas peningkatan berhasil.	Tidak ada.

Operasi API terkait

Operasi API	Deskripsi
UpgradeDBInstanceMajorVersionPrecheck	Memeriksa pra-peningkatan untuk peningkatan versi utama instans ApsaraDB RDS for PostgreSQL.
DescribeUpgradeMajorVersionPrecheckTask	Mengambil laporan pemeriksaan pra-peningkatan untuk peningkatan versi utama instans ApsaraDB RDS for PostgreSQL.
UpgradeDBInstanceMajorVersion	Memperbarui versi utama instans ApsaraDB RDS for PostgreSQL.
DescribeUpgradeMajorVersionTask	Mengambil tugas historis peningkatan versi utama untuk instans ApsaraDB RDS for PostgreSQL.

Referensi

FAQ

Apakah saya dapat memodifikasi instans, misalnya mengubah tipe instans, selama peningkatan versi utama?

Anda tidak dapat memodifikasi instans selama peningkatan versi utama. Anda hanya dapat melakukan operasi lain setelah peningkatan versi utama selesai.

Apakah peningkatan versi utama otomatis didukung?

Peningkatan otomatis ke versi utama database tidak didukung.

Apakah penurunan versi utama didukung?

Penurunan versi utama tidak didukung setelah peningkatan. Untuk menurunkan versi, Anda dapat membeli instans yang menjalankan versi lebih rendah dan menggunakan DTS untuk memigrasi data ke instans tersebut.

Setelah peningkatan versi utama, konflik `raster_overviews` dilaporkan ketika saya membuat tampilan `raster_overviews` di instans tujuan. Bagaimana cara menangani masalah ini?

Jika versi PostGIS lebih awal dari 2.5.2 dan versi ApsaraDB RDS for PostgreSQL adalah 10 atau 11, Anda mungkin menghadapi konflik `raster_overviews` ketika Anda membuat tampilan `raster_overviews` di instans tujuan setelah Anda meningkatkan plugin dan kemudian meningkatkan versi database utama ke PostgreSQL 12.

Solusi:

Tingkatkan versi plugin PostGIS di instans sumber.
Jalankan perintah berikut dua kali untuk memastikan keberhasilan.
```
SELECT PostGIS_Extensions_Upgrade();
SELECT PostGIS_Extensions_Upgrade();
```

Tentukan apakah plugin PostGIS Raster digunakan dan pilih metode peningkatan yang sesuai.

Plugin PostGIS Raster digunakan

Jalankan perintah berikut di instans sumber untuk memodifikasi tampilan `raster_overviews`.

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

Lakukan peningkatan versi utama untuk instans PostgreSQL setidaknya ke PostgreSQL 12.

Setelah peningkatan selesai, buat ulang tampilan di 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;

Plugin PostGIS Raster tidak digunakan

Jalankan perintah berikut di instans sumber untuk menghapus plugin.
```
DROP EXTENSION PostGIS_Raster;
```
Lakukan peningkatan versi utama untuk instans PostgreSQL setidaknya ke PostgreSQL 12.

Bagaimana cara mencegah masalah sinkronisasi data yang disebabkan oleh perebutan slot replikasi selama peningkatan?

Untuk menjaga data langganan pada instans sumber (yang menjalankan versi lebih rendah), pastikan bahwa instans sumber tidak mati karena beban berlebih selama peningkatan. Jika tidak, slot replikasi dapat diambil alih oleh instans tujuan (yang menjalankan versi lebih tinggi), yang dapat menyebabkan ketidaksesuaian data.
Setelah peningkatan selesai, gunakan pernyataan SQL berikut untuk menonaktifkan langganan pada database tujuan.
```
\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;
```
Untuk menyimpan data langganan pada instans tujuan, nonaktifkan langganan pada instans sumber sebelum peningkatan versi utama. Setelah peningkatan selesai, aktifkan kembali langganan pada instans tujuan. Pernyataan SQL berikut memberikan contoh:
- Nonaktifkan langganan pada instans sumber.
```
\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;
```
- Aktifkan langganan pada instans tujuan.
```
\c your_database
ALTER SUBSCRIPTION your_subscription_name ENABLE;
```

Catatan

Untuk informasi lebih lanjut tentang penggunaan slot replikasi untuk langganan data, lihat Langganan logis dan Pelacakan perubahan.
Jika Anda tidak mengikuti langkah-langkah sebelumnya, data langganan Anda mungkin menjadi tidak konsisten. Untuk memastikan konsistensi data, lihat Bagaimana cara menangani ketidaksesuaian data langganan setelah peningkatan?

Bagaimana cara menangani ketidaksesuaian data langganan setelah peningkatan?

Setelah peningkatan berhasil, hapus data tabel pada instans tujuan (yang menjalankan versi lebih tinggi). Lalu, buat ulang langganan dan atur copy_data=true. Untuk informasi lebih lanjut, lihat ALTER SUBSCRIPTION.

Gunakan kata kunci CONFLICT untuk mengimpor data yang dikonsumsi oleh instans sumber (yang menjalankan versi lebih rendah) ke instans tujuan. Kode berikut memberikan contoh.

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');

-- dalam kasus dengan timestamp lebih baru: lakukan pembaruan
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;

-- dalam kasus dengan timestamp lebih lama: abaikan
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;

-- dalam kasus dengan nilai baru: cukup masukkan
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;