Kuasai sepenuhnya tiga log utama MySQL: binlog, buat semula log dan buat asal log-tutorial mysql-php.cn

Artikel ini membawakan anda pengetahuan yang berkaitan tentang log mysql Apa yang perlu kita fokuskan ialah log binari (binlog) dan log transaksi (termasuk log buat semula dan buat asalkan log).

Kuasai sepenuhnya tiga log utama MySQL: binlog, buat semula log dan buat asal log

1. binlog

binlog digunakan untuk merekodkan operasi tulis (tidak termasuk pertanyaan) maklumat yang dilaksanakan oleh pangkalan data dan disimpan dalam bentuk binari dalam cakera itu. Binlog ialah log logik mysql dan direkodkan oleh lapisan pelayan pangkalan data Mysql menggunakan mana-mana enjin storan akan merekodkan log binlog.

Log logik: boleh difahami secara ringkas sebagai pernyataan sql;
Log fizikal: Data dalam MySQL disimpan dalam halaman data, dan log fizikal merekodkan apa yang ada pada halaman data. Masukkan coretan kod di sini

Binlog ditulis dengan menambahkannya dijana Fail baharu untuk menyimpan log.

senario penggunaan binlog
Projek Dalam aplikasi sebenar, terdapat dua senario penggunaan utama binlog, iaitu replikasi master-slave dan pemulihan data.

Replikasi Master-slave: Dayakan binlog pada bahagian Master, dan kemudian hantar binlog ke setiap bahagian Slave Bahagian Slave memainkan semula binlog untuk mencapai konsistensi data master-slave.
Pemulihan data: Pulihkan data dengan menggunakan alat mysqlbinlog.

Prinsip penyegerakan master-slave MySQL
Kuasai sepenuhnya tiga log utama MySQL: binlog, buat semula log dan buat asal log

Benang pembuangan binlog nod induk
Apabila hamba nod disambungkan Apabila nod induk digunakan, nod induk akan mencipta benang dump log untuk menghantar kandungan binlog. Apabila membaca operasi dalam binlog, utas ini akan mengunci binlog pada nod induk Apabila bacaan selesai, kunci akan dilepaskan walaupun sebelum ia dihantar ke nod hamba Benang
Benang SQL nod hamba
prinsip penyegerakan master-slave pangkalan data MySQL

kandungan binlog

Sebagai disebutkan di atas, binlog ialah Log logik boleh difahami secara ringkas sebagai pernyataan SQL, tetapi sebenarnya ia juga mengandungi logik terbalik pernyataan SQL yang dilaksanakan. padam sepadan dengan memadam sendiri dan maklumat sisipan terbalik mengandungi maklumat tentang baris data sebelum dan selepas kemas kini yang sepadan dilaksanakan mengandungi sisipannya sendiri dan maklumat pemadaman yang sepadan.

format binlog

Terdapat tiga format binlog iaitu penyata, baris dan campuran. Sebelum MySQL 5.7.7, pernyataan telah digunakan secara lalai, dan selepas MySQL 5.7.7, baris digunakan secara lalai. Format log boleh diubah suai melalui binlog-format dalam fail konfigurasi my.ini. (1) Pernyataan: Replikasi berasaskan penyata (SBR), setiap pernyataan SQL yang mengubah suai data akan direkodkan dalam binlog.

Kelebihan: Tidak perlu merekod perubahan secara khusus dalam baris tertentu, menjimatkan ruang, mengurangkan IO dan meningkatkan prestasi

Keburukan: Apabila melakukan operasi seperti sysdate() atau sleep; () , yang boleh menyebabkan ketidakkonsistenan antara data induk dan hamba;
(2) baris: replikasi berasaskan baris (RBR), yang tidak merekodkan maklumat berkaitan konteks pernyataan SQL, tetapi merekodkan yang Butiran rekod yang diubah suai.

Kelebihan: Butiran setiap pengubahsuaian rekod baris direkodkan dengan sangat terperinci, jadi tidak akan ada situasi di mana data tidak boleh disalin dengan betul

