Tentang pemeliharaan pada instance Cloud SQL

Halaman ini menjelaskan cara pembaruan pemeliharaan pada instance Cloud SQL, dan cara mengontrol waktu pembaruan tersebut. Untuk memulai, lihat Menemukan dan menyetel masa pemeliharaan.

Ringkasan

Sebagai layanan terkelola, Cloud SQL secara otomatis mengupdate instance untuk memastikan bahwa hardware, sistem operasi, dan mesin database yang mendasarinya dapat diandalkan, berperforma, aman, dan terbaru. Sebagian besar update ini dilakukan saat instance Cloud SQL aktif dan berjalan. Namun, update sistem tertentu memerlukan gangguan layanan singkat agar dapat dilakukan. Update ini disebut pemeliharaan.

Pemeliharaan memperbarui sistem operasi dan mesin database. Karena update ini mengharuskan instance dimulai ulang, update akan mengalami periode nonaktif. Pembaruan pemeliharaan memberikan manfaat berikut:

  • Fitur Cloud SQL. Untuk meluncurkan fitur baru, mesin database akan diupdate dan plugin baru ke database diinstal.

  • Upgrade versi database. Penyedia software database yang mengembangkan PostgreSQL merilis versi minor baru beberapa kali setahun. Setiap versi baru dilengkapi dengan perbaikan bug, patch keamanan, peningkatan performa, dan fitur database baru. Anda dapat menemukan versi minor terbaru yang didukung Cloud SQL untuk PostgreSQL dengan meninjau catatan rilis atau Kebijakan versi dan versi database. Instance Cloud SQL diupgrade ke versi database terbaru tidak lama setelah dirilis, sehingga Anda bisa mendapatkan manfaat dari menjalankan software database terbaru.

  • Patch sistem operasi. Kami terus memantau kerentanan keamanan yang baru teridentifikasi di sistem operasi. Setelah ditemukan, kami melakukan patch pada sistem operasi untuk melindungi Anda dari risiko baru.

Dampak pemeliharaan

Selama peristiwa pemeliharaan, instance Cloud SQL untuk PostgreSQL kehilangan konektivitas rata-rata kurang dari 30 detik.

Untuk edisi Cloud SQL Enterprise Plus, Cloud SQL menawarkan pemeliharaan terencana dengan periode nonaktif nyaris nol.

Periode nonaktif mungkin lebih tinggi untuk instance yang memiliki aktivitas tinggi selama pemeliharaan atau memiliki set data yang sangat besar. Cloud SQL biasanya menjadwalkan pemeliharaan setiap beberapa bulan sekali.

Anda dapat mengambil langkah-langkah untuk memastikan bahwa pemeliharaan berdampak sekecil mungkin pada operasi Anda menggunakan setelan pemeliharaan kami dan dengan membuat sistem Anda tahan terhadap error sementara.

Pemeliharaan terencana periode nonaktif yang mendekati nol

Dengan periode nonaktif terencana yang mendekati nol, instance edisi Cloud SQL Enterprise Plus dengan ketersediaan tinggi biasanya kehilangan konektivitas selama kurang dari 1 detik selama pemeliharaan terencana.

Periode nonaktif mungkin lebih tinggi untuk instance yang memiliki aktivitas tinggi selama pemeliharaan.

Prasyarat dan batasan

  • Jumlah replika baca di instance edisi Cloud SQL untuk PostgreSQL Enterprise Plus harus kurang dari nilai yang ditetapkan untuk flag max_wal_senders dan max_replication_slots. Untuk informasi selengkapnya, lihat mengonfigurasi flag database.

  • Jika Anda menggunakan Auth Proxy Cloud SQL atau Cloud SQL Language Connectors, pastikan sudah diupdate ke versi terbarunya.

  • Setiap tabel yang tidak dicatat akan kosong setelah pemeliharaan terencana.

  • Selama pemeliharaan, log database akan memiliki pesan dari dua VM yang berbeda.
  • Jika DDL dikeluarkan selama pemeliharaan terencana, perubahan mungkin memiliki stempel waktu pembuatan atau modifikasi yang jatuh setelah stempel waktu pemeliharaan.

