Peningkatan Versi Utama dengan Metode Peningkatan Lokal - ApsaraDB RDS

Tema ini menjelaskan cara memutakhirkan versi utama instans ApsaraDB RDS for PostgreSQL menggunakan metode pemutakhiran di tempat.

Prasyarat

Instans menjalankan ApsaraDB RDS for PostgreSQL 16 atau versi sebelumnya.
Jenis penyimpanan instans adalah disk cloud.
Catatan
Jika instans menggunakan disk lokal berkinerja tinggi, Anda hanya dapat memutakhirkan versi utama menggunakan metode penyebaran biru-hijau.
Metode penagihan instans adalah bayar sesuai penggunaan atau langganan.
Catatan
Jika instans merupakan instans tanpa server, Anda hanya dapat memutakhirkan versi utama menggunakan metode penyebaran biru-hijau.
Instans bukan merupakan instans hanya baca atau instans klaster khusus.
Babelfish tidak diaktifkan untuk instans tersebut. Nomor versi mesin minor tidak diakhiri dengan babelfish.

Informasi latar belakang

Metode pemutakhiran di tempat menggunakan pg_upgrade untuk memutakhirkan instans sumber ke versi tujuan. Semua metadata, termasuk konfigurasi dan informasi penagihan dari instans sumber, dipertahankan.

Konsol ApsaraDB RDS juga mendukung pemutakhiran versi utama menggunakan metode tanpa downtime dan metode penyebaran biru-hijau. Untuk perbandingan metode pemutakhiran, lihat Pengenalan Metode Pemutakhiran Versi Utama.

Biaya pemutakhiran

Gratis.

Peringatan

Dampak layanan: Selama alih bencana, instans diatur ke mode hanya baca, dan koneksi transien yang berlangsung beberapa menit mungkin terjadi. Kami sarankan Anda melakukan pemutakhiran selama jam-jam sepi.
Durasi status hanya baca bergantung pada jumlah objek basis data. Semakin banyak objek basis data yang dimiliki oleh instans, semakin lama status hanya baca berlangsung. Jika jumlah objek basis data mencapai jutaan, status hanya baca mungkin berlangsung selama puluhan menit hingga berjam-jam. Anda dapat menjalankan perintah SELECT count(1) FROM pg_class; untuk melihat jumlah objek basis data.
Tipe instans: Jika tipe instans tidak memenuhi spesifikasi yang direkomendasikan selama pemutakhiran, sistem secara otomatis mencoba memutakhirkan instans menggunakan tipe instans yang direkomendasikan. Tindakan ini menempatkan instans dalam status hanya baca selama beberapa menit dan menyebabkan koneksi transien tambahan yang berlangsung beberapa detik. Sebelum Anda memutakhirkan versi utama, Anda harus menyelesaikan peringatan tentang tipe instans di laporan pemeriksaan pemutakhiran versi utama.
Slot replikasi:
- Jika instans sumber adalah penerbit yang memiliki slot replikasi, slot replikasi akan hilang setelah pemutakhiran.
- Jika instans sumber adalah subscriber yang memiliki slot replikasi, preemption slot replikasi mungkin terjadi selama pemutakhiran dan menyebabkan ketidaksesuaian data. Untuk informasi lebih lanjut tentang cara menyelesaikan masalah ini, lihat Bagaimana cara mencegah ketidaksesuaian data yang disebabkan oleh preemption slot replikasi selama pemutakhiran?
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 dari template parameter untuk versi tujuan.
- Selama pemutakhiran, sistem sementara mengubah nilai statement_timeout menjadi 0 dan mengembalikannya ke nilai awal setelah pemutakhiran selesai.
Tugas DTS: Jika instans yang akan ditingkatkan merupakan instans sumber atau tujuan untuk Data Transmission Service (DTS), Anda perlu membuat ulang tugas DTS setelah pemutakhiran.
Masalah kompatibilitas plugin: Saat Anda memutakhirkan versi utama, sistem secara otomatis memperbarui instans ke versi mesin minor terbaru. Hal ini dapat menyebabkan masalah kompatibilitas plugin.
Cadangan instans: Cadangan penuh dilakukan pada instans sebelum dan sesudah pemutakhiran. Ini memungkinkan pemulihan berbasis kloning selanjutnya.

Langkah 1: Lakukan pemeriksaan pra-pemutakhiran

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-nya.
(Opsional) Jika instans hanya-baca telah dibuat untuk instans yang akan ditingkatkan, ubah titik akhir instans hanya-baca di aplikasi Anda menjadi titik akhir instans utama, lalu hapus instans hanya-baca tersebut.