Kelemahan: Setiap baris direkodkan secara terperinci Rekod butiran pengubahsuaian, yang akan menghasilkan banyak kandungan log. Andaikan terdapat kenyataan kemas kini dan banyak rekod diubah suai Setiap rekod yang diubah suai akan direkodkan dalam binlog. Khususnya, untuk pengendalian alter table, disebabkan oleh perubahan dalam struktur jadual, setiap baris rekod akan berubah, menyebabkan peningkatan mendadak dalam volum log; di atas, pernyataan dan baris Setiap mempunyai kelebihan dan kekurangannya sendiri, jadi versi campuran muncul untuk mencampurkan kedua-duanya. Dalam keadaan biasa, format penyata digunakan untuk menyimpan Apabila penyata tidak dapat diselesaikan, tukar kepada format baris untuk menyimpan.

Masa siram Binlog

Untuk enjin storan InnoDB, binlog hanya akan direkodkan apabila transaksi diserahkan Pada masa ini, rekod masih dalam ingatan , dan MySQL lulus sync_binlog mengawal masa pembilasan binlog Julat nilai ialah 0-N:

0: Tiada curahan paksa ke cakera, sistem akan menentukan masa untuk menulis ke cakera; Binlog akan ditulis ke cakera untuk setiap urus niaga N;
Seperti yang dapat dilihat dari di atas, tetapan paling selamat untuk sync_binlog ialah 1, yang juga merupakan versi selepas MySQL 5.7.7 nilai lalai. Walau bagaimanapun, menetapkan nilai yang lebih besar boleh meningkatkan prestasi pangkalan data Oleh itu, dalam situasi sebenar, anda juga boleh meningkatkan nilai dengan sewajarnya dan mengorbankan tahap ketekalan tertentu untuk mendapatkan prestasi yang lebih baik.

Saiz fail fizikal binlog

Dalam fail konfigurasi my.ini, saiz binlog boleh dikonfigurasikan melalui max_binlog_size. Apabila volum log melebihi saiz fail binlog, sistem akan menjana semula fail baharu untuk terus menyimpan fail. Apakah yang perlu saya lakukan apabila transaksi agak besar, atau apabila terdapat lebih banyak log, dan ruang fizikal yang didudukinya terlalu besar? MySQL menyediakan mekanisme pemadaman automatik, yang boleh diselesaikan dengan mengkonfigurasi parameter expire_logs_days dalam fail konfigurasi my.ini Unit ialah hari. Apabila parameter ini ialah 0, ia bermakna ia tidak akan dipadamkan apabila ia adalah N, ia bermakna ia akan dipadamkan secara automatik selepas hari ke-N. 2. buat semula log

redolog ialah sistem log proprietari enjin InnoDB. Ia digunakan terutamanya untuk mencapai ketahanan transaksi dan fungsi selamat ranap. Redolog ialah log fizikal, yang merekodkan pengubahsuaian khusus pada halaman data selepas pernyataan SQL dilaksanakan.

Kita semua tahu bahawa apabila MySQL sedang berjalan, data akan dimuatkan dari cakera ke dalam memori. Apabila pernyataan SQL dilaksanakan untuk mengubah suai data, kandungan yang diubah suai sebenarnya hanya disimpan sementara dalam memori Jika kuasa terputus atau situasi lain berlaku pada masa ini, pengubahsuaian ini akan hilang. Oleh itu, selepas mengubah suai data, MySQL akan mencari peluang untuk membuang rekod memori ini kembali ke cakera. Tetapi terdapat masalah prestasi, terutamanya dalam dua aspek:

InnoDB berinteraksi dengan cakera dalam unit data halaman dan transaksi hanya boleh mengubah suai beberapa bait pada halaman , jika halaman data yang lengkap disiram kembali ke cakera, sumber dibazirkan;

Oleh itu, MySQL mereka bentuk redolog untuk merekodkan pengubahsuaian khusus yang dibuat pada halaman data oleh transaksi, dan kemudian siram redolog kembali ke cakera. Anda mungkin mempunyai keraguan Pada asalnya, saya mahu mengurangkan io. Pereka bentuk InnoDB telah mengambil kira perkara ini pada permulaan reka bentuk. Fail Redolog biasanya agak kecil, dan proses flash kembali ke cakera adalah IO berjujukan, yang mempunyai prestasi yang lebih baik daripada IO rawak.

Konsep asas buat semula log