Menyimulasikan pemeliharaan terencana dengan periode nonaktif hampir nol

Untuk menguji periode nonaktif pemeliharaan terencana instance utama edisi Cloud SQL Enterprise Plus tanpa mengupdate instance database, Anda dapat menyimulasikan pemeliharaan terencana periode nonaktif hampir nol.

Untuk melakukannya, panggil simulasi peristiwa pemeliharaan pada instance edisi Cloud SQL Enterprise Plus yang memenuhi syarat untuk pemeliharaan periode nonaktif yang direncanakan hampir nol. Permintaan simulasi menghasilkan operasi update instance ke versi pemeliharaan yang sama sebelum operasi.

Anda dapat menjalankan simulasi meskipun terdapat update pemeliharaan yang tertunda pada instance. Versi instance tetap sama selama simulasi.

Untuk menyimulasikan peristiwa pemeliharaan terencana periode nonaktif hampir nol, gunakan perintah gcloud CLI berikut:

gcloud sql instances patch INSTANCE_NAME --simulate-maintenance-event

Ganti INSTANCE_NAME dengan nama instance tempat Anda ingin menjalankan peristiwa simulasi pemeliharaan.

Setelan pemeliharaan

Cloud SQL menawarkan kemampuan untuk mengonfigurasi update pemeliharaan melalui serangkaian setelan pemeliharaan.

Anda dapat mengonfigurasi pemeliharaan agar dijadwalkan pada waktu saat periode nonaktif singkat menyebabkan dampak terendah pada aplikasi Anda. Untuk setiap instance Cloud SQL, Anda dapat mengonfigurasi hal berikut:

  • Masa pemeliharaan. Hari dan jam saat Cloud SQL menjadwalkan pemeliharaan. Masa pemeliharaan berlangsung selama satu jam. Pelajari cara mengonfigurasi masa pemeliharaan.

  • Urutan update. Menetapkan urutan pembaruan instance Cloud SQL yang relatif terhadap instance lain di region yang sama. Urutan update dapat ditetapkan ke Any, Earlier, atau Later. Instance Later akan diupdate satu minggu setelah instance Earlier dengan masa pemeliharaan yang sama di region yang sama. Anda menetapkan urutan update saat mengonfigurasi masa pemeliharaan.

  • Periode tolak pemeliharaan. Blok hari saat Cloud SQL tidak menjadwalkan pemeliharaan. Periode pemeliharaan penolakan dapat berlangsung hingga 90 hari. Pelajari cara mengonfigurasi periode tolak pemeliharaan.

Masa pemeliharaan default

Jika Anda tidak menetapkan masa pemeliharaan, Cloud SQL akan memperbarui instance dalam periode default berikut sesuai dengan zona waktu instance:

  • Periode hari kerja (Hari Senin sampai hari Jumat): 22.00-06.00
  • Periode akhir pekan: Hari Jumat, 22.00 hingga hari Senin, 06.00

Contoh pemeliharaan

Asumsikan Anda adalah developer di retailer yang mengelola layanan keranjang belanja. Anda memiliki satu instance Cloud SQL untuk lingkungan produksi dan yang kedua untuk lingkungan staging. Anda ingin pemeliharaan dilakukan pada saat instance menangani jumlah traffic terendah, yaitu sekitar tengah malam pada hari Minggu. Anda juga ingin melewatkan pemeliharaan selama musim belanja liburan akhir tahun yang sibuk.

Dalam hal ini, Anda menyetel setelan pemeliharaan instance produksi ke:

  • Masa pemeliharaan: Hari Minggu antara pukul 12.00-01.00 ET
  • Urutan update: Later
  • Periode pemeliharaan yang ditolak: 1 November hingga 15 Januari.

