Memutakhirkan Versi Utama dengan Penyebaran Biru-Hijau - ApsaraDB RDS

Topik ini menjelaskan cara meningkatkan versi utama database ApsaraDB RDS untuk PostgreSQL menggunakan metode penyebaran biru-hijau.

Prasyarat

Instans menjalankan ApsaraDB RDS for PostgreSQL 16 atau versi sebelumnya.
Instans bukan merupakan read-only instance atau dedicated cluster instance.
Babelfish tidak diaktifkan untuk instans tersebut. Nomor versi mesin minor tidak diakhiri dengan babelfish.

Informasi latar belakang

Dalam penyebaran biru-hijau, instans sumber dipulihkan ke instans baru. Kemudian, pg_upgrade digunakan untuk meningkatkan instans baru ke versi target. Jika Anda melakukan cutover, Titik akhir dari instans sumber secara otomatis beralih ke instans baru.

Konsol ApsaraDB RDS for PostgreSQL juga mendukung peningkatan versi utama database menggunakan mode tanpa downtime dan mode peningkatan lokal. Untuk perbandingan berbagai mode, lihat Pengenalan Solusi Peningkatan Versi Utama.

Biaya Peningkatan

Saat Anda meningkatkan versi utama menggunakan penyebaran biru-hijau, sistem akan membuat instans baru berdasarkan instans sumber. Setelah peningkatan selesai:

Instans sumber dan instans baru keduanya akan ditagih.
Metode penagihan dan biaya untuk instans sumber tetap tidak berubah.
Metode penagihan untuk instans baru mungkin berbeda dari instans sumber.
Metode penagihan instans sumber
Metode penagihan instans baru
Langganan/Bayar sesuai pemakaian
Bayar sesuai pemakaian
Serverless
Serverless
Catatan
Untuk menghemat biaya, setelah layanan pada instans baru berjalan stabil, kami sarankan Anda mengonversi instans baru menjadi langganan dan melepaskan atau berhenti berlangganan dari instans sumber. Namun, perhatikan hal berikut:
- Jika instans sumber Anda adalah instansi langganan yang belum kedaluwarsa, instans baru tidak dapat mewarisi durasi langganan yang tersisa. Melepaskan instans sumber dapat mengakibatkan kerugian finansial. Untuk informasi lebih lanjut tentang aturan pembatalan langganan, lihat Kebijakan Pengembalian Dana.
- Instans baru tidak mewarisi diskon apa pun yang diterapkan pada instans sumber. Anda dapat melihat jumlah pengembalian dana spesifik di halaman pembatalan langganan instans sebelum memutuskan apakah akan meningkatkan.
- Jumlah dan waktu pengembalian dana untuk instansi langganan bergantung pada tagihan pembatalan langganan aktual. Pengembalian dana tidak diproses secara real-time.

Langkah Pencegahan

