Persyaratan Batasan Mengatur dan memeriksa nilai parameter Meng-upgrade Aurora PostgreSQL ke versi mayor yang baru Melakukan tugas pasca-upgrade

Menggunakan replikasi logis untuk melakukan upgrade versi mayor untuk Aurora PostgreSQL

Menggunakan replikasi logis dan kloning cepat Aurora, Anda dapat melakukan upgrade versi mayor yang menggunakan versi basis data Aurora PostgreSQL saat ini sambil secara bertahap memigrasikan data yang berubah ke basis data versi mayor yang baru. Proses upgrade dengan waktu henti rendah ini disebut sebagai blue/green upgrade. Versi basis data saat ini disebut sebagai lingkungan “blue” dan versi basis data baru disebut sebagai lingkungan “green”.

Kloning cepat Aurora sepenuhnya memuat data yang ada dengan mengambil snapshot basis data sumber. Kloning cepat menggunakan copy-on-write protokol yang dibangun di atas lapisan penyimpanan Aurora, yang memungkinkan Anda membuat tiruan database dalam waktu singkat. Metode ini sangat efektif saat meng-upgrade ke basis data besar.

Replikasi logis di PostgreSQL melacak dan mentransfer perubahan data Anda dari instans awal ke instans baru yang berjalan secara paralel hingga Anda pindah ke versi PostgreSQL yang lebih baru. Replikasi logis menggunakan model "publish and subscribe". Untuk informasi selengkapnya tentang replikasi logis Aurora PostgreSQL, lihat Replikasi dengan Amazon Aurora PostgreSQL.

Tip

Anda dapat meminimalkan waktu henti yang diperlukan untuk upgrade versi mayor dengan menggunakan fitur Deployment Blue/Green Amazon RDS terkelola. Untuk informasi selengkapnya, lihat Menggunakan Deployment Blue/Green Amazon RDS untuk pembaruan basis data.

Topik

Persyaratan
Batasan
Mengatur dan memeriksa nilai parameter
Meng-upgrade Aurora PostgreSQL ke versi mayor yang baru
Melakukan tugas pasca-upgrade

Persyaratan

Anda harus memenuhi persyaratan berikut untuk melakukan proses upgrade dengan waktu henti rendah ini:

Anda harus memiliki izin rds_superuser.
Klaster DB Aurora PostgreSQL yang ingin Anda upgrade harus menjalankan versi yang didukung yang dapat melakukan upgrade versi mayor menggunakan replikasi logis. Pastikan untuk menerapkan pembaruan dan patch versi minor apa pun ke klaster DB Anda. Fungsi aurora_volume_logical_start_lsn yang digunakan dalam teknik ini didukung dalam versi Aurora PostgreSQL berikut:
- 15.2 dan versi 15 yang lebih tinggi
- Versi 14.3 dan versi 14 yang lebih tinggi
- Versi 13.6 dan versi 13 yang lebih tinggi
- Versi 12.10 dan versi 12 yang lebih tinggi
- Versi 11.15 dan versi 11 yang lebih tinggi
- 10.20 dan versi 10 yang lebih tinggi
Untuk informasi selengkapnya tentang fungsi aurora_volume_logical_start_lsn, lihat aurora_volume_logical_start_lsn.
Semua tabel Anda harus memiliki kunci primer atau menyertakan kolom identitas PostgreSQL.
Konfigurasikan grup keamanan untuk VPC Anda agar mengizinkan akses masuk dan keluar antara dua klaster DB Aurora PostgreSQL, baik yang lama maupun yang baru. Anda dapat memberikan akses ke rentang perutean antar domain tanpa kelas (CIDR) tertentu atau ke grup keamanan lain di VPC Anda atau VPC peer. (VPC peer membutuhkan koneksi peering VPC.)

catatan

Untuk informasi terperinci tentang izin yang diperlukan untuk mengonfigurasi dan mengelola skenario replikasi logis yang berjalan, lihat Dokumentasi inti PostgreSQL.

Batasan

