Kuasai sepenuhnya prinsip MySQL dan reka bentuk seni bina enjin storan InnoDB

Artikel ini membawakan anda pengetahuan yang berkaitan tentang reka bentuk seni bina enjin storan InnoDB dalam prinsip mysql saya harap ia akan membantu anda.

Struktur komponen InnoDB:

1. kolam penimbal: kolam penimbal, data cakera cache

2. buat semula log penimbal: merekodkan operasi pada kumpulan penimbal dan menulis pada cakera mengikut dasar untuk mengelakkan kehilangan data akibat masa henti tetapi transaksi telah diserahkan

3. buat asal log : apabila data dalam kumpulan penimbal diproses Semasa membuat pengubahsuaian, anda boleh melancarkan semula urus niaga sebelum ia dilakukan Nilai lama ditulis pada fail log batal untuk memudahkan pengembalian pada masa ini pool tidak konsisten dengan yang ada dalam cakera, iaitu data kotor

1. >

perlu dikemas kini kepada pangkalan data Apakah operasi yang akan dilakukan oleh InnoDB?

update users set name = 'lisi' where id = 1

Pertama, InnoDB akan menentukan sama ada id data = 1 wujud dalam kumpulan penimbal Jika ia tidak wujud, ia akan dimuatkan daripada cakera ke dalam kumpulan penimbal. dan ia juga akan Menambah kunci eksklusif pada data baris untuk menghalang berbilang SQL daripada mengubah suai data baris pada masa yang sama.

2. Buat asal fail log

Anggap id = 1. Nilai asal nama data ini ialah name = 'zhangsan' . Sekarang Kami ingin mengemas kini kepada name = 'lisi', maka kami perlu menulis nilai lama name='zhangsan' dan id=1 ke fail log batal. Bagi pelajar yang biasa dengan pangkalan data, mereka semua memahami konsep transaksi Sebelum transaksi diserahkan, semua operasi boleh ditarik balik, iaitu nama = 'lisi' boleh digulung semula kepada nama =. 'zhangsan' , jadi nilai sebelum kemas kini ditulis pada fail log buat asal.

3. Kemas kini data kumpulan penimbal

Selepas fail log buat asal ditulis, mula mengemas kini entri ini dalam data memori. Kemas kini nama = 'zhangsan' dengan id = 1 kepada nama = 'lisi'. Pada masa ini, data dalam memori telah dikemas kini, tetapi data pada cakera tidak berubah Pada masa ini, data kotor yang tidak konsisten muncul.

Pada masa ini, anda mungkin mempunyai soalan Jika transaksi diserahkan, tetapi perkhidmatan MySQL tidak berfungsi, dan data dalam memori belum ditulis ke cakera, adakah ia akan Menyebabkan kehilangan data dan menyebabkan ketidakkonsistenan dalam data pelaksanaan SQL?

4. buat semula log penimbal

Dalam struktur InnoDB, terdapat penampan semula log untuk menyimpan semula log, sebagai contoh, id =1, name ='zhangsan' ditukar kepada name='lisi' dan ia adalah log.

Tetapi pada masa ini, penimbal log semula hanya wujud dalam ingatan, dan pemulihan data selepas MySQL dimatikan tidak dapat direalisasikan.

5 Jika urus niaga tidak diserahkan, adakah akan ada kesan jika pangkalan data turun?

Malah, ia tidak mempunyai kesan Transaksi tidak diserahkan, yang bermaksud bahawa pelaksanaan tidak berjaya Walaupun selepas MySQL ranap atau terputus, data yang diubah suai dalam kumpulan penimbal dan buat semula log penimbal dalam ingatan akan hilang, dan tidak akan memberi kesan Tidak menjejaskan konsistensi data. Jika komit transaksi gagal, data dalam pangkalan data tidak akan berubah.

6. Hantar transaksi, strategi konfigurasi log buat semula

Apabila menyerahkan transaksi, log buat semula akan melaksanakan buat semula mengikut strategi Log ditulis ke cakera daripada penimbal log buat semula. Dasar ini dikonfigurasikan melalui innoDB_flush_log_at_trx_commit.

Parameter innoDB_flush_log_at_trx_commit ialah 0. Walaupun selepas transaksi dilakukan, log buat semula tidak akan ditulis pada cakera. Selepas MySQL ranap, data dalam memori akan hilang.

Parameter innoDB_flush_log_at_trx_commit ialah 1. Selepas transaksi diserahkan, log buat semula akan dipadamkan daripada memori ke cakera, selagi transaksi berjaya diserahkan, log buat semula mesti wujud pada cakera.

