1 buat asal
1.1 Apa itu buat asal
Log buat asal digunakan untuk menyimpan data sebelum itu diubahsuai, dengan mengandaikan bahawa data baris dengan id=2 dalam jadual tba diubah suai dan Name='B' ditukar kepada Name = 'B2', maka log buat asal akan digunakan untuk menyimpan rekod Name=' B'. Jika terdapat pengecualian dalam pengubahsuaian ini, Anda boleh menggunakan batal log untuk melaksanakan operasi rollback dan memastikan konsistensi transaksi.
Operasi perubahan data terutamanya datang daripada INSERT UPDATE DELETE, dan UNDO LOG terbahagi kepada dua jenis Satu ialah INSERT_UNDO (operasi INSERT), yang merekodkan nilai kunci unik yang dimasukkan; yang satu lagi ialah UPDATE_UNDO dan operasi DELETE), rekod nilai kunci unik yang diubah suai dan rekod lajur lama.
| Id |
Nama |
| 1 |
A |
| 2 |
B |
| 3 |
C td> |
| 4 |
D |
1.2 buat asal parameter
Tetapan parameter buat asal berkaitan MySQL termasuk yang berikut:
mysql> show global variables like '%undo%';
+--------------------------+------------+
| Variable_name | Value |
+--------------------------+------------+
| innodb_max_undo_log_size | 1073741824 |
| innodb_undo_directory | ./ |
| innodb_undo_log_truncate | OFF |
| innodb_undo_logs | 128 |
| innodb_undo_tablespaces | 3 |
+--------------------------+------------+
mysql> show global variables like '%truncate%';
+--------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------+-------+
| innodb_purge_rseg_truncate_frequency | 128 |
| innodb_undo_log_truncate | OFF |
+--------------------------------------+-------+
Salin selepas log masuk
Kawal saiz fail undo tablespace maksimum Apabila innodb_undo_log_truncate dimulakan, truncate akan dicuba hanya apabila undo tablespace melebihi ambang innodb_max_undo_log_size. Saiz lalai nilai ini ialah 1G, dan saiz lalai selepas truncate ialah 10M.
Tetapkan bilangan buat asal ruang jadual bebas, julat ialah 0-128, lalai ialah 0, 0 Menunjukkan bahawa ruang jadual asal bebas tidak didayakan dan log buat asal disimpan dalam fail ibdata. Parameter ini hanya boleh ditentukan apabila memulakan tika MySQL Jika tika telah dibuat, parameter ini tidak boleh ditukar Jika bilangan innodb_undo_tablespaces yang dinyatakan dalam fail konfigurasi pangkalan data. ia akan Permulaan gagal, menunjukkan bahawa tetapan parameter tidak betul.
Jika parameter ini ditetapkan kepada n (n>0), maka n buat asal fail (buat asal001, buat asal002... buat asal n), saiz lalai setiap fail ialah 10M.
Bilakah anda perlu menetapkan parameter ini?
Apabila tekanan penulisan DB tinggi, anda boleh menyediakan ruang jadual UNDO bebas, asingkan UNDO LOG daripada fail ibdata dan tentukan direktori innodb_undo_directory untuk penyimpanan Ia boleh dikonfigurasikan pada a cakera berkelajuan tinggi untuk mempercepatkan prestasi membaca dan menulis UNDO LOG.
Benang pembersihan InnoDB dihidupkan atau dimatikan mengikut tetapan innodb_undo_log_truncate_innod_truncate parameter_innodb_undo_log_truncate , dan potong kekerapan untuk melakukan penambakan ruang dan buat asal pemulaan semula fail.
Premis untuk parameter ini berkuat kuasa ialah ruang jadual bebas telah disediakan dan bilangan ruang jadual bebas lebih besar daripada atau sama dengan 2.
Dalam proses pangkas buat asal fail log, utas pembersihan perlu menyemak sama ada terdapat transaksi aktif pada fail Jika tidak, fail log batal perlu ditandakan sebagai tidak boleh diperuntukkan , undo log akan direkodkan ke fail lain, jadi sekurang-kurangnya 2 fail ruang jadual bebas diperlukan untuk melaksanakan operasi truncate Selepas menandakannya sebagai tidak boleh diperuntukkan, fail bebas undo_
_trunc.log akan dibuat untuk merekodkan yang tertentu. buat asal fail log sedang dipotong , dan kemudian mula memulakan fail log batal kepada 10M Selepas operasi selesai, padam fail undo__trunc.log yang mewakili tindakan truncate berlaku semasa proses truncate, perkhidmatan pangkalan data akan dimulakan semula Selepas dimulakan semula, perkhidmatan akan mendapati fail ini akan terus menyelesaikan operasi truncate Selepas memadamkan fail, fail log batal akan ditandakan sebagai tersedia untuk peruntukan.
digunakan untuk mengawal kekerapan pembersihan segmen rollback, lalainya ialah 128. Dengan mengandaikan ia ditetapkan kepada n, ini bermakna apabila urutan penyelarasan operasi Innodb Purge membersihkan urus niaga sebanyak 128 kali, pembersihan Sejarah akan dicetuskan untuk menyemak sama ada status ruang jadual log asal semasa akan mencetuskan pemotongan.
1.3 buat asal pengurusan ruang
Jika anda perlu menyediakan ruang jadual bebas, anda perlu menentukan bilangan ruang jadual bebas apabila memulakan contoh pangkalan data. UNDO secara dalaman terdiri daripada berbilang segmen rollback, iaitu segmen Rollback, sejumlah 128, yang disimpan dalam ruang jadual sistem ibdata, dari resg slot0 hingga resg slot127, setiap slot resg, iaitu setiap The segmen rollback secara dalaman terdiri daripada 1024 segmen buat asal. Segmen rollback diperuntukkan seperti berikut:
-
slot 0, dikhaskan untuk ruang jadual sistem; -32 dikhaskan untuk ruang meja sementara Setiap kali pangkalan data dimulakan semula, ruang jadual sementara akan dibina semula; BATALKAN ruang jadual bebas; jika tidak, tempah ia untuk ruang jadual sistem; 1024 operasi urus niaga serentak Setiap urus niaga menduduki satu slot buat asal segmen Ambil perhatian bahawa jika terdapat urus niaga jadual sementara dalam urus niaga, satu lagi slot buat asal segmen dalam ruang jadual sementara, iaitu, menduduki 2 slot buat asal segmen . Jika terdapat:
dalam log ralat, ini bermakna terdapat terlalu banyak transaksi serentak dan anda perlu mempertimbangkan sama ada untuk memunggah perniagaan. -
Segmen putar balik diperuntukkan menggunakan penjadualan undian Jika ruang jadual bebas disediakan, segmen buat asal dalam segmen ruang jadual sistem tidak akan digunakan, tetapi ruang bebas akan digunakan , pada masa yang sama, jika segmen lihat kembali berada dalam operasi Truncate, ia tidak diperuntukkan.
2 buat semula
2.1 Apa itu buat semula
Apabila pangkalan data mengubah suai data , halaman data perlu dibaca dari cakera ke dalam kumpulan penimbal, dan kemudian diubah suai dalam kumpulan penimbal Pada masa ini, halaman data dalam kumpulan penimbal akan tidak konsisten dengan kandungan halaman data pada halaman data dalam kolam penampan dipanggil halaman kotor Data, jika perkhidmatan DB dimulakan semula yang tidak normal berlaku pada masa ini, maka data itu belum lagi berada dalam memori dan belum disegerakkan ke fail cakera (perhatikan bahawa penyegerakan ke fail cakera adalah. IO rawak), iaitu, kehilangan data akan berlaku Jika kali ini, apabila terdapat fail, apabila halaman data dalam kumpulan penimbal ditukar, rekod pengubahsuaian yang sepadan boleh direkodkan ke fail ini (perhatikan bahawa rakaman log adalah. IO berurutan), kemudian apabila perkhidmatan DB ranap dan DB dipulihkan, Ia juga boleh digunakan semula pada fail cakera berdasarkan kandungan rakaman fail ini, dan data akan kekal konsisten.
Fail ini ialah log buat semula, yang digunakan untuk merekod data yang diubah suai mengikut turutan. Ia boleh membawa faedah ini:
Apabila halaman kotor dalam kumpulan penimbal belum dimuatkan semula ke cakera, ranap berlaku selepas memulakan perkhidmatan, anda boleh mengetahui perkara yang perlu diperbaharui melalui log buat semula.
-
Data dalam kumpulan penimbal disalurkan terus ke fail cakera, yang merupakan IO rawak dan mempunyai kecekapan yang lemah data dalam kumpulan penimbal ke log buat semula ialah IO berurutan boleh meningkatkan kelajuan penyerahan urus niaga; ='B' ditukar kepada Name = 'B2', kemudian Log buat semula akan digunakan untuk menyimpan rekod dengan Name='B2' Jika pengecualian berlaku apabila pengubahsuaian ini disalurkan ke fail cakera, log buat semula boleh digunakan untuk melaksanakan operasi buat semula untuk memastikan ketahanan transaksi.
| Id |
Nama |
| 1 |
A |
| 2 |
B |
| 3 |
C td> |
| 4 |
D |
Perhatikan di sini perbezaan antara log buat semula dan log binari dijana oleh lapisan enjin storan, manakala log binari dijana oleh lapisan pangkalan data. Katakan transaksi besar memasukkan 100,000 baris rekod ke dalam tba Semasa proses ini, rekod secara berterusan direkodkan secara berurutan dalam log buat semula, tetapi log perduaan tidak akan merekodkan Hanya apabila urus niaga dilakukan, ia akan ditulis ke fail log perduaan di sekali. Terdapat tiga format rakaman berbeza yang tersedia untuk log binari, iaitu baris, pernyataan dan campuran, dan borang rakaman antaranya adalah berbeza.
2.2 buat semula Parameter
- innodb_log_file_size
Saiz tetapan fail, nilai lalai ialah 48M, nilai maksimum ialah 512G, perhatikan apa yang dirujuk oleh nilai maksimum Ia adalah jumlah keseluruhan fail siri log buat semula, iaitu, (innodb_log_files_in_group * innodb_log_file_size) tidak boleh lebih besar daripada nilai maksimum 512G.
- innodb_log_group_home_dir
Laluan storan fail
innod_log
Kawasan cache Log Semula, lalai 8M, boleh ditetapkan kepada 1-8M. Tangguhkan penulisan log urus niaga ke cakera, masukkan log buat semula ke dalam penimbal, dan kemudian siram log daripada penimbal ke cakera mengikut tetapan parameter innodb_flush_log_at_trx_commit.
innodb_flush_log_at_trx_commit-
innodb_flush_log_at_trx_commit akan berubah daripada redo log_at_trx_commit=red Penimbal log ditulis kepada sistem dan dibuang ke fail cakera melalui fsync.
-
innodb_flush_log_at_trx_commit=2, setiap kali transaksi dilakukan, MySQL akan menulis log daripada penimbal log semula kepada sistem, tetapi hanya menulisnya ke penimbal sistem fail dan menyegerakkannya ke cakera secara dalaman daripada dokumen sistem. Jika kejadian pangkalan data ranap, log buat semula tidak akan hilang Walau bagaimanapun, jika pelayan ranap, bahagian data ini akan hilang kerana penimbal sistem fail tidak mempunyai masa untuk menyegerakkan ke fail cakera.
- innodb_flush_log_at_trx_commit=0, semasa transaksi, log sentiasa berada dalam penimbal log buat semula, sama seperti tetapan lain, tetapi apabila transaksi dilakukan, tiada operasi tulis buat semula berlaku, tetapi di dalam MySQL Ia beroperasi sekali sesaat untuk menulis data daripada penimbal log semula kepada sistem. Jika ranap sistem berlaku, operasi pengubahsuaian transaksi dalam masa 1 saat akan hilang.
Nota: Disebabkan isu dasar penjadualan proses, "melakukan operasi flush (flush ke cakera) sekali sesaat" tidak menjamin 100% "sesaat" .
2.3
buat semulaib_logfile[number]
Pengurusan Angkasa
Buat semula Fail log dinamakan dengan - Log semula menulis fail secara berurutan Apabila ia penuh, ia kembali ke fail pertama dan menimpanya. (Tetapi apabila melakukan semula pusat pemeriksaan, tanda titik pemeriksaan pengepala fail log pertama juga akan dikemas kini, jadi secara tegasnya ia tidak dikira sebagai penulisan berurutan). Malah, log buat semula terdiri daripada dua bahagian: penimbal log buat semula dan fail log buat semula. Dalam kumpulan penimbal, pengubahsuaian data direkodkan kepada penimbal log buat semula.
-
Penyerahan urus niaga (bergantung pada tetapan parameter innodb_flush_log_at_trx_commit)
-
Benang latar belakang
-
3.1 Proses yang dipermudahkan untuk Buat asal + Buat semula urus niaga
Andaikan terdapat dua data A dan B, masing-masing dengan nilai 1 dan 2 Mulakan a urus niaga. Kandungan operasi transaksi ialah: tukar 1 Ubah suai kepada 3 dan 2 kepada 4, maka rekod sebenar adalah seperti berikut (dipermudahkan):
B. Rekod A=1 untuk membuat asal log. C. Ubah suai A=3.
D. Rekod A=3 untuk buat semula log. E. Rekod B=2 kepada buat asal log.
F. Ubah suai B =4.
G. Rekod B=4 untuk buat semula log.
H. Tulis buat semula log pada cakera.
I. Penyerahan transaksi
3.2 Impak IO
Tujuan utama mereka bentuk Undo + Redo adalah untuk meningkatkan prestasi input dan output serta meningkatkan pemprosesan kapasiti pangkalan data. Dapat dilihat bahawa B D E G H adalah semua operasi baharu, tetapi B D E G ditimbal ke kawasan penimbal Hanya G menambah operasi IO Untuk memastikan Redo Log boleh mempunyai prestasi IO yang lebih baik, reka bentuk Log Redo InnoDB mempunyai Ciri-ciri berikut:
B. Cuba pastikan Redo Log disimpan dalam ruang berterusan. Oleh itu, ruang fail log akan diperuntukkan sepenuhnya apabila sistem dimulakan buat kali pertama. Untuk meningkatkan prestasi, Redo Log akan direkodkan dalam cara IO berurutan dan dilengkapkan dengan cara langkah demi langkah.
B. Tulis log dalam kelompok. Log tidak ditulis terus ke fail, tetapi terlebih dahulu ditulis ke penimbal log semula Apabila log perlu dibuang ke cakera (seperti penyerahan transaksi), banyak log ditulis ke cakera bersama-sama > C. Urus niaga serentak Berkongsi ruang storan Redo Log, Redo Log mereka direkodkan bersama secara bergilir-gilir mengikut susunan pelaksanaan penyata untuk mengurangkan ruang yang diduduki oleh log. Contohnya, kandungan rekod dalam Log Buat Semula mungkin seperti berikut:
Rekod 1: Rekod 2: Rekod 3:
Rekod 4:
Rekod 5:
D. Kerana C, apabila transaksi menulis Log Semula pada cakera, log transaksi lain yang tidak terikat juga akan ditulis pada cakera.
E. Hanya operasi tambah berurutan dilakukan pada Log Buat Semula Apabila transaksi perlu ditarik balik, rekod Log Buat Semulanya tidak akan dipadamkan daripada Log Buat Semula.
3.3 Pemulihan
Seperti yang dinyatakan sebelum ini, urus niaga tidak komited dan urus niaga terbalik juga akan direkodkan dalam Log Buat Semula, jadi apabila pulih, urus niaga ini mesti diproses khas daripada pemprosesan. Terdapat 2 strategi pemulihan yang berbeza:
A. Apabila memulihkan, hanya buat semula transaksi yang dilakukan.
Apabila pulih, semua urus niaga perlu dilaksanakan semula, termasuk urus niaga tanpa komitmen dan urus niaga yang ditarik balik. Kemudian gulung semula
urus niaga tidak komited melalui Undo Log.
Enjin storan InnoDB pangkalan data MySQL menggunakan strategi B. Mekanisme pemulihan dalam enjin storan InnoDB mempunyai beberapa ciri: A. Apabila membuat semula Log Buat Semula, dan
Tidak mengambil berat tentang transaksi. Semasa pemulihan, tiada tingkah laku BEGIN, COMMIT atau ROLLBACK. Tidak kira transaksi yang mana setiap log milik. Walaupun kandungan berkaitan transaksi seperti ID transaksi akan direkodkan dalam Log Buat Semula, kandungan ini hanya dianggap sebagai sebahagian daripada data yang akan dikendalikan. B. Apabila menggunakan strategi B, Undo Log mesti diteruskan dan Undo Log yang sepadan mesti ditulis pada cakera sebelum menulis Redo Log. Hubungan antara Undo dan Redo Log ini menjadikan kegigihan menjadi rumit. Untuk mengurangkan kerumitan, InnoDB menganggap Undo Log sebagai data, jadi operasi merekod Undo Log juga akan direkodkan dalam redo log. Dengan menyimpan log buat asal dalam memori, keperluan menulis semula log ke cakera sebelum menulisnya dielakkan.
Log Buat Semula yang mengandungi operasi Buat Asal Log kelihatan seperti ini: Rekod 1: Buat asal sisipan log
> ; Rekod 2: Rekod 3: Buat asal sisipan log
> Rekod 4: Rekod 5:
Buat asal sisipan log > Rekod 6: < ;trx3 , padam …>
C. Pada ketika ini, masih terdapat isu yang belum dijelaskan. Memandangkan Buat Semula bukan transaksional, bukankah mungkin untuk melaksanakan semula transaksi terbalik?
Memang benar. Pada masa yang sama, Innodb juga akan merekodkan operasi semasa rollback transaksi ke log buat semula. Apabila operasi rollback dilakukan, pengubahsuaian pada data direkodkan dalam Redo Log, kerana operasi rollback pada dasarnya juga mengubah suai data.
Log Buat Semula bagi transaksi yang digulung semula kelihatan seperti ini:
Rekod 1: > Rekod 2: masukkan A…>
Rekod 3: > Rekod 4: kemas kini B
…>
Rekod 5: > Rekod 6: padam C
…>
Rekod 7: masukkan C>
Rekod 8: kemas kini B kepada nilai lama>
Atas ialah kandungan terperinci Bagaimana untuk menyediakan fail log mysql buat asal log dan buat semula log. 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)