Redolog terdiri daripada dua bahagian, satu ialah penimbal log semula cache log dalam ingatan, dan satu lagi ialah fail log buat semula dalam cakera. Setiap kali rekod data diubah suai, pengubahsuaian ini akan ditulis kepada penimbal log buat semula terlebih dahulu, dan kemudian tunggu peluang yang sesuai untuk mengepam semula pengubahsuaian dalam ingatan kepada fail log buat semula. Teknologi menulis log dahulu dan kemudian menulis ke cakera ialah teknologi WAL (Write-Ahead Logging). Perlu diingatkan bahawa redolog disiram kembali ke cakera sebelum halaman data Pengubahsuaian pada indeks berkelompok, indeks sekunder dan halaman buat asal semua perlu direkodkan dalam redolog.

Dalam sistem pengendalian komputer, data penimbal dalam ruang pengguna secara amnya tidak boleh ditulis terus ke cakera, dan mesti melalui penimbal ruang kernel sistem pengendalian (OS Buffer ). Oleh itu, menulis penimbal log buat semula ke fail log buat semula sebenarnya menulisnya ke Penampan OS terlebih dahulu, dan kemudian mengepamnya ke fail log buat semula melalui panggilan sistem fsync().

sokongan mysql Tiga pemasaan untuk menulis penimbal log buat semula kepada fail log semula boleh dikonfigurasikan melalui parameter innodb_flush_log_at_trx_commit Maksud setiap nilai parameter adalah seperti berikut:

format rakaman semula log
Redolog menggunakan saiz tetap dan format penulisan kitaran Apabila redolog penuh, ia akan ditulis dari awal lagi. Mengapa ia direka seperti ini?
Tujuan utama buat semula log adalah untuk mengurangkan keperluan untuk pembilasan halaman data. Redolog merekodkan pengubahsuaian pada halaman data, tetapi apabila halaman data juga dipadamkan kembali ke cakera, rekod ini menjadi tidak berguna. Oleh itu, apabila MySQL menentukan bahawa redolog sebelumnya telah kehilangan kesannya, data baharu akan menimpa data yang tidak sah. Jadi bagaimana untuk menilai sama ada ia perlu dilindungi?

Gambar di atas ialah gambarajah skematik fail log buat semula pos mewakili nombor jujukan log LSN (nombor jujukan log) yang direkodkan oleh redolog. Apabila halaman data telah disiram kembali ke cakera, LSN dalam fail log buat semula akan dikemas kini, menunjukkan bahawa data sebelum LSN ini telah ditulis ke cakera LSN ini adalah titik semak. Bahagian antara pos tulis dan titik semak ialah bahagian ganti redolog, yang digunakan untuk merekodkan rekod baharu, bahagian antara titik semak dan pos tulis ialah bahagian halaman data yang diubah suai yang telah direkodkan oleh redolog, tetapi halaman data; belum disiram kembali ke cakera pada masa ini. Apabila pos tulis mengejar titik semak, ia akan terlebih dahulu menolak titik semak ke hadapan, mengosongkan kedudukan, dan kemudian merekodkan log baharu.

Apabila memulakan innodb, tidak kira sama ada ia ditutup secara normal atau luar biasa kali terakhir, operasi pemulihan akan sentiasa dilakukan. Semasa pemulihan, LSN dalam halaman data akan disemak terlebih dahulu Jika LSN ini lebih kecil daripada LSN dalam redolog, iaitu kedudukan tulis pos, bermakna operasi yang belum selesai pada halaman data direkodkan dalam redolog, dan kemudian ia akan bermula dari pusat semak terdekat , mula menyegerakkan data.

Adakah mungkin LSN dalam halaman data lebih besar daripada LSN dalam redolog? Jawapannya sudah tentu boleh. Apabila ini berlaku, bahagian di luar redolog tidak akan dibuat semula, kerana ini sendiri bermakna apa yang telah dilakukan tidak perlu dibuat semula.
Perbezaan antara buat semula log dan binlog

redo log binlog

文件大小 redo log的大小是固定的。 binlog可通过配置参数max_binlog_size设置每个binlog文件的大小。

实现方式 redo log是InnoDB引擎层实现的，并不是所有引擎都有。 binlog是Server层实现的，所有引擎都可以使用 binlog日志

