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 mesin database, dan dalam beberapa kasus, sistem operasi. 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 MySQL merilis versi minor baru beberapa kali dalam 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 MySQL dengan meninjau catatan rilis atau Kebijakan versi dan versi database. Instance Cloud SQL diupgrade ke versi database terbaru segera setelah dirilis, sehingga Anda bisa mendapat manfaat dari menjalankan software database yang terbaru.

    Anda harus melakukan upgrade versi minor MySQL 8.0 secara manual. Lihat Menyetel versi minor MySQL untuk instance.

  • 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

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

Cloud SQL menjadwalkan peristiwa update pemeliharaan biasanya setiap beberapa bulan sekali. Update pemeliharaan dapat memerlukan waktu sekitar 5 hingga 10 menit untuk setiap instance. Jika instance memiliki replika baca, durasi keseluruhan update pemeliharaan dapat memerlukan waktu lebih lama. Namun, selama peristiwa update pemeliharaan, setiap instance edisi Cloud SQL Enterprise kehilangan konektivitas rata-rata kurang dari 60 detik. Periode nonaktif mungkin lebih tinggi untuk instance yang mengalami aktivitas dalam jumlah besar selama peristiwa update pemeliharaan atau memiliki set data yang sangat besar.

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 pemeliharaan terencana periode nonaktif yang nyaris nol, instance edisi Cloud SQL Enterprise Plus biasanya kehilangan konektivitas kurang dari 1 detik selama pemeliharaan terencana.

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

Prasyarat dan batasan

  • Anda harus mengaktifkan logging biner di instance.

  • Jika Anda menggunakan salah satu flag berikut, flag tersebut harus disetel ke nilai default:

    • sync_binlog, nilai: 1
    • innodb_flush_log_at_trx_commit, nilai 1
    • replica_skip_errors, nilai OFF
    • binlog_order_commit, nilai ON

    Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi flag database.

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

  • Jika memiliki replika eksternal dengan GTID yang diaktifkan, Anda harus mengonfigurasi replika tersebut untuk menggunakan positioning otomatis berbasis GTID, jika tidak, replikasi tersebut akan rusak setelah pemeliharaan. Untuk informasi selengkapnya, lihat Positioning otomatis GTID.

  • UID server MySQL Anda akan berubah selama pemeliharaan.

  • 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 periode nonaktif yang mendekati nol

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

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

Anda dapat melakukan simulasi meskipun memiliki update pemeliharaan yang tertunda di instance. Versi instance tetap sama selama simulasi.

Untuk menyimulasikan peristiwa pemeliharaan terencana dengan downtime 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 pemeliharaan simulasi.

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:

  • Waktu pemeliharaan (sebelumnya Urutan update). Minggu periode peluncuran untuk mengupdate instance Cloud SQL Anda. Anda memiliki opsi berikut ini:

    • Any: update pemeliharaan dapat terjadi kapan saja, tetapi biasanya terjadi dalam Minggu ke-1.
    • Week 1: pemeliharaan terjadi 7 hingga 14 hari setelah notifikasi pemeliharaan dikirim.
    • Week 2: pembaruan pemeliharaan terjadi 15 hingga 21 hari setelah notifikasi dikirim.
    • Week 5: pembaruan pemeliharaan terjadi 35 hingga 42 hari setelah notifikasi dikirim.

    Anda menetapkan jadwal update pemeliharaan saat mengonfigurasi masa pemeliharaan.

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

  • Periode tolak pemeliharaan. Blok hari saat Cloud SQL tidak menjadwalkan pemeliharaan. Anda dapat menetapkan periode pemeliharaan penolakan 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
  • Waktu pemeliharaan: Week 2
  • Periode pemeliharaan yang ditolak: 1 November hingga 15 Januari.

Setelan pemeliharaan untuk lingkungan staging Anda akan sama, hanya saja waktu pemeliharaan ditetapkan ke Week 2. 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 atau menyiapkan periode pemeliharaan yang ditolak 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 menjadwalkan ulang update pemeliharaan hingga 24 jam sebelum update pemeliharaan dijadwalkan. Misalnya, jika Anda meluncurkan layanan baru selama masa pemeliharaan terjadwal, sebaiknya Anda menunda update pemeliharaan hingga beberapa hari setelah peluncuran.

