Apa saja perubahan di mysql 8?

• Memindahkan fitur khusus kami ke versi baru
• Memastikan replikasi kompatibel antara versi utama
• Meminimalkan perubahan yang diperlukan untuk kueri aplikasi yang ada
• Memperbaiki regresi kinerja yang mencegah server mendukung beban kerja kami

Peningkatan versi utama terakhir kami, ke MySQL 5. 6, membutuhkan waktu lebih dari satu tahun untuk diluncurkan. Ketika versi 5. 7 dirilis, kami masih dalam pengembangan mesin penyimpanan LSM-Tree kami, MyRocks, pada versi 5. 6. Sejak upgrade ke 5. 7 sementara membangun mesin penyimpanan baru secara bersamaan akan memperlambat kemajuan MyRocks secara signifikan, kami memilih untuk tetap menggunakan 5. 6 hingga MyRocks selesai. MySQL8. 0 diumumkan saat kami menyelesaikan peluncuran MyRocks ke tingkat layanan basis data pengguna (UDB) kami.

Versi itu menyertakan fitur menarik seperti replikasi paralel berbasis set tulis dan kamus data transaksional yang menyediakan dukungan atom DDL. Bagi kami, pindah ke 8. 0 juga akan membawa 5. 7 fitur yang kami lewatkan, termasuk Document Store. Versi 5. 6 mendekati akhir masa pakainya, dan kami ingin tetap aktif dalam komunitas MySQL, terutama dengan pekerjaan kami di mesin penyimpanan MyRocks. Penyempurnaan di 8. 0, seperti DDL instan, dapat mempercepat perubahan skema MyRocks, tetapi kami harus menggunakan 8. 0 basis kode untuk menggunakannya. Mengingat manfaat pembaruan kode, kami memutuskan untuk bermigrasi ke 8. 0. Kami berbagi bagaimana kami menangani 8 kami. 0 proyek migrasi — dan beberapa kejutan yang kami temukan dalam prosesnya. Ketika kami awalnya membatasi proyek, jelas bahwa pindah ke 8. 0 akan lebih sulit daripada bermigrasi ke 5. 6 atau MyRocks

• Pada saat itu, 5. 6 cabang memiliki lebih dari 1.700 tambalan kode ke port ke 8. 0. Saat kami mem-porting perubahan tersebut, fitur dan perbaikan MySQL Facebook baru ditambahkan ke 5. 6 basis kode yang memindahkan tiang gawang lebih jauh
• Kami memiliki banyak server MySQL yang berjalan dalam produksi, melayani sejumlah besar aplikasi yang berbeda. Kami juga memiliki infrastruktur perangkat lunak yang ekstensif untuk mengelola instans MySQL. Aplikasi ini melakukan operasi seperti mengumpulkan statistik dan mengelola cadangan server
• Upgrade dari 5. 6 sampai 8. 0 dilewati 5. 7 seluruhnya. API yang aktif di 5. 6 akan ditinggalkan dalam 5. 7 dan mungkin dihapus di 8. 0, mengharuskan kami memperbarui aplikasi apa pun menggunakan API yang sekarang dihapus
• Sejumlah fitur Facebook tidak kompatibel dengan yang serupa di 8. 0 dan memerlukan penghentian dan jalur migrasi ke depan
• Peningkatan MyRocks diperlukan untuk berjalan di 8. 0, termasuk partisi asli dan pemulihan kerusakan

Tambalan kode

