Menggunakan zero-downtime patching

Melakukan upgrade untuk Aurora SQL My DB cluster melibatkan kemungkinan pemadaman ketika database dimatikan dan saat 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, dengan upaya terbaik, untuk mempertahankan koneksi klien melalui peningkatan Aurora My. SQL Jika ZDP berhasil diselesaikan, sesi aplikasi dipertahankan dan mesin database restart saat upgrade sedang berlangsung. Pengaktifan ulang mesin basis data dapat menyebabkan penurunan throughput yang berlangsung selama beberapa detik hingga kira-kira satu menit.

ZDPtidak berlaku untuk yang berikut:

• Patch dan peningkatan sistem operasi (OS)

• Peningkatan versi mayor

ZDPtersedia untuk semua SQL versi Aurora My yang didukung dan kelas instans DB.

ZDPtidak didukung untuk Aurora Serverless v1 atau database global Aurora.

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 di log SQL kesalahan saya. Anda juga dapat melihat informasi tentang kapan Aurora My SQL menggunakan ZDP atau memilih untuk tidak menggunakan ZDP pada halaman Acara di AWS Management Console.

Di Aurora My SQL versi 2.10 dan yang lebih tinggi dan versi 3, Aurora dapat melakukan patch zero-downtime apakah replikasi log biner diaktifkan atau tidak. Jika replikasi log biner diaktifkan, Aurora SQL My secara otomatis menjatuhkan koneksi ke target binlog selama operasi. ZDP Aurora My SQL secara otomatis terhubung kembali ke target binlog dan melanjutkan replikasi setelah restart selesai.

ZDPjuga bekerja dalam kombinasi dengan peningkatan reboot di Aurora My SQL 2.10 dan lebih tinggi. 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. Sebelum Aurora My SQL 2.10, hanya ZDP berlaku untuk instance DB penulis dari sebuah cluster.

ZDPmungkin 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 ada jendela waktu yang sesuai untuk melakukan ZDP menjadi tersedia karena satu atau lebih dari kondisi ini, patch kembali ke perilaku standar.

catatan

Untuk Aurora My SQL versi 2 lebih rendah dari 2.11.0 dan versi 3 lebih rendah dari 3.04.0, ZDP mungkin tidak berhasil diselesaikan ketika ada koneksi Secure Socket Layer (SSL) atau Transport Layer Security () terbuka. TLS

Meskipun koneksi tetap utuh setelah ZDP operasi yang berhasil, 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 engine diatur ulang setelah restart yang menggunakan ZDP mekanisme ZDR atau.

• LAST_INSERT_ID.

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

• 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.