ApsaraDB RDS:Peningkatan versi utama di tempat

Prasyarat

Sebelum memulai, pastikan bahwa:

• Instans menjalankan ApsaraDB RDS for PostgreSQL 16 atau versi sebelumnya.

• Jenis penyimpanan adalah cloud disk.

• Metode penagihan adalah pay-as-you-go atau subscription.

• Instans bukan read-only instance atau instans klaster khusus.

• Babelfish tidak diaktifkan. Nomor versi mesin minor tidak diakhiri dengan babelfish.

Penagihan

Gratis.

Catatan penggunaan

Tinjau hal-hal berikut sebelum memulai peningkatan.

SELECT count(1) FROM pg_class;

Langkah 1: Jalankan pemeriksaan pra-peningkatan

1. Masuk ke Konsol ApsaraDB RDS. Di bilah navigasi atas, pilih wilayah tempat instans berada. Temukan dan klik ID instans.

2. (Opsional) Jika instans memiliki instans read-only, ubah endpoint aplikasi dari endpoint instans read-only ke endpoint instans utama, lalu hapus instans read-only tersebut.

   Catatan Ubah endpoint aplikasi selama jam sepi untuk meminimalkan dampak terhadap layanan.

3. Di panel navigasi kiri, klik Major Version Upgrade.

   Catatan Jika Major Version Upgrade tidak muncul, periksa versi dan konfigurasi instans Anda. Untuk informasi lebih lanjut, lihat Prasyarat.

4. Di tab Upgrade Check, klik Create upgrade check report.

5. Pilih versi tujuan, atur Upgrade Mode ke Local Upgrade, lalu klik OK. Status instans berubah menjadi Maintaining Instance selama pemeriksaan berlangsung, lalu kembali ke Running setelah pemeriksaan selesai.

6. Tinjau hasil pemeriksaan:

   • Success atau Warning: lanjutkan ke Langkah 2.

   • Gagal: Klik View Information, perbaiki masalah yang diidentifikasi dalam laporan, lalu jalankan pemeriksaan ulang. Untuk informasi selengkapnya mengenai kesalahan umum, lihat Menafsirkan laporan pemeriksaan peningkatan versi utama ApsaraDB RDS untuk PostgreSQL.

   Penting

   - Jika hasilnya Warning, perbaiki masalah tersebut dan jalankan kembali pemeriksaan hingga hasilnya Success. - Jika Anda membuat plugin pada instans utama setelah pemeriksaan berhasil, jalankan kembali pemeriksaan tersebut.

Langkah 2: Tingkatkan versi mesin utama

1. Klik tab Upgrade Instance. Baca peringatan, pilih versi peningkatan, lalu klik Create Upgrade Task.

2. Di kotak dialog, baca prompt lalu klik OK.

3. Di bagian Create Major Engine Version Upgrade Task, atur Upgrade Mode ke Local Upgrade dan konfigurasi Cutover End Time:

   • immediately: alih bencana terjadi segera setelah migrasi selesai.

   • Instance operation and maintenance time: alih bencana terjadi dalam jendela pemeliharaan yang dikonfigurasi.

4. Klik Create now. Status instans berubah menjadi Migration in Progress saat tugas peningkatan dimulai. Durasi peningkatan berbanding lurus dengan jumlah objek basis data. Lacak kemajuan di Task Hub.

   Penting

   - Tugas peningkatan tidak dapat dimodifikasi atau dihapus setelah dibuat. - Selama instans berada dalam status Migration in Progress, operasi seperti memodifikasi parameter, me-restart, atau melepas instans tidak tersedia.

5. Peningkatan selesai ketika baik instans sumber maupun tujuan menunjukkan status Running.

   Catatan Di tab Upgrade History, klik View Information di kolom Upgrade Log untuk melihat durasi read-only dan log peningkatan lengkap. Durasi read-only adalah waktu antara Cutover End Time dan Cutover End Time, tidak termasuk periode flush cache DNS.

Langkah selanjutnya

Jika Anda menghapus instans read-only sebelum peningkatan:

1. Buat instans read-only pada instans tujuan.

2. Di aplikasi Anda, perbarui endpoint agar mengarah ke instans read-only baru.

