Apakah perbezaan antara redo log dan binlog dalam mysql

Saya ingin bercakap dengan anda tentang dua mata pengetahuan kecil dalam mysql: redo log 和 binlog .

redo log: Log lapisan enjin storan InnoDB, jadi jika enjin storan yang anda gunakan bukan InnoDB, tiada log buat semula sama sekali.

binlog: Log direkodkan oleh lapisan MySQL Server, jadi tidak kira apa enjin storan yang digunakan, selagi MySQL, akan ada binlog Apabila melakukan replikasi master-slave MySQL, yang binlog digunakan.

Seterusnya, mari kita lihat dengan lebih dekat apa yang mereka lakukan?

buat semula log

Mengapa kita memerlukan fail log buat semula ini?

Di sini, kami boleh memberikan contoh Sekarang kami ingin mengubah suai data dalam pangkalan data Sekarang, kenyataan kemas kini disertakan dengan operasi pertanyaan data ini, dan kemudian lakukan operasi kemas kini, bukan?

Jika jumlah data agak kecil, tidak mengapa dan ia boleh ditemui dan dikemas kini dengan cepat tetapi bagaimana jika jumlah data agak besar, dengan 100 juta keping data di dalamnya? Lebih-lebih lagi, operasi kemas kini mesti ditulis ke cakera, jadi apakah kos IO di tengah?

Bagaimana jika saya mempunyai berpuluh-puluh kenyataan kemas kini yang dikemas kini satu demi satu? Jika anda memikirkannya dengan cara ini, anda boleh bayangkan bahawa kos operasi ini adalah sangat tinggi Jadi bolehkah kos ini dikurangkan?

Pada masa ini, buat semula log mula dimainkan. Apabila rekod dikemas kini, enjin InnoDB akan terlebih dahulu menulis rekod ke log buat semula dan mengemas kini memori pada masa yang sama, supaya data berjaya dikemas kini.

Tetapi pada masa ini, ia belum dikemas kini ke cakera, bukan? Jangan risau, InnoDB akan mengemas kini rekod ini ke cakera pada masa yang sesuai.

Idea atau teknologi sedemikian mempunyai nama yang betul: Teknologi WAL, juga dikenali sebagai WriteAheadLogging, terasnya ialah menulis log dahulu dan kemudian menulis ke cakera.

Tidak boleh buat semula log terus menulis?

Saiz log buat semula ditetapkan, dan kandungan sebelumnya akan ditimpa Setelah penuh, penyegerakan log buat semula ke cakera akan dicetuskan untuk memberi ruang untuk merekodkan pengubahsuaian seterusnya. .

Jika pangkalan data tidak berfungsi atau dimulakan semula, data tidak akan hilang.

Oleh kerana log buat semula, rekod yang diserahkan sebelum ini masih ada. Anda hanya perlu memulihkannya dengan sewajarnya berdasarkan rekod dalam log buat semula.

binlog

binlog ialah log rakaman lapisan Pelayan MySQL.

Perbezaan antara log buat semula dan binlog:

• log buat semula adalah unik kepada enjin InnoDB binlog dilaksanakan oleh lapisan Pelayan MySQL dan tersedia untuk semua enjin .

• Log buat semula ialah log fizikal, yang merekodkan "Pengubahsuaian XXX telah dibuat pada halaman XXX"; baris dengan id = 2" ".

• Log buat semula mempunyai saiz tetap, jadi ruangnya akan habis Jika ia habis, anda mesti melakukan beberapa operasi menulis pada cakera sebelum anda boleh meneruskan binlog boleh ditambah Penulisan, iaitu, binlog tidak mempunyai konsep ruang, teruskan menulis.

binlog merekodkan semua pernyataan DDL dan DML dalam bentuk peristiwa (kerana ia merekodkan operasi dan bukannya nilai data, ia adalah log logik) dan boleh digunakan sebagai replikasi Daripada utama dan pemulihan data.

Apabila fungsi binlog dihidupkan, kami boleh mengeksport binlog ke dalam pernyataan SQL dan memainkan semula semua operasi untuk mencapai pemulihan data.

Selepas memiliki dua log ini, mari kita lihat bagaimana pernyataan kemas kini dilaksanakan (buat semula tidak boleh ditulis sekali gus):

Contohnya, pernyataan:

update user set name='小马' where id=1;

• Soal data ini dahulu, dan jika terdapat cache, cache juga akan digunakan.

• Tukar nama kepada

  , kemudian panggil antara muka API enjin, tulis baris data ini pada memori dan rekod log buat semula pada masa yang sama. Pada masa ini, log buat semula memasuki keadaan sediakan, dan kemudian memberitahu pelaksana bahawa pelaksanaan telah selesai dan boleh diserahkan pada bila-bila masa. 小马

• Selepas menerima pemberitahuan, pelaksana merekodkan binlog, kemudian memanggil antara muka enjin storan dan menetapkan log buat semula kepada keadaan komit.

• Kemas kini selesai.

Anda boleh mendapati bahawa log buat semula berada dalam keadaan sediakan dahulu, dan selepas binlog selesai, ia berada dalam keadaan komit Kaedah ini dipanggil "dua-. komitmen fasa". Kenapa jadi begini?

Kedua-dua log buat semula dan binlog boleh digunakan untuk mewakili status komit transaksi dan

adalah untuk memastikan kedua-dua keadaan ini konsisten secara logik. 两阶段提交

Anda boleh menganggap bahawa jika anda tidak menggunakan kaedah ini, tetapi tulis semula log dahulu dan kemudian binlog, apakah yang akan berlaku? Jika pengecualian berlaku semasa menulis binlog dan operasi kemas kini telah dijalankan dalam log buat semula, tetapi binlog tidak dikemas kini pada masa ini, adakah terdapat ketidakkonsistenan data?

Begitu juga dengan menulis binlog dahulu dan kemudian buat semula log. Oleh itu, apabila menulis, mula-mula letakkan semula log dalam keadaan sediakan, dan selepas binlog selesai menulis, letakkan semula log dalam keadaan komit, dengan itu mengekalkan konsistensi logik.

Atas ialah kandungan terperinci Apakah perbezaan antara redo log dan binlog dalam mysql. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!