Setelan pemeliharaan untuk lingkungan staging Anda akan sama, hanya saja urutan update akan ditetapkan ke Earlier. Hal ini memastikan Anda dapat menjalankan pengujian penerimaan operasional untuk rilis pemeliharaan dalam staging setidaknya tujuh hari sebelum pemeliharaan diluncurkan ke produksi. Jika terjadi masalah dalam lingkungan staging, Anda memiliki waktu untuk mendiagnosis dan memperbaiki masalah sehingga lingkungan produksi Anda tidak terpengaruh.

Notifikasi pemeliharaan mendatang

Anda dapat menerima notifikasi tentang pemeliharaan mendatang yang dikirimkan ke email Anda setidaknya satu minggu sebelum jadwal pemeliharaan. Jika Anda ingin menyetel filter email untuk notifikasi, judul emailnya adalah Pemeliharaan mendatang untuk instance instancename Cloud SQL Anda.

Notifikasi untuk pemeliharaan tidak dikirim secara default. Anda harus memilih untuk menerima notifikasi pemeliharaan. Sebelum dapat menerima notifikasi, Anda juga harus memilih masa pemeliharaan.

Notifikasi dikirim ke alamat email yang terkait dengan Akun Google Anda. Alias email khusus tidak dapat dikonfigurasi (misalnya, alias email tim).

Anda memilih untuk menerima notifikasi pemeliharaan untuk semua instance Cloud SQL yang memiliki masa pemeliharaan di project tertentu. Anda akan menerima satu notifikasi per instance. Notifikasi pemeliharaan mendatang tidak dikirim untuk replika baca.

Anda juga dapat melihat informasi pemeliharaan mendatang di Konsol Google Cloud.

  • Dalam daftar Instance, di kolom Pemeliharaan. Jika pemeliharaan dijadwalkan, Anda akan melihat tanggal dan waktu jadwal pemeliharaan dimulai. Anda dapat memfilter daftar instance menggunakan istilah Maintenance untuk menemukan semua instance yang dijadwalkan untuk pemeliharaan. Kolom Pemeliharaan hanya ditampilkan saat pemeliharaan dijadwalkan pada satu atau beberapa instance dalam project. Jika tidak ada pemeliharaan yang dijadwalkan, kolom akan disembunyikan.
  • Pada halaman Detail instance di panel Pemeliharaan. Jika pemeliharaan dijadwalkan, di bagian Mendatang, Anda akan melihat tanggal dan waktu jadwal pemeliharaan dimulai.

  • Pada halaman AKTIVITAS di Konsol Google Cloud, Anda dapat melihat daftar instance yang dijadwalkan untuk pemeliharaan. Jika pemeliharaan dijadwalkan, instance akan memiliki pesan Pemeliharaan SQL, serta tanggal dan waktu kapan jadwal pemeliharaan dimulai.

Menjadwalkan ulang pemeliharaan

Jika memiliki masa pemeliharaan untuk instance, Anda dapat menjadwal ulang pemeliharaan kapan saja sebelum pemeliharaan saat ini dijadwalkan. Misalnya, jika Anda memiliki layanan baru yang diluncurkan selama waktu pemeliharaan yang saat ini dijadwalkan, Anda mungkin ingin menjadwal ulang masa pemeliharaan menjadi beberapa hari setelah peluncuran.

Anda dapat menjadwal ulang pemeliharaan beberapa kali selama belum lebih dari 28 hari setelah waktu yang dijadwalkan sebelumnya.

Anda memiliki beberapa opsi penjadwalan untuk masa pemeliharaan baru:

  • Segera terapkan update. Anda dapat segera menerapkan update ke instance, bukan menunggu masa pemeliharaan terjadwal. Dalam hal ini, pemeliharaan biasanya dimulai dalam waktu lima menit.

  • Jadwalkan ulang ke waktu lain. Anda dapat menunda peristiwa pemeliharaan terjadwal dengan dua cara:

    • Masa pemeliharaan berikutnya yang tersedia. Opsi ini menunda pemeliharaan ke masa pemeliharaan berikutnya yang tersedia setelah waktu pemeliharaan terjadwal saat ini, biasanya satu minggu kemudian.
    • Waktu tertentu. Opsi ini memungkinkan Anda dapat memilih waktu tertentu dalam 28 hari setelah waktu pemeliharaan yang telah dijadwalkan sebelumnya.

