Apakah perbezaan antara binlog/redolog/undolog dalam MySQL?

Apakah perbezaan antara MySQL binlog/redolog/undolog?

Saya ingin bercakap dengan anda tentang mekanisme penguncian dalam InnoDB, jadi ia pasti akan melibatkan sistem log MySQL, binlog, buat semula log, buat asal log, dll. Saya melihat tiga log ini diringkaskan oleh beberapa rakan Tidak buruk, cepat dan kongsi dengan rakan anda.

Log ialah bahagian penting dalam pangkalan data mysql, merekodkan pelbagai maklumat status semasa operasi pangkalan data. mysqlLog terutamanya termasuk log ralat, log pertanyaan, log pertanyaan perlahan, log transaksi dan log binari.

Sebagai pembangun, perkara yang perlu kita fokuskan ialah log binari (binlog) dan log transaksi (termasuk redo log dan undo log Artikel ini akan memperkenalkan ketiga-tiga log ini secara terperinci seterusnya).

log bin

binlog digunakan untuk merekodkan operasi tulis (tidak termasuk pertanyaan) maklumat yang dilakukan oleh pangkalan data dan disimpan pada cakera dalam bentuk binari. binlog ialah log logik mysql dan direkodkan oleh lapisan Server Pangkalan data mysql menggunakan mana-mana enjin storan akan merekodkan binlog log.

• Log logik: Dapat difahami bahawa apa yang direkodkan ialah pernyataan sql

• Log fizikal: mysqlData akhirnya. disimpan dalam halaman data Ya, log fizikal merekodkan perubahan halaman data.

binlog ditulis dengan menambahkan Anda boleh menetapkan saiz setiap fail max_binlog_size melalui parameter binlog Apabila saiz fail mencapai nilai yang diberikan, Fail baharu akan dijana untuk menyimpan log.

Dalam aplikasi sebenar, terdapat dua senario penggunaan utama binlog, iaitu replikasi tuan-hamba dan pemulihan data.

• Replikasi tuan-hamba: Hidupkan Master pada hujung binlog, kemudian hantar binlog ke setiap hujung Slave dan Slave tayangan semula hujung binlog untuk mencapai Data tuan-hamba adalah konsisten.

• Pemulihan Data: Pulihkan data dengan menggunakan alat mysqlbinlog.

Masa siram Binlog

Untuk enjin storan InnoDB, ia hanya akan direkodkan apabila transaksi dilakukan biglog, dan rekod masih dalam ingatan pada masa ini , kemudian bilakah biglog dipadamkan ke cakera?

mysqlKawal pemasaan memberus sync_binlog melalui parameter biglog Julat nilai ialah 0-N:

• 0: Tiada keperluan wajib. Sistem menentukan masa untuk menulis ke cakera;

• 1: commit mesti ditulis ke cakera setiap kali binlog digunakan;

  N: Setiap N transaksi,
akan ditulis ke cakera.

• binlog

  Seperti yang dapat dilihat daripada di atas, tetapan paling selamat untuk
ialah

, yang juga merupakan nilai lalai untuk versi selepas

. 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. sync_binlog1format log binlog MySQL 5.7.7

Log mempunyai tiga format iaitu

,

dan binlog. STATMENTROWSebelum MIXED, format lalai ialah

dan selepas

, nilai lalai ialah MySQL 5.7.7. Format log ditentukan melalui STATEMENT. MySQL 5.7.7ROWbinlog-format

: Berdasarkan replikasi pernyataan
• (

  ), setiap pernyataan SQL yang mengubah suai data akan direkodkan dalam STATMENT. SQLstatement-based replication, SBRbinlog

: Replikasi berasaskan baris (
• ), yang tidak merekodkan maklumat konteks setiap pernyataan SQL, tetapi hanya merekodkan data yang telah diubah suai.

  ROWrow-based replication, RBR

: Salinan campuran (
• ) berdasarkan mod

  dan MIXED menggunakan mod STATMENT untuk menyimpan ROW Untuk operasi yang tidak boleh disalin, gunakan mixed-based replication, MBR Simpan mod STATEMENTbinlogSTATEMENTROWbinlogbuat semula log

Mengapa anda perlu buat semula log

Kita semua tahu bahawa salah satu daripada empat ciri urus niaga adalah kegigihan Khususnya, selagi transaksi berjaya diserahkan, pengubahsuaian yang dibuat pada pangkalan data akan disimpan secara kekal, dan adalah mustahil untuk kembali ke keadaan asal untuk sebarang. sebab.

Jadi bagaimanakah

memastikan konsistensi?

Cara mudahnya ialah dengan mengepam semua halaman data yang terlibat dalam pengubahsuaian pada cakera setiap kali transaksi dilakukan. Walau bagaimanapun, berbuat demikian akan menyebabkan masalah prestasi yang serius, yang ditunjukkan terutamanya dalam dua aspek:

• Kerana Innodb berinteraksi dengan cakera dalam unit 页, dan transaksi hanya boleh mengubah suai beberapa bait dalam halaman data Pada masa ini, data If yang lengkap halaman disiram ke cakera, ia akan menjadi pembaziran sumber!

• Transaksi mungkin melibatkan pengubahsuaian berbilang halaman data, dan halaman data ini tidak berterusan secara fizikal Prestasi penggunaan penulisan IO rawak adalah terlalu lemah!

