Pembaruan mesin basis data Aurora MySQL 2021-05-25 (versi 2.10.0) (Dihentikan)

Versi: 2.10.0

Aurora MySQL 2.10.0 tersedia secara umum. Aurora MySQL versi 2.x kompatibel dengan MySQL 5.7, dan Aurora MySQL versi 1.x kompatibel dengan MySQL 5.6.

Rilis Aurora MySQL yang saat ini didukung adalah 1.19.5, 1.19.6, 1.22.*, 1.23.*, 2.04.*, 2.07.*, 2.08.*, 2.09.*, 2.10.*, 3.01.*, dan 3.02.*.

Anda dapat meningkatkan klaster basis data Aurora MySQL 2.* yang ada ke Aurora MySQL 2.10.0. Untuk klaster yang menjalankan Aurora MySQL versi 1, Anda dapat meningkatkan klaster Aurora MySQL 1.23 atau yang lebih tinggi yang sudah ada langsung ke 2.10.0. Anda juga dapat memulihkan snapshot dari rilis Aurora MySQL yang saat ini didukung ke Aurora MySQL 2.10.0.

Jika Anda memiliki pertanyaan atau masalah, AWS Support tersedia di forum komunitas dan melalui AWS Support. Untuk informasi selengkapnya, lihat Memelihara klaster DB Amazon Aurora di Panduan Pengguna Amazon Aurora.

catatan

Untuk informasi tentang cara meningkatkan versi klaster basis data MySQL Aurora Anda, lihat Meningkatkan versi kecil atau tingkat patch klaster DB Aurora MySQL di Panduan Pengguna Amazon Aurora.

Perbaikan

Memperbaiki masalah keamanan dan CVE yang tercantum di bawah ini:

Perbaikan dan penyempurnaan lain untuk penanganan fine-tune di lingkungan terkelola. Di bawah ini adalah beberapa perbaikan CVE tambahan:

• CVE-2021-23841

• CVE-2021-3449

• CVE-2020-28196

• CVE-2020-14790

• CVE-2020-14776

• CVE-2020-14567

• CVE-2020-14559

• CVE-2020-14553

• CVE-2020-14547

• CVE-2020-14540

• CVE-2020-14539

• CVE-2018-3251

• CVE-2018-3156

• CVE-2018-3143

• CVE-2016-5440

Fitur-fitur baru:

• Kelas instans db.t3.large sekarang didukung untuk Aurora MySQL.

• Replikasi log biner:

  • Memperkenalkan cache I/O binlog untuk meningkatkan kinerja binlog dengan mengurangi pertentangan antara thread penulis dan thread dump. Untuk informasi selengkapnya, lihat Mengoptimalkan replikasi log biner di Panduan Pengguna Amazon Aurora.

  • Di Aurora MySQL versi 2.08, kami memperkenalkan pemrosesan log biner (binlog) yang ditingkatkan untuk mengurangi waktu pemulihan akibat crash dan latensi waktu commit saat melibatkan transaksi yang sangat besar. Perbaikan ini sekarang didukung untuk klaster yang mengaktifkan GTID.

• Ketersediaan instans pembaca yang ditingkatkan:

  • Sebelumnya, saat instans penulis memulai ulang, semua instans pembaca di klaster Aurora MySQL juga memulai ulang. Dengan peluncuran hari ini, instans pembaca dalam Wilayah terus melayani permintaan baca selama instans penulis memulai ulang, sehingga meningkatkan ketersediaan baca di klaster. Untuk informasi selengkapnya, lihat Booting ulang klaster Aurora MySQL (versi 2.10 dan lebih tinggi) di Panduan Pengguna Amazon Aurora.

    penting

    Setelah Anda meningkatkan ke Aurora MySQL 2.10, booting ulang instans penulis tidak akan menyebabkan boot ulang pada seluruh klaster. Jika Anda ingin melakukan booting ulang seluruh klaster, sekarang Anda mem-booting ulang semua instans pembaca di klaster setelah booting ulang instans penulis.

• Memperbaiki kinerja pembacaan halaman read ahead yang diminta oleh teknik logika read ahead (LRA). Hal ini dilakukan melalui batching beberapa pembacaan halaman dalam satu permintaan yang dikirimkan ke penyimpanan Aurora. Hasilnya, kueri yang menggunakan optimasi LRA mengeksekusi hingga 3x lebih cepat.