Catatan
Untuk memastikan stabilitas layanan, kami sarankan Anda mengubah titik akhir aplikasi selama jam-jam sepi.
Di panel navigasi kiri, klik Major Version Upgrade.

Catatan
Jika Major Version Upgrade tidak muncul di panel navigasi 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 Local Upgrade, lalu klik OK.
Status instans berubah menjadi Maintaining Instance. Setelah pemeriksaan pra-pemutakhiran selesai, status instans berubah menjadi Running.

Jika hasil laporan pemeriksaan pemutakhiran adalah Success atau Warning, Anda dapat melanjutkan dengan pemutakhiran versi utama. Jika hasilnya adalah Failed, klik View Information. Perbaiki item abnormal berdasarkan laporan, lalu lakukan pemeriksaan pra-pemutakhiran lagi. Untuk informasi lebih lanjut tentang kesalahan umum dan penyebabnya, lihat Interpretasi laporan pemeriksaan pemutakhiran versi utama ApsaraDB RDS for PostgreSQL.
Penting
- Untuk memastikan pemutakhiran berhasil, jika hasil pemeriksaan adalah Warning, kami sarankan Anda memperbaiki item abnormal berdasarkan laporan dan melakukan pemeriksaan pra-pemutakhiran lagi hingga hasilnya adalah Success.
- Setelah pemeriksaan pra-pemutakhiran berhasil, jika Anda membuat plugin pada instans utama, Anda harus melakukan pemeriksaan lagi.

Langkah 2: Tingkatkan versi utama

Klik tab Upgrade Instance. Baca peringatan, select the destination version, lalu klik Create Upgrade Task.
Di kotak dialog yang muncul, baca prompt dan klik OK.
Pada bagian Create Major Engine Version Upgrade Task, atur Upgrade Mode ke Local Upgrade dan konfigurasikan Cutover time. Waktu alih bencana adalah saat layanan Anda dialihkan ke instans tujuan setelah migrasi selesai.
- immediately: Alih bencana dilakukan segera setelah migrasi selesai.
- Instance operation and maintenance time: Alih bencana dilakukan dalam jendela pemeliharaan yang ditentukan.
Klik Create.
Ketika status instans berubah menjadi Migrating, tugas pemutakhiran telah dimulai.
Waktu yang diperlukan untuk pemutakhiran sangat bergantung pada jumlah objek basis data di instans. Semakin banyak objek basis data, semakin lama pemutakhiran berlangsung. Selama pemutakhiran versi utama, Anda dapat melihat kemajuan pemutakhiran di Pusat Tugas.
Penting
- Anda tidak dapat memodifikasi atau menghapus tugas pemutakhiran setelah dibuat.
- Ketika instans sumber berada dalam status Migrating, Anda tidak dapat melakukan operasi dan pemeliharaan (O&M) pada instans, seperti memodifikasi parameter, me-restart instans, atau melepaskan instans.
Lihat hasil pemutakhiran.
Instans berhasil ditingkatkan ketika status instans sumber dan tujuan adalah Running.
Catatan
Setelah pemutakhiran selesai, di tab Upgrade History, temukan tugas pemutakhiran dan klik View Information di kolom Upgrade Log untuk melihat durasi hanya baca dan proses pemutakhiran terperinci. Durasi hanya baca adalah periode antara Cutover Time dan Switchover End Time. Periode ini tidak termasuk waktu selama instans tidak dapat diakses karena cache DNS belum dibersihkan.

Apa yang harus dilakukan selanjutnya

Jika Anda menghapus instans hanya baca sebelum pemutakhiran, ikuti langkah-langkah berikut:

Buat instans hanya baca ApsaraDB RDS for PostgreSQL pada instans tujuan.
Di aplikasi Anda, perbarui titik akhir yang sebelumnya diarahkan ke instans utama menjadi titik akhir instans hanya baca baru.

Deskripsi hasil pemutakhiran

Kolom Upgrade Result pada tab Upgrade History menampilkan salah satu status berikut untuk tugas pemutakhiran.

Hasil pemutakhiran	Status instans	Arti	Tindakan yang tersedia
Running	Migrating	Tugas pemutakhiran sedang berjalan.	Tidak ada.
Succeeded	Running	Tugas pemutakhiran berhasil.	Tidak ada.

Operasi API terkait

