Dokumen ini menjelaskan upgrade versi utama di tempat untuk database AlloyDB untuk PostgreSQL, yang memungkinkan Anda mengupgrade database ke versi yang lebih tinggi tanpa memigrasikan data atau mengganti instance yang ada.
Komunitas PostgreSQL secara berkala merilis versi utama baru yang berisi fitur baru, peningkatan performa, dan peningkatan keamanan. Setelah PostgreSQL merilis versi utama baru, AlloyDB menambahkan dukungan untuk versi yang kompatibel. Agar database Anda tetap terupdate, Anda dapat mengupgrade cluster AlloyDB dengan mengupgrade ke versi utama yang lebih tinggi. Anda dapat mengupgrade cluster dengan menggunakan fitur upgrade di tempat 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 (kumpulan baca dan utama) diupgrade sebagai bagian dari operasi yang sama.
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. Waktu istirahat dimulai. Operasi baca masih dapat dilakukan melalui kumpulan baca.
- Memulai pencadangan pra-upgrade.
- Mengupgrade instance utama.
- Membuat instance pool baca tidak tersedia.
- Membuat instance utama tersedia. Waktu istirahat berakhir.
- Memulai pencadangan pasca-upgrade.
- Mengupgrade instance kumpulan baca.
Setelah pemeriksaan pra-upgrade berhasil, 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 baca dan tulis hingga instance utama diupgrade. Waktu nonaktif yang diharapkan biasanya 20 menit hingga satu jam, dan terutama bergantung pada skema database dan jumlah objek Anda.
Setelah instance utama diupgrade, instance kumpulan baca menjadi tidak tersedia. Upgrade dicoba di semua instance pool baca secara bersamaan. Waktu nonaktif diperkirakan berlangsung sekitar 20 menit.
Jika upgrade versi utama gagal pada langkah apa pun sebelum instance utama diupgrade, AlloyDB akan otomatis mengembalikan semua perubahan.
Setelah instance utama diupgrade, versi cluster akan diupgrade ke versi target dan tidak ada rollback yang dipicu untuk kegagalan apa pun setelah titik ini. Misalnya, AlloyDB tidak melakukan roll back cluster jika satu atau beberapa upgrade instance kumpulan baca gagal. Dalam situasi ini, hubungi Dukungan Google Cloud CLI.
Tabel berikut memberikan perkiraan waktu yang diperlukan untuk menyelesaikan upgrade bagi cluster dengan ukuran database yang berbeda:
| Ukuran Database | Pra-upgrade (tanpa periode nonaktif) | Periode nonaktif utama | Waktu non-operasional 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 | Sekitar 3 jam 45 menit |
| 32 TB | Sekitar 5 jam 30 menit | ~20 menit | ~20 menit | Sekitar 6 jam 15 menit |
| 64 TB | Sekitar 11 jam | ~20 menit | ~20 menit | Sekitar 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 diterapkan.
Status upgrade
Anda dapat memantau status operasi upgrade versi utama database di tempat 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 kumpulan baca)CLEANUP
Kemungkinan status tahap ini meliputi:
NOT_STARTEDIN_PROGRESSSUCCESSFAILEDCANCEL_IN_PROGRESSCANCELLED
Pembatalan upgrade
Anda dapat membatalkan operasi upgrade hingga titik tertentu selama upgrade instance utama. Setelah titik tersebut terlewati, Anda tidak dapat membatalkan upgrade.
Di konsol Google Cloud , operasi tidak dapat dibatalkan jika tombol
Batalkan upgrade berwarna abu-abu. Dengan menggunakan Google Cloud CLI atau REST API, Anda dapat menentukan apakah Anda dapat membatalkan upgrade dengan memeriksa upgradeClusterStatus di 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 pencadangan berkelanjutan berikut, dengan XX adalah versi utama sumber
dan YY adalah 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 pra-upgrade. Perhatikan bahwa pemulihan bukanlah operasi di tempat dan 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 bahwa pencadangan hanya menyimpan data yang berubah relatif terhadap pencadangan berkelanjutan sebelumnya. Pendekatan ini mengurangi ukuran dan biaya (dalam resource) pencadangan, serta mempercepat proses pembuatan pencadangan. 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) mengharuskan cadangan versi tersedia. Pemulihan tidak tersedia di cluster yang diupgrade hingga cadangan pasca-upgrade, atau cadangan lain yang dimulai setelah instance utama diupgrade, selesai.