Kami pertama kali mengatur 8. 0 untuk membangun dan menguji di lingkungan pengembangan kami. Kami kemudian memulai perjalanan panjang untuk memindahkan tambalan dari 5 kami. 6 cabang. Ada lebih dari 1.700 tambalan saat kami mulai, tetapi kami dapat mengaturnya ke dalam beberapa kategori utama. Sebagian besar kode kustom kami memiliki komentar dan deskripsi yang baik sehingga kami dapat dengan mudah menentukan apakah kode tersebut masih diperlukan oleh aplikasi atau dapat dihapus. Fitur yang diaktifkan oleh kata kunci khusus atau nama variabel unik juga memudahkan untuk menentukan relevansi karena kami dapat mencari melalui basis kode aplikasi kami untuk menemukan kasus penggunaannya. Beberapa tambalan sangat tidak jelas dan membutuhkan pekerjaan detektif — menggali dokumen desain lama, pos, dan/atau komentar tinjauan kode — untuk memahami riwayatnya

Kami menyortir setiap tambalan ke dalam salah satu dari empat ember

1. Menjatuhkan. Fitur yang tidak lagi digunakan, atau memiliki fungsi yang setara di 8. 0, tidak perlu diporting
2. Bangun/Klien. Fitur non-server yang mendukung lingkungan build kami dan alat MySQL yang dimodifikasi seperti mysqlbinlog, atau fungsionalitas tambahan seperti API klien async, telah di-porting
3. Server Non-MyRocks. Fitur di server mysqld yang tidak terkait dengan mesin penyimpanan MyRocks kami di-porting
4. Server MyRocks. Fitur yang mendukung mesin penyimpanan MyRocks dipindahkan

Kami melacak status dan informasi historis yang relevan dari setiap tambalan menggunakan spreadsheet, dan mencatat alasan kami saat melepas tambalan. Beberapa tambalan yang memperbarui fitur yang sama dikelompokkan bersama untuk porting. Patch porting dan berkomitmen ke 8. 0 cabang dianotasi dengan 5. 6 komit informasi. Perbedaan pada status porting pasti akan muncul karena banyaknya tambalan yang perlu kami saring dan catatan ini membantu kami menyelesaikannya

Setiap kategori klien dan server secara alami menjadi tonggak rilis perangkat lunak. Dengan porting semua perubahan terkait klien, kami dapat memperbarui perkakas klien dan kode konektor ke 8. 0. Setelah semua fitur server non-MyRocks dipindahkan, kami dapat menerapkan 8. 0 mysqld untuk server InnoDB. Menyelesaikan fitur server MyRocks memungkinkan kami memperbarui instalasi MyRocks

Beberapa fitur yang paling kompleks memerlukan perubahan signifikan untuk 8. 0, dan beberapa area memiliki masalah kompatibilitas yang besar. Misalnya hulu 8. 0 format acara binlog tidak kompatibel dengan beberapa kebiasaan kami 5. 6 modifikasi. Kode kesalahan yang digunakan oleh Facebook 5. 6 fitur bertentangan dengan yang ditugaskan ke fitur baru oleh upstream 8. 0. Kami akhirnya perlu menambal 5. 6 server agar kompatibel ke depan dengan 8. 0

Butuh beberapa tahun untuk menyelesaikan porting semua fitur ini. Pada saat kami mencapai akhir, kami telah mengevaluasi lebih dari 2.300 tambalan dan mem-porting 1.500 di antaranya menjadi 8. 0

Jalur migrasi

Kami mengelompokkan beberapa instance mysqld menjadi satu set replika MySQL. Setiap instans dalam kumpulan replika berisi data yang sama tetapi didistribusikan secara geografis ke pusat data yang berbeda untuk menyediakan ketersediaan data dan dukungan failover. Setiap kumpulan replika memiliki satu instance utama. Instance yang tersisa semuanya sekunder. Primer menangani semua lalu lintas tulis dan mereplikasi data secara asinkron ke semua sekunder

Kami mulai dengan set replika yang terdiri dari 5. 6 primer/5. 6 sekunder dan tujuan akhirnya adalah set replika dengan 8. 0 primer/8. 0 sekunder. Kami mengikuti rencana yang mirip dengan rencana migrasi UDB MyRocks.

