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. mysql
Log 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).
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: mysql
Data 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
.
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?
mysql
Kawal 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;
binlog
. 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_binlog
1
format log binlog MySQL 5.7.7
dan binlog
. STATMENT
ROW
Sebelum MIXED
, format lalai ialah
, nilai lalai ialah MySQL 5.7.7
. Format log ditentukan melalui STATEMENT
. MySQL 5.7.7
ROW
binlog-format
), setiap pernyataan SQL yang mengubah suai data akan direkodkan dalam STATMENT
. SQL
statement-based replication, SBR
binlog
ROW
row-based replication, RBR
dan MIXED
menggunakan mod STATMENT
untuk menyimpan ROW
Untuk operasi yang tidak boleh disalin, gunakan mixed-based replication, MBR
Simpan mod STATEMENT
binlog
STATEMENT
ROW
binlog
buat semula log
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
direkaredo 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).
redo log
Termasuk dua bahagian: satu ialah penimbal log dalam ingatan (redo log buffer
), dan satu lagi ialah fail log pada cakera ( redo logfile
).
mysql
Setiap 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:
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
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 log
write 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
innodb
dimulakan semula redo log
, ia akan menyemak dahulu binlog
halaman data dalam cakera Jika
dalam log, pemulihan akan bermula dari innodb
. LSN
LSN
Terdapat 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
checkpoint
Perbezaan antara redo log dan binlogLSN
LSN
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.
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!