REDO LOG dipanggil redo log apabila pelayan MySQL ranap atau terputus secara tidak sengaja. Pastikan transaksi yang komited diteruskan ke cakera (ketekunan).
InnoDB mengendalikan rekod dalam unit halaman Penambahan, pemadaman, pengubahsuaian dan pertanyaan akan memuatkan keseluruhan halaman ke dalam kumpulan penimbal (cakera -> memori Operasi pengubahsuaian dalam transaksi tidak mengubah suai data secara langsung). Sebaliknya, data dalam kumpulan penimbal dalam ingatan diubah suai terlebih dahulu, dan benang latar belakang menyegarkannya ke cakera sekali-sekala.
Kolam penimbal: Ia boleh menyimpan indeks dan data, mempercepatkan membaca dan menulis, mengendalikan halaman data secara terus dalam ingatan dan mempunyai urutan khusus untuk menulis halaman kotor dalam kumpulan penimbal ke cakera.
Mengapa tidak mengubah suai terus data pada cakera?
Kerana jika anda mengubah suai data cakera secara langsung, ia adalah IO rawak Data yang diubah suai diedarkan di lokasi yang berbeza pada cakera dan perlu dicari ke belakang dan ke belakang, kadar hit adalah rendah, penggunaan adalah tinggi, dan pengubahsuaian kecil tidak boleh Seluruh halaman tidak dimuat semula ke cakera, dan kadar penggunaan adalah rendah
Sebaliknya, IO berjujukan, data cakera diedarkan dalam satu bahagian cakera, jadi; proses carian ditinggalkan dan masa pencarian disimpan.
Menggunakan benang latar belakang untuk menyegarkan cakera pada frekuensi tertentu boleh mengurangkan kekerapan IO rawak dan meningkatkan daya pemprosesan Ini adalah sebab asas untuk menggunakan kumpulan penimbal.
Masalah dengan mengubah suai memori dan kemudian menyegerakkannya secara tidak segerak ke cakera:
Oleh kerana kumpulan penimbal ialah kawasan dalam memori, data mungkin hilang jika sistem ranap secara tidak dijangka, dan beberapa data kotor mungkin tidak dimuat semula dalam masa Cakera, ketahanan transaksi tidak dijamin. Oleh itu, buat semula log diperkenalkan. Apabila mengubah suai data, log tambahan direkodkan, yang menunjukkan bahawa offset xx halaman xx telah berubah sebanyak xx Apabila sistem ranap, ia boleh dipulihkan berdasarkan kandungan log.
Perbezaan antara menulis log dan menyegarkan cakera secara langsung ialah: menulis log ialah menambah penulisan, IO berjujukan, lebih pantas dan kandungan bertulis lebih kecil
Log buat semula terdiri daripada dua bahagian :
buat semula penimbal log (tahap memori, lalai 16M, boleh diubah suai melalui parameter innodb_log_buffer_size)
buat semula fail log (berterusan, cakera tahap)
Proses umum operasi pengubahsuaian:
Langkah 1: Mula-mula baca data asal daripada cakera ke dalam memori , ubah suai salinan memori data dan jana data kotor
Langkah 2: Jana log buat semula dan tuliskannya ke dalam penimbal log buat semula, merekodkan nilai data yang diubah suai
Langkah 3 : Secara lalai, kandungan penimbal log buat semula akan dibuang ke fail log buat semula selepas transaksi diserahkan, dan fail log buat semula akan dilampirkan dan ditulis
Langkah 4: Muat semula data yang diubah suai secara kerap dalam memori ke cakera ( Apa yang kita bincangkan di sini ialah data kotor yang belum disiram oleh benang latar belakang dalam masa)
Apa yang biasanya dipanggil Log Tulis Ke Hadapan (kegigihan pra-log) bermakna bahawa sebelum meneruskan halaman data, pertama Halaman log yang sepadan dikekalkan dalam ingatan.
Faedah log buat semula:
Mengurangkan kekerapan muat semula cakera
log buat semula mengambil sedikit ruang
Kelajuan menulis semula log adalah pantas
Bolehkah log buat semula pasti menjamin ketahanan transaksi?
Tidak semestinya ini bergantung pada strategi penyiraman semula log, kerana penimbal log buat semula juga berada dalam ingatan Jika transaksi diserahkan, penimbal semula log belum sempat memuat semula data ke log semula fail untuk kegigihan, jika masa henti berlaku pada masa ini, data masih akan hilang. Bagaimana untuk menyelesaikannya? Strategi sapuan.
InnoDB menyediakan tiga strategi untuk parameter innodb_flush_log_at_trx_commit untuk mengawal apabila penimbal log buat semula disiram ke fail log buat semula:
Nilainya ialah 0: mulakan urutan latar belakang, muat semula ke cakera setiap 1s, dan tidak perlu memuat semula apabila menyerahkan transaksi
Nilai ialah 1: menyegerakkan muat semula apabila komit ( Nilai lalai), benar-benar menjamin kegigihan data
Nilai ialah 2: Apabila melakukan, ia hanya disiram ke dalam penimbal kernel os, dan masa pembilasan khusus tidak pasti
Apabila nilainya 0:
Oleh kerana terdapat selang 1s, 1 saat data akan hilang dalam masa yang paling teruk kes. Nilai
ialah 1:
Apabila membuat komitmen, anda perlu menyegarkan semula penimbal log buat semula secara aktif ke fail log buat semula Jika ia turun di tengah , urus niaga akan Jika gagal, tidak akan ada kerugian, dan ketahanan urus niaga benar-benar boleh dijamin. Tetapi kecekapan adalah yang paling teruk.
Apabila nilai ialah 2: ia ditentukan berdasarkan os.
boleh dilaraskan kepada 0 atau 2 untuk meningkatkan prestasi transaksi, tetapi sifat ACID hilang
innodb_log_group_home_dir: Tentukan laluan di mana kumpulan fail log buat semula berada Nilai lalai ialah ./, yang bermaksud ia berada dalam direktori data pangkalan data. Terdapat dua fail bernama ib_logfile0 dan ib_logfile1 dalam direktori data lalai MySQL Log dalam penimbal log disalurkan ke dua fail cakera ini secara lalai.
innodb_log_files_in_group: Nyatakan bilangan fail log buat semula, kaedah penamaan seperti: ib_logfile0, iblogfile1... iblogfilen. Lalai ialah 2, maksimum ialah 100.
Secara lalai, saiz innodb_log_file_size ditetapkan kepada 48M, yang digunakan untuk tetapan saiz fail log buat semula tunggal.
log asal digunakan untuk memastikan atomicity dan konsistensi transaksi. Ia mempunyai dua fungsi: ① Menyediakan operasi rollback ② Kawalan berbilang versi MVVC
Operasi rollback
Seperti yang dinyatakan dalam log buat semula sebelum ini, benang latar belakang akan menyegarkan semula data dalam kumpulan penimbal dari semasa ke semasa ke masa.
MVVC
Apabila baris baca dikunci oleh transaksi lain, ia boleh menganalisis versi data sebelumnya bagi rekod baris daripada log buat asal, supaya pengguna boleh membacanya Kepada data sebelum operasi transaksi semasa - baca gambar.
Bacaan syot kilat: Data yang dibaca oleh SQL ialah versi sejarah, tiada penguncian diperlukan, SELECT biasa ialah bacaan syot kilat.
Komponen log buat asal:
Apabila memasukkan rekod, nilai kunci utama rekod mesti direkodkan supaya data boleh dipadamkan semasa pemulangan semula.
Apabila mengemas kini rekod, semua nilai lama yang diubah suai mesti direkodkan, dan kemudian dikemas kini kepada nilai lama apabila digulung semula.
Apabila memadam, semua rekod mesti direkodkan dan rekod kandungan mesti dimasukkan semula apabila digulung semula.
Operasi pilih tidak akan menghasilkan log buat asal
Dalam enjin storan InnoDB, log asal menggunakan segmen putar balik untuk putar balik Segmen disimpan dan setiap segmen rollback mengandungi 1024 segmen log asal. Selepas MySQL5.5, terdapat sejumlah 128 segmen rollback. Iaitu, sejumlah 128 * 1024 operasi buat asal boleh direkodkan.
Setiap urus niaga hanya akan menggunakan satu segmen gulung balik dan satu segmen gulung balik mungkin menyediakan berbilang transaksi pada masa yang sama.
Memadamkan log buat asal tidak boleh dilakukan serta-merta selepas melakukan transaksi, kerana sesetengah transaksi mungkin mahu membaca versi data sebelumnya (dibaca syot kilat). Oleh itu, apabila transaksi dilakukan, log buat asal dimasukkan ke dalam senarai terpaut, dipanggil rantaian versi Sama ada log buat asal dipadamkan atau tidak dinilai oleh benang yang dipanggil pembersihan.
buat asal log terbahagi kepada:
masukkan buat asal log
Kerana rekod operasi sisipan hanya boleh dilihat oleh transaksi itu sendiri dan tidak kepada transaksi lain. Ia boleh dilihat (ini adalah keperluan pengasingan transaksi), jadi log batal boleh dipadamkan terus selepas transaksi dilakukan. Tiada operasi pembersihan diperlukan.
kemas kini log asal
Buat asal log merekodkan perubahan yang dibuat untuk memadam dan mengemas kini operasi.. Untuk menyokong mekanisme MVCC, log buat asal tidak boleh dipadamkan serta-merta apabila transaksi dilakukan. Apabila menyerahkan, tambahkannya pada senarai log asal dan tunggu urutan pembersihan melakukan pemadaman akhir.
Andaikan terdapat 2 nilai, A=1 dan B=2, dan kemudian transaksi mengubah suai A kepada 3 dan B kepada 4. Proses pengubahsuaian Boleh dipermudahkan kepada:
1.mulakan
Jika sistem turun dalam mana-mana langkah 1-8 dan urus niaga tidak dilakukan, urus niaga itu tidak akan memberi kesan kepada data pada cakera.
2. Rekod A=1 untuk membuat asal log
3.kemas kini A=3
4 5. Rekod B=2 untuk membatalkan log
6.kemas kini B=4
7 Rekod B=4 untuk membuat semula log
8 🎜>
Jika ia turun antara 8-9, anda boleh memilih untuk melancarkan semula selepas pemulihan, atau anda boleh memilih untuk meneruskan penyerahan transaksi, kerana log buat semula telah berterusan pada masa ini masa.
Sekiranya sistem turun selepas 9 dan data yang ditukar dalam peta memori belum sempat dibuang semula ke cakera, maka selepas sistem dipulihkan, data boleh disiram kembali ke cakera mengikut log buat semula.
Untuk enjin InnoDB, sebagai tambahan kepada data rekod itu sendiri, setiap rekod baris juga mempunyai Beberapa lajur tersembunyi:
DB_ROW_ID∶Id kunci utama rekod.
DB_TRX_ID: ID Transaksi Apabila rekod diubah suai, ID transaksi akan direkodkan.
DB_ROLL_PTR: Penunjuk putar balik, penuding dalam rantai versi.
begin; INSERT INTO user (name) VALUES ('tom');
Setiap kali data dimasukkan, log buat asal operasi sisipan akan dibuat dan penuding balik data akan menghala ke log ini. Log buat asal akan merekodkan nombor siri log buat asal, lajur dan nilai kunci utama yang dimasukkan... Kemudian apabila melakukan rollback, data yang sepadan boleh dipadamkan terus melalui kunci utama.
Apabila kami melaksanakan KEMASKINI:
Apabila menjalankan operasi kemas kini, log buat asal kemas kini akan dihasilkan, termasuk dua kes mengemas kini kunci utama dan tidak mengemas kini kunci utama. Andaikan bahawa operasi kemas kini kini dilakukan:
UPDATE user SET name='Sun' WHERE id=1;
Pada masa ini, rekod log asal baharu akan ditambahkan pada rantai versi, no buat asalnya ialah 1 dan log buat asal baharu Penunjuk putar balik akan menghala ke log buat asal lama (buat asal tidak=0).
Andaikan anda melaksanakan sekarang:
UPDATE user SET id=2 WHERE id=1;
Untuk operasi mengemas kini kunci utama, tanda pemadam data asal akan dibuka dahulu data sebenarnya tidak dipadamkan, pemadaman sebenar akan diserahkan kepada benang pembersihan untuk menilai, dan kemudian data baharu akan dimasukkan kemudian bertambah.
Anda boleh mendapati bahawa setiap perubahan pada data akan menjana log buat asal Apabila rekod ditukar beberapa kali, berbilang log buat asal akan dijana log sebelum perubahan, dan Nombor jujukan setiap log buat asal semakin meningkat, jadi apabila anda ingin berpatah balik, tolak ke hadapan mengikut nombor urutan untuk mencari data asal kami.
Mengambil contoh di atas, dengan mengandaikan pemulangan semula dilaksanakan, proses yang sepadan hendaklah seperti berikut:
1 daripada 3 memadamkan data dengan id=2
2 Log undo no=2 memulihkan tanda padam data id=1 kepada 0
3 1 Log memulihkan nama data dengan id=1 kepada Tom
4 Padamkan data dengan id=1 melalui log batal no=0
kawalan konkurensi berbilang versi MySQL MVVC.
Log binari, juga dikenali sebagai log kemas kini, ialah sejenis fail log dalam format binari yang merekodkan perubahan yang dibuat pada pangkalan data.. Ia merekodkan semua kenyataan kemas kini yang dilaksanakan oleh pangkalan data.
Senario aplikasi utama binlog:
Pemulihan data: Jika MySQL berhenti tanpa diduga, anda boleh menggunakan log ini untuk pemulihan dan sandaran
Replikasi data: tuan menghantar log binarinya kepada hamba untuk mencapai konsistensi data tuan-hamba
show variables like '%log_bin%';
Lihat log log bin:
mysqlbinlog -v "/var/lib/mysql/binlog/xxx.000002"
Gunakan Data pemulihan log:
mysqlbinlog [option] filename|mysql –uuser -ppass;
Padam log binari:
PURGE {MASTER | BINARY} LOGS TO ‘指定日志文件名'
PURGE {MASTER | BINARY} LOGS BEFORE ‘指定日期'Semasa pelaksanaan urus niaga, log pertama kali ditulis ke cache log bin, dan apabila transaksi dilakukan, Binlog cache ditulis pada fail binlog. Oleh kerana binlog transaksi tidak boleh dipecahkan, tidak kira betapa besar transaksi itu, ia mesti ditulis sekali, jadi sistem akan memperuntukkan blok memori kepada setiap utas sebagai cache binlog.
Log buat semula yang dijana oleh lapisan enjin storan InnoDB ialah log fizikal yang digunakan untuk merekod " Apakah pengubahsuaian yang dibuat pada halaman data yang mana?"
Binlog ialah log logik, dan kandungan yang direkodkan ialah logik asal penyataan Ia serupa dengan menambah 1 pada medan c baris dengan ID=2, yang tergolong dalam lapisan perkhidmatan.
Dua fokus juga berbeza Log Redo memberikan InnoDB keupayaan untuk pulih daripada ranap sistem, dan binlog memastikan ketekalan data seni bina kelompok MySQL.
Semasa pelaksanaan kenyataan kemas kini, dua log, log buat semula dan binlog, akan direkodkan Berdasarkan transaksi asas, log buat semula boleh ditulis secara berterusan semasa proses pelaksanaan transaksi Binlog hanya ditulis apabila transaksi dilakukan, jadi masa penulisan log semula dan binlog adalah berbeza.
Jika logik antara redo log dan binlog tidak konsisten, apakah masalah yang akan berlaku?
Ambil penyataan kemas kini sebagai contoh Andaikan bahawa untuk rekod dengan id=2, nilai medan c ialah 0. Kemas kini nilai medan c kepada 1. Pernyataan SQL ialah kemas kini T set c=1 di mana. id=2.
Andaikan selepas menulis log buat semula semasa pelaksanaan, pengecualian berlaku semasa penulisan log binlog Apakah yang akan berlaku?
Kerana binlog ialah. terganggu secara tidak normal Tulis, jadi tiada rekod pengubahsuaian yang sepadan. Oleh itu, apabila log binlog digunakan untuk memulihkan data atau hamba membaca binlog induk kemudian, kemas kini ini akan ditinggalkan. Nilai c baris yang dipulihkan ialah 0, dan nilai c baris ini dalam pangkalan data asal ialah 1 kepada pemulihan log buat semula Data akhir tidak konsisten.
Enjin storan InnoDB menggunakan skema komit dua fasa untuk menangani isu ketekalan logik antara kedua-dua log. Penyerahan dua peringkat merujuk kepada membahagikan log buat semula kepada dua langkah: sediakan dan buat komitmen.
Biarkan penyerahan akhir log buat semula dan log bin diikat bersama Seperti yang dinyatakan sebelum ini, apabila transaksi dilakukan, secara lalai, log buat semula perlu disegerakkan terlebih dahulu sebelum komit berjaya, jadi jika mereka. terikat bersama, bin Log juga mempunyai ciri ini, yang memastikan bahawa data tidak akan hilang.
Selepas menggunakan komit dua fasa, pengecualian semasa menulis binlog tidak akan terjejas, kerana apabila MySQL memulihkan data berdasarkan log redo log, didapati log redo masih dalam peringkat penyediaan Dan jika tiada log binlog yang sepadan, penyerahan akan gagal dan data akan ditarik balik.
Dalam senario lain, pengecualian berlaku semasa fasa komit log buat semula Adakah urus niaga akan ditarik balik?
tidak akan melancarkan semula transaksi Ia akan melaksanakan logik yang dibingkai dalam gambar di atas Walaupun log buat semula berada dalam peringkat penyediaan, log binlog yang sepadan boleh ditemui melalui ID transaksi , jadi MySQL menganggapnya sudah lengkap dan akan menyerahkan transaksi untuk memulihkan data.
Atas ialah kandungan terperinci Apakah mata pengetahuan bagi log semula dan buat asal log dalam log MySQL?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