Pada masa ini, walaupun jika data dalam kumpulan penimbal tidak disalurkan ke cakera, anda masih boleh mengetahui data yang telah diubah suai daripada log buat semula, dan MySQL ditutup dan dimulakan semula Selepas itu, data yang diubah suai boleh dipulihkan daripada log buat semula.

1. Parameter innoDB_flush_log_at_trx_commit ialah 2. Selepas urus niaga diserahkan, log buat semula hanya kekal dalam cache os dan belum disiram ke cakera, sekiranya perkhidmatan tidak berfungsi pada masa ini. Kemudian data dalam cache os juga akan hilang Walaupun transaksi berjaya dihantar, data akan hilang.

Selepas membacanya, saya percaya bahawa untuk memastikan keselamatan data, parameter 1 ialah strategi terbaik.

7 Penyerahan terakhir transaksi, binlog

binlog sebenarnya adalah fail log milik Pelayan MySQL, dan ia dicadangkan di sini kerana ia mempunyai hubungan yang besar dengan persatuan log semula.

1) Perbezaan antara biglog dan buat semula log

• buat semula log: merekodkan semula log dengan sifat fizikal separa, seperti "halaman data mana Yang direkodkan, apakah pengubahsuaian telah dibuat?"

• binlog: berat sebelah terhadap log logik, seperti: "Lakukan satu baris data dengan id=10 dalam jadual pengguna Selepas operasi kemas kini, apakah nilai selepas kemas kini?"

2) Semasa menyerahkan transaksi, tulis binlog pada masa yang sama

Semasa melakukan kemas kini, innoDB dan Pelaksana sentiasa berinteraksi, termasuk memuatkan data ke dalam kumpulan penimbal, menulis fail log batal, mengemas kini data memori, menulis log buat semula dan mengepam ke cakera. Penulisan kepada binlog juga dilakukan oleh pelaksana.

Langkah 1, 2, 3 dan 4 ialah perkara yang anda lakukan apabila anda melaksanakan kenyataan kemas kini dan langkah 5 dan 6 ialah perkara yang anda lakukan apabila anda melakukan transaksi.

3) Analisis strategi siram log Binlog

Parameter sync_binlog mengawal strategi siram binlog

1. Nilai lalai sync_binlog ialah 0, selepas transaksi dihantar , log binlog akan disimpan dalam cache os Selepas MySQL dimatikan, data dalam cache os akan hilang

2. Nilai sync_binlog ialah 1. Selepas transaksi. diserahkan, log binlog disiram terus ke tengah cakera.

4) Lengkapkan penyerahan transaksi berdasarkan binlog dan buat semula log

Selepas binlog ditulis ke cakera, lokasi dan nama fail fail log binlog akan ditulis untuk buat semula fail log, dan tulis tanda komit dalam fail log buat semula.

5) Apakah kepentingan teg komit? Teg

commit bermaksud untuk memastikan log buat semula dan log binlog konsisten. Jika penyerahan transaksi bermula pada langkah 5 atau langkah 6, MySQL tidak berfungsi, dan tiada tanda komit dalam log buat semula, penyerahan transaksi gagal.

bermakna tanda komit ialah transaksi akhirnya berjaya dilakukan.

8. Kumpulan penimbal Data kotor dialihkan ke cakera

Data kotor disiram ke cakera secara rawak oleh benang IO latar belakang.

Pada masa ini, saya terfikir tentang apa yang perlu dilakukan jika MySQL rosak sebelum memancarkan cakera? Pada masa ini, transaksi telah berjaya dihantar, dan terdapat tanda komit dalam log buat semula Walaupun ia tidak berfungsi, selepas dimulakan semula, data akan dikemas kini ke dalam memori mengikut fail log buat semula, menunggu IO. benang untuk menyiram cakera.

9 Ringkasan

Selepas melaksanakan analisis melalui pernyataan kemas kini, kami mengetahui bahawa enjin storan InnoDB mengandungi kolam penimbal kolam penimbal, penimbal semula log dan cache lain data. Fail log seperti undo dan reod log, serta fail log MySQL Server.

Apabila melaksanakan pernyataan kemas kini, kumpulan penimbal, menulis fail log batal, menulis penimbal log buat semula dan operasi lain akan diubah suai apabila transaksi diserahkan, log buat semula akan dipadamkan, binlog akan dipadamkan , dan nama fail binlog akan ditulis dan kedudukan, tulis tanda komit, dan akhirnya tunggu benang IO untuk secara rawak mengepam data kotor dalam kumpulan penimbal.

Pembelajaran yang disyorkan: tutorial video mysql

Atas ialah kandungan terperinci Kuasai sepenuhnya prinsip MySQL dan reka bentuk seni bina enjin storan InnoDB. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!