Operasi API	Deskripsi
UpgradeDBInstanceMajorVersionPrecheck	Menjalankan pemeriksaan pra-pemutakhiran untuk pemutakhiran versi utama instans ApsaraDB RDS for PostgreSQL.
DescribeUpgradeMajorVersionPrecheckTask	Mengquery laporan pemeriksaan pra-pemutakhiran untuk pemutakhiran versi utama instans ApsaraDB RDS for PostgreSQL.
UpgradeDBInstanceMajorVersion	Memutakhirkan versi utama instans ApsaraDB RDS for PostgreSQL.
DescribeUpgradeMajorVersionTask	Mengquery tugas-tugas historis pemutakhiran versi utama untuk instans ApsaraDB RDS for PostgreSQL.

Referensi

Tanya Jawab Umum

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

Anda tidak dapat memodifikasi instans selama pemutakhiran versi utama. Operasi lain hanya dapat dilakukan setelah pemutakhiran selesai.

Apakah pemutakhiran otomatis versi utama didukung?

Pemutakhiran otomatis ke versi basis data utama tidak didukung.

Apakah pemutakhiran turun versi utama didukung?

Pemutakhiran turun versi utama tidak didukung setelah pemutakhiran. Untuk menurunkan versi, Anda dapat membeli instans dengan versi lebih rendah dan menggunakan DTS untuk memigrasikan data ke instans tersebut.

Setelah saya memutakhirkan versi utama, kesalahan konflik `raster_overviews` dilaporkan ketika saya membuat tampilan `raster_overviews` pada instans tujuan. Bagaimana cara memperbaikinya?

Jika versi PostGIS lebih awal dari 2.5.2 dan versi ApsaraDB RDS for PostgreSQL adalah 10 atau 11, Anda mungkin mengalami konflik `raster_overviews` saat membuat tampilan `raster_overviews` di instans tujuan setelah memutakhirkan plugin dan memutakhirkan versi basis data 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 pemutakhiran 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 pemutakhiran versi utama untuk instans PostgreSQL setidaknya ke PostgreSQL 12.

Setelah pemutakhiran 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 pemutakhiran versi utama untuk instans PostgreSQL setidaknya ke PostgreSQL 12.

Bagaimana cara mencegah ketidaksesuaian data yang disebabkan oleh preemption slot replikasi selama pemutakhiran?

Jika Anda ingin menyimpan data langganan di instans sumber, pastikan bahwa instans sumber tidak mati karena payload yang berlebihan selama pemutakhiran. Jika tidak, slot replikasi mungkin direbut oleh instans tujuan, yang dapat menyebabkan ketidaksesuaian data.
Setelah pemutakhiran selesai, jalankan pernyataan SQL berikut untuk menonaktifkan langganan di basis data tujuan.
```
\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;
```
Jika Anda ingin menyimpan data langganan ke instans tujuan, nonaktifkan langganan di instans sumber sebelum pemutakhiran versi utama. Setelah pemutakhiran selesai, aktifkan langganan di instans tujuan. Perintah SQL berikut memberikan contoh:
- Nonaktifkan langganan di instans sumber.
```
\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;
```
- Aktifkan langganan di instans tujuan.
```
\c your_database
ALTER SUBSCRIPTION your_subscription_name ENABLE;
```

Catatan

Untuk informasi lebih lanjut tentang cara menggunakan slot replikasi untuk langganan data, lihat Langganan logis dan Pelacakan perubahan.
Jika Anda tidak melakukan operasi sebelumnya, data langganan Anda mungkin tidak konsisten. Untuk memastikan konsistensi data, lihat Bagaimana cara memperbaiki ketidaksesuaian data langganan setelah pemutakhiran?

Bagaimana cara menangani ketidaksesuaian data langganan setelah pemutakhiran?

Setelah pemutakhiran berhasil, hapus data tabel di instans tujuan (yang menjalankan versi lebih tinggi). Kemudian, 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 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 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;

Mengapa saya perlu menghapus instans hanya baca sebelum pemutakhiran versi utama?

Setelah pemutakhiran, node hanya baca yang dibuat pengguna dan slot replikasi tetap ada di instans sumber dan tidak secara otomatis dipindahkan ke instans tujuan. Oleh karena itu, sebelum melakukan pemutakhiran versi utama, Anda harus mengubah titik akhir instans hanya baca di aplikasi Anda ke titik akhir instans utama dan kemudian menghapus instans hanya baca yang ada. Setelah pemutakhiran selesai, Anda harus membeli dan mengonfigurasi instans hanya baca baru.