Dampak Layanan: Saat Anda melakukan peningkatan menggunakan penyebaran biru-hijau dengan alih bencana, instans sumber diatur menjadi read-only selama proses alih bencana. Hal ini menyebabkan gangguan koneksi sementara yang berlangsung selama beberapa menit. Kami sarankan Anda melakukan peningkatan selama jam-jam sepi. Jika Anda memilih untuk tidak melakukan alih bencana, layanan Anda tidak akan terpengaruh.
- Durasi instans sumber dalam mode read-only bergantung pada jumlah objek basis data. Semakin banyak objek basis data yang dimiliki instans, semakin lama durasi read-only. Jika jumlah objek basis data mencapai jutaan, durasi read-only bisa mencapai puluhan menit atau bahkan jam. Anda dapat menjalankan perintah SELECT count(1) FROM pg_class; untuk melihat jumlah objek basis data.
- Durasi Gangguan Koneksi Sementara yang dirasakan oleh klien bergantung pada waktu pembersihan cache DNS. Anda dapat mengalihkan vSwitch dan menggunakan durasi gangguan layanan untuk memperkirakan waktu pembersihan cache DNS klien.
- Durasi Proses Peningkatan bergantung pada jumlah objek basis data dalam instans. Semakin banyak objek basis data yang dimiliki instans, semakin lama peningkatan berlangsung. Untuk peningkatan versi utama, Anda dapat melihat kemajuan tugas di Task Hub.
- Untuk penyebaran biru-hijau, jika Anda tidak ingin instans sumber diatur menjadi read-only setelah alih bencana, Anda harus mengatur parameter rds_force_trans_ro_non_sup ke off setelah peningkatan. Untuk informasi lebih lanjut, lihat Setel Parameter Instans.
Peningkatan Lintas Versi: ApsaraDB RDS for PostgreSQL 9.4 dan 10 yang menggunakan disk lokal berkinerja tinggi hanya dapat ditingkatkan ke instans yang menggunakan cloud disk. Anda dapat meningkatkannya ke versi maksimum ApsaraDB RDS for PostgreSQL 14. Untuk meningkatkan ke PostgreSQL 15 atau versi yang lebih baru, Anda harus terlebih dahulu meningkatkan ke versi perantara (PostgreSQL 9.4 dapat ditingkatkan ke 10, 11, 12, 13, atau 14; PostgreSQL 10 dapat ditingkatkan ke 11, 12, 13, atau 14), dan kemudian tingkatkan ke PostgreSQL 15 atau versi yang lebih baru.
Slot Replikasi:
- Jika instans sumber adalah publisher dengan slot replikasi, slot replikasi tersebut akan hilang setelah peningkatan.
- Jika instans sumber adalah subscriber slot replikasi, peningkatan dapat menyebabkan masalah sinkronisasi data karena preemption slot replikasi. Untuk menyelesaikan masalah ini, lihat Cara Mencegah Ketidaksesuaian Data yang Disebabkan oleh Preemption Slot Replikasi Selama Peningkatan.
IP Virtual: Untuk penyebaran biru-hijau dengan alih bencana, alamat IP virtual dari instans baru berubah setelah peningkatan. Anda harus memeriksa konektivitas jaringan, seperti konfigurasi firewall.
- Dampak Perubahan IP Virtual: Jika Anda telah mengonfigurasi IP virtual di aplikasi Anda, Anda harus memodifikasi konfigurasi aplikasi untuk menunjuk ke alamat IP virtual instans baru.
- Rekomendasi: Untuk menghindari kompleksitas konfigurasi manual, kami sarankan Anda langsung mengonfigurasi alamat koneksi instans di aplikasi Anda. Untuk informasi lebih lanjut tentang cara mendapatkan alamat koneksi, lihat Lihat atau Modifikasi Alamat Koneksi dan Port.
Perubahan Parameter:
- Jika instans sumber menggunakan parameter yang tidak didukung oleh versi tujuan, parameter tersebut secara 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 diatur ke nilai default dari 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 Data Transmission Service (DTS), Anda perlu membuat ulang Tugas DTS setelah peningkatan.
Masalah Kompatibilitas Plugin: Saat Anda melakukan peningkatan versi utama, sistem secara otomatis memperbarui ke versi mesin minor terbaru, dan Anda mungkin menghadapi masalah kompatibilitas plugin.
Instans baru tidak mewarisi Instance Name, tag, aturan peringatan CloudMonitor, atau data cadangan dari instans sumber.

Langkah 1: 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 dari instans tersebut.
(Opsional) Jika terdapat instansi hanya baca untuk instans sumber, ubah titik akhir instansi hanya baca di aplikasi Anda menjadi titik akhir instans utama, lalu hapus instansi hanya baca tersebut.
Catatan
Untuk memastikan stabilitas layanan, ubah titik akhir aplikasi selama jam sepi.
Di panel navigasi di sebelah kiri, klik Major Version Upgrade.
Catatan
Jika Major Version Upgrade tidak ditampilkan 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 peningkatan, atur Upgrade Mode ke Blue-green Deployment, 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. Kemudian, 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, baca pesan peringatan, pilih versi di bawah Select An Upgrade Version, lalu klik Create Upgrade Task.
Dalam kotak dialog yang muncul, baca pesan dan klik OK.

Dalam bagian Create Major Engine Version Upgrade Task, Upgrade Mode disetel ke Blue-green Deployment. Konfigurasikan parameter peningkatan. Tabel berikut hanya menjelaskan parameter kunci.