Untuk menjadwalkan ulang pemeliharaan, lihat menjadwalkan ulang pemeliharaan terencana.

Cara kerja pemeliharaan

Agar pemeliharaan tetap singkat, Cloud SQL menggunakan alur kerja failover pemeliharaan yang sebagian besar menyerupai alur kerja failover otomatis untuk instance dengan ketersediaan tinggi.

Singkatnya, berikut ini merupakan langkah-langkahnya:

  1. Siapkan VM yang telah diupdate dengan software baru.
  2. Hentikan VM asli.
  3. Alihkan disk dan IP statis ke VM yang telah diupdate.
  4. Mulai VM yang telah diupdate.

Telusuri tab di bawah untuk melihat detail alur kerja, termasuk sebelum dan setelah pemeliharaan.

Sebelum pemeliharaan

Sebelum pemeliharaan, klien berkomunikasi dengan VM asli melalui alamat IP statis. Data disimpan di persistent disk yang terpasang ke VM asli. Dalam contoh ini, instance Cloud SQL memiliki ketersediaan tinggi yang telah dikonfigurasi, yang berarti bahwa VM lain berada dalam mode standby untuk mengambil alih jika terjadi pemadaman layanan yang tidak direncanakan. Instance Cloud SQL menyalurkan traffic ke aplikasi.

Diagram yang menunjukkan status sebelum pemeliharaan

Langkah 1

Menyiapkan VM baru.

Virtual Machine (VM) baru disiapkan dengan software database dan sistem operasi (OS) VM terbaru. OS VM yang telah diupdate akan dimulai. Pada tahap ini, mesin database belum dimulai. Untuk instance dengan ketersediaan tinggi, VM standby baru juga akan disiapkan.

Total periode nonaktif dipersingkat secara substansial dengan menginstal update software di VM lain saat instance Cloud SQL asli masih melayani traffic.

Diagram yang menunjukkan penyiapan VM

Langkah 2

Nonaktifkan VM asli.

Mesin database dimatikan agar disk dapat dilepas dari VM asli dan dipasang ke VM yang telah diupdate. Sebelum dinonaktifkan, mesin database menunggu beberapa detik hingga transaksi yang sedang berlangsung di-commit dan permintaan dari koneksi yang ada untuk dikosongkan. Setelah itu, setiap transaksi yang terbuka atau berjalan lama akan di-roll back. Database berhenti menerima koneksi baru, dan koneksi yang sudah ada akan dihapus. Instance menjadi tidak tersedia dan periode nonaktif untuk pemeliharaan dimulai.

Diagram instance setelah failover

Langkah 3

Beralihlah ke VM yang telah diupdate.

Disk akan dilepas dari VM asli dan dipasang ke VM yang telah diupdate. Alamat IP statis dikonfigurasi ulang agar mengarah ke VM yang telah diupdate. Hal ini memastikan bahwa aplikasi menggunakan alamat IP yang sama setelah pemeliharaan seperti sebelumnya. Cache database diganti dengan VM asli, yang berarti cache database dihapus secara efektif selama pemeliharaan.

Diagram pengalihan ke VM yang telah diupdate

Langkah 4

Mulai VM yang telah diupdate.

Mesin database yang telah diupdate akan dimulai di disk data. Penggunaan disk data umum memastikan bahwa semua transaksi yang ditulis ke instance asli sebelum pemeliharaan masih ada di database yang diperbarui setelah pemeliharaan. Jika ada transaksi yang belum selesai dan tidak selesai di-roll back selama penonaktifan database, database secara otomatis akan menjalani pemulihan error untuk memastikan bahwa database dipulihkan ke keadaan yang dapat digunakan.

Diagram memulai VM yang telah diupdate

Setelah pemeliharaan

