Rumah >pangkalan data >tutorial mysql >Panduan komprehensif untuk log MySQL
Artikel ini membawa anda pengetahuan yang berkaitan tentang mysql, yang terutamanya memperkenalkan isu yang berkaitan dengan log sistem memastikan bahawa data tidak akan hilang tidak kira apabila ia ranap, mari kita lihat bersama-sama, saya harap ia akan membantu semua orang.
Pembelajaran yang disyorkan: tutorial video mysql
Sistem pengelogan MySQL adalah jaminan Mysql bahawa data tidak akan hilang tidak kira apabila ia ranap Kuncinya
Seperti yang kita semua tahu, Mysql ialah pangkalan data yang berterusan Semua data disimpan ke cakera keras untuk memastikan bahawa data tidak akan hilang
Mysql memastikan bahawa data tidak akan hilang hilang daripada dua aspek berikut untuk mencerminkan
dapat memulihkan keadaan data pada bila-bila masa
memastikan data tidak hilang tanpa mengira ranap sebelum atau selepas transaksi diserahkan
Ranap sistem semasa transaksi boleh dipulihkan kepada keadaan sebelum transaksi diserahkan
Data yang diserahkan akan tidak akan hilang jika transaksi ranap selepas transaksi diserahkan
MySQL menjamin perkara di atas Kunci kepada dua mata ini dicapai melalui tiga log batal log, buat semula log dan binlog Seterusnya, kami akan memperkenalkan satu demi satu satu
log asal ialah pengembalian log Gulung Mysql, simpan versi lama data
Fungsi utama
Simpan versi lama data Bekerjasama dengan Read View dan medan tersembunyi melaksanakan bacaan syot kilat Mysql digunakan untuk melancarkan semula versi sebelum transaksi dimulakan apabila pelaksanaan transaksi gagalApakah jenis log asal yang ada
Terdapat dua jenis log asal Untuk arahan sisip, log buat asal merekodkan kunci utama rekod yang baru ditambah Semasa pemulangan semula, ia berdasarkan kunci utama dalam log buat asal hanya padamkan rekod yang sepadanUntuk perintah kemas kini / padam, buat asal log merekodkan data lama rekod yang diubah suaiSetiap baris data dalam Mysql mempunyai baris data terkini yang diubah suai. Kedua-dua medan id transaksi dan penuding balik Apabila baris data diubah suai, penunjuk log batal akan tuding ke baris data lama, dan penuding balik baris data yang baru dijana akan menghala ke penuding log buat asal semasa yang ditunjuk olehPeranan log buat semula
Bertanggungjawab untuk merekodkan pengubahsuaian data oleh urus niaga yang diserahkan. >
Biarkan Mysql tidak perlu menunggu data diteruskan ke cakera apabila melakukan transaksi Ia hanya perlu meneruskan log semula ke cakera 🎜>Bilangan log buat semula yang tidak jelas menunjukkan bahawa cakera belum disiram Bilangan halaman kotor
Mengapa anda memilih untuk meneruskan log semula semasa melakukan transaksi, dan bukannya berterusan. data ke cakera?
Data yang berterusan ke cakera ialah proses IO rawak, jadi Mysql memilih untuk cache data dan menunggu peluang yang sesuai untuk menulis data ke cakera sekaligus untuk mengurangkan IO Walau bagaimanapun, terdapat risiko kehilangan cache data dalam ingatan, jadi Mysql memilih untuk mengekalkan log buat semula Log buat semula ditulis secara berurutan, dan kecekapan kegigihan adalah lebih tinggi daripada penulisan rawak, dan log buat semula merekodkan perubahan dalam data selagi log buat semula ada, data boleh dipulihkan selepas Mysql dimulakan semula
buat asal log merekodkan status data lama semasa pelaksanaan transaksi, dan buat semula log merekodkan status selepas kemas kini data
buat semula log sebenarnya menjamin kegigihan dan ketekalan transaksi, manakala buat asal log Ini memastikan atomicity transaksi
binlog ialah log yang dilaksanakan oleh lapisan pelayan Mysql dan biasa kepada semua enjin
fungsi
Binlog merekodkan logik pernyataan asal mysql, dan ia direkodkan dalam bentuk penulisan tambah, jadi ia boleh digunakan untuk memulihkan status data pangkalan data mysql pada bila-bila masa
Pada masa yang sama, binlog juga merupakan kebergantungan Mysql untuk melaksanakan replikasi induk-hamba Perpustakaan hamba menyegerakkan status data perpustakaan utama dengan menyalin main balik binlog dari perpustakaan utama
Definisi
Tulis log ke cakera dahulu, dan kemudian tulis data ke cakera Operasi tulis Mysql ialah tidak ditulis pada cakera serta-merta, tetapi log ditulis dahulu untuk memastikan buat semula Kedua-dua log dan binlog diteruskan ke cakera, dan kemudian benang latar belakang memilih peluang untuk mengekalkan data ke cakera keras
Mengapa kita perlu menulis log ke cakera terlebih dahulu
Oleh kerana membilas halaman kotor adalah proses membaca dan menulis secara rawak, kelajuan berterusan ke cakera pastinya tidak sepantas buat semula log |. Oleh itu, kami memilih untuk mengubah suai data dalam memori dahulu, dan kemudian memilihnya kemudian. dipadamkan ke cakera, log buat semula |. perlu ditulis pada cakera dan kemudian dihapuskan Mengapa tidak menghapuskan kesemuanya dan kemudian memulihkannya melalui log semula pada kali berikutnya ia digunakan?
Dari sudut prestasi, jika data perlu dibandingkan. dan dikemas kini dengan log buat semula setiap kali ia dibaca dari cakera ke memori, kecekapannya sangat rendah
Jika tiada data dalam ingatan, anda pasti boleh mendapatkan data terkini yang betul dengan membacanya dari cakera tanpa perlu membandingkannya dengan log buat semulaProses penulisan binlog dan buat semula log - jaminan asas mekanisme WALKedua-dua binlog dan buat semula log membahagikan penulisan log kepada tiga proses: tulis cache, tulis dan segerakkanMySQL mengepam halaman kotor dan menulisnya ke cakera untuk memastikan halaman data selagi ia berada dalam ingatan. ia pastinya data terkini yang boleh dikembalikan
Semasa proses pelaksanaan urus niaga, log binlog dan buat semula akan ditulis pada cache yang diperuntukkan yang sepadan, supaya ia boleh ditulis pada cakera sekali gus apabila urus niaga diserahkan Ia akan dilakukan terlebih dahulu apabila transaksi dihantar. tulis menulis data ke cache halaman sistem pengendalian Pada masa ini, data sebenarnya belum ditulis ke fail, tetapi ia telah diserahkan kepada cache sistem operasi untuk disimpan proses ranap pada masa ini, bahagian data bertulis ini tidak akan hilang Benang kernel sistem pengendalian akan bertanggungjawab untuk menulis bahagian data cache ini ke cakera
Tetapi jika sistem pengendalian ranap, bahagian data ini akan hilang
log semula dikawal melalui innodb_flush_log_at_trx_commit
ditetapkan kepada 0, yang bermaksud setiap kali Apabila transaksi dilakukan, log buat semula hanya tinggal dalam cache log buat semula
Binlog dikawal oleh parameter sync_binlog
sync_binlog=0, ini bermakna setiap kali transaksi diserahkan, ia hanya menulis, bukan fsync
Mengapa penyerahan log dua peringkat diperlukan
berkaitan dengan mekanisme pengembalian log semula InnoDB tidak boleh digulung semula selepas transaksi diserahkan Jika binlog gagal ditulis selepas log buat semula diserahkan, dua ketidakkonsistenan akan berlaku
Jika pangkalan data dimulakan semula secara tidak normal pada masa ini, yang mana satu harus berdasarkan Perlu difikirkan tentang cara memulihkan data dalam berbilang salinan, jadi penyerahan log dua peringkat diperlukan
Andaikan pangkalan data ranap pada masa A, kerana binlog belum ditulis dan log buat semula belum diserahkan, jadi transaksi akan digulung semula selepas dimulakan semula, dan kedua-dua log masih berada dalam keadaan yang sama
Sekiranya tempoh masa Jika B, anda perlu menilai bendera komit bagi log buat semula ia terus
Jika buat semula Jika tiada bendera komit yang sepadan dengan transaksi dalam log, binlog akan diperiksa
Jika binlog telah lengkap dan mempunyai bendera komit, urus niaga akan diserahkan dan bendera komit akan ditambah selepas log buat semula Jika binlog Gulung semula transaksi jika tidak lengkap
Di sini. anda boleh mendapati bahawa ranap sistem berlaku dalam penyerahan log dua peringkat adalah berdasarkan binlog untuk pertimbangan standard Sebabnya adalah kerana replikasi induk-hamba adalah berdasarkan binlog perlu diperiksa, ia akan mengambil masa yang lebih lama untuk beralih ke perpustakaan hamba jika perpustakaan utama ditutup dengan menggunakan binlog sebagai penanda aras, jika perpustakaan utama ditutup, anda boleh terus menggunakan binlog untuk memulihkan data dari perpustakaan hamba itu, tidak perlu menyemak integriti log buat semula
Selain itu, binlog ialah log biasa untuk lapisan Mysql Server, itulah sebabnya binlog dipilih sebagai penanda aras
Kelemahan penyerahan log dua peringkatTetapi prestasi akan merosot apabila jumlah konkurensi adalah besar
Mekanisme penyerahan kumpulan
Peranan mekanisme penyerahan kumpulanApabila terdapat transaksi yang telah penyerahan melarikan diri, log berbilang transaksi digabungkan bersama untuk menulis, mengurangkan operasi IO cakera
Pelaksanaan mekanisme penyerahan kumpulanMekanisme penyerahan kumpulan membahagikan proses komit kepada tiga memproses, mengekalkan baris gilir untuk setiap proses dan menggunakan kunci untuk memastikan penulisan transaksi Urutan
Transaksi peneraju akan membawa semua urus niaga ke log buat semula Lakukan fsync tulis, iaitu tulis log buat semula ke cakera, dan lengkapkan fasa cadangan daripada log buat semula
Jika Mysql ranap pada peringkat ini, set transaksi ini akan dilancarkan semula selepas memulakan semula flush阶段
: Lakukan operasi fsync pada fail binlog (gabungkan binlog berbilang transaksi dan siram cakera bersama-sama)
Selepas menulis binlog ke fail binlog dalam peringkat siram, ia akan menunggu untuk tempoh masa sebelum mengepam cakera , tujuannya adalah untuk menggabungkan binlog daripada lebih banyak transaksi dan siram cakera bersama-sama untuk mengurangkan penggunaan
Akan ada had masa dan had transaksi maksimum untuk menunggu Jika salah satu syarat dipenuhi, binlog akan dipadamkan serta-merta
peringkat penyegerakan Terutamanya bertanggungjawab untuk penyerahan kumpulan binlog Jika Mysql ranap pada peringkat semasa, anda boleh terus melengkapkan penyerahan transaksi melalui rekod siram log semula selepas memulakan semula sync
Pembelajaran yang disyorkan:
Tutorial video mysqlAtas ialah kandungan terperinci Panduan komprehensif untuk log MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!