1. Untuk setiap set replika, buat dan tambahkan 8. 0 sekunder melalui salinan logis menggunakan mysqldump. Sekunder ini tidak melayani lalu lintas baca aplikasi apa pun
2. Aktifkan lalu lintas baca di 8. 0 sekunder
3. Izinkan 8. 0 instance yang akan dipromosikan ke primer
4. Nonaktifkan 5. 6 contoh untuk lalu lintas baca
5. Hapus semua 5. 6 contoh

Setiap set replika dapat bertransisi melalui setiap langkah di atas secara mandiri dan tetap pada satu langkah selama diperlukan. Kami memisahkan set replika menjadi kelompok yang jauh lebih kecil, yang kami gembalakan melalui setiap transisi. Jika kami menemukan masalah, kami dapat kembali ke langkah sebelumnya. Dalam beberapa kasus, set replika dapat mencapai langkah terakhir sebelum yang lainnya memulai

Untuk mengotomatiskan transisi sejumlah besar kumpulan replika, kami perlu membangun infrastruktur perangkat lunak baru. Kita dapat mengelompokkan set replika bersama dan memindahkannya melalui setiap tahap hanya dengan mengubah baris dalam file konfigurasi. Set replika apa pun yang mengalami masalah kemudian dapat dibatalkan satu per satu

Replikasi berbasis baris

Sebagai bagian dari 8. 0 upaya migrasi, kami memutuskan untuk standarisasi menggunakan replikasi berbasis baris (RBR). Beberapa 8. 0 membutuhkan RBR, dan itu menyederhanakan upaya porting MyRocks kami. Sementara sebagian besar set replika MySQL kami sudah menggunakan RBR, replikasi berbasis pernyataan (SBR) yang masih berjalan tidak dapat dengan mudah dikonversi. Set replika ini biasanya memiliki tabel tanpa kunci kardinalitas tinggi. Beralih sepenuhnya ke RBR telah menjadi tujuan, tetapi pekerjaan panjang yang diperlukan untuk menambahkan kunci utama sering kali diprioritaskan lebih rendah daripada proyek lain

Oleh karena itu, kami menjadikan RBR sebagai persyaratan untuk 8. 0. Setelah mengevaluasi dan menambahkan kunci utama ke setiap tabel, kami mengganti set replika SBR terakhir tahun ini. Menggunakan RBR juga memberi kami solusi alternatif untuk menyelesaikan masalah aplikasi yang kami temui saat kami memindahkan beberapa set replika ke 8. 0 pendahuluan, yang akan dibahas nanti

Validasi otomatisasi

Sebagian besar 8. Proses migrasi V.0 melibatkan pengujian dan verifikasi server mysqld dengan infrastruktur otomasi dan kueri aplikasi kami

Seiring berkembangnya armada MySQL kami, infrastruktur otomatisasi yang kami gunakan untuk mengelola server juga meningkat. Untuk memastikan semua otomatisasi MySQL kami kompatibel dengan 8. 0, kami berinvestasi dalam membangun lingkungan pengujian, yang memanfaatkan kumpulan replika pengujian dengan mesin virtual untuk memverifikasi perilaku. Kami menulis tes integrasi ke canary setiap bagian dari otomatisasi untuk berjalan di kedua 5. 6 versi dan 8. 0 versi dan memverifikasi kebenarannya. Kami menemukan beberapa bug dan perbedaan perilaku saat kami melakukan latihan ini

Karena setiap infrastruktur MySQL telah divalidasi dengan 8. 0, kami menemukan dan memperbaiki (atau mengatasi) sejumlah masalah menarik