记录方式 redo log 采用循环写的方式记录，当写到结尾时，会回到开头循环写日志。 binlog 通过追加的方式记录，当文件大小大于给定值后，后续的日志会记录到新的文件上

适用场景 redo log适用于崩溃恢复(crash-safe) binlog适用于主从复制和数据恢复

buat semula log th> binlog

Saiz fail Saiz log buat semula ditetapkan. Binlog boleh menetapkan saiz setiap fail binlog melalui parameter konfigurasi max_binlog_size.

Kaedah pelaksanaan Log buat semula dilaksanakan oleh lapisan enjin InnoDB dan tidak semua enjin memilikinya. Binlog dilaksanakan oleh lapisan Pelayan dan semua enjin boleh menggunakan log binlog

Kaedah rakaman Log buat semula ditulis dalam gelung Apabila menulis hingga akhir, ia akan kembali ke permulaan untuk menulis log dalam gelung. Binlog direkodkan dengan menambahkan Apabila saiz fail lebih besar daripada nilai yang diberikan, log berikutnya akan direkodkan ke fail baharu

Senario yang berkenaan / td> log buat semula sesuai untuk pemulihan ranap (crash-safe) binlog sesuai untuk replikasi master-slave dan pemulihan data

Ia boleh dilihat daripada perbezaan antara binlog dan log semula: log binlog hanya digunakan untuk pengarkiban, dan hanya bergantung pada binlog tidak mempunyai keupayaan selamat ranap. Tetapi hanya buat semula log tidak akan berfungsi, kerana buat semula log adalah unik untuk InnoDB, dan rekod dalam log akan ditimpa selepas ditulis ke cakera. Oleh itu, kedua-dua binlog dan log semula perlu direkodkan pada masa yang sama untuk memastikan bahawa data tidak akan hilang apabila pangkalan data ditutup dan dimulakan semula.
Penyerahan dua peringkat
Di atas secara ringkas memperkenalkan redolog dan binlog Apabila mengubah suai data, mereka akan menyimpan pengubahsuaian ini, tetapi satu log fizikal dan satu lagi log logik. Jadi bagaimana mereka melakukan proses pengubahsuaian?

Andaikan terdapat kenyataan kemas kini yang akan dilaksanakan sekarang, kemas kini daripada table_name set c=c 1 di mana id=2, proses pelaksanaan adalah seperti berikut:

Mula-mula cari rekod dengan id=2 ;

Pelaksana mendapat data baris yang diberikan oleh enjin, menambah 1 pada nilai ini untuk mendapatkan baris data baharu, dan kemudian memanggil antara muka enjin untuk menulis baris data baharu ini

Enjin akan Data baharu dikemas kini ke dalam memori, dan operasi kemas kini direkodkan dalam redolog Pada masa ini, redolog berada dalam keadaan sediakan. Kemudian pelaksana dimaklumkan bahawa pelaksanaan telah selesai dan transaksi boleh diserahkan pada bila-bila masa

Pelaksana menjana binlog operasi ini dan menulis binlog ke cakera

Pelaksana memanggil antara muka transaksi komit enjin, dan enjin Tukar log buat semula yang baru ditulis kepada keadaan komit, dan kemas kini selesai; 🎜> Ini membahagikan penulisan redolog Proses penyediaan dan komit dipanggil komit dua fasa.

Kedua-dua redolog dan binlog boleh digunakan untuk mewakili status komit transaksi, dan komit dua fasa adalah untuk memastikan kedua-dua keadaan konsisten secara logik. Jika anda tidak menggunakan komit dua fasa, tetapi tulis satu dahulu dan kemudian yang lain, ia mungkin menyebabkan beberapa masalah.

Pada masa ini, kemas kini masih digunakan sebagai contoh. Andaikan bahawa id semasa=2 dan terdapat medan c=0 masing-masing Analisis situasi berikut:
Tulis redolog dahulu dan kemudian binlog