Setelah Langkah 4, instance Cloud SQL dapat menerima koneksi dan kembali untuk menyalurkan traffic ke aplikasi.

Dari sisi aplikasi, selain software yang telah diupdate, instance Cloud SQL terlihat sama. Aplikasi tersebut masih terhubung ke instance Cloud SQL menggunakan alamat IP statis yang sama, dan VM yang telah diupdate akan berjalan di zona yang sama dengan VM asli. Semua data yang ditulis ke database asli akan dipertahankan.

Diagram setelah pemeliharaan

Meminimalkan dampak pemeliharaan

Secara umum, Google Cloud merekomendasikan agar pengguna yang menjalankan aplikasi di cloud membuat sistem mereka tahan terhadap error sementara, yang merupakan masalah komunikasi antar-layanan sesaat yang disebabkan oleh ketidaktersediaan sementara. Error sementara tidak dapat dihindari di cloud.

Beberapa error sementara yang terjadi selama pemeliharaan adalah koneksi yang terputus dan transaksi berlangsung yang gagal. Jika Anda mendesain sistem dan menyesuaikan aplikasi agar tahan terhadap error sementara, Anda juga diposisikan untuk meminimalkan dampak akibat pemeliharaan database.

Untuk meminimalkan dampak koneksi yang terputus, Anda dapat menggunakan kumpulan koneksi. Meskipun koneksi antara pooler dan database dihentikan selama pemeliharaan, koneksi antara aplikasi dan pooler akan tetap dipertahankan. Dengan demikian, pekerjaan membangun kembali koneksi bersifat transparan pada aplikasi dan dipindahkan ke pooler koneksi.

Untuk mengurangi kegagalan transaksi, Anda dapat membatasi jumlah transaksi yang berjalan lama. Menulis ulang kueri agar lebih kecil dan lebih efisien tidak hanya mengurangi periode nonaktif pemeliharaan, tetapi juga meningkatkan performa dan keandalan database.

Anda dapat menggunakan Query Insights untuk mengidentifikasi kueri yang lambat.

Untuk pulih secara efisien dari penurunan koneksi dan kegagalan transaksi, Anda dapat mengelola koneksi database secara efisien. Anda dapat mem-build logika percobaan ulang koneksi dan kueri dengan back-off eksponensial ke dalam aplikasi dan pooler koneksi Anda. Jika kueri gagal atau koneksi terputus, sistem akan menerapkan periode tunggu sebelum mencoba ulang, yang akan meningkat untuk setiap percobaan ulang berikutnya. Misalnya, sistem mungkin hanya menunggu beberapa detik untuk percobaan ulang pertama, tetapi membutuhkan hingga satu menit untuk percobaan ulang keempat. Dengan mengikuti pola ini, Anda dapat memastikan kegagalan tersebut dapat dikoreksi, tanpa membebani layanan secara berlebih.

Solusi kreatif lainnya juga dapat meminimalkan dampak pemeliharaan, mulai dari menggunakan skrip untuk menghangatkan cache database setelah pemeliharaan hingga menyederhanakan jumlah tabel dalam database. Sebaiknya ikuti praktik terbaik pengelolaan database dan panduan operasional untuk memastikan pemeliharaan berjalan lancar.

Pemeliharaan yang mendesak

Dalam kasus yang sangat jarang terjadi, Cloud SQL mungkin perlu menjadwalkan pemeliharaan di luar setelan pemeliharaan untuk mem-patch masalah stabilitas serius atau kerentanan yang mendesak. Update ini dikirimkan dengan cepat, dan Cloud SQL menghitungnya sebagai periode nonaktif terhadap SLA.

Pemeliharaan mandiri

Cloud SQL secara rutin merilis patch dan peningkatan software untuk kerentanan keamanan melalui versi pemeliharaan baru yang dapat diinstal pada instance Anda. Cloud SQL menyimpan log perubahan pemeliharaan Cloud SQL untuk setiap versi utama mesin database. Untuk mempelajari lebih lanjut, lihat log perubahan pemeliharaan Cloud SQL.

