Cara menggunakan binlog MySQL, buat semula log dan buat asal log

1. binlog

Binlog digunakan untuk merekodkan maklumat tentang operasi tulis yang dilakukan dalam pangkalan data. Ia tidak termasuk operasi pertanyaan dan disimpan pada cakera dalam format binari. 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. Rekod log fizikal berubah pada halaman data; masukkan bahagian kod di sini

binlog ditulis dengan menambahkan, dan saiz setiap fail binlog boleh ditetapkan melalui parameter max_binlog_size , apabila saiz fail mencapai nilai yang diberikan, fail baharu akan dijana 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 induk-hamba MySQL

• Benang dump binlog nod induk
  Apabila nod hamba bersambung ke nod induk, 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 I/O nod hamba

  Apabila perintah hamba mula dilaksanakan pada nod hamba, nod hamba akan mencipta benang I/O untuk menyambung ke nod induk dan meminta binlog yang dikemas kini dalam pustaka induk. Selepas benang I/O menerima kemas kini daripada proses pembuangan binlog nod induk, ia menyimpannya dalam log geganti setempat

• 
  Benang SQL nod hamba

  Benang SQL bertanggungjawab untuk; membaca relaylog Kandungan dihuraikan ke dalam operasi khusus dan dilaksanakan untuk memastikan konsistensi data master-slave
prinsip penyegerakan master-slave pangkalan data MySQL

• 
  
  

  kandungan binlog;

Seperti yang dinyatakan di atas, binlog ialah log logik, yang 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: Bila melaksanakan sysdate( ) atau sleep() dan operasi lain, ia mungkin membawa kepada ketidakkonsistenan antara data induk dan hamba; tidak merekodkan maklumat berkaitan konteks pernyataan sql, tetapi merekodkan 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 : Memandangkan butiran setiap pengubahsuaian rekod akan direkodkan dengan sangat terperinci, sejumlah besar kandungan log akan dijana. 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 perubahan dalam struktur jadual, setiap baris rekod akan berubah, mengakibatkan peningkatan mendadak dalam volum log; : Mengikut apa yang diperkatakan di atas, Statement dan row masing-masing mempunyai kelebihan dan kekurangan masing-masing, 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.
Khususnya, seperti yang dinyatakan di atas, versi baharu (selepas MySQL 5.7.7) menggunakan format baris secara lalai Baris di sini juga telah dioptimumkan dengan sewajarnya Apabila menghadapi operasi jadual ubah, format pernyataan digunakan untuk rakaman . Selebihnya Operasi masih menggunakan format baris.

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 memutuskan bila hendak menulis ke cakera

  • 1: Binlog mesti ditulis selepas setiap penyerahan Tulis ke; cakera;

  • N: Binlog akan ditulis ke cakera untuk setiap transaksi N; untuk sync_binlog ialah 1, yang juga merupakan nilai lalai untuk versi MySQL selepas 5.7.7. 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

  Anda boleh mengawal saiz binlog dengan mengkonfigurasi parameter max_binlog_size, yang terletak dalam fail konfigurasi my.ini. Sistem akan mencipta fail baharu untuk terus menyimpan log apabila saiz log melebihi had kapasiti fail binlog. Apakah yang perlu saya lakukan apabila transaksi agak besar, atau apabila terdapat lebih banyak log, dan ruang fizikal yang diduduki pada masa ini 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 kegigihan transaksi dan melaksanakan 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 keadaan 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 ingin mengurangkan io. Pereka bentuk InnoDB telah mengambil kira perkara ini pada permulaan reka bentuk. Buat semula fail log biasanya kecil, dan I/O berurutan digunakan semasa pemadaman cakera. Prestasi yang lebih baik berbanding dengan I/O rawak.
  

  Konsep asas log buat semula

  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 memori ke 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 log binlog dan redo perlu direkodkan pada masa yang sama untuk memastikan bahawa apabila pangkalan data dimatikan dan dimulakan semula, data tidak akan hilang.
  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 id= 2 rekod ini;

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

  • Enjin mengemas kini baris data baharu ini ke dalam memori dan merekodkan operasi kemas kini ke dalam redolog Pada masa ini, redolog sedang dalam persediaan negeri. Kemudian maklumkan kepada pelaksana bahawa pelaksanaan telah selesai dan transaksi boleh diserahkan pada bila-bila masa;

  • Pelaksana memanggil antara muka transaksi komit enjin, dan enjin menukar log buat semula yang baru ditulis kepada keadaan komit, dan kemas kini selesai; Gambarajah skematik adalah seperti berikut:

  Proses pembahagian penulisan redolog ini kepada dua langkah: sediakan 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, pernyataan 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. Gunakan undolog untuk memulihkan rekod kepada keadaan sebelum urus niaga dimulakan apabila urus niaga digulung semula. 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. Semasa proses pemulihan data, gabungan binlog dan redolog dapat memastikan ketepatan pemulihan data. Proses fungsi log buat asal adalah seperti berikut:
  

  Tulis versi pra-ubah suai pada log buat asal sebelum transaksi bermula; 🎜 >

  Mulakan pengubahsuaian dan simpan data yang diubah suai ke memori
  

  Teruskan undolog ke cakera; >
  • Flash halaman data kembali ke cakera;

  • Transaksi penyerahan; halaman kembali ke cakera. Jika undolog selesai, maklumat yang direkodkan di dalamnya boleh digunakan untuk melancarkan transaksi untuk memulihkan data.

    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 proses pemulihan data, pemulihan data dilengkapkan dengan menyelaraskan fungsi redolog dan undolog, dan operasi rolling ke hadapan dan rollback. Prosesnya adalah seperti berikut:
    
    

Atas ialah kandungan terperinci Cara menggunakan binlog MySQL, buat semula log dan buat asal log. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!