Konfigurasi	Deskripsi
Storage type	Instans baru hanya mendukung SSD perusahaan (ESSD) dan disk berkinerja premium. Jika Anda memilih ESSD, Anda dapat mengubah tingkat kinerja (PL). Kelas penyimpanan instans baru harus sama dengan instans sumber. Catatan Kapasitas penyimpanan minimum ESSD bervariasi berdasarkan PL. Saat Anda mengubah PL, kapasitas penyimpanan minimum instans secara otomatis disesuaikan berdasarkan PL yang dipilih. Pastikan nilai baru memenuhi persyaratan. Jika instans sumber menggunakan disk lokal berkinerja tinggi, instans baru hanya dapat menggunakan ESSD.
The Available Zone	Sistem memungkinkan Anda mengonfigurasi instans primer dan sekunder baru di zona berbeda setelah peningkatan. Atur parameter ini sesuai kebutuhan.
For Available Zone
Primary Instance Switch
Standby Instance Switch
Cutover configuration	Pilih apakah akan mengalihkan lalu lintas ke instans baru berdasarkan kebutuhan Anda. No cutting: Lalu lintas tidak dialihkan secara otomatis. Opsi ini biasanya digunakan untuk menguji kompatibilitas layanan Anda dengan versi baru sebelum peningkatan resmi. Cutover: Lalu lintas dialihkan secara otomatis. Opsi ini biasanya digunakan untuk peningkatan resmi setelah Anda memastikan bahwa layanan Anda dapat berjalan stabil pada versi baru. Setelah pemotongan, aplikasi Anda secara otomatis terhubung ke instans baru. Anda tidak perlu mengubah titik akhir database dalam aplikasi Anda. Catatan Anda tidak dapat melakukan rollback setelah pemotongan. Pilih opsi ini dengan hati-hati. Selama pemotongan, instans sumber disetel ke mode read-only, yang menyebabkan koneksi transien yang berlangsung selama beberapa menit. Lakukan peningkatan selama jam-jam sepi. Jika Anda memilih untuk tidak melakukan pemotongan, layanan Anda tidak akan terpengaruh. Kami sarankan Anda memilih No cutting untuk percobaan pertama Anda. Setelah Anda sepenuhnya menguji dan memverifikasi lapisan aplikasi, rilis instans baru, ulangi operasi peningkatan, lalu pilih Cutover untuk memulai peningkatan resmi.
Storage Capacity	Pilih kapasitas penyimpanan untuk instans baru. Saat Anda meningkatkan versi utama instans yang menggunakan disk lokal berkinerja tinggi, Anda dapat menurunkan skala kapasitas penyimpanan. Kapasitas penyimpanan minimum yang dapat dipilih harus memenuhi kondisi berikut: Yang lebih kecil dari dua nilai berikut: Penyimpanan terpakai instans sumber × 120%. Jika hasilnya (dalam GB) bukan kelipatan 5, dibulatkan ke kelipatan 5 terdekat. Catatan Anda dapat melihat ruang penyimpanan terpakai instans sumber menggunakan fitur Monitoring And Alarms untuk memeriksa metrik Disk Space (MB). Untuk informasi lebih lanjut, lihat Lihat Monitoring Ditingkatkan. Kapasitas penyimpanan instans sumber. Lebih besar atau sama dengan kapasitas penyimpanan minimum yang dapat dibeli untuk ESSD. Jika tidak, nilai berikut digunakan sebagai kapasitas penyimpanan minimum yang dapat dibeli: PL1 ESSD: 20 GB. PL2 ESSD: 500 GB. PL3 ESSD: 1.500 GB. Catatan Contoh: Instans sumber Anda memiliki kapasitas penyimpanan 100 GB, dan 70 GB digunakan. Saat Anda meningkatkan versi utama, Anda memilih PL1 ESSD untuk tipe penyimpanan. Perhitungan: 70 × 120% = 84. Dibulatkan ke kelipatan 5 terdekat, nilainya adalah 85 GB. Oleh karena itu, kapasitas penyimpanan minimum yang dapat dibeli adalah 85 GB. Instans sumber Anda memiliki kapasitas penyimpanan 700 GB, dan 350 GB digunakan. Saat Anda meningkatkan versi utama, Anda memilih PL2 ESSD untuk tipe penyimpanan. Perhitungan: 350 × 120% = 420. 420 GB kurang dari kapasitas penyimpanan minimum yang dapat dibeli untuk PL2 ESSD, yaitu 500 GB. Oleh karena itu, kapasitas penyimpanan minimum yang dapat dibeli adalah 500 GB.
Instance Type	Tentukan tipe instans untuk instans baru. Untuk informasi lebih lanjut, lihat Daftar Tipe Instans Utama.

Klik Create.
Saat status instans berubah menjadi Migrating, tugas peningkatan telah dimulai.
Waktu yang diperlukan untuk peningkatan sangat berkaitan dengan jumlah objek basis data dalam instans. Semakin banyak objek basis data, semakin lama peningkatan berlangsung. Selama peningkatan versi utama, Anda dapat melihat kemajuan peningkatan di Task Hub.
Penting
- Setelah tugas peningkatan dibuat, tugas tersebut tidak dapat dimodifikasi atau dihapus.
- Saat instans sumber berada dalam status Migrating, Anda tidak dapat melakukan operasi O&M seperti memodifikasi parameter, me-restart, atau melepaskan instans.
- Jika pesan Insufficient Resources muncul saat Anda membuat tugas, ubah Target Primary Zone.
Lihat hasil peningkatan.
Saat status instans sumber dan baru adalah Running, peningkatan berhasil.
Catatan
- Untuk penyebaran biru-hijau dengan pemotongan, lalu lintas secara otomatis dialihkan ke instans baru (versi lebih tinggi) setelah peningkatan.
- Untuk penyebaran biru-hijau tanpa pemotongan, lalu lintas tidak dialihkan ke instans baru (versi lebih tinggi) setelah peningkatan.
- Setelah peningkatan selesai, di tab Upgrade History, klik View Information di kolom Upgrade Log untuk tugas peningkatan target. Anda dapat melihat durasi mode read-only instans dan proses peningkatan rinci. Durasi read-only adalah periode antara Cutover Time dan Cutover End Time. Periode ini tidak termasuk waktu ketika instans tidak dapat dijangkau karena cache DNS belum diperbarui.
- Untuk penyebaran biru-hijau tanpa pemotongan, sistem juga menampilkan Cutover Time dan Cutover End Time untuk referensi dan estimasi Anda dalam skenario pemotongan.