Meskipun Cloud SQL menjadwalkan update pemeliharaan setiap beberapa bulan untuk memastikan Anda memiliki software terbaru, Anda dapat menggunakan pemeliharaan mandiri agar instance Anda selalu terupdate jika:

  • Anda memerlukan update lebih cepat daripada peristiwa pemeliharaan terjadwal berikutnya.
  • Anda ingin mengikuti perkembangan software terbaru setelah melewatkan update pemeliharaan terbaru.

Jika menggunakan replika baca, Anda dapat menggunakan pemeliharaan mandiri untuk mengupdate semua replika baca Anda. Anda menentukan instance utama, dan permintaan pemeliharaan akan memperbarui semua replika baca dari instance utama ke versi pemeliharaan yang ditentukan. Kemudian instance utama diupdate ke versi pemeliharaan.

Batasan pemeliharaan

Bagian ini menjelaskan batasan pemeliharaan Cloud SQL.

Batasan penjadwalan ulang

Ada beberapa hal yang perlu Anda ketahui tentang penjadwalan ulang:

  • Anda harus menjadwalkan ulang pemeliharaan setidaknya 24 jam sebelum peristiwa pemeliharaan yang awalnya dijadwalkan sebelumnya dilakukan.

  • Anda dapat menjadwalkan ulang pemeliharaan pada satu atau beberapa instance di project Anda. Namun, Anda hanya dapat menjadwalkan ulang instance satu per satu (penjadwalan ulang massal tidak tersedia).

  • Anda dapat menjadwalkan ulang pemeliharaan ke waktu yang berada dalam periode tolak pemeliharaan, atau bahkan di luar masa pemeliharaan, selama jangka waktu tersebut berada dalam batas penjadwalan ulang 28 hari.

  • Jika operasi pemeliharaan sedang berlangsung, penjadwalan ulang akan tertunda hingga operasi selesai.

Batasan periode tolak pemeliharaan

Ada beberapa hal yang perlu Anda ketahui tentang periode tolak pemeliharaan:

  • Anda dapat mengalami periode tolak pemeliharaan meskipun tidak memiliki periode pemeliharaan yang dikonfigurasi untuk instance Anda. Periode pemeliharaan penolakan dapat berlangsung mulai 1 hingga 90 hari.

  • Periode tolak pemeliharaan lebih diprioritaskan daripada masa pemeliharaan terjadwal. Jika ada konflik antara waktu masa pemeliharaan dan periode tolak pemeliharaan, maka periode tolak pemeliharaan akan diutamakan.

  • Periode tolak pemeliharaan dan penjadwalan relatif adalah fitur independen. Periode tolak pemeliharaan yang ditentukan pada instance Earlier tidak berdampak dalam menentukan jadwal untuk instance Later. Notifikasi tidak dikirim jika jadwal pemeliharaan berada dalam periode pemeliharaan penolakan untuk instance Earlier atau Later.

  • Jika periode tolak ditetapkan pada instance utama, pemeliharaan untuk semua replika yang terkait dengan instance utama juga akan ditolak. Misalnya, instance utama yang terletak di region A memiliki tiga replika baca: dua di region A dan satu di region B. Jika periode tolak ditetapkan pada instance utama, pemeliharaan untuk setiap replika, termasuk replika di region B, tidak menerima pemeliharaan hingga periode tolak pada instance utama berakhir.

  • Jika periode tolak pemeliharaan ditetapkan setelah pemeliharaan dijadwalkan sehingga periode tolak pemeliharaan tumpang-tindih dengan waktu pemeliharaan terjadwal, maka update akan dilewati.

  • Anda dapat menyetel periode tolak pemeliharaan agar berulang setiap tahun dengan tidak menyertakan tahun dalam parameter tanggal mulai dan akhir. Jika tahun disertakan, maka periode pemeliharaan penolakan hanya ditetapkan untuk tahun tersebut.

  • Anda dapat menetapkan beberapa periode tolak pemeliharaan dalam satu tahun. Sebaiknya hindari menghubungkan periode tolak secara bersamaan untuk melewati peristiwa pemeliharaan terjadwal berturut-turut. Penting bagi Anda mengikuti perkembangan pemeliharaan Cloud SQL untuk memastikan instance Anda beroperasi dengan andal. Biasanya, pemeliharaan Cloud SQL dijadwalkan setiap beberapa bulan sekali.

  • Untuk memastikan keandalan layanan, Cloud SQL dapat memberi tahu pengguna dengan instance yang menjalankan rilis pemeliharaan yang berusia lebih dari 12 bulan bahwa peluncuran pemeliharaan berikutnya diperlukan.

  • Saat periode tolak pemeliharaan berakhir, perilaku pemeliharaan reguler akan dilanjutkan.

  • Periode penolakan pemeliharaan tidak memengaruhi operasi yang dipicu pengguna, misalnya memiliki pemeliharaan mandiri.