Saat Anda melakukan upgrade dengan waktu henti rendah pada klaster DB Aurora PostgreSQL Anda untuk meng-upgrade-nya ke versi mayor baru, Anda menggunakan fitur replikasi logis PostgreSQL native. Fitur ini memiliki kemampuan dan batasan yang sama dengan replikasi logis PostgreSQL. Untuk informasi selengkapnya, lihat Replikasi logis PostgreSQL.

Perintah bahasa definisi data (DDL) tidak direplikasi.
Replikasi tidak mendukung perubahan skema dalam basis data aktif. Skema dibuat kembali dalam bentuk aslinya selama proses kloning. Jika Anda mengubah skema setelah kloning, tetapi sebelum menyelesaikan upgrade, perubahan tersebut tidak akan tercermin dalam instans yang di-upgrade.
Objek besar tidak direplikasi, tetapi Anda dapat menyimpan data dalam tabel normal.
Replikasi hanya didukung oleh tabel, termasuk tabel yang dipartisi. Replikasi ke jenis relasi lain, seperti tampilan, tampilan terwujud, atau tabel asing, tidak didukung.
Data urutan tidak direplikasi dan memerlukan pembaruan manual pasca-failover.

catatan

Upgrade ini tidak mendukung auto-scripting. Anda harus melakukan semua langkah secara manual.

Mengatur dan memeriksa nilai parameter

Sebelum meng-upgrade, konfigurasikan instans penulis klaster DB Aurora PostgreSQL Anda untuk bertindak sebagai server penerbitan. Instans harus menggunakan grup parameter klaster DB kustom dengan pengaturan berikut:

rds.logical_replication – Atur parameter ini ke 1. Parameterrds.logical_replication memiliki tujuan yang sama dengan parameter wal_level server PostgreSQL mandiri dan parameter lain yang mengontrol manajemen file write-ahead log.
max_replication_slots – Atur parameter ini ke jumlah total langganan yang berencana Anda buat. Jika Anda menggunakan AWS DMS, atur parameter ini ke jumlah AWS DMS tugas yang Anda rencanakan untuk digunakan untuk pengambilan data yang diubah dari cluster DB ini.
max_wal_senders – Atur ke jumlah koneksi konkuren, plus beberapa tambahan, untuk mengakomodasi tugas manajemen dan sesi baru. Jika Anda menggunakan AWS DMS, jumlah max_wal_senders harus sama dengan jumlah sesi bersamaan ditambah jumlah AWS DMS tugas yang mungkin bekerja pada waktu tertentu.
max_logical_replication_workers – Atur ke jumlah pekerja replikasi logis dan pekerja sinkronisasi tabel yang Anda inginkan. Umumnya aman untuk mengatur jumlah pekerja replikasi ke nilai yang sama yang digunakan untuk max_wal_senders. Pekerja diambil dari kumpulan proses latar belakang (max_worker_processes) yang dialokasikan untuk server.
max_worker_processes – Atur ke jumlah proses latar belakang untuk server. Jumlah ini harus cukup besar untuk mengalokasikan pekerja untuk replikasi, proses autovacuum, dan proses pemeliharaan lainnya yang mungkin terjadi secara bersamaan.

Saat Anda meng-upgrade ke versi Aurora PostgreSQL yang lebih baru, Anda perlu menduplikasi parameter apa pun yang Anda modifikasi di grup parameter versi sebelumnya. Parameter ini diterapkan ke versi yang di-upgrade. Anda dapat mengkueri tabel pg_settings untuk mendapatkan daftar pengaturan parameter sehingga Anda dapat membuatnya kembali di klaster DB Aurora PostgreSQL baru Anda.

Misalnya, untuk mendapatkan pengaturan untuk parameter replikasi, jalankan kueri berikut:


SELECT name, setting FROM pg_settings WHERE name in 
('rds.logical_replication', 'max_replication_slots', 
'max_wal_senders', 'max_logical_replication_workers', 
'max_worker_processes');

Meng-upgrade Aurora PostgreSQL ke versi mayor yang baru

Untuk mempersiapkan penerbit (blue)