Apa yang harus dilakukan selanjutnya

Jika Anda meningkatkan instans menggunakan pola penyebaran biru-hijau (cutover), segera rilis instans sumber setelah Anda memastikan bahwa layanan Anda berjalan stabil di instans baru.
Kami juga menyarankan Anda untuk mengubah metode penagihan untuk instans baru menjadi langganan untuk penghematan biaya.
Catatan
- Jika Anda melepaskan instans langganan sebelum tanggal kedaluwarsanya, Anda mungkin mengalami kerugian.
- Jika Anda menerima diskon saat membeli instans sumber, instans baru tidak mewarisi diskon ini. Pembatalan langganan instans sumber tunduk pada halaman pembatalan langganan aktual.
- Jumlah dan waktu pengembalian dana untuk instans langganan bergantung pada tagihan pembatalan langganan aktual. Pengembalian dana tidak diproses secara real-time.
(Opsional) Instans baru tidak mencakup instans hanya baca. Jika Anda menghapus instans hanya baca sebelum peningkatan, lakukan langkah-langkah berikut:
1. Pada instans baru, buat instans PostgreSQL hanya baca lagi.
2. Dalam aplikasi Anda, ubah titik akhir yang sebelumnya Anda atur ke titik akhir instans utama kembali ke titik akhir instans hanya baca baru.

Deskripsi hasil peningkatan

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

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

Operasi API terkait

Operasi API	Deskripsi
UpgradeDBInstanceMajorVersionPrecheck	Menjalankan pemeriksaan pra-peningkatan untuk peningkatan versi utama instans ApsaraDB RDS for PostgreSQL.
DescribeUpgradeMajorVersionPrecheckTask	Memeriksa laporan pemeriksaan pra-peningkatan untuk peningkatan versi utama instans ApsaraDB RDS for PostgreSQL.
UpgradeDBInstanceMajorVersion	Memperbarui versi utama instans ApsaraDB RDS for PostgreSQL.
DescribeUpgradeMajorVersionTask	Memeriksa tugas-tugas historis dari 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 database utama tidak didukung.

Apakah penurunan versi utama didukung?

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

Setelah peningkatan versi utama, terjadi kesalahan konflik raster_overviews ketika saya membuat tampilan raster_overviews di instans baru. 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` ketika 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 pada 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 pada 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 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;

Plugin PostGIS Raster tidak digunakan

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

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

Untuk menjaga data langganan pada instans sumber (versi lebih rendah), pastikan bahwa instans sumber tidak gagal karena muatan berlebih selama peningkatan. Jika tidak, slot replikasi mungkin diambil alih oleh instans tujuan (versi lebih tinggi), yang menyebabkan ketidaksesuaian data.
Setelah peningkatan selesai, jalankan pernyataan SQL berikut untuk menonaktifkan langganan pada database instans tujuan.
```
\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;
```
Untuk menjaga data langganan pada instans tujuan, nonaktifkan langganan pada instans sumber sebelum peningkatan versi utama. Setelah peningkatan selesai, aktifkan kembali langganan pada instans tujuan. Berikut adalah contoh pernyataan SQL:
- 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 pelacakan perubahan dengan slot replikasi, lihat Langganan Logis dan Pelacakan Perubahan.
Jika Anda tidak melakukan operasi sebelumnya, data langganan Anda mungkin menjadi tidak konsisten. Untuk informasi lebih lanjut tentang cara menyelesaikan masalah ini, 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). 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 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 sisipkan
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 peningkatan versi utama?

Setelah peningkatan, node hanya baca dan slot replikasi tetap ada di instans sumber dan tidak secara otomatis dipindahkan ke instans baru. Oleh karena itu, sebelum Anda melakukan peningkatan versi utama, Anda harus mengubah titik akhir instans hanya baca di aplikasi Anda ke titik akhir instans utama dan menghapus instans hanya baca yang ada. Setelah peningkatan selesai, buat dan konfigurasikan instans hanya baca baru.

Metode penagihan instans sumber	Metode penagihan instans baru
Langganan/Bayar sesuai pemakaian	Bayar sesuai pemakaian
Serverless	Serverless