FAQ tentang Pemeliharaan

Apakah periode nonaktif pemeliharaan diperhitungkan dalam SLA?

Periode nonaktif dari pemeliharaan normal tidak diperhitungkan dalam SLA. Namun, Cloud SQL menghitung periode nonaktif pemeliharaan yang sensitif terhadap waktu berdasarkan SLA.

Bagaimana pengaruh pemeliharaan terhadap replika baca?

  • Cloud SQL selalu memelihara replika baca sebelum instance utama. Jika instance utama memiliki masa pemeliharaan, replika baca mengamati masa pemeliharaan yang sama.
  • Jika instance utama Anda memiliki beberapa replika baca, Cloud SQL mungkin akan mengupdate beberapa replika secara bersamaan.
  • Replika baca mengamati periode tolak pemeliharaan yang ditetapkan untuk instance utama.

Dapatkah saya membatalkan pemeliharaan terjadwal?

Anda tidak dapat membatalkan masa pemeliharaan terjadwal, tetapi dapat menjadwalkan ulang. Anda juga dapat mengonfigurasi periode pemeliharaan penolakan yang tumpang tindih dengan waktu pemeliharaan terjadwal untuk melewati pemeliharaan secara efektif.

Apa yang terjadi jika peristiwa pemeliharaan dibatalkan?

Jika Cloud SQL membatalkan peristiwa pemeliharaan, Anda akan menerima notifikasi bahwa pemeliharaan dibatalkan terlebih dahulu, jika memungkinkan.

Anda akan menerima notifikasi baru tentang pemeliharaan mendatang saat peristiwa pemeliharaan dijadwalkan ulang.

Apakah pemeliharaan Cloud SQL bersifat kumulatif?

Update terkait pemeliharaan bersifat kumulatif. Anda tidak perlu menerapkan setiap update pemeliharaan yang mungkin Anda lewatkan. Versi pemeliharaan terbaru diterapkan di update pemeliharaan terjadwal berikutnya. Atau, Anda dapat menerapkan update pemeliharaan terbaru menggunakan pemeliharaan mandiri.

Berapa lama waktu yang diperlukan untuk pemeliharaan mandiri untuk semua replika baca instance utama?

Jumlah waktu yang dibutuhkan oleh update pemeliharaan mandiri bergantung pada jumlah total replika baca instance utama Anda. Untuk mengurangi waktu yang diperlukan oleh update pemeliharaan mandiri, Anda dapat mengupdate beberapa replika baca satu per satu, lalu melakukan update pada instance utama untuk mengupdate replika baca lainnya.

Update kedua akan melewati semua replika yang sudah memiliki versi pemeliharaan target.

Jika saya memiliki beberapa replika baca dari instance utama, dapatkah saya melakukan pemeliharaan mandiri pada satu replika baca?

Ya, Anda dapat melakukan pemeliharaan mandiri pada setiap instance replika baca. Namun, sebaiknya segera perbarui replika baca dan instance utama lainnya ke versi pemeliharaan yang sama. Sebaiknya Anda mengoperasikan semua replika baca dan instance utama dengan versi pemeliharaan yang identik.

Langkah selanjutnya