Dalam contoh berikut, instans penulis sumber (blue) adalah klaster DB Aurora PostgreSQL yang menjalankan PostgreSQL versi 11.15. Ini adalah simpul penerbitan dalam skenario replikasi kita. Untuk demonstrasi ini, instans penulis sumber kita menghosting tabel sampel yang menyimpan serangkaian nilai:
```
CREATE TABLE my_table (a int PRIMARY KEY);
INSERT INTO my_table VALUES (generate_series(1,100));
```
Untuk membuat penerbitan pada instans sumber, hubungkan ke simpul penulis instans dengan psql (CLI untuk PostgreSQL) atau dengan klien pilihan Anda). Masukkan perintah berikut di setiap basis data:
```
CREATE PUBLICATION publication_name FOR ALL TABLES;
```
Publication_name menentukan nama penerbitan.
Anda juga perlu membuat slot replikasi pada instans. Perintah berikut membuat slot replikasi dan memuat plug-in pendekodean logis pgoutput. Plug-in ini mengubah pembacaan konten dari write-ahead logging (WAL) ke protokol replikasi logis, dan memfilter data sesuai dengan spesifikasi penerbitan.
```
SELECT pg_create_logical_replication_slot('replication_slot_name', 'pgoutput');
```

Untuk mengkloning penerbit

Gunakan Konsol Amazon RDS untuk membuat klon dari instans sumber. Sorot nama instans di Konsol Amazon RDS, lalu pilih Buat klona di menu Tindakan.
Berikan nama yang unik untuk instans. Sebagian besar pengaturan adalah default dari instans sumber. Ketika Anda telah membuat perubahan yang diperlukan untuk instans baru, pilih Buat klona.
Saat instans target dimulai, kolom Status simpul penulis akan menampilkan Membuat di kolom Status. Saat instans siap, statusnya berubah menjadi Tersedia.

Untuk mempersiapkan klon untuk upgrade

Klon adalah instans 'green' dalam model deployment. Ini adalah host dari simpul langganan replikasi. Ketika simpul tersedia, hubungkan dengan psql dan kueri simpul penulis baru untuk mendapatkan nomor urutan log (LSN). LSN mengidentifikasi awal catatan di stream WAL.
```
SELECT aurora_volume_logical_start_lsn();
```

Dalam respons dari kueri, Anda akan menemukan nomor LSN. Anda memerlukan nomor ini nanti dalam prosesnya, jadi catatlah.


postgres=> SELECT aurora_volume_logical_start_lsn();
aurora_volume_logical_start_lsn 
---------------
0/402E2F0
(1 row)

Sebelum meng-upgrade klon, hapus slot replikasi klon.


SELECT pg_drop_replication_slot('replication_slot_name');

Untuk meng-upgrade klaster ke versi mayor yang baru

Setelah mengkloning simpul penyedia, gunakan Konsol Amazon RDS untuk memulai upgrade versi mayor pada simpul langganan. Sorot nama instans di konsol RDS, dan pilih tombol Modifikasi. Pilih versi yang diperbarui dan grup parameter Anda yang diperbarui, lalu segera terapkan pengaturan untuk meng-upgrade instans target.

Anda juga dapat menggunakan CLI untuk melakukan upgrade:


aws rds modify-db-cluster —db-cluster-identifier $TARGET_Aurora_ID —engine-version 13.6 —allow-major-version-upgrade —apply-immediately

Untuk mempersiapkan pelanggan (hijau)