• Mulai ulang dan patching zero-downtime:

  • Memperbaiki zero-downtime restart (ZDR) dan zero-downtime patching (ZDP) untuk mengaktifkan ZDR dan ZDP dalam skenario yang lebih luas, termasuk dukungan tambahan untuk kasus ketika pencatatan log biner diaktifkan. Selain itu, memperbaiki visibilitas ke peristiwa ZDR dan ZDP. Lihat dokumentasi untuk mengetahui detailnya: Zero-downtime restart (ZDR) untuk Amazon Aurora MySQL dan Menggunakan zero-downtime patching di Panduan Pengguna Amazon Aurora.

Perbaikan ketersediaan:

• Perbaikan untuk startup yang lebih cepat ketika basis data memiliki indeks dan tabel sementara dalam jumlah besar yang dibuat selama aktivitas DDL yang terganggu sebelumnya.

• Memperbaiki beberapa masalah yang berkaitan dengan mulai ulang beberapa kali selama pemulihan crash operasi DDL yang terganggu, seperti DROP TRIGGER, ALTER TABLE, dan khususnya ALTER TABLE yang memodifikasi jenis partisi atau jumlah partisi di dalam tabel.

• Memperbaiki masalah yang dapat menyebabkan mulai ulang server selama pemrosesan log Aliran Aktivitas Basis Data (DAS).

• Memperbaiki masalah yang memunculkan pesan kesalahan saat memproses kueri ALTER pada tabel sistem.

Perbaikan umum:

• Memperbaiki masalah di mana cache kueri dapat mengembalikan hasil usang pada instans pembaca.

• Memperbaiki masalah di mana beberapa metrik commit Aurora tidak diperbarui saat variabel sistem innodb_flush_log_at_trx_commit diatur ke 0 atau 2.

• Memperbaiki masalah di mana hasil kueri yang disimpan dalam cache kueri tidak disegarkan oleh transaksi multi-pernyataan.

• Memperbaiki masalah yang dapat menyebabkan stempel waktu yang terakhir diubah dari file log biner tidak diperbarui dengan benar. Hal ini dapat menyebabkan file log biner dibersihkan sebelum waktunya, sebelum mencapai periode retensi yang dikonfigurasi pelanggan.

• Memperbaiki kesalahan nama dan posisi file binlog yang dilaporkan dari InnoDB setelah pemulihan crash.

• Memperbaiki masalah yang dapat menyebabkan transaksi besar menghasilkan peristiwa binlog yang salah jika parameter binlog_checksum diatur ke NONE.

• Memperbaiki masalah yang menyebabkan replika binlog berhenti dengan kesalahan jika transaksi yang direplikasi berisi pernyataan DDL dan perubahan baris dalam jumlah besar.

• Memperbaiki masalah yang menyebabkan mulai ulang dalam instans pembaca saat menghapus tabel.

• Memperbaiki masalah yang menyebabkan kegagalan konektor sumber terbuka saat mencoba mengonsumsi file binlog dengan transaksi besar.

• Memperbaiki masalah yang dapat menyebabkan hasil kueri salah pada kolom geometri besar setelah membuat indeks spasial pada tabel dengan nilai geometri besar.

• Basis data sekarang membuat ulang ruang tabel sementara selama mulai ulang, yang memungkinkan ruang penyimpanan terkait dilepaskan dan diklaim kembali.

• Memperbaiki masalah yang mencegah terpotongnya tabel performance_schema pada instans pembaca Aurora.

• Memperbaiki masalah yang menyebabkan replika binlog berhenti dengan kesalahan HA_ERR_KEY_NOT_FOUND.

• Memperbaiki masalah yang menyebabkan basis data memulai ulang saat menjalankan pernyataan FLUSH TABLES WITH READ LOCK.

• Memperbaiki masalah yang mencegah penggunaan fungsi penguncian tingkat pengguna pada instans pembaca Aurora.

Integrasi perbaikan bug MySQL Community Edition