1. Perangkat lunak yang mem-parse keluaran teks dari log kesalahan, keluaran mysqldump, atau server menampilkan perintah dengan mudah rusak. Sedikit perubahan pada keluaran server sering mengungkapkan bug dalam logika penguraian alat
2. 8. Pengaturan kolasi utf8mb4 default .0 menghasilkan ketidaksesuaian antara 5. 6 dan 8. 0 contoh. 8. 0 tabel dapat menggunakan utf8mb4_0900 collations baru bahkan untuk membuat pernyataan yang dihasilkan oleh 5. 6 menunjukkan buat tabel karena 5. 6 skema menggunakan utf8mb4_general_ci tidak menentukan susunan secara eksplisit. Perbedaan tabel ini sering menyebabkan masalah dengan alat replikasi dan verifikasi skema.
3. Kode kesalahan untuk kegagalan replikasi tertentu berubah dan kami harus memperbaiki otomatisasi kami untuk menanganinya dengan benar
4. 8. Tabel usang kamus data versi 0. frm, tetapi beberapa otomatisasi kami menggunakannya untuk mendeteksi modifikasi skema tabel
5. Kami harus memperbarui otomatisasi kami untuk mendukung privasi dinamis yang diperkenalkan di 8. 0

Validasi aplikasi

Kami ingin transisi untuk aplikasi menjadi setransparan mungkin, tetapi beberapa kueri aplikasi mencapai regresi kinerja atau akan gagal pada 8. 0

Untuk migrasi MyRocks, kami membuat kerangka kerja pengujian bayangan MySQL yang menangkap lalu lintas produksi dan memutarnya kembali untuk menguji instance. Untuk setiap beban kerja aplikasi, kami membuat instance pengujian pada 8. 0 dan memutar ulang kueri lalu lintas bayangan kepada mereka. Kami menangkap dan mencatat kesalahan yang kembali dari 8. 0 server dan menemukan beberapa masalah menarik. Sayangnya, tidak semua masalah ini ditemukan selama pengujian. Misalnya, kebuntuan transaksi ditemukan oleh aplikasi selama migrasi. Kami dapat mengembalikan aplikasi ini ke 5. 6 sementara sementara kami meneliti solusi yang berbeda

• Kata kunci cadangan baru diperkenalkan di 8. 0 dan beberapa, seperti grup dan peringkat, bertentangan dengan nama kolom tabel populer dan alias yang digunakan dalam kueri aplikasi. Kueri ini tidak luput dari nama melalui kutipan balik, yang menyebabkan kesalahan parsing. Aplikasi yang menggunakan pustaka perangkat lunak yang secara otomatis lolos dari nama kolom dalam kueri tidak mengalami masalah ini, tetapi tidak semua aplikasi menggunakannya. Memperbaiki masalah itu sederhana, tetapi butuh waktu untuk melacak pemilik aplikasi dan basis kode yang menghasilkan kueri ini
• Beberapa inkompatibilitas REGEXP juga ditemukan antara 5. 6 dan 8. 0
• Beberapa aplikasi mengalami kebuntuan transaksi yang dapat dibaca berulang yang melibatkan masukkan … pada kunci duplikat queries on InnoDB. 5.6 had a bug which was corrected in 8.0, but the fix increased the likelihood of transaction deadlocks. After analyzing our queries, we were able to resolve them by lowering the isolation level. This option was available to us since we had made the switch to row-based replication.
• Kebiasaan kami 5. 6 fungsi Document Store dan JSON tidak kompatibel dengan 8. 0. Aplikasi yang menggunakan Document Store diperlukan untuk mengonversi jenis dokumen menjadi teks untuk migrasi. Untuk fungsi JSON, kami menambahkan 5. Versi 6-kompatibel ke 8. 0 sehingga aplikasi dapat bermigrasi ke 8. 0 API di lain waktu

Permintaan kami dan pengujian kinerja dari 8. 0 menemukan beberapa masalah yang perlu segera diatasi

• Kami menemukan hotspot pertengkaran mutex baru di sekitar cache ACL. Ketika sejumlah besar koneksi dibuka secara bersamaan, mereka semua dapat memblokir pemeriksaan ACL
• Perselisihan serupa ditemukan dengan akses indeks binlog ketika banyak file binlog hadir dan tingkat penulisan binlog yang tinggi sering merotasi file
• Beberapa kueri yang melibatkan tabel temp rusak. Kueri akan mengembalikan kesalahan yang tidak terduga atau membutuhkan waktu lama untuk dijalankan sehingga waktu habis

