View a markdown version of this page

Menggunakan zero-downtime patching - Amazon Aurora

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Menggunakan zero-downtime patching

Peningkatan klaster DB Aurora MySQL kemungkinan akan menimbulkan pemadaman layanan saat basis data dinonaktifkan dan sedang ditingkatkan. Secara default, jika Anda memulai peningkatan saat basis data sibuk, Anda akan kehilangan semua koneksi dan transaksi yang sedang diproses oleh klaster DB. Jika Anda menunggu hingga basis data idle untuk melakukan peningkatan, Anda mungkin harus menunggu lama.

Fitur zero-downtime patching (ZDP) mencoba, berdasarkan upaya terbaik, untuk menjaga koneksi klien selama peningkatan Aurora MySQL. Jika ZDP berhasil diselesaikan, sesi aplikasi dipertahankan dan mesin basis data dimulai ulang saat peningkatan sedang berlangsung. Pengaktifan ulang mesin basis data dapat menyebabkan penurunan throughput yang berlangsung selama beberapa detik hingga kira-kira satu menit.

ZDP tidak berlaku untuk hal-hal berikut ini:

  • Patch dan peningkatan sistem operasi (OS)

  • Peningkatan versi mayor

ZDP tersedia untuk semua versi Aurora MySQL yang didukung dan kelas instans DB.

catatan

Kami menyarankan penggunaan kelas instans DB T hanya untuk server pengembangan dan pengujian, atau server non-produksi lainnya. Untuk detail selengkapnya tentang kelas instans T, lihat Menggunakan kelas instans T untuk pengembangan dan pengujian.

Anda dapat melihat metrik atribut penting selama ZDP dalam log kesalahan MySQL. Anda juga dapat melihat informasi tentang kapan Aurora MySQL menggunakan ZDP atau memilih untuk tidak menggunakan ZDP di halaman Peristiwa di Konsol Manajemen AWS.

Di Aurora MySQL, Aurora dapat melakukan patch zero-downtime apakah replikasi log biner diaktifkan atau tidak. Jika replikasi log biner diaktifkan, Aurora MySQL secara otomatis memutuskan koneksi ke target binlog selama operasi ZDP. Aurora MySQL secara otomatis menghubungkan kembali ke target binlog dan melanjutkan replikasi setelah pengaktifan ulang selesai.

ZDP juga bekerja dalam kombinasi dengan peningkatan reboot di Aurora MySQL. Patching terhadap instans DB penulis akan secara otomatis menjalankan patching terhadap pembaca secara bersamaan. Setelah melakukan patching, Aurora memulihkan koneksi pada instans DB penulis dan pembaca.

ZDP mungkin tidak berhasil diselesaikan dalam kondisi berikut:

  • Kueri atau transaksi berjalan lama sedang berlangsung. Jika Aurora dapat melakukan ZDP dalam kasus ini, setiap transaksi terbuka dibatalkan tetapi koneksi mereka dipertahankan.

  • Tabel sementara, kunci pengguna, atau kunci tabel sedang digunakan, misalnya saat pernyataan bahasa definisi data (DDL) berjalan. Aurora menjatuhkan koneksi ini.

  • Ada perubahan parameter tertunda.

Jika tidak tersedia jangka waktu yang sesuai untuk melakukan ZDP karena satu atau beberapa dari kondisi ini, patching akan kembali ke perilaku standar.

Meskipun koneksi tetap utuh setelah operasi ZDP yang sukses, beberapa variabel dan fitur diinisialisasi ulang. Jenis informasi berikut ini tidak dipertahankan selama pengaktifan ulang yang disebabkan oleh zero-downtime patching:

  • Variabel global. Aurora memulihkan variabel sesi, tetapi tidak memulihkan variabel global setelah pengaktifan ulang.

  • Variabel status. Secara khusus, nilai uptime yang dilaporkan oleh status mesin direset setelah pengaktifan ulang yang menggunakan mekanisme ZDR atau ZDP.

  • LAST_INSERT_ID.

  • Status auto_increment dalam memori untuk tabel. Status inkremen otomatis dalam memori diinisialisasi ulang. Untuk informasi selengkapnya tentang nilai inkremen otomatis, lihat Panduan Referensi MySQL.

  • Informasi diagnostik dari tabel INFORMATION_SCHEMA dan PERFORMANCE_SCHEMA. Informasi diagnostik ini juga muncul dalam output perintah seperti SHOW PROFILE dan SHOW PROFILES.

Aktivitas berikut yang berkaitan dengan pengaktifan ulang dengan nol waktu henti akan dilaporkan di halaman Peristiwa:

  • Mencoba meningkatkan basis data dengan nol waktu henti.

  • Mencoba meningkatkan basis data dengan nol waktu henti selesai. Peristiwa ini melaporkan berapa lama prosesnya berjalan. Peristiwa ini juga melaporkan berapa banyak koneksi yang dipertahankan selama pengaktifan ulang dan berapa banyak koneksi yang terputus. Anda dapat melihat log kesalahan basis data untuk melihat detail selengkapnya tentang apa yang terjadi selama pengaktifan ulang.