Susunan khas log MySQL: buat semula log dan buat asal log

Artikel ini membawa anda pengetahuan yang berkaitan tentang mysql Log MySQL merekodkan operasi harian dan maklumat ralat pangkalan data MySQL MySQL mempunyai jenis fail log yang berbeza (setiap jenis log yang berbeza) ), anda boleh menanyakan status berjalan pangkalan data MySQL, operasi pengguna, mesej ralat, dan lain-lain daripada log Mari kita lihat mereka bersama-sama.

Pembelajaran yang disyorkan: tutorial video mysql

Redo Log

REDO LOG dipanggil redo log After pelayan MySQL secara tiba-tiba ranap atau jatuh, ia dijamin bahawa transaksi yang diserahkan diteruskan ke cakera (persistence).

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 dilakukan Keseluruhan halaman tidak dimuat semula ke cakera, dan kadar penggunaan adalah rendah; cakera, jadi proses carian ditinggalkan dan masa carian 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)

1. buat semula fail log (berterusan, tahap cakera)
2. 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, yang merekodkan nilai data yang diubah suai

Langkah 3: Secara lalai, selepas transaksi dilakukan, Kandungannya dimuatkan semula ke fail log buat semula, dan fail log buat semula dilampirkan

Langkah 4: Sentiasa menyegarkan semula data yang diubah suai dalam memori ke cakera (di sini kita bercakap tentang data yang belum. telah disegarkan semula oleh benang latar belakang dalam masa Data kotor pada cakera)

Apa yang biasanya dipanggil Log Tulis Ke Hadapan (ketekalan pra-log) merujuk kepada mengekalkan halaman log yang sepadan dalam ingatan sebelum meneruskan halaman data.

Faedah log buat semula:

Kekerapan muat semula cakera dikurangkan

• Log buat semula mengambil lebih sedikit ruang
• Log buat semula menulis dengan cepat
• Bolehkah buat semula log 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.

strategi siram semula log

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:

Nilai ialah 0: Mulakan utas latar belakang dan muat semula ia ke cakera setiap 1s Tidak perlu memuat semula apabila menyerahkan transaksi

• Nilainya ialah 1: Muat semula segerak dilakukan apabila melakukan (nilai lalai). memastikan ketahanan data.
• Nilainya ialah 2: Apabila melakukan, ia hanya disalurkan ke dalam penimbal kernel os nilai ialah 0:

Oleh kerana terdapat selang 1s, 1 saat data akan hilang dalam kes yang paling teruk. Nilai

ialah 1:

Apabila membuat komitmen, anda perlu menyegarkan semula penimbal log buat semula secara aktif ke fail log buat semula. Tetapi kecekapan adalah yang paling teruk.

Jika nilai ialah 2: ia ditentukan mengikut os.

Boleh dilaraskan kepada 0 atau 2 untuk meningkatkan prestasi transaksi, tetapi ciri ACID hilang

Parameter lain

• innodb_log_group_home_dir: Tentukan laluan di mana fail log buat semula kumpulan terletak, 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: Menentukan bilangan fail log buat semula Kaedah penamaan ialah: ib_logfile0, iblogfile1... iblogfilen. Lalai ialah 2, maksimum ialah 100.
• innodb_log_file_size: Tetapkan saiz fail log buat semula tunggal, nilai lalai ialah 48M.

Buat Asal Log

Buat asal log digunakan untuk memastikan atomicity dan konsistensi transaksi. Ia mempunyai dua fungsi: ① Menyediakan operasi rollback ② MVVC kawalan berbilang versi

Operasi rollback

Seperti yang dinyatakan dalam log buat semula tadi, benang latar belakang akan menyegarkan semula data dalam kumpulan penimbal dari masa ke masa 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 rollback.
• 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 menjana log asal

Segmen gulung balik dan buat asal halaman

Dalam enjin storan InnoDB, log buat asal menggunakan segmen gulung balik segmen untuk storan , 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.

Log buat asal tidak boleh dipadamkan serta-merta selepas transaksi diserahkan. Sesetengah transaksi mungkin mahu membaca versi data sebelumnya (dibaca gambar). 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 jenis

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

