ApsaraDB RDS:Tingkatkan versi utama menggunakan penyebaran biru-hijau

Prasyarat

Sebelum memulai, pastikan bahwa:

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

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

• Babelfish tidak diaktifkan pada instans (nomor versi mesin minor tidak diakhiri dengan babelfish).

Penagihan

Saat Anda memulai peningkatan penyebaran biru-hijau, sistem membuat instans baru berdasarkan instans sumber. Kedua instans ditagih secara terpisah hingga Anda melepas instans sumber.

Setelah memastikan layanan Anda berjalan stabil pada instans baru, ubah metode penagihan instans baru menjadi subscription dan lepas atau batalkan langganan instans sumber.

Dampak potensial

Tinjau hal berikut sebelum memulai peningkatan.

Langkah 1: Jalankan pemeriksaan pra-peningkatan

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

2. (Opsional) Jika terdapat instans read-only untuk instans sumber, ubah titik akhir instans read-only di aplikasi Anda ke titik akhir instans primary selama jam sepi, lalu hapus instans read-only tersebut.

   Menghapus instans read-only sebelum peningkatan diperlukan karena node read-only dan slot replikasi tidak secara otomatis ditransfer ke instans baru. Setelah peningkatan, buat instans read-only baru pada instans baru.

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

   Jika Major Version Upgrade tidak terlihat, verifikasi bahwa instans Anda memenuhi prasyarat yang tercantum di atas.

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

5. Pilih versi target, atur Upgrade Mode ke Blue-green Deployment, lalu klik OK. Status instans berubah menjadi Maintaining Instance. Setelah pemeriksaan selesai, status kembali menjadi Running.

6. Tinjau hasil laporan pemeriksaan:

   • Success atau Warning: lanjutkan ke Langkah 2.

   • Failed: klik View Information, perbaiki masalah yang teridentifikasi, lalu jalankan ulang pemeriksaan.

   Penting

   - Untuk hasil Warning, perbaiki semua item yang ditandai dan jalankan ulang pemeriksaan hingga hasilnya Success. - Jika Anda membuat plugin pada instans primary setelah pemeriksaan berhasil, jalankan ulang pemeriksaan sebelum melanjutkan.

Langkah selanjutnya

1. Jika Anda melakukan peningkatan menggunakan metode penyebaran biru-hijau (cutover), setelah memastikan layanan Anda berjalan stabil pada instans baru, lepas instans sumber. Ubah metode penagihan instans baru menjadi subscription untuk menghemat biaya.

   Melepas instans subscription sebelum masa berlaku habis dapat menyebabkan kerugian finansial. Instans baru tidak mewarisi diskon apa pun dari instans sumber. Pengembalian dana mengikuti tagihan pembatalan langganan aktual dan tidak diproses secara real time.

2. (Opsional) Jika Anda menghapus instans read-only sebelum peningkatan, buat ulang pada instans baru:

   1. Buat instans read-only PostgreSQL pada instans baru.

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

Referensi API

Referensi

• Pengenalan peningkatan versi utama

• Lakukan peningkatan versi utama menggunakan mode zero-downtime

• Lakukan peningkatan versi utama menggunakan mode in-place upgrade

• Interpretasikan laporan pemeriksaan peningkatan versi utama ApsaraDB RDS for PostgreSQL

FAQ

Apakah saya dapat memodifikasi instans selama peningkatan versi utama?

Tidak. Instans tidak dapat dimodifikasi selama peningkatan sedang berlangsung. Modifikasi hanya tersedia setelah peningkatan selesai.

Apakah peningkatan versi utama otomatis didukung?

Tidak. Peningkatan versi utama harus dipicu secara manual.

Apakah downgrade versi utama didukung?

Tidak. Downgrade tidak didukung setelah peningkatan versi utama. Untuk menjalankan versi yang lebih rendah, beli instans baru pada versi tersebut dan gunakan Data Transmission Service (DTS) untuk memigrasikan data Anda.

Setelah peningkatan versi utama, saya mendapatkan konflik `raster_overviews` saat membuat view di instans baru. Bagaimana cara memperbaikinya?

Masalah ini terjadi ketika versi PostGIS lebih awal dari 2.5.2 dan Anda meningkatkan dari PostgreSQL 10 atau 11 ke PostgreSQL 12 tanpa terlebih dahulu meningkatkan plugin PostGIS.

Langkah 1: Tingkatkan plugin PostGIS pada instans sumber.

Jalankan perintah berikut dua kali untuk memastikan peningkatan berhasil:

SELECT PostGIS_Extensions_Upgrade();
SELECT PostGIS_Extensions_Upgrade();

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

Jika plugin PostGIS Raster sedang digunakan:

1. Pada instans sumber, lepaskan 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 minimal PostgreSQL 12.

3. Setelah peningkatan, buat ulang view pada instans baru:

   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:

1. Letakkan plugin pada instance sumber:

   DROP EXTENSION PostGIS_Raster;

2. Tingkatkan instans PostgreSQL ke minimal PostgreSQL 12.

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

Jika instans sumber adalah subscriber slot replikasi, slot replikasi dapat diambil alih oleh instans baru selama peningkatan, yang dapat menyebabkan inkonsistensi data.

Untuk menyimpan data subscription pada instans sumber (versi lebih rendah): pastikan instans sumber tidak gagal akibat beban berlebih selama peningkatan untuk mencegah slot replikasi diambil alih. Setelah peningkatan selesai, nonaktifkan subscription pada instans baru:

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Untuk mempertahankan data subscription pada instans baru (versi lebih tinggi): nonaktifkan subscription pada instans sumber sebelum memulai peningkatan, lalu aktifkan kembali pada instans baru setelah peningkatan selesai.

Nonaktifkan pada instans sumber:

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Aktifkan pada instans baru:

\c your_database
ALTER SUBSCRIPTION your_subscription_name ENABLE;

Untuk informasi lebih lanjut, lihat Logical Subscription dan Change Tracking.

Bagaimana cara menangani inkonsistensi data subscription setelah peningkatan?

Jika inkonsistensi telah terjadi, gunakan pendekatan berikut untuk menyelaraskan:

1. Pada instans baru, hapus data tabel yang terdampak, buat ulang subscription dengan copy_data=true. Untuk detailnya, lihat ALTER SUBSCRIPTION.

2. Gunakan ON CONFLICT untuk mengimpor data dari instans sumber. Contoh berikut menunjukkan cara menangani skenario konflik berbeda:

   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 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: pertahankan baris yang ada
   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: sisipkan langsung
   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?

Node read-only dan slot replikasi pada instans sumber tidak secara otomatis ditransfer ke instans baru setelah peningkatan. Menghapus instans read-only sebelum peningkatan mencegah konflik titik akhir dan memastikan cutover yang bersih. Setelah peningkatan, buat instans read-only baru pada instans baru dan perbarui titik akhir aplikasi Anda sesuai.