Untuk mengadopsi fitur PostgreSQL baru, peningkatan performa, dan peningkatan keamanan tanpa memigrasikan data atau mengubah string koneksi aplikasi, Anda dapat melakukan upgrade versi utama secara langsung pada cluster AlloyDB untuk PostgreSQL.
Komunitas PostgreSQL secara berkala merilis versi utama baru yang berisi fitur, peningkatan performa, serta peningkatan keamanan yang baru. Setelah PostgreSQL merilis versi utama baru, AlloyDB akan menambahkan dukungan untuk versi yang kompatibel. Agar database Anda selalu terbaru, Anda dapat mengupgrade cluster AlloyDB dengan mengupgrade ke versi utama yang lebih tinggi. Anda dapat mengupgrade cluster menggunakan fitur upgrade langsung ini atau dengan memigrasikan data ke cluster AlloyDB baru.
Untuk mengetahui informasi selengkapnya, lihat Kebijakan versi database.
Upgrade versi utama secara langsung adalah cara yang efisien untuk mengupgrade versi utama cluster Anda karena alasan berikut:
- AlloyDB mempertahankan detail cluster dan instance serta setelan database seperti nama instance, alamat IP, dan flag database setelah upgrade.
- Anda tidak perlu mengubah string koneksi aplikasi.
- Semua instance cluster (utama dan kumpulan baca) diupgrade sebagai bagian dari operasi yang sama.
Selain itu, keanggotaan peran dengan pemberi izin yang tidak ada (keanggotaan tanpa induk) tidak dipertahankan. Jika ada cluster yang berisi keanggotaan tanpa induk dalam katalog pg_auth_members, keanggotaan peran ini akan hilang setelah upgrade. Untuk mengetahui informasi selengkapnya, lihat
Menyiapkan cluster untuk upgrade versi utama.
Alur kerja upgrade versi utama secara langsung
Saat Anda memulai upgrade pada cluster, AlloyDB akan melakukan tindakan berikut:
- Menjalankan pemeriksaan pra-upgrade untuk menemukan inkompatibilitas yang dapat memengaruhi upgrade.
- Mempersiapkan upgrade versi utama, yang mencakup pembuatan clone internal cluster.
- Membuat instance utama tidak tersedia. Periode nonaktif dimulai. Operasi baca masih dapat dilakukan melalui kumpulan baca.
- Memulai pencadangan pra-upgrade.
- Mengupgrade instance utama.
- Membuat instance read pool tidak tersedia.
- Membuat instance utama tersedia. Waktu istirahat berakhir.
- Memulai pencadangan pasca-upgrade.
- Mengupgrade instance kumpulan baca.
Setelah pemeriksaan pra-upgrade lulus, cluster Anda akan di-clone ke cluster internal dalam project yang sama. Pencadangan dan pemulihan yang diperlukan untuk meng-clone cluster memerlukan waktu sekitar 10 menit per terabyte data.
Selama operasi clone, Anda dapat terus menggunakan cluster asli. Setelah operasi clone selesai, proses upgrade akan dimulai. Instance utama tidak tersedia untuk pembacaan dan penulisan hingga instance utama diupgrade. Perkiraan periode nonaktif biasanya adalah 20 menit hingga satu jam, dan terutama bergantung pada skema database dan jumlah objek.
Setelah instance utama diupgrade, instance kumpulan baca menjadi tidak tersedia. Upgrade akan dicoba di semua instance kumpulan baca secara bersamaan. Periode nonaktif diperkirakan akan berlangsung sekitar 20 menit.
Jika upgrade versi utama gagal pada langkah apa pun sebelum instance utama diupgrade, AlloyDB akan otomatis me-roll back semua perubahan.
Setelah instance utama diupgrade, versi cluster akan diupgrade ke versi target dan tidak ada rollback yang dipicu untuk kegagalan apa pun setelah tahap ini. Misalnya, AlloyDB tidak akan me-roll back cluster jika satu atau beberapa upgrade instance pool baca gagal. Dalam situasi ini, hubungi Google Cloud Dukungan.
Tabel berikut memberikan perkiraan waktu yang diperlukan untuk menyelesaikan upgrade cluster dengan berbagai ukuran database:
| Ukuran Database | Pra-upgrade (tanpa periode nonaktif) | Periode nonaktif utama | Periode nonaktif kumpulan baca | Durasi total |
|---|---|---|---|---|
| 100 GB | ~15 menit | ~20 menit | ~20 menit | ~1 jam |
| 1 TB | ~30 menit | ~20 menit | ~20 menit | ~1 jam 15 menit |
| 4 TB | ~1 jam | ~20 menit | ~20 menit | ~1 jam 45 menit |
| 16 TB | Sekitar 3 jam | ~20 menit | ~20 menit | ~3 jam 45 menit |
| 32 TB | ~5 jam 30 menit | ~20 menit | ~20 menit | ~6 jam 15 menit |
| 64 TB | ~11 jam | ~20 menit | ~20 menit | ~12 jam |
| 128 TB | ~21 jam 30 menit | ~20 menit | ~20 menit | ~22 jam 15 menit |
Untuk mengetahui informasi selengkapnya, lihat Mengupgrade versi utama database yang sudah diterapkan.
Status upgrade
Anda dapat memantau status operasi upgrade versi utama database yang diterapkan saat sedang berlangsung.
Proses upgrade mencakup tahap-tahap berikut:
ALLOYDB_PRECHECKPG_UPGRADE_CHECKPREPARE_FOR_UPGRADEPRIMARY_INSTANCE_UPGRADEREAD_POOL_INSTANCES_UPGRADEROLLBACK(hanya jika terjadi kegagalan sebelum upgrade read pool)CLEANUP
Kemungkinan status dari tahap ini mencakup:
NOT_STARTEDIN_PROGRESSSUCCESSFAILEDCANCEL_IN_PROGRESSCANCELLED
Pembatalan upgrade
Anda dapat membatalkan operasi upgrade hingga titik tertentu selama upgrade instance utama. Setelah melewati titik tersebut, Anda tidak dapat membatalkan upgrade.
Di konsol Google Cloud , operasi tidak dapat dibatalkan jika tombol Cancel upgrade berwarna abu-abu. Dengan menggunakan Google Cloud CLI atau
REST API, Anda dapat
menentukan apakah Anda dapat membatalkan upgrade dengan memeriksa
upgradeClusterStatus dalam status upgrade:
- Jika
cancellableadalahtrue, Anda dapat membatalkan upgrade. - Jika
cancellableadalahfalseatau tidak ada dalam status, Anda tidak dapat membatalkan upgrade.
Pencadangan otomatis sebelum dan setelah upgrade
Saat Anda melakukan upgrade versi utama, AlloyDB secara otomatis
membuat cadangan berkelanjutan berikut, dengan XX sebagai versi utama sumber
dan YY sebagai versi utama target.
- Cadangan pra-upgrade dibuat segera sebelum upgrade dimulai. Cadangan ini diberi nama menggunakan format
pre-upgrade-bkp-pgXX-pgYY-<uuid>. Anda dapat menggunakan cadangan ini untuk memulihkan ke status sebelum upgrade. Perhatikan bahwa pemulihan bukanlah operasi di tempat dan akan membuat cluster baru. - Cadangan pasca-upgrade dibuat setelah instance utama diupgrade. Cadangan ini diberi nama menggunakan format
post-upgrade-bkp-pgXX-pgYY-<uuid>.
Pencadangan berkelanjutan bersifat inkremental, yang berarti pencadangan hanya menyimpan data yang berubah dibandingkan dengan pencadangan berkelanjutan sebelumnya. Pendekatan ini mengurangi ukuran dan biaya (dalam resource) pencadangan, serta mempercepat proses pembuatan cadangan. Untuk mengetahui informasi selengkapnya, lihat Ringkasan pencadangan dan pemulihan data.
Saat Anda melihat daftar cadangan, cadangan upgrade akan dicantumkan dengan jenis
CONTINUOUS. Untuk mengetahui informasi selengkapnya, lihat
Melihat daftar cadangan.
Melakukan pemulihan point-in-time (PITR) memerlukan ketersediaan cadangan versi. Pemulihan tidak tersedia di cluster yang diupgrade hingga pencadangan pasca-upgrade, atau pencadangan lain yang dimulai setelah instance utama diupgrade, selesai.