Oleh itu, mysql direka redo log Secara khusus, ia hanya merekodkan pengubahsuaian yang dibuat pada halaman data oleh transaksi, supaya masalah prestasi dapat diselesaikan dengan sempurna. ( Secara relatifnya, fail adalah lebih kecil dan ia adalah IO berjujukan).

Konsep asas buat semula log

redo logTermasuk dua bahagian: satu ialah penimbal log dalam ingatan (redo log buffer), dan satu lagi ialah fail log pada cakera ( redo logfile).

mysqlSetiap kali penyataan DML dilaksanakan, rekod itu mula-mula ditulis ke redo log buffer dan kemudian berbilang rekod operasi ditulis kepada redo log file pada satu masa kemudian. Teknologi menulis log dahulu dan kemudian menulis ke cakera ialah teknologi MySQL yang sering disebut dalam
WAL(Write-Ahead Logging).

Dalam sistem pengendalian komputer, data penimbal dalam ruang pengguna (user space) secara amnya tidak boleh ditulis terus ke cakera, dan mesti melalui ruang kernel sistem pengendalian (kernel space) penimbal ( OS Buffer).

Oleh itu, menulis redo log buffer ke redo logfile sebenarnya menulis OS Buffer dahulu, dan kemudian mengepamnya ke fsync()redo log file melalui panggilan sistem
Prosesnya adalah seperti berikut:

mysql menyokong tiga pemasaan untuk menulis redo log buffer kepada redo log file, yang boleh dikonfigurasikan melalui parameter innodb_flush_log_at_trx_commit Maksud setiap nilai parameter adalah seperti berikut:

buat semula format rakaman log

Seperti yang dinyatakan sebelum ini, redo log sebenarnya merekodkan perubahan pada halaman data dan rekod perubahan ini Tidak perlu menyimpan kesemuanya, jadi redo log dilaksanakan menggunakan kaedah penulisan kitaran saiz tetap Apabila menulis hingga akhir, ia akan kembali ke permulaan untuk menulis log dalam gelung. Seperti yang ditunjukkan dalam gambar di bawah:

Pada masa yang sama, kita boleh dengan mudah mengetahui bahawa dalam innodb, terdapat kedua-duanya redo log yang perlu disiram, dan terdapat juga 数据页 yang perlu disegarkan semula. Tujuan utama redo log adalah untuk mengurangkan keperluan 数据页 menyegarkan cakera**.

Dalam gambar di atas, write pos mewakili kedudukan redo log (nombor urutan logik) rekod semasa LSN dan check point mewakili kedudukan redo log selepas rekod perubahan halaman data disiram 🎜>(nombor urutan logik) kedudukan. LSN

Bahagian antara

dan write pos ialah bahagian kosong check point, digunakan untuk merekod rekod baharu; Rekod perubahan halaman data. Apabila redo log mengejar check point, ia akan terlebih dahulu menolak write pos ke hadapan untuk mengosongkan ruang sebelum merakam log baharu. Apabila redo logwrite pos bermula check point, tidak kira sama ada ia ditutup secara normal atau luar biasa kali terakhir, operasi pemulihan akan sentiasa dilakukan. Kerana check point merekodkan perubahan fizikal halaman data, kelajuan pemulihan adalah lebih pantas daripada log logik (seperti

). Apabila

innodb dimulakan semula redo log, ia akan menyemak dahulu binlog halaman data dalam cakera Jika

halaman data kurang daripada

dalam log, pemulihan akan bermula dari innodb. LSNLSNTerdapat juga situasi di mana proses memberus cakera LSN sedang berjalan sebelum penutupan, dan kemajuan memberus cakera halaman data melebihi kemajuan memberus cakera pada halaman log Pada masa ini, data yang direkodkan dalam halaman data akan muncul checkpoint lebih besar daripada

dalam log Pada masa ini, bahagian yang melebihi kemajuan log tidak akan dibuat semula, kerana ini sendiri bermakna apa yang telah dilakukan. tidak perlu dibuat semula.

checkpointPerbezaan antara redo log dan binlogLSNLSN

Ia boleh dilihat daripada perbezaan antara

dan :

log hanya digunakan untuk mengarkib, dan hanya bergantung pada

tidak mempunyai keupayaan binlog. redo log

Tetapi hanya redo log tidak akan berfungsi, kerana redo log unik untuk InnoDB, dan rekod dalam log akan ditimpa selepas diletakkan. Oleh itu, kedua-dua binlog dan redo log perlu direkodkan pada masa yang sama untuk memastikan data tidak akan hilang apabila pangkalan data tidak berfungsi dan dimulakan semula.

buat asal log

Salah satu daripada empat ciri utama urus niaga pangkalan data ialah atomicity Secara khusus, atomicity merujuk kepada satu siri operasi pada pangkalan data, sama ada semuanya berjaya atau semua gagal, tidak Mungkin ada. kejayaan separa.

Malah, lapisan bawah atomicity dicapai melalui undo log. undo log terutamanya merekodkan perubahan logik data Sebagai contoh, pernyataan INSERT sepadan dengan DELETE daripada undo log untuk setiap pernyataan UPDATE, ia sepadan dengan UPDATE yang bertentangan dengan undo log. Dengan cara ini, Apabila ralat berlaku, anda boleh kembali ke keadaan data sebelum transaksi.

Pada masa yang sama, undo log juga merupakan kunci kepada pelaksanaan MVCC (kawalan pertukaran mata wang berbilang versi).

Atas ialah kandungan terperinci Apakah perbezaan antara binlog/redolog/undolog dalam MySQL?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!