Saat klon tersedia setelah upgrade, hubungkan dengan psql dan tentukan langganan. Untuk melakukannya, Anda perlu menentukan opsi berikut dalam perintah CREATE SUBSCRIPTION:
- subscription_name – Nama langganan.
- admin_user_name – Nama pengguna administratif dengan izin rds_superuser.
- admin_user_password – Kata sandi yang terkait dengan pengguna administratif.
- source_instance_URL – URL instans server penerbitan.
- database – Basis data yang akan terhubung dengan server langganan.
- publication_name – Nama server penerbitan.
- replication_slot_name – Nama slot replikasi.
```
CREATE SUBSCRIPTION subscription_name 
CONNECTION 'postgres://admin_user_name:admin_user_password@source_instance_URL/database' PUBLICATION publication_name 
WITH (copy_data = false, create_slot = false, enabled = false, connect = true, slot_name = 'replication_slot_name');
```
Setelah membuat langganan, jalankan kueri terhadap tampilan pg_replication_origin untuk mengambil nilai roname, yang merupakan pengidentifikasi asal replikasi. Setiap instans memiliki satu roname:
```
SELECT * FROM pg_replication_origin;
```
Sebagai contoh:
```
postgres=> 
SELECT * FROM pg_replication_origin;
 
roident | roname 
---------+----------
1 | pg_24586
```
Berikan LSN yang Anda catat dari kueri sebelumnya dari simpul penerbitan dan roname yang dihasilkan dari simpul langganan [INSTANCE] dalam perintah. Perintah ini menggunakan fungsi pg_replication_origin_advance untuk menentukan titik awal dalam urutan log untuk replikasi.
```
SELECT pg_replication_origin_advance('roname', 'log_sequence_number');
```
roname adalah pengidentifikasi yang dihasilkan oleh tampilan pg_replication_origin.

log_sequence_number adalah nilai yang dihasilkan oleh kueri sebelumnya terhadap fungsi aurora_volume_logical_start_lsn.
Kemudian, gunakan klausa ALTER SUBSCRIPTION... ENABLE untuk mengaktifkan replikasi logis.
```
ALTER SUBSCRIPTION subscription_name ENABLE;
```

Pada tahap ini, Anda dapat mengonfirmasi bahwa replikasi berfungsi. Tambahkan nilai ke instans penerbitan, lalu konfirmasikan bahwa nilainya direplikasi ke simpul langganan.

Kemudian, gunakan perintah berikut untuk memantau lag replikasi pada simpul penerbitan:


SELECT now() AS CURRENT_TIME, slot_name, active, active_pid, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),
confirmed_flush_lsn)) AS diff_size, pg_wal_lsn_diff(pg_current_wal_lsn(),
confirmed_flush_lsn) AS diff_bytes FROM pg_replication_slots WHERE slot_type = 'logical';

Sebagai contoh:


postgres=> SELECT now() AS CURRENT_TIME, slot_name, active, active_pid, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), 
confirmed_flush_lsn)) AS diff_size, pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn) AS diff_bytes FROM pg_replication_slots WHERE slot_type = 'logical';
 
current_time                   | slot_name             | active | active_pid | diff_size | diff_bytes 
-------------------------------+-----------------------+--------+------------+-----------+------------
2022-04-13 15:11:00.243401+00  | replication_slot_name | t      | 21854      | 136 bytes | 136
(1 row)

Anda dapat memantau lag replikasi menggunakan nilai diff_size dan diff_bytes. Saat nilai ini mencapai 0, replika telah menyamai instans DB sumber.

Melakukan tugas pasca-upgrade

Saat upgrade selesai, status instans ditampilkan sebagai Tersedia di kolom Status dalam dasbor konsol. Pada instans baru, kami menyarankan agar Anda melakukan hal berikut:

Arahkan ulang aplikasi Anda untuk mengarah ke simpul penulis.
Tambahkan simpul pembaca untuk mengelola caseload dan memberikan ketersediaan tinggi jika terjadi masalah dengan simpul penulis.
Klaster DB Aurora PostgreSQL terkadang memerlukan pembaruan sistem operasi. Pembaruan ini mungkin menyertakan pustaka glibc versi yang lebih baru. Selama pembaruan tersebut, sebaiknya Anda mengikuti pedoman seperti yang dijelaskan dalam Kolasi yang didukung di Aurora PostgreSQL.
Perbarui izin pengguna pada instans baru untuk memastikan akses.

Setelah menguji aplikasi dan data pada instans baru, kami sarankan agar Anda membuat cadangan akhir instans awal Anda sebelum menghapusnya. Untuk informasi selengkapnya tentang penggunaan replikasi logis pada host Aurora, lihat Menyiapkan replikasi logis untuk klaster DB Aurora PostgreSQL Anda.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Menganalisis penggunaan sumber daya dengan CloudWatch metrik

Pemecahan masalah penyimpanan