Penggunaan memori dibandingkan dengan 5. 6 telah meningkat, terutama untuk instans MyRocks kami, karena InnoDB di 8. 0 harus dimuat. Pengaturan performance_schema default mengaktifkan semua instrumen dan menghabiskan banyak memori. Kami membatasi penggunaan memori dengan hanya mengaktifkan sejumlah kecil instrumen dan membuat perubahan kode untuk menonaktifkan tabel yang tidak dapat dimatikan secara manual. Namun, tidak semua peningkatan memori dialokasikan oleh performance_schema. Kami perlu memeriksa dan memodifikasi berbagai struktur data internal InnoDB untuk mengurangi jejak memori lebih lanjut. Usaha ini menghasilkan 8. Penggunaan memori 0 turun ke tingkat yang dapat diterima.  

Apa berikutnya

8. 0 migrasi telah memakan waktu beberapa tahun sejauh ini. Kami telah mengonversi banyak set replika InnoDB kami untuk berjalan sepenuhnya pada 8. 0. Sebagian besar yang tersisa berada pada berbagai tahap di sepanjang jalur migrasi. Sekarang sebagian besar fitur khusus kami telah dipindahkan ke 8. 0, memperbarui ke rilis minor Oracle relatif lebih mudah dan kami berencana untuk mengikuti versi terbaru

Melewatkan versi utama seperti 5. 7 memperkenalkan masalah, yang perlu diselesaikan oleh migrasi kami

Pertama, kami tidak dapat memutakhirkan server di tempat dan perlu menggunakan logical dump dan restore untuk membangun server baru. Namun, untuk instance mysqld yang sangat besar, ini dapat memakan waktu berhari-hari di server produksi langsung dan proses rapuh ini kemungkinan besar akan terhenti sebelum dapat diselesaikan. Untuk instans besar ini, kami harus memodifikasi sistem pencadangan dan pemulihan untuk menangani pembangunan kembali

Kedua, jauh lebih sulit untuk mendeteksi perubahan API karena 5. 7 dapat memberikan peringatan penghentian kepada klien aplikasi kami untuk memperbaiki potensi masalah. Sebagai gantinya, kami perlu menjalankan pengujian bayangan tambahan untuk menemukan kegagalan sebelum kami dapat memigrasikan beban kerja produksi. Menggunakan perangkat lunak klien mysql yang secara otomatis keluar dari nama objek skema membantu mengurangi jumlah masalah kompatibilitas

Mendukung dua versi utama dalam satu set replika itu sulit. Setelah set replika mempromosikan utamanya menjadi 8. 0 misalnya, yang terbaik adalah menonaktifkan dan menghapus 5. 6 orang secepat mungkin. Pengguna aplikasi cenderung menemukan fitur baru yang hanya didukung oleh 8. 0, seperti utf8mb4_0900 collations, dan menggunakan ini dapat memutus aliran replikasi antara 8. 0 dan 5. 6 contoh.

Terlepas dari semua rintangan di jalur migrasi kami, kami telah melihat manfaat menjalankan 8. 0. Beberapa aplikasi memilih konversi awal ke 8. 0 untuk memanfaatkan fitur seperti Penyimpanan Dokumen dan peningkatan dukungan waktu dan waktu. Kami telah mempertimbangkan cara mendukung fitur mesin penyimpanan seperti DDL Instan di MyRocks. Secara keseluruhan, versi baru sangat memperluas apa yang bisa kita lakukan dengan MySQL @ Facebook

Apa perbedaan antara MySQL 5. 7 dan MySQL 8?

Apa yang baru di MySQL 8. 0 28?

Apa yang terjadi pada MySQL 8. 0 29?

Haruskah saya menggunakan MySQL 5. 7 atau 8?