Referensi hasil peningkatan

Kolom Upgrade Result di tab Upgrade History menampilkan salah satu status berikut:

Referensi API

Referensi

• Pengenalan peningkatan versi utama

• Tingkatkan versi mesin utama menggunakan metode tanpa downtime

• Tingkatkan versi mesin utama menggunakan metode penyebaran biru-hijau

• Interpretasi laporan pemeriksaan peningkatan versi mesin utama

FAQ

Apakah saya dapat memodifikasi instans selama peningkatan versi mesin utama?

Tidak. Tunggu hingga peningkatan selesai sebelum melakukan perubahan pada instans.

Apakah peningkatan versi mesin utama otomatis didukung?

Tidak. Peningkatan versi mesin utama harus dimulai secara manual.

Apakah penurunan versi mesin utama didukung?

Tidak. Untuk menjalankan versi yang lebih rendah, beli instans baru pada versi target dan gunakan DTS untuk melakukan migrasi data.

Setelah peningkatan, saya mendapatkan error konflik `raster_overviews` saat membuat view. Bagaimana cara memperbaikinya?

Hal ini memengaruhi versi PostGIS sebelum 2.5.2 pada PostgreSQL 10 atau 11 saat ditingkatkan ke PostgreSQL 12. Ikuti langkah-langkah berikut:

1. Pada instans sumber, tingkatkan plugin PostGIS. Jalankan perintah berikut dua kali untuk memastikan keberhasilannya:

   SELECT PostGIS_Extensions_Upgrade();
   SELECT PostGIS_Extensions_Upgrade();

2. Pilih solusi berdasarkan apakah Anda menggunakan plugin PostGIS Raster atau tidak.

Jika Anda menggunakan PostGIS Raster:

1. Pada instans sumber, hapus view raster_overviews dari ekstensi dan ganti dengan placeholder:

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

2. Tingkatkan instans PostgreSQL ke PostgreSQL 12 atau lebih tinggi.

3. Pada instans tujuan, buat ulang view lengkap dan tambahkan kembali ke ekstensi:

   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 Anda tidak menggunakan PostGIS Raster:

1. Pada instans sumber, hapus ekstensi:

   DROP EXTENSION PostGIS_Raster;

2. Tingkatkan instans PostgreSQL ke PostgreSQL 12 atau lebih tinggi.

Bagaimana cara mencegah inkonsistensi data akibat preemption slot replikasi selama peningkatan?

Pilih salah satu pendekatan berikut berdasarkan lokasi data subscription yang diinginkan setelah peningkatan.

Simpan data subscription di instans sumber:

Pastikan instans sumber tidak mati karena beban berlebih selama peningkatan. Jika hal ini terjadi, slot replikasi mungkin diambil alih oleh instans tujuan, menyebabkan inkonsistensi data. Setelah peningkatan, nonaktifkan subscription pada database tujuan:

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Pindahkan data subscription ke instans tujuan:

Sebelum peningkatan, nonaktifkan subscription pada instans sumber:

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Setelah peningkatan, aktifkan subscription pada instans tujuan:

\c your_database
ALTER SUBSCRIPTION your_subscription_name ENABLE;

Bagaimana cara memperbaiki inkonsistensi data subscription setelah peningkatan?

1. Pada instans tujuan (versi lebih tinggi), hapus data tabel yang terpengaruh. Lalu buat ulang subscription dengan copy_data=true. Untuk detailnya, lihat ALTER SUBSCRIPTION.

2. Gunakan ON CONFLICT untuk mengimpor data dari instans sumber (versi lebih rendah) ke instans tujuan. Contoh polanya sebagai berikut:

   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');
   
   -- Timestamp lebih baru: perbarui baris yang sudah ada
   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;
   
   -- Timestamp lebih lama: lewati baris
   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;
   
   -- Baris baru: 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;

Mengapa saya perlu menghapus instans read-only sebelum peningkatan versi mesin utama?

Node hanya-baca dan slot replikasi mereka tetap terhubung ke instans sumber setelah peningkatan dan tidak secara otomatis dipindahkan ke instans tujuan. Hapus node dan slot tersebut sebelum peningkatan, lalu buat ulang di instans tujuan setelah peningkatan.