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

batal log balik log

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 gagal

Apakah 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 sepadan

Untuk perintah kemas kini / padam, buat asal log merekodkan data lama rekod yang diubah suai

Setiap 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 oleh

• Untuk dapat. elakkan masalah konkurensi apabila penunjuk log buat asal diubah suai, Mysql akan menambah kunci eksklusif pada penunjuk log buat asal sebelum pengubahsuaian untuk memastikan penulisan log buat asal yang betul . sebelum transaksi dimulakan. Apabila urus niaga diserahkan, log buat asal kehilangan fungsinya dan perlu dipadamkan
  Log buat asal diserahkan kepada utas Purage dalam Mysql untuk mengurusnya semak bendera deleted_bit dalam log buat asal secara berkala. Bendera ini akan ditetapkan kepada benar selepas transaksi dilakukan. log

Log buat semula ialah log fizikal Mysql, bertanggungjawab untuk merekodkan jenis operasi yang dilakukan pada halaman data tertentu

Peranan 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

Dalam InnoDB, log buat semula ialah kewujudan seperti baris gilir bersaiz tetap adalah dari kedudukan tulis pos di belakang Apabila data berterusan, titik semak digerakkan untuk membaca ke hadapan
• Sebab reka bentuk ini adalah kerana log buat semula wujud ke. mengelakkan data halaman kotor yang dicache daripada hilang selepas ranap Mysql
  Apabila data dalam Mysql disimpan ke cakera, ia adalah Log buat semula dalam bahagian kegigihan sebenarnya tidak berguna, dan ruang boleh dibuat untuk merakam baharu data

• Perbezaan antara buat asal log dan buat semula log

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

log arkib binlog

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

Jadi ia dipanggil Binlog ialah log arkib

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

MySQL mengepam halaman kotor dan menulisnya ke cakera untuk memastikan halaman data selagi ia berada dalam ingatan. ia pastinya data terkini yang boleh dikembalikan

Jika tiada data dalam ingatan, anda pasti boleh mendapatkan data terkini yang betul dengan membacanya dari cakera tanpa perlu membandingkannya dengan log buat semula

Proses penulisan binlog dan buat semula log - jaminan asas mekanisme WAL

Kedua-dua binlog dan buat semula log membahagikan penulisan log kepada tiga proses: tulis cache, tulis dan segerakkan

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

Akhir sekali, mysql secara manual memanggil penyegerakan untuk mengekalkan data yang ditulis dalam cache halaman ke cakera keras . Selepas penulisan selesai, data diteruskan dengan jayanya

• Langkah tulis dan penyegerakan terakhir mysql menyediakan parameter yang sepadan untuk mengawal strategi tulis

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

Risiko kerugian adalah yang paling besar
Apabila ditetapkan kepada 1, ia bermakna setiap Apabila setiap transaksi dilakukan, log buat semula terus dikekalkan ke cakera

Risiko kerugian adalah minimum, tetapi penggunaan IO adalah besar
Apabila ditetapkan kepada 2 , yang bermaksud setiap kali transaksi dilakukan, buat semula log hanya ditulis pada cache halaman

Pendudukan IO dipusatkan, dan proses penulisan yang paling banyak menggunakan IO pada cakera diserahkan kepada sistem pengendalian

• Binlog dikawal oleh parameter sync_binlog

sync_binlog=0, ini bermakna setiap kali transaksi diserahkan, ia hanya menulis, bukan fsync

sync_binlog=1 bermaksud bahawa fsync akan dilaksanakan setiap kali transaksi diserahkan, tetapi Selepas mengumpul N transaksi, fsync
Penyerahan log dua fasa

• Apakah itu penyerahan log dua fasa

Proses penyerahan semula log dibahagikan kepada dua peringkat: sediakan dan komit penyerahan log Binlog berada di tengah-tengah dua peringkat ini

Apabila transaksi diserahkan, log buat semula diserahkan dahulu dan kemudian memasuki keadaan sediakan Kemudian selepas penyerahan binlog selesai, log buat semula boleh menukar status log untuk komit diserahkan

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 peringkat

Bilangan IO cakera adalah tinggi
Apabila menyerahkan log, akan ada menjadi operasi siram sepadan dengan buat semula log dan binlog, dan bilangan IO adalah tinggi

Persaingan sengit untuk kunci
Untuk memastikan bahawa apabila berbilang urus niaga diserahkan, rekod log dan perintah penyerahan transaksi adalah konsisten, kunci akan digunakan Untuk memastikan susunan relatif penyerahan log

Tetapi prestasi akan merosot apabila jumlah konkurensi adalah besar

Mekanisme penyerahan kumpulan

Peranan mekanisme penyerahan kumpulan

Apabila terdapat transaksi yang telah penyerahan melarikan diri, log berbilang transaksi digabungkan bersama untuk menulis, mengurangkan operasi IO cakera

Pelaksanaan mekanisme penyerahan kumpulan

Mekanisme penyerahan kumpulan membahagikan proses komit kepada tiga memproses, mengekalkan baris gilir untuk setiap proses dan menggunakan kunci untuk memastikan penulisan transaksi Urutan

dibahagikan kepada tiga peringkat dan mengunci secara berasingan boleh mengurangkan butiran kunci, tanpa mengunci keseluruhan proses penyerahan daripada urus niaga
Apabila baris gilir kosong Pada masa itu, urus niaga pertama yang memasuki baris gilir akan menjadi peneraju urus niaga seterusnya, yang membawa urus niaga berikutnya untuk melengkapkan peringkat operasi seterusnya

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阶段

fasa 2:

: 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

kerana binlog. telah menyelesaikan penyerahan pada masa ini, anda boleh terus menyerahkan transaksi berdasarkan log buat semula
Fasa 3:
: Lakukan operasi komit InnoDB pada setiap transaksi

• Pembelajaran yang disyorkan:

  Tutorial video mysql

Atas ialah kandungan terperinci Panduan komprehensif untuk log MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!