Anggapkan redolog ditulis dahulu selesai, tetapi binlog masih belum ditulis Apabila saya selesai menulis, MySQL tiba-tiba menemui pengecualian dan dimulakan semula. Oleh kerana redolog telah ditulis sebelum ini, rekod yang diubah suai masih wujud selepas sistem dimulakan semula, jadi nilai c dalam baris ini selepas pemulihan ialah 1. Walau bagaimanapun, disebabkan sistem mula semula, rekod ini tidak wujud dalam binlog. Apabila membuat sandaran log kemudian, kenyataan ini tidak wujud dalam binlog yang disimpan. Kemudian anda akan mendapati bahawa jika anda perlu menggunakan binlog ini untuk memulihkan perpustakaan sementara, kerana binlog pernyataan ini hilang, perpustakaan sementara tidak akan dikemas kini kali ini Nilai c dalam baris yang dipulihkan ialah 0, iaitu sama dengan nilai perpustakaan asal yang berbeza.

Tulis binlog dahulu dan kemudian redolog
Jika anda menulis binlog dahulu dan kemudian mulakan semula sistem semasa menulis redolog. Selepas dimulakan semula, tiada rekod pengubahsuaian c dalam redolog, dan nilai c masih 0 pada masa ini. Tetapi log "Tukar c dari 0 kepada 1" telah direkodkan dalam binlog. Oleh itu, apabila binlog digunakan untuk memulihkan kemudian, satu lagi transaksi akan keluar Nilai c dalam baris yang dipulihkan ialah 1, yang berbeza daripada nilai dalam pangkalan data asal.
Oleh itu, secara ringkasnya, jika log ditulis dahulu dan kemudian log lain ditulis, status pangkalan data akan tidak konsisten dengan status perpustakaan yang dipulihkan menggunakan binlog.
3. batal log
undolog digunakan terutamanya untuk merekodkan status sebelum rekod baris tertentu diubah suai dan merekodkan data sebelum pengubahsuaian. Dalam kes ini, apabila urus niaga digulung semula, rekod boleh dipulihkan kepada keadaan sebelum urus niaga dimulakan melalui undolog. Keatomisan dan ketahanan urus niaga juga dicapai dengan undolog. Log buat asal merekodkan perubahan logik data Sebagai contoh, penyataan INSERT sepadan dengan log buat asal PADAM Untuk setiap penyataan KEMASKINI, ia sepadan dengan log buat asal UPDATE yang bertentangan, supaya apabila ralat berlaku, ia boleh digulung. kembali ke status data sebelum transaksi. Pada masa yang sama, apabila melakukan pemulihan data, ia digunakan bersama dengan binlog dan redolog untuk memastikan ketepatan pemulihan data.

Proses fungsi log buat asal adalah seperti berikut:

Tulis versi pra-ubah suai pada log buat asal sebelum transaksi bermula; 🎜 > Mula membuat pengubahsuaian dan simpan data yang diubah suai ke memori;

Perlu diambil perhatian bahawa, seperti redolog, undolog mesti disalurkan kembali ke cakera sebelum halaman data. Apabila memulihkan data, jika undolog selesai, transaksi boleh ditarik balik berdasarkan undolog.

Dalam transaksi, sekeping data yang sama mungkin diubah suai beberapa kali, jadi adakah rekod sebelum setiap pengubahsuaian perlu direkodkan dalam undolog? Dalam kes ini, jumlah log undolog akan menjadi terlalu besar dan redolog akan mula dimainkan pada masa ini. Dalam transaksi, jika rekod yang sama diubah suai, undolog hanya akan merekodkan rekod asal sebelum urus niaga dimulakan Apabila rekod ini diubah suai semula, redolog akan merekodkan perubahan seterusnya. Semasa pemulihan data, redolog melengkapkan rollforward dan undolog melengkapkan rollback Kedua-duanya menyelaras antara satu sama lain untuk menyelesaikan pemulihan data. Prosesnya adalah seperti berikut:

Fungsi lain ialah rantai kawalan berbilang versi MVCC Sila rujuk artikel ini
Prinsip pelaksanaan MySQL MVCC

binlog, redolog dan Undolog ialah. tiga log paling penting dalam MySQL Semasa pemulihan data, ketiga-tiganya menyelaras dan bekerjasama untuk memastikan ketepatan pemulihan data.

Pembelajaran yang disyorkan: tutorial video mysql

Atas ialah kandungan terperinci Kuasai sepenuhnya tiga log utama MySQL: binlog, buat semula log dan buat asal log. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!