kemas kini log asal merekodkan log buat asal yang dijana oleh operasi pemadaman dan kemas kini. Log buat asal mungkin perlu menyediakan mekanisme MVCC, jadi ia tidak boleh dipadamkan apabila transaksi dilakukan. Apabila menyerahkan, masukkannya ke dalam senarai log batal dan tunggu benang pembersihan melakukan pemadaman terakhir.

Kitaran hayat log buat asal

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
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 sistem turun dalam mana-mana langkah langkah 1-8 dan transaksi tidak dilakukan, urus niaga itu tidak akan memberi kesan kepada data pada cakera.

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.

• Jika sistem turun selepas 9 dan data yang ditukar dalam peta memori tidak disiram semula ke cakera, maka selepas sistem pulih, data boleh disiram semula ke cakera mengikut log semula.

Proses penjanaan terperinci

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: penuding balik, penuding dalam rantaian versi.

Apabila kami melaksanakan INSERT:

begin;
INSERT INTO user (name) VALUES ('tom');

Data yang dimasukkan akan menjana log buat asal sisipan dan penuding balik data akan menghala kepadanya. 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:

Log buat asal kemas kini akan dijana untuk operasi kemas kini dan ia akan dibahagikan kepada yang mengemas kini kunci utama dan yang tidak. Andaikan Sekarang laksanakan:

UPDATE user SET name='Sun' WHERE id=1;

Pada masa ini, rekod log asal baharu akan ditambahkan pada rantaian versi, no buat asalnya ialah 1 , dan respons log buat asal baharu Penunjuk gulung 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 , tiada sebenar Apabila memadam data, pemadaman sebenar akan diserahkan kepada benang pembersihan untuk menilai, dan kemudian sekeping data baharu akan dimasukkan kemudian Data baharu juga akan menjana log batal, dan nombor jujukan batal log akan dinaikkan.

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.

Cara membuat asal log digulung semula

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.

Sambungan

log bin

binlog ialah log binari, fail log binari, juga dipanggil log perubahan (log kemas kini). 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: induk menyalinnya binari Log diserahkan kepada hamba untuk mencapai ketekalan data tuan-hamba

show variables like '%log_bin%';

Lihat log tong:

mysqlbinlog -v "/var/lib/mysql/binlog/xxx.000002"

Gunakan log untuk memulihkan data:

mysqlbinlog [option] filename|mysql –uuser -ppass;

Padam log binari:

PURGE {MASTER | BINARY} LOGS TO ‘指定日志文件名'
PURGE {MASTER | BINARY} LOGS BEFORE ‘指定日期'

Pemasaan penulisan

Semasa pelaksanaan urus niaga, log pertama kali ditulis ke cache log bin, dan apabila transaksi diserahkan, cache binlog ditulis ke 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.

Perbandingan antara binlog dan buat semula log

• Log buat semula ialah log fizikal Kandungan rekod ialah "xx pengubahsuaian dibuat pada xx halaman data", yang dimiliki oleh Dijana oleh lapisan enjin storan InnoDB.
• 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.

Komit dua fasa

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 log buat semula ditulis semasa proses pelaksanaan, pengecualian berlaku semasa penulisan log binlog Apakah yang akan berlaku?

Kerana binlog. tidak ditulis Pengecualian berlaku pada penghujung Pada masa ini, tiada rekod pengubahsuaian yang sepadan dalam binlog. Oleh itu, apabila log binlog digunakan untuk memulihkan data atau hamba membaca binlog tuan, kemas kini ini akan ditinggalkan Nilai c baris yang dipulihkan ialah 0, dan nilai c baris ini dalam pangkalan data asal ialah 1 disebabkan oleh. pemulihan log buat semula Data akhir tidak konsisten.

Untuk menyelesaikan masalah ketekalan logik antara dua log, enjin storan InnoDB menggunakan skema komit dua fasa. Pisahkan log buat semula kepada dua langkah, sediakan dan komit, yang merupakan komit dua peringkat.

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 fikir ia sudah lengkap dan akan menyerahkan transaksi untuk memulihkan data.

Pembelajaran yang disyorkan: tutorial video mysql

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