Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Mengupgrade versi server utama cluster

Mengupgrade cluster AlloyDB untuk PostgreSQL ke versi utama PostgreSQL yang lebih baru memungkinkan Anda menggunakan fitur database, peningkatan performa, dan update keamanan terbaru. Anda dapat mengupgrade versi utama cluster di tempat atau dengan memigrasikan data ke cluster yang menjalankan versi PostgreSQL yang lebih baru.

Untuk mengetahui informasi selengkapnya tentang cara membuat cluster, lihat Membuat cluster dan instance utamanya.

Kompatibilitas versi cluster dan PostgreSQL

Saat membuat cluster AlloyDB, Anda memilih versi utama PostgreSQL yang kompatibel dengan instance dalam cluster. Secara default, nilai ini adalah 17.

AlloyDB melakukan upgrade versi database minor otomatis selama pemeliharaan berkala. Misalnya, jika Anda membuat cluster dengan kompatibilitas 17, AlloyDB akan terus mengupgrade server database ke versi minor terbaru dari 17.

Namun, upgrade versi utama PostgreSQL mengharuskan Anda merencanakan, menguji, dan melakukan upgrade sendiri.

Ada beberapa metode untuk melakukan upgrade versi utama cluster Anda:

Upgrade versi utama langsung yang kami rekomendasikan untuk digunakan.
Memigrasikan data dengan ekspor data berbasis file.
Menggunakan Database Migration Service.

Setiap solusi upgrade menawarkan kelebihan dan kekurangan yang berbeda. Lihat tabel berikut untuk perbandingan singkat guna membantu Anda memilih pendekatan yang tepat untuk skenario Anda.

Upgrade versi utama langsung	Ekspor data berbasis file	Migrasi dengan Database Migration Service
Cluster Anda, termasuk instance baca, akan diupgrade ke versi utama yang lebih tinggi yang dipilih.	Ekspor berbasis file memindahkan snapshot satu kali dari database Anda.	Database Migration Service menawarkan kemampuan replikasi berkelanjutan selama proses migrasi, sehingga mengurangi kemungkinan hilangnya data di cluster baru Anda.
Anda dapat terus mengerjakan cluster selama tahap pra-upgrade.	Aplikasi Anda mengalami periode nonaktif yang lebih lama yang dimulai saat Anda mengekspor data. Anda tidak dapat menerima penulisan database di cluster asli hingga cluster baru beroperasi sepenuhnya.	Aplikasi Anda mengalami periode nonaktif yang lebih singkat yang dimulai saat Anda ingin mengalihkan aplikasi untuk menggunakan cluster baru.
Anda dapat memperkirakan waktu nonaktif sekitar 20 menit atau lebih selama proses upgrade, bergantung pada skema Anda. Setelah upgrade, Anda dapat mengakses cluster dengan alamat IP yang sama.	Anda memiliki kontrol terperinci yang lebih besar atas data yang akan disertakan dalam ekspor dan dapat memilih untuk tidak memigrasikan tabel tertentu atau entitas lainnya.	Database Migration Service otomatis memigrasikan semua database yang ada di instance Anda, dan semua instance di cluster Anda. Anda tidak dapat memilih untuk mengecualikan tabel atau tampilan tertentu dari data migrasi.
Cluster Anda dapat mengaktifkan mode penerapan SSL.	Cluster Anda dapat mengaktifkan mode penerapan SSL.	Untuk tujuan migrasi, Database Migration Service mengharuskan Anda menonaktifkan mode penerapan SSL di cluster sumber.

Bagian berikutnya menjelaskan proses melakukan upgrade versi utama, termasuk memigrasikan data Anda.

Upgrade versi utama langsung

Upgrade di tempat akan mengupdate cluster yang ada tanpa mengharuskan Anda menyiapkan cluster tambahan. Untuk mengetahui informasi selengkapnya, lihat Mengupgrade versi utama database yang sudah diterapkan.

Melakukan migrasi menggunakan ekspor data berbasis file

Untuk menggunakan server database yang kompatibel dengan versi utama PostgreSQL yang lebih tinggi, Anda perlu membuat cluster yang identik secara fungsional di region yang sama, lalu memigrasikan data ke dalamnya.

Ikuti langkah-langkah berikut:

Buat cluster yang dikonfigurasi dengan kompatibilitas versi utama PostgreSQL yang ingin Anda gunakan. Buat cluster di region yang sama dengan cluster Anda saat ini.
Siapkan cluster baru dengan versi utama baru agar sesuai dengan konfigurasi cluster saat ini:
1. Buat instance kumpulan baca tambahan sesuai kebutuhan.
2. Buat cluster sekunder sesuai kebutuhan.
  
  Saat membuat cluster sekunder, Anda tidak perlu menentukan nomor versi utama PostgreSQL. AlloyDB menerapkan versi PostgreSQL cluster utama ke semua cluster sekundernya.
3. Perbarui flag database cluster baru agar sesuai dengan setelan flag cluster saat ini.
4. Aktifkan ekstensi apa pun yang diperlukan aplikasi Anda.
Ekspor data Anda dari cluster lama ke file menggunakan psql atau pg_dump.
Impor data Anda dari file ke cluster baru.