Ada beberapa batasan untuk menjadwalkan ulang update pemeliharaan. Setelah Cloud SQL mengirimkan email notifikasi, Cloud SQL akan melakukan update pemeliharaan dalam jangka waktu tujuh minggu untuk menghindari tumpang-tindih dengan update pemeliharaan Cloud SQL berikutnya. Misalnya, jika Anda memilih waktu pemeliharaan Minggu ke-1 atau Minggu ke-2, Anda dapat menjadwalkan ulang update pemeliharaan hingga maksimum 4 minggu (28 hari) setelah tanggal yang dijadwalkan sebelumnya. Jika menetapkan instance ke waktu pemeliharaan Minggu ke-5, Anda hanya dapat menjadwalkan ulang peristiwa pemeliharaan hingga maksimum satu minggu (7 hari) setelah tanggal asli. Anda dapat menjadwalkan ulang pemeliharaan beberapa kali selama peristiwa pemeliharaan yang dijadwalkan ulang berada dalam durasi penjadwalan ulang yang ditentukan oleh waktu pemeliharaan yang Anda konfigurasikan untuk instance.

Untuk semua batasan lainnya, lihat Batasan penjadwalan ulang.

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 memilih waktu tertentu untuk durasi penjadwalan ulang yang ditentukan oleh waktu pemeliharaan yang Anda konfigurasikan untuk instance.
      • 28 hari jika Anda memilih waktu pemeliharaan Minggu 1 atau Minggu 2
      • 7 hari jika Anda memilih waktu pemeliharaan Minggu ke-5

Untuk petunjuk tentang cara 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 database di VM asli.
  3. Alihkan disk dan IP statis ke VM yang telah diupdate.
  4. Mulai database di VM yang telah diupdate.

Telusuri tab berikut 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

Hentikan database di 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 database di 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 terputus selama pemeliharaan, koneksi antara aplikasi dan pooler 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.

Untuk pulih secara efisien dari penurunan koneksi dan kegagalan transaksi, Anda dapat mengelola koneksi database Anda 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 menganggapnya sebagai periode nonaktif berdasarkan SLA.

Pemeliharaan mandiri

Cloud SQL secara rutin merilis peningkatan software dan patch untuk kerentanan keamanan melalui versi pemeliharaan baru yang dapat Anda instal di instance. Cloud SQL mengelola 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 memperbarui semua replika baca. Anda menentukan instance utama, dan permintaan pemeliharaan akan memperbarui semua replika baca instance utama ke versi pemeliharaan yang ditentukan. Kemudian, instance utama akan 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 durasi penjadwalan ulang berada dalam jangka waktu yang ditentukan oleh waktu pemeliharaan yang Anda konfigurasikan untuk instance Anda.

  • 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 waktu pemeliharaan adalah fitur independen. Jika Anda membuat periode tolak pemeliharaan untuk instance yang memiliki pengaturan waktu pemeliharaan Week 1, hal ini tidak berdampak dalam menentukan update terjadwal untuk instance dengan pengaturan waktu pemeliharaan Week 2. Jika update pemeliharaan terjadwal berada dalam periode penolakan pemeliharaan, Cloud SQL tidak akan mengirimkan notifikasi untuk instance yang telah Anda konfigurasi dengan waktu pemeliharaan.

  • 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, seperti pemeliharaan mandiri.

FAQ tentang Pemeliharaan

Bagaimana pengaruh pemeliharaan terhadap instance failover HA Lama?

Instance failover HA lama akan dihapus untuk update dari pemeliharaan. Instance tersebut menerima update pemeliharaan tepat sebelum instance utama. Anda tidak dapat menetapkan periode pemeliharaan secara langsung pada instance failover HA Lama, karena instance ini memiliki masa pemeliharaan yang sama dengan instance utama.

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 di awal, 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 pada update pemeliharaan terjadwal berikutnya. Atau, Anda dapat menerapkan update pemeliharaan terbaru menggunakan pemeliharaan mandiri.

Apa yang terjadi jika instance dihentikan selama update pemeliharaan terjadwal?

Jika instance dihentikan selama update pemeliharaan terjadwal, Cloud SQL akan melewati update pemeliharaan. Namun, saat Anda memulai ulang instance lagi, Cloud SQL akan otomatis mengupdate instance dengan update pemeliharaan terbaru.

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

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

Pembaruan kedua akan melewati 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 update replika baca dan instance utama lainnya ke versi pemeliharaan yang sama segera setelah itu. Sebaiknya operasikan semua replika baca dan instance utama dengan versi pemeliharaan yang identik.

Langkah selanjutnya