• Transaksi yang berseling terkadang dapat menyebabkan deadlock pada pengaplikasi replika saat tingkat isolasi transaksi diatur ke REPEATABLE READ. (Bug #25040331)

• Ketika prosedur tersimpan berisi pernyataan yang merujuk ke suatu tampilan yang pada gilirannya merujuk ke tampilan lain, prosedur tidak dapat berhasil diinvokasi lebih dari sekali. (Bug #87858, Bug #26864199)

• Untuk kueri dengan banyak kondisi OR, pengoptimal sekarang lebih hemat memori dan lebih kecil kemungkinannya untuk melebihi batas memori yang diberlakukan oleh variabel sistem range_optimizer_max_mem_size. Selain itu, nilai default untuk variabel tersebut telah dinaikkan dari 1.536.000 menjadi 8.388.608. (Bug #79450, Bug #22283790)

• Replikasi: Di fungsi next_event(), yang dipanggil oleh thread SQL replika untuk membaca peristiwa berikutnya dari log relay, thread SQL tersebut tidak melepaskan relaylog.log_lock yang diperolehnya saat mengalami kesalahan (misalnya, karena log relay tertutup), sehingga menyebabkan hang pada semua thread lain yang menunggu untuk mendapatkan kunci pada log relay. Dengan perbaikan ini, kunci dilepaskan sebelum thread SQL meninggalkan fungsi dalam situasi tersebut. (Bug #21697821)

• Memperbaiki kerusakan memori untuk ALTER TABLE dengan kolom virtual. (Bug #24961167; Bug #24960450)

• Replikasi: Replika multithread tidak dapat dikonfigurasi dengan ukuran antrean kecil menggunakan slave_pending_jobs_size_max jika diperlukan untuk memproses transaksi yang lebih besar dari ukuran tersebut. Setiap paket yang lebih besar daripada slave_pending_jobs_size_max ditolak dengan kesalahan ER_MTS_EVENT_BIGGER_PENDING_JOBS_SIZE_MAX, bahkan jika paket lebih kecil dari batas yang ditetapkan oleh slave_max_allowed_packet. Dengan perbaikan ini, slave_pending_jobs_size_max menjadi batas lembut, bukan batas keras. Jika ukuran paket melebihi slave_pending_jobs_size_max tapi kurang dari slave_max_allowed_packet, transaksi ditangguhkan sampai semua pekerja replika memiliki antrean kosong, dan kemudian diproses. Semua transaksi berikutnya ditangguhkan sampai transaksi besar selesai. Oleh karena itu, ukuran antrean untuk pekerja replika dapat dibatasi sambil tetap memungkinkan transaksi sesekali yang lebih besar. (Bug #21280753, Bug #77406)

• Replikasi: Ketika menggunakan replika multithread, kesalahan applier menampilkan data ID pekerja yang tidak konsisten dengan data yang dieksternalkan dalam tabel replikasi Skema Kinerja. (Bug #25231367)

• Replikasi: Pada replika replikasi berbasis GTID yang berjalan dengan -GTID-mode=on, -log-bin=off, dan menggunakan -, ketika kesalahan ditemukan yang harus diabaikan tidak diperbarui dengan benar, menyebabkan slave-skip-errors sinkronisasi yang longgar dengan. Exec_Master_Log_Pos Exec_Master_Log_Pos Read_master_log_pos Jika GTID_NEXT tidak ditentukan, replika tidak akan pernah memperbarui status GTID ketika dibatalkan dari transaksi pernyataan tunggal. Exec_Master_Log_Pos tidak akan diperbarui karena meskipun transaksi selesai, status GTID akan menunjukkan sebaliknya. Perbaikan ini menghilangkan batasan pembaruan status GTID saat transaksi dibatalkan hanya jika GTID_NEXT ditentukan. (Bug #22268777)

• Replikasi: Pernyataan yang gagal sebagian tidak menggunakan secara benar GTID yang ditentukan atau dibuat secara otomatis saat pencatatan log biner dinonaktifkan. Perbaikan ini memastikan bahwa DROP TABLE yang gagal sebagian, DROP USER yang gagal sebagian, atau DROP VIEW yang gagal sebagian menggunakan GTID masing-masing yang relevan dan menyimpannya ke dalam tabel @@GLOBAL.GTID_EXECUTED dan mysql.gtid_executed ketika pencatatan log biner dinonaktifkan. (Bug #21686749)

• Replikasi: Replika yang menjalankan MySQL 5.7 tidak dapat terhubung ke sumber MySQL 5.5 karena kesalahan saat mengambil server_uuid, yang bukan bagian dari MySQL 5.5. Hal ini disebabkan oleh perubahan pada metode pengambilan server_uuid. (Bug #22748612)

• Replikasi: Mekanisme melewatkan transaksi GTID yang secara diam-diam melewatkan transaksi GTID yang sebelumnya dijalankan tidak berfungsi dengan baik untuk transaksi XA. (Bug #25041920)

• Pernyataan ">XA ROLLBACK yang gagal karena ID transaksi yang diberikan salah, dapat direkam dalam log biner dengan ID transaksi yang benar, oleh karena itu dapat ditindaklanjuti dengan replika replikasi. Pemeriksaan sekarang dilakukan untuk situasi kesalahan sebelum pencatatan log biner terjadi, dan pernyataan ROLLBACK XA yang gagal tidak dicatat. (Bug #26618925)

• Replikasi: Jika replika disiapkan menggunakan pernyataan CHANGE MASTER TO yang tidak menentukan nama file log sumber dan posisi log sumber, lalu matikan sebelum START SLAVE dikeluarkan, lalu restart dengan opsi - relay-log-recovery set, replikasi tidak dimulai. Hal ini terjadi karena thread penerima belum dimulai sebelum pemulihan log relay diupayakan, jadi tidak ada peristiwa rotasi log yang tersedia di log relay untuk memberikan nama file log sumber dan posisi log sumber. Dalam situasi ini, replika sekarang melompati pemulihan log relay dan mencatat log peringatan, lalu melanjutkan untuk memulai replikasi. (Bug #28996606, Bug #93397)

• Replikasi: Dalam replikasi berbasis baris, sebuah pesan yang salah menampilkan panjang bidang dikembalikan saat mereplikasi dari tabel dengan kolom utf8mb3 ke tabel definisi yang sama di mana kolom didefinisikan dengan kumpulan karakter utf8mb4. (Bug #25135304, Bug #83918)

• Replikasi: Saat pernyataan RESET SLAVE dikeluarkan pada replika replikasi dengan GTID yang digunakan, file log relay yang ada dibersihkan, tetapi file log relay pengganti dibuat sebelum kumpulan GTID yang diterima untuk saluran dihapus. Oleh karena itu, kumpulan GTID sebelumnya ditulis ke file log relay baru sebagai peristiwa PREVIOUS_GTIDS, sehingga menyebabkan kesalahan fatal dalam replikasi yang menyatakan bahwa replika memiliki lebih banyak GTID daripada sumbernya, meskipun kumpulan gtid_executed untuk kedua server kosong. Sekarang, ketika RESET SLAVE diterbitkan, kumpulan GTID yang diterima dihapus sebelum file log relay baru dihasilkan, sehingga situasi ini tidak terjadi. (Bug #27411175)

• Replikasi: Dengan GTID yang digunakan untuk replikasi, transaksi termasuk pernyataan yang menyebabkan kesalahan parsing (ER_PARSE_ERROR) tidak dapat dilewati secara manual dengan metode yang disarankan untuk memasukkan transaksi kosong atau penggantian dengan GTID yang sama. Tindakan ini seharusnya menghasilkan replika yang mengidentifikasi GTID seperti yang sudah digunakan, dan oleh karena itu melewatkan transaksi yang tidak diinginkan yang membagikan GTID-nya. Namun, dalam kasus kesalahan penguraian, karena pernyataan diuraikan sebelum GTID diperiksa untuk melihat apakah perlu dilewati, thread applier replikasi berhenti karena kesalahan penguraian, meskipun tujuannya adalah agar transaksi dilewati juga. Dengan perbaikan ini, thread applier replikasi sekarang mengabaikan kesalahan penguraian jika transaksi yang bersangkutan perlu dilewati karena GTID sudah digunakan. Perhatikan bahwa perubahan perilaku ini tidak berlaku dalam kasus beban kerja yang terdiri dari output log biner yang dihasilkan oleh mysqlbinlog. Dalam situasi tersebut, akan ada risiko bahwa transaksi dengan kesalahan penguraian yang segera mengikuti transaksi yang dilewati juga akan secara diam-diam dilewati, ketika transaksi tersebut akan meningkatkan kesalahan. (Bug #27638268)

• Replikasi: Mengaktifkan thread SQL untuk GTID melewatkan transaksi parsial. (Bug #25800025)

• Replikasi: Ketika parameter batas waktu negatif atau pecahan diberikan ke WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(), server berperilaku dengan cara yang tidak terduga. Dengan perbaikan ini:

  • Nilai batas waktu pecahan dibaca apa adanya, tanpa pembulatan.

  • Nilai batas waktu negatif ditolak dengan kesalahan jika server menggunakan mode SQL yang ketat; jika server tidak dalam mode SQL yang ketat, nilainya membuat fungsi segera mengembalikan NULL tanpa menunggu apa pun dan kemudian mengeluarkan peringatan. (Bug #24976304, Bug #83537)

• Replikasi: Jika fungsi WAIT_FOR_EXECUTED_GTID_SET() digunakan dengan nilai batas waktu termasuk bagian pecahan (misalnya, 1,5), kesalahan dalam logika casting berarti batas waktu dibulatkan ke bawah ke seluruh detik terdekat, dan ke nol untuk nilai kurang dari 1 detik (misalnya, 0,1). Logika casting sekarang telah diperbaiki sehingga nilai batas waktu diterapkan seperti yang ditentukan semula tanpa pembulatan. Terima kasih kepada Dirkjan Bussink atas kontribusinya. (Bug #29324564, Bug #94247)

• Dengan GTID diaktifkan, XA COMMIT pada transaksi XA yang terputus dalam transaksi multi-pernyataan menimbulkan pernyataan. (Bug #22173903)

• Replikasi: Sebuah pernyataan diangkat dalam build debug jika pernyataan XA ROLLBACK dikeluarkan untuk pengenal transaksi yang tidak diketahui ketika nilai gtid_next telah ditetapkan secara manual. Server sekarang tidak mencoba memperbarui status GTID jika pernyataan ROLLBACK XA gagal dengan kesalahan. (Bug #27928837, Bug #90640)

• Memperbaiki masalah urutan penyortiran yang salah ketika beberapa fungsi CASE yang digunakan dalam klausa ORDER BY (Bug #22810883).

• Beberapa kueri yang menggunakan pengurutan dapat mengakses kolom yang tidak diinisialisasi selama pengoptimalan dan menyebabkan server keluar. (Bug #27389294)

Perbandingan dengan Aurora MySQL versi 1

Fitur Amazon Aurora MySQL berikut ini didukung di Aurora MySQL versi 1 (kompatibel dengan MySQL 5.6), tetapi fitur-fitur tersebut saat ini tidak didukung di Aurora MySQL versi 2 (kompatibel dengan MySQL 5.7).

• Sambungan hash. Untuk informasi selengkapnya, lihat Mengoptimalkan kueri sambungan terindeks Aurora dengan asynchronous key prefetch di Panduan Pengguna Amazon Aurora.

• Fungsi asli untuk memanggil AWS Lambda fungsi secara sinkron. Untuk informasi selengkapnya, lihat Menginvokasi fungsi Lambda dengan fungsi asli Aurora MySQL di Panduan Pengguna Amazon Aurora.

• Pindai batching. Untuk informasi selengkapnya, lihat Pembaruan mesin basis data Aurora MySQL 2017-12-11 (versi 1.16) (Dihentikan).

• Memigrasikan data dari MySQL menggunakan bucket Amazon S3. Untuk informasi selengkapnya, lihat Memigrasikan data dari MySQL menggunakan bucket Amazon S3 di Panduan Pengguna Amazon Aurora.

Kompatibilitas MySQL 5.7

Versi Aurora MySQL ini kompatibel dengan kabel dengan MySQL 5.7 dan menyertakan fitur seperti dukungan JSON, indeks spasial, dan kolom yang dihasilkan. Aurora MySQL menggunakan implementasi asli pengindeksan spasial menggunakan kurva z-order untuk memberikan kinerja tulis >20x lebih baik dan kinerja baca >10x lebih baik daripada MySQL 5.7 untuk set data spasial.

Versi Aurora MySQL ini saat ini tidak mendukung fitur MySQL 5.7 berikut:

• Plugin replikasi kelompok

• Peningkatan ukuran halaman

• Pemuatan pool buffer InnoDB saat pengaktifan

• Plugin pengurai teks lengkap InnoDB

• Replikasi multisumber

• Perubahan ukuran pool buffer online

• Plugin validasi kata sandi

• Plugin tulis ulang kueri

• Penyaringan replikasi

• Pernyataan SQL CREATE TABLESPACE