Aplikasi Anda dapat terhubung ke instance cluster baru di alamat IP barunya.

Melakukan migrasi menggunakan Database Migration Service

Anda dapat menggunakan Database Migration Service untuk memindahkan data dari database PostgreSQL ke cluster AlloyDB. Database Migration Service tidak menyediakan konfigurasi yang dikhususkan untuk sumber data AlloyDB, tetapi AlloyDB kompatibel dengan PostgreSQL sehingga Anda dapat menggunakan konfigurasi yang ditujukan untuk sumber PostgreSQL generik.

Jalur migrasi ini bukan upgrade langsung dan menghasilkan pembuatan cluster baru dengan alamat IP yang berbeda. Sebaiknya clone cluster Anda terlebih dahulu dan lakukan migrasi pengujian untuk memverifikasi apakah aplikasi Anda kompatibel dengan pendekatan ini.

Pertimbangan penting

Sebelum bersiap untuk bermigrasi dengan Database Migration Service, pertimbangkan dengan cermat batasan berikut untuk memastikan jalur migrasi ini sesuai dengan skenario upgrade Anda.

Batasan

Instance AlloyDB yang dikonfigurasi dengan Private Service Connect tidak didukung.
Anda tidak dapat melakukan update instance atau permintaan failover pada cluster sumber selama migrasi. Operasi ini dapat menyebabkan tugas migrasi gagal.
Semua batasan standar untuk migrasi PostgreSQL ke AlloyDB berlaku untuk skenario ini. Untuk mengetahui daftar lengkap batasan lainnya, lihat Batasan umum dalam dokumentasi Database Migration Service.

Kualitas migrasi

Jenis data tertentu, seperti objek besar, tidak dimigrasikan. Untuk mengetahui daftar lengkap data yang didukung, lihat Fidelitas migrasi dalam dokumentasi Database Migration Service.

Penguncian dan periode nonaktif database sumber

Database Migration Service menggunakan migrasi berkelanjutan untuk memindahkan data ke cluster AlloyDB. Jenis migrasi ini menyebabkan penguncian singkat (di bawah 10 detik) pada tabel database sumber, satu per satu, saat dump data awal dibuat.

Setelah migrasi selesai, Anda harus menghentikan semua penulisan di database sumber sebelum dapat mengalihkan aplikasi ke cluster baru. Prosedur ini memerlukan periode nonaktif. Untuk ringkasan yang lebih mendetail, lihat Migrasi berkelanjutan dalam dokumentasi Database Migration Service.

Batasan replikasi

Setelah tugas migrasi beralih ke fase change data capture (CDC), Database Migration Service akan terus mereplikasi data baru yang ditulis ke database sumber Anda.

Untuk tabel yang tidak memiliki kunci utama, hanya pernyataan INSERT yang direplikasi selama fase CDC. Setiap tindakan CREATE, UPDATE, atau DELETE yang dilakukan pada tabel yang tidak memiliki kunci utama selama fase CDC harus dibuat ulang di database tujuan secara manual untuk menghindari kehilangan data.

Sebelum memulai

Aktifkan Database Migration Service API, jika belum diaktifkan.
Peran yang diperlukan untuk mengaktifkan API
Untuk mengaktifkan API, Anda memerlukan izin serviceusage.services.enable. Jika Anda membuat project, kemungkinan Anda sudah memiliki izin ini melalui peran Pemilik (roles/owner). Jika tidak, Anda bisa mendapatkan izin ini melalui peran Service Usage Admin (roles/serviceusage.serviceUsageAdmin). Pelajari cara memberikan peran.
Mengaktifkan API

Pastikan Anda memiliki peran berikut di project:
- Salah satu dari berikut ini:
  - AlloyDB > AlloyDB Admin
  - Basic > Owner
  - Dasar > Editor
- Anda juga harus memiliki izin compute.networks.list di Google Cloud project yang Anda gunakan. Untuk mendapatkan izin ini sekaligus mengikuti prinsip hak istimewa terendah, minta administrator untuk memberi Anda peran Compute Engine > Compute Network User (roles/compute.networkUser).
- Database Migration Admin
Memeriksa peran
1. Di konsol Google Cloud , buka halaman IAM.
  Buka IAM
2. Pilih project.
3. Di kolom Principal, temukan semua baris yang mengidentifikasi Anda atau grup yang mencakup Anda. Untuk mengetahui grup tempat Anda disertakan, hubungi administrator Anda.
4. Untuk semua baris yang menentukan atau menyertakan Anda, periksa kolom Peran untuk melihat apakah daftar peran menyertakan peran yang diperlukan.
Memberikan peran
1. Di konsol Google Cloud , buka halaman IAM.
  Buka IAM
2. Pilih project.
3. Klik Grant access.
4. Di kolom New principals, masukkan ID pengguna Anda. Biasanya, ini adalah alamat email untuk Akun Google.
5. Klik Select a role, lalu telusuri peran.
6. Untuk memberikan peran tambahan, klik Add another role, lalu tambahkan tiap peran tambahan.
7. Klik Simpan.
Pastikan jaringan Virtual Private Cloud (VPC) di project Google Cloud yang Anda gunakan dikonfigurasi untuk akses layanan pribadi ke AlloyDB.
Tentukan region tempat Anda ingin membuat cluster tujuan. Semua entity Database Migration Service (profil koneksi, tugas migrasi) harus dibuat di region yang sama dengan cluster tujuan Anda.
Siapkan pengguna database yang ingin Anda hubungkan ke cluster dan jalankan pernyataan migrasi di database sumber. Pengguna database ini memerlukan serangkaian izin dan peran tertentu. Sebaiknya Anda membuat pengguna database baru dan menetapkannya secara khusus untuk tujuan melakukan migrasi.

Mengonfigurasi instance sumber

Database Migration Service memerlukan konfigurasi khusus agar dapat terhubung dan menyalin data dari cluster sumber ke cluster tujuan baru.

Untuk mengonfigurasi instance sumber AlloyDB, lakukan langkah-langkah berikut:

Konfigurasi flag database di setiap instance dalam cluster sumber Anda. Gunakan nilai berikut:

Flag	Nilai
`alloydb.logical_decoding`	Tetapkan ke `on`.
`alloydb.enable_pglogical`	Tetapkan ke `on`.
`max_replication_slots`	Flag ini menentukan jumlah maksimum slot replikasi yang dapat didukung oleh instance sumber. Nilai minimum untuk flag ini adalah `50`. Hitung nilai minimum menggunakan formula berikut: `(the number of databases in your instance) * (the number of simultaneous migration jobs you want to perform) + (slots reserved for table synchronization) + (the number of replication slots that you use for your read replicas)` Perhatikan contoh berikut: Anda tidak memiliki replika baca di sumber. Anda memiliki 30 database di instance sumber utama. Anda ingin membuat 2 tugas migrasi untuk cluster sumber. Anda ingin menggunakan 10 slot untuk replikasi tabel. Dalam kasus tersebut, jumlah `max_replication_slots` harus minimal `70`, yang dihitung sebagai `30 * 2 + 10 + 0`.
`max_wal_senders`	Tetapkan flag ini ke setidaknya 10 lebih banyak dari nilai `max_replication_slots` ditambah jumlah pengirim yang sudah digunakan di instance Anda. Misalnya, jika Anda menetapkan flag `max_replication_slots` ke `70` dan Anda sudah menggunakan 2 pengirim, `max_wal_senders` harus minimal `82` (dihitung sebagai `70 + 10 + 2 = 82`).
`max_worker_processes`	Tetapkan flag ini ke setidaknya jumlah database dalam instance Anda ditambah jumlah `max_worker_processes` yang sudah Anda gunakan. Misalnya, jika Anda memiliki 30 database di instance sumber dan tidak menggunakan proses pekerja apa pun, tetapkan flag ini ke `30`.

Nonaktifkan mode penerapan SSL di setiap instance di cluster sumber Anda.

Mengonfigurasi database sumber

Anda harus menginstal ekstensi pglogical dan memberikan izin yang diperlukan kepada pengguna database yang Anda tetapkan sebagai pengguna migrasi di setiap database dalam instance Anda.

Untuk mengonfigurasi database, lakukan langkah-langkah berikut:

Hubungkan ke database postgres default menggunakan klien psql.
Instal ekstensi pglogical dengan menjalankan perintah berikut:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Berikan izin kepada pengguna database migrasi di semua skema kecuali untuk skema information dan skema yang namanya dimulai dengan awalan pg_. Jalankan pernyataan berikut:
```
GRANT USAGE on SCHEMA SCHEMA_NAME to USER_NAME;
GRANT SELECT on ALL TABLES in SCHEMA SCHEMA_NAME to USER_NAME;
GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA_NAME to USER_NAME;
```
Ganti kode berikut:
- SCHEMA_NAME: nama skema yang ada di database Anda
- USER_NAME: nama pengguna database yang Anda siapkan di bagian Sebelum memulai
Ulangi langkah ini untuk setiap skema dalam database Anda kecuali untuk skema information, dan skema yang namanya diawali dengan awalan pg_. Anda dapat mencantumkan semua skema database dengan perintah meta \dn.

Berikan izin yang diperlukan yang tersisa. Jalankan pernyataan berikut:

GRANT USAGE on SCHEMA pglogical to PUBLIC;
GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER_NAME;
ALTER USER USER_NAME with REPLICATION;

Ganti USER_NAME dengan nama pengguna database yang Anda siapkan di bagian Sebelum memulai.

Hubungkan ke setiap database lain di instance Anda dan ulangi langkah 2, 3, dan 4.
- Anda dapat mencantumkan semua database dalam instance dengan perintah meta \list.
- Anda dapat beralih ke database lain tanpa mereset koneksi klien psql menggunakan perintah \connect DATABASE_NAME.
Ulangi prosedur ini untuk setiap instance di cluster AlloyDB sumber Anda.

Menjalankan migrasi di Database Migration Service