Mari analisa log transaksi MySQL bersama-sama

Artikel ini membawa anda pengetahuan yang berkaitan tentang mysql, yang terutamanya memperkenalkan isu-isu yang berkaitan dengan transaksi mysql adalah ciri penting yang membezakan MySQL daripada NoSQL dan memastikan data pangkalan data hubungan Teknologi utama ketekalan, Saya harap ia akan membantu semua orang.

Pembelajaran yang disyorkan: tutorial video pembelajaran mysql

1 Transaksi MySQL

Transaksi ialah perkara yang membezakan MySQL NoSQL Ciri penting ialah teknologi utama untuk memastikan ketekalan data pangkalan data hubungan. Transaksi boleh dianggap sebagai unit pelaksanaan asas operasi pangkalan data, yang mungkin termasuk satu atau lebih pernyataan SQL. Apabila pernyataan ini dilaksanakan, sama ada kesemuanya dilaksanakan atau tiada satu pun daripadanya dilaksanakan.

Pelaksanaan urus niaga terutamanya termasuk dua operasi, komit dan tarik balik.

Serah: komit, tulis keputusan pelaksanaan transaksi ke pangkalan data.

Kembali: gulung balik, gulung semula semua pernyataan yang dilaksanakan dan kembalikan data sebelum pengubahsuaian.

Transaksi MySQL merangkumi empat ciri, dikenali sebagai empat raja ACID.

Atomicity: Penyata sama ada dilaksanakan sepenuhnya atau tidak dilaksanakan langsung.

Ketahanan: memastikan bahawa data tidak akan hilang kerana masa henti dan sebab lain selepas penyerahan transaksi; terutamanya berdasarkan log buat semula: memastikan pelaksanaan transaksi adalah sebaik mungkin mungkin Tidak terjejas oleh urus niaga lain; Tahap pengasingan lalai InnoDB ialah RR Pelaksanaan RR terutamanya berdasarkan mekanisme kunci, lajur tersembunyi data, log batal dan mekanisme kunci kunci seterusnya: Konsistensi: urus niaga merealisasikan konsistensi memerlukan jaminan peringkat pangkalan data dan jaminan peringkat aplikasi Sama seperti operasi atom, ini bermakna urus niaga tidak boleh dibahagikan sama ada semua operasi atau tiada operasi dilakukan jika pernyataan SQL dalam transaksi gagal laksanakan, penyataan yang dilaksanakan juga mesti digulung semula, dan pangkalan data kembali ke keadaan sebelum urus niaga hanya 0 dan 1, tiada nilai lain

Keatomisan transaksi menunjukkan bahawa urus niaga adalah keseluruhan . Apabila urus niaga tidak dapat dilaksanakan dengan jayanya, semua penyata yang telah dilaksanakan dalam urus niaga perlu digulung semula untuk membuat pemulangan pangkalan data Apabila urus niaga perlu ditarik balik, enjin InnoDB akan memanggil log buat asal Pernyataan SQL. Pemulihan semula data urus niaga itu dilakukan, sebarang operasi lain atau masa henti sistem tidak akan menjejaskan hasil pelaksanaan transaksi asal Kegigihan transaksi adalah melalui enjin storan InnoDB dilaksanakan

Pengasingan

Atomicity dan ketahanan adalah sifat satu transaksi itu sendiri, manakala pengasingan merujuk kepada hubungan yang harus dikekalkan antara urus niaga jangan campur tangan antara satu sama lain, dan operasi satu urus niaga diasingkan daripada urus niaga lain Oleh kerana urus niaga mungkin bukan sahaja mengandungi satu penyata SQL, jadi kemungkinan besar transaksi lain akan mula dilaksanakan semasa pelaksanaan urus niaga. Oleh itu, penyelarasan berbilang transaksi memerlukan operasi antara urus niaga diasingkan antara satu sama lain Ini agak serupa dengan konsep penyegerakan data antara berbilang rangkaian 🎜>

Pengasingan antara transaksi dicapai melalui mekanisme kunci Apabila transaksi perlu mengubah suai baris data tertentu dalam pangkalan data, ia perlu diubah suai terlebih dahulu pada data yang dikunci dan hanya boleh menunggu urus niaga semasa untuk melakukan atau melancarkan semula untuk melepaskan kunci

Mekanisme penguncian bukanlah konsep yang tidak biasa dan digunakan dalam banyak senario yang berbeza bagi penguncian digunakan untuk melindungi dan menyegerakkan data. Dalam MySQL, kunci juga boleh dibahagikan kepada jenis yang berbeza mengikut piawaian bahagian yang berbeza.

Dibahagikan mengikut butiran: kunci baris, kunci meja, kunci halaman

Dibahagikan mengikut penggunaan: kunci kongsi, kunci eksklusif

Terbahagi mengikut idea: pesimis kunci , Kunci Optimis

Terdapat banyak perkara pengetahuan tentang mekanisme penguncian, saya akan membincangkan semuanya. Berikut ialah pengenalan ringkas kepada kunci dibahagikan mengikut butiran.

Kebutiran: merujuk kepada tahap penghalusan atau kekomprekan data yang disimpan dalam unit data gudang data. Semakin tinggi tahap pemurnian, semakin kecil tahap perincian, sebaliknya, semakin rendah tahap pemurnian, semakin besar tahap perincian.

MySQL boleh dibahagikan kepada kunci baris, kunci jadual dan kunci halaman mengikut butiran kunci.

Kunci baris: kunci dengan butiran terkecil, menunjukkan bahawa hanya baris operasi semasa dikunci; kebutiran terbesar, menunjukkan bahawa operasi semasa mengunci seluruh jadual

Kunci halaman: Kunci dengan butiran antara kunci peringkat baris dan kunci peringkat meja, yang bermaksud mengunci halaman.

Pembahagian pangkalan data berbutir

Tiga jenis kunci mengunci data pada tahap yang berbeza Disebabkan perbezaan dalam butiran, ia membawa kelebihan dan keburukan juga berbeza.

Kunci jadual akan mengunci keseluruhan jadual semasa mengendalikan data, jadi prestasi serentak adalah lemah

Kunci baris hanya mengunci data yang perlu dikendalikan dan prestasi serentak adalah; baik. Walau bagaimanapun, memandangkan mengunci dirinya sendiri menggunakan sumber (mendapatkan kunci, menyemak kunci, melepaskan kunci, dll. semua menggunakan sumber), menggunakan kunci meja boleh menjimatkan banyak sumber apabila terdapat banyak data terkunci.

Enjin storan yang berbeza dalam MySQL menyokong kunci yang berbeza. MyIsam hanya menyokong kunci meja, manakala InnoDB menyokong kedua-dua kunci meja dan kunci baris Atas sebab prestasi, kunci baris digunakan dalam kebanyakan kes.

Masalah membaca dan menulis serentak

Dalam situasi serentak, pembacaan dan penulisan MySQL serentak boleh menyebabkan tiga jenis masalah, bacaan kotor, tidak berulang dan bacaan hantu .

(1) Bacaan kotor: Transaksi semasa membaca data tidak terikat daripada transaksi lain, iaitu data kotor.

Contohnya, dalam rajah di atas, apabila transaksi A membaca volum bacaan artikel, ia membaca data yang dihantar oleh transaksi B. Jika transaksi B tidak berjaya diserahkan pada akhirnya, menyebabkan transaksi itu ditarik balik, maka jumlah bacaan sebenarnya tidak berjaya diubah suai, tetapi nilai yang diubah suai dibaca dalam transaksi A, yang jelas tidak munasabah.

(2) Bacaan tidak boleh berulang: Data yang sama dibaca dua kali dalam transaksi A, tetapi keputusan kedua-dua bacaan adalah berbeza. Perbezaan antara bacaan kotor dan bacaan tidak boleh berulang ialah yang pertama membaca data tidak terikat oleh transaksi lain, manakala yang kedua membaca data yang telah diserahkan oleh transaksi lain.

Contohnya, dalam rajah di atas, apabila transaksi A membaca data volum bacaan artikel satu demi satu, hasilnya berbeza. Ini bermakna semasa pelaksanaan transaksi A, nilai volum bacaan telah diubah suai oleh transaksi lain. Ini menjadikan keputusan pertanyaan data tidak lagi boleh dipercayai dan juga tidak realistik.

(3) Bacaan hantu: Dalam transaksi A, pangkalan data disoal dua kali mengikut keadaan tertentu Bilangan baris dalam dua hasil pertanyaan adalah berbeza Fenomena ini dipanggil bacaan hantu. Perbezaan antara bacaan tidak berulang dan bacaan hantu boleh difahami dengan mudah sebagai: yang pertama bermakna data telah berubah, manakala yang kedua bermakna bilangan baris data telah berubah.

Contohnya, dalam gambar di atas, apabila menanyakan artikel dengan 0

Tahap Pengasingan

Berdasarkan tiga masalah di atas, empat tahap pengasingan dijana, menunjukkan darjah sifat pengasingan pangkalan data yang berbeza.

Dalam reka bentuk pangkalan data sebenar, semakin tinggi tahap pengasingan, semakin rendah kecekapan konkurensi pangkalan data dan jika tahap pengasingan terlalu rendah, ia akan menyebabkan pangkalan data gagal semasa proses membaca dan menulis Anda akan menghadapi semua jenis masalah yang tidak kemas.

Oleh itu, dalam kebanyakan sistem pangkalan data, tahap pengasingan lalai dibaca komited (seperti Oracle) atau bacaan berulang RR (enjin InnoDB MySQL).

MVCC

Satu lagi ketul kenyal. MVCC digunakan untuk melaksanakan tahap pengasingan ketiga di atas, yang boleh membaca RR berulang kali.

MVCC: Kawalan Pertukaran Berbilang Versi, protokol kawalan penukaran berbilang versi.

Ciri MVCC ialah pada masa yang sama, transaksi berbeza boleh membaca versi data yang berbeza, sekali gus menyelesaikan masalah bacaan kotor dan bacaan tidak berulang.

MVCC sebenarnya mencapai kewujudan bersama berbilang versi data melalui lajur tersembunyi data dan log balik (buat asal log). Kelebihan ini ialah apabila menggunakan MVCC untuk membaca data, tidak perlu mengunci, sekali gus mengelakkan konflik membaca dan menulis serentak.

Apabila melaksanakan MVCC, beberapa lajur tersembunyi tambahan akan disimpan dalam setiap baris data, seperti nombor versi dan masa pemadaman apabila baris semasa dibuat dan penuding balik ke log buat asal. Nombor versi di sini bukan nilai masa sebenar, tetapi nombor versi sistem. Setiap kali transaksi baharu dimulakan, nombor versi sistem dinaikkan secara automatik. Nombor versi sistem pada permulaan transaksi akan digunakan sebagai nombor versi transaksi, yang digunakan untuk membandingkan dengan nombor versi setiap baris rekod dalam pertanyaan.

Setiap transaksi mempunyai nombor versinya sendiri, supaya apabila operasi data dilakukan dalam transaksi, kawalan versi data dicapai melalui perbandingan nombor versi.

Selain itu, tahap pengasingan RR yang dilaksanakan oleh InnoDB boleh mengelakkan fenomena bacaan hantu, yang dicapai melalui mekanisme kunci kunci seterusnya.

Kunci kekunci seterusnya sebenarnya ialah sejenis kunci baris, tetapi ia bukan sahaja mengunci rekod baris semasa itu sendiri, tetapi juga mengunci julat. Contohnya, dalam contoh bacaan hantu di atas, apabila anda mula menanyakan artikel dengan 0

Kunci jurang: Sekat jurang dalam rekod indeks

Walaupun InnoDB menggunakan kunci kekunci seterusnya untuk mengelakkan masalah bacaan hantu, ia bukanlah pengasingan yang benar-benar boleh bersiri. Mari lihat contoh lain.

Mula-mula tanya soalan:

Pada masa T6, selepas transaksi A melakukan transaksi, teka jumlah bacaan artikel A dan artikel B Untuk berapa?

Jawapannya ialah isipadu bacaan artikel AB telah diubah suai kepada 10,000. Ini bermakna penyerahan transaksi B sebenarnya mempengaruhi pelaksanaan transaksi A, menunjukkan bahawa kedua-dua transaksi tidak diasingkan sepenuhnya. Walaupun ia boleh mengelakkan fenomena bacaan hantu, ia tidak mencapai tahap kebolehbersirian.

Ini juga menunjukkan bahawa mengelakkan bacaan kotor, bacaan tidak berulang dan bacaan hantu adalah syarat yang perlu tetapi tidak mencukupi untuk mencapai tahap pengasingan bersiri. Kebolehan bersiri boleh mengelakkan bacaan kotor, bacaan tidak berulang dan bacaan hantu, tetapi mengelakkan bacaan kotor, bacaan tidak berulang dan bacaan hantu tidak semestinya mencapai kebolehbersirian.

Konsistensi

Konsistensi bermaksud bahawa selepas transaksi dilaksanakan, kekangan integriti pangkalan data tidak dimusnahkan, dan keadaan data adalah sah sebelum dan selepas transaksi itu dilaksanakan.

Konsistensi ialah matlamat utama yang diusahakan oleh urus niaga Atomicity, ketahanan dan pengasingan sebenarnya wujud untuk memastikan ketekalan status pangkalan data.

Saya tidak akan bercakap banyak lagi. Anda rasa dengan teliti.

2. Sistem log MySQL

Setelah memahami seni bina asas MySQL, anda secara amnya boleh mempunyai pemahaman yang lebih jelas tentang proses pelaksanaan MySQL. Seterusnya saya akan memperkenalkan sistem pembalakan kepada anda.

Sistem pengelogan MySQL ialah komponen penting dalam pangkalan data dan digunakan untuk merekodkan kemas kini dan pengubahsuaian kepada pangkalan data. Jika pangkalan data gagal, data asal pangkalan data boleh dipulihkan melalui rekod log yang berbeza. Oleh itu, sebenarnya, sistem log secara langsung menentukan keteguhan dan keteguhan operasi MySQL.

MySQL mempunyai banyak jenis log, seperti log binari (binlog), log ralat, log pertanyaan, log pertanyaan perlahan, dll. Selain itu, enjin storan InnoDB juga menyediakan dua jenis log: log semula ( buat semula log) dan buat asal log (log balik). Di sini kita akan menumpukan pada enjin InnoDB dan menganalisis tiga jenis log buat semula, log rollback dan log binari.

Log buat semula (log semula)

Log buat semula (log buat semula) ialah log lapisan enjin InnoDB Ia digunakan untuk merekodkan perubahan dalam data yang disebabkan oleh operasi transaksi ialah pengubahsuaian fizikal halaman data.

Fungsi redo diary ni sebenarnya senang nak faham, biar saya guna analogi. Pengubahsuaian data dalam pangkalan data adalah seperti kertas yang anda tulis Bagaimana jika kertas itu hilang satu hari? Untuk mengelakkan kejadian malang ini, semasa menulis kertas, kita boleh menyimpan buku nota kecil untuk merekodkan setiap pengubahsuaian, dan merekodkan bila dan jenis pengubahsuaian yang dibuat pada halaman tertentu. Ini adalah log buat semula.

Apabila enjin InnoDB mengemas kini data, ia mula-mula menulis rekod kemas kini ke log buat semula, dan kemudian mengemas kini kandungan dalam log ke cakera apabila sistem melahu atau mengikut strategi kemas kini yang ditetapkan. Ini adalah apa yang dipanggil teknologi write-ahead (Write Ahead logging). Teknologi ini boleh mengurangkan kekerapan operasi IO dan meningkatkan kecekapan penyegaran semula data.

Pembilasan data kotor

Perlu diingat bahawa saiz log buat semula ditetapkan Untuk terus menulis rekod kemas kini, dalam buat semula Dua kedudukan bendera ditetapkan dalam log, checkpoint dan write_pos, yang masing-masing menunjukkan kedudukan pemadaman direkodkan dan kedudukan di mana penulisan direkodkan. Gambar rajah penulisan data log semula boleh dilihat dalam rajah di bawah.

Apabila bendera write_pos mencapai penghujung log, ia akan melompat dari hujung ke kepala log untuk penulisan edaran semula. Oleh itu, struktur logik redo log tidak linear, tetapi boleh dianggap sebagai gerakan bulat. Ruang antara write_pos dan checkpoint boleh digunakan untuk menulis data baharu Penulisan dan pemadaman dijalankan ke belakang dan ke hadapan dalam kitaran.

Apabila write_pos mengejar pusat pemeriksaan, ini bermakna log buat semula penuh. Pada masa ini, anda tidak boleh terus melaksanakan penyata kemas kini pangkalan data baharu Anda perlu menghentikan dan memadam beberapa rekod dahulu, dan melaksanakan peraturan pusat pemeriksaan untuk mengosongkan ruang boleh tulis.

Peraturan pusat pemeriksaan: Selepas pusat pemeriksaan dicetuskan, kedua-dua halaman data kotor dan halaman log kotor dalam penimbal akan dibuang ke cakera.

Data kotor: merujuk kepada data dalam memori yang belum dibuang ke cakera.

Konsep paling penting dalam redo log ialah kumpulan penimbal, iaitu kawasan yang diperuntukkan dalam ingatan dan mengandungi pemetaan beberapa halaman data dalam cakera sebagai penimbal untuk mengakses pangkalan data.

Apabila meminta untuk membaca data, ia akan terlebih dahulu menentukan sama ada terdapat pukulan dalam kumpulan penimbal. Jika terdapat kesilapan, ia akan diambil pada cakera dan dimasukkan ke dalam kumpulan penimbal; 🎜>

Apabila permintaan dibuat untuk menulis data, ia akan ditulis ke kumpulan penimbal terlebih dahulu, dan data yang diubah suai dalam kumpulan penimbal akan sentiasa dimuat semula ke cakera. Proses ini juga dipanggil memberus.

Oleh itu, apabila data diubah suai, selain mengubah suai data dalam kumpulan penimbal, operasi juga akan direkodkan dalam log buat semula apabila transaksi diserahkan, data akan dibuang mengikut rekod dalam plat log buat semula. Jika MySQL terputus, data dalam log buat semula boleh dibaca apabila dimulakan semula dan pangkalan data boleh dipulihkan, dengan itu memastikan ketahanan transaksi dan menjadikan pangkalan data selamat ranap.

Pembilasan log kotor

Selain pembilasan data kotor yang disebutkan di atas, sebenarnya, apabila log buat semula direkodkan, untuk memastikan kegigihan fail log , juga perlu melalui proses menulis rekod log dari memori ke cakera. Log buat semula log boleh dibahagikan kepada dua bahagian Satu ialah buff log buat semula log cache yang wujud dalam memori yang tidak menentu, dan satu lagi ialah fail log buat semula log yang disimpan pada cakera.

Untuk memastikan setiap rekod boleh ditulis pada log pada cakera, operasi fsync sistem pengendalian dipanggil setiap kali log dalam penimbal log buat semula ditulis pada fail log buat semula.

fungsi fsync: disertakan dalam fail pengepala sistem UNIX #include , digunakan untuk menyegerakkan semua data fail yang diubah suai dalam memori ke peranti storan.

Semasa proses penulisan, ia juga perlu melalui penimbal os ruang kernel sistem pengendalian. Proses penulisan redo log dapat dilihat pada rajah di bawah.

buat semula proses siram log

Log binari (binlog)

Binlog log binari ialah lapisan perkhidmatan log juga dipanggil log arkib. Binlog terutamanya merekodkan perubahan dalam pangkalan data, termasuk semua operasi kemas kini pangkalan data. Semua operasi yang melibatkan perubahan data mesti direkodkan dalam log binari. Oleh itu, binlog boleh menyalin dan menyandarkan data dengan mudah, jadi ia sering digunakan untuk penyegerakan perpustakaan tuan-hamba.

Kandungan yang disimpan dalam binlog di sini nampaknya sangat serupa dengan log buat semula, tetapi tidak. Log buat semula ialah log fizikal, yang merekodkan pengubahsuaian sebenar kepada data tertentu manakala binlog ialah log logik, yang merekodkan logik asal pernyataan SQL, seperti "berikan medan baris dengan ID=2; Tambah 1". Kandungan dalam log binlog adalah binari Bergantung pada parameter format log, ia mungkin berdasarkan pernyataan SQL, data itu sendiri, atau campuran kedua-duanya. Rekod yang biasa digunakan ialah pernyataan SQL.

Pemahaman peribadi saya tentang konsep fizik dan logik di sini ialah:

Log fizikal boleh dianggap sebagai maklumat perubahan pada halaman data dalam pangkalan data sebenar, dan hanya keputusan dinilai. Tidak kira "cara mana" membawa kepada hasil ini;

Log logik boleh dianggap sebagai perubahan dalam data yang disebabkan oleh kaedah atau kaedah operasi tertentu, dan menyimpan operasi logik.

Pada masa yang sama, buat semula log berdasarkan pemulihan ranap untuk memastikan pemulihan data selepas MySQL tidak berfungsi manakala binlog adalah berdasarkan pemulihan titik dalam masa untuk memastikan pelayan boleh memulihkan data berdasarkan pada titik masa, atau Buat sandaran data anda.

Malah, MySQL tidak mempunyai log semula pada mulanya. Kerana pada mulanya MySQL tidak mempunyai enjin InnoDB, enjin terbina dalam adalah MyISAM. Binlog ialah log lapisan perkhidmatan, jadi ia boleh digunakan oleh semua enjin. Walau bagaimanapun, log binlog sahaja hanya boleh menyediakan fungsi pengarkiban dan tidak dapat menyediakan keupayaan selamat ranap Oleh itu, enjin InnoDB menggunakan teknologi yang dipelajari daripada Oracle, iaitu, buat semula log, untuk mencapai keupayaan selamat ranap. Di sini, ciri-ciri log buat semula dan binlog dibandingkan masing-masing:

Perbandingan ciri-ciri log buat semula dan binlog

Apabila MySQL melaksanakan pernyataan kemas kini, Ia akan melibatkan membaca dan menulis log buat semula dan log binlog. Proses pelaksanaan kenyataan kemas kini adalah seperti berikut:

Proses pelaksanaan pernyataan kemas kini MySQL

Seperti yang dapat dilihat dari rajah di atas, apabila MySQL melaksanakan pernyataan kemas kini, ia menghuraikan dan melaksanakan pernyataan dalam perkhidmatan lapisan. Lapisan enjin mengekstrak dan menyimpan data pada masa yang sama, lapisan perkhidmatan menulis binlog dan menulis log semula dalam InnoDB.

Bukan itu sahaja, terdapat dua peringkat penyerahan semasa menulis redo log Satu ialah penulisan keadaan sediakan sebelum penulisan binlog, dan satu lagi ialah penulisan keadaan komit selepas penulisan binlog.

Sebab mengapa penyerahan dua peringkat sebegitu diatur adalah wajar. Sekarang kita boleh menganggap bahawa daripada menggunakan penyerahan dua fasa, kita menggunakan penyerahan "fasa tunggal", iaitu, sama ada tulis semula log dahulu dan kemudian tulis binlog atau tulis binlog dahulu dan kemudian tulis semula log; Penyerahan dalam dua cara ini akan menyebabkan keadaan pangkalan data asal tidak konsisten dengan keadaan pangkalan data yang dipulihkan.

Tulis log buat semula dahulu, kemudian tulis binlog:

Selepas menulis log buat semula, data mempunyai keupayaan selamat ranap pada masa ini, jadi sistem ranap dan data Ia akan dipulihkan kepada keadaan sebelum transaksi dimulakan. Walau bagaimanapun, jika sistem ranap apabila log buat semula selesai dan sebelum binlog ditulis, sistem ranap. Pada masa ini, binlog tidak menyimpan kenyataan kemas kini di atas, menyebabkan kenyataan kemas kini di atas hilang apabila binlog digunakan untuk membuat sandaran atau memulihkan pangkalan data. Akibatnya, data dalam baris id=2 tidak dikemas kini.

Masalah menulis semula log dahulu dan kemudian binlog

Tulis binlog dahulu dan kemudian buat semula log:

Selepas menulis binlog, semua pernyataan disimpan, jadi data dalam baris id=2 dalam pangkalan data yang disalin atau dipulihkan melalui binlog akan dikemas kini kepada a=1. Walau bagaimanapun, jika sistem ranap sebelum log buat semula ditulis, transaksi yang direkodkan dalam log buat semula akan menjadi tidak sah, menyebabkan data dalam baris id=2 dalam pangkalan data sebenar tidak dikemas kini.

Masalah menulis binlog dahulu dan kemudian buat semula log

Dapat dilihat bahawa penyerahan dua peringkat adalah untuk mengelakkan masalah di atas, menjadikan binlog dan buat semula log Maklumat yang disimpan dalam adalah konsisten.

Log putar balik (buat asal log)

Log putar balik juga merupakan log yang disediakan oleh enjin InnoDB Seperti namanya, fungsi log balik adalah untuk gulung semula data. Apabila urus niaga mengubah suai pangkalan data, enjin InnoDB bukan sahaja akan merekodkan log buat semula, tetapi juga menjana log buat asal yang sepadan jika pelaksanaan urus niaga gagal atau panggil balik, menyebabkan urus niaga ditarik balik, maklumat dalam log buat asal; boleh digunakan untuk memulihkan data Tatal ke cara ia kelihatan sebelum pengubahsuaian.

Tetapi buat asal log berbeza daripada buat semula log Ia adalah log logik. Ia merekodkan maklumat yang berkaitan dengan pelaksanaan pernyataan SQL. Apabila rollback berlaku, enjin InnoDB akan melakukan perkara yang bertentangan dengan kerja sebelumnya berdasarkan rekod dalam log buat asal. Sebagai contoh, untuk setiap operasi pemadaman data (insert), operasi pemadaman data (padam) akan dilakukan semasa pemulangan semula (delete), operasi pemadaman data (insert) akan dilakukan semasa rollback; kemas kini Operasi (kemas kini), apabila melancarkan semula, operasi kemas kini data terbalik (kemas kini) akan dilakukan untuk menukar kembali data. Buat asal log mempunyai dua fungsi, satu adalah untuk menyediakan rollback, dan satu lagi adalah untuk melaksanakan MVCC.

3. Replikasi tuan-hamba

Konsep replikasi tuan-hamba adalah sangat mudah untuk menyalin pangkalan data yang sama daripada pangkalan data asal dipanggil pangkalan data induk , pangkalan data yang direplikasi dipanggil pangkalan data hamba. Pangkalan data hamba akan menyegerakkan data dengan pangkalan data induk untuk mengekalkan konsistensi data antara keduanya.

Prinsip replikasi tuan-hamba sebenarnya dilaksanakan melalui log bin. Log bin log menyimpan semua pernyataan SQL dalam pangkalan data Dengan menyalin pernyataan SQL dalam log log bin dan kemudian melaksanakan pernyataan, pangkalan data hamba dan pangkalan data induk boleh disegerakkan.

Proses replikasi tuan-hamba boleh dilihat dalam rajah di bawah. Proses replikasi induk-hamba terutamanya dijalankan oleh tiga utas Satu utas penghantaran berjalan dalam pelayan induk dan digunakan untuk menghantar log binlog ke pelayan hamba. Terdapat dua utas I/O tambahan dan utas SQL yang berjalan pada pelayan hamba. Benang I/O digunakan untuk membaca kandungan log binlog yang dihantar oleh pelayan utama dan menyalinnya ke log geganti tempatan. Benang SQL digunakan untuk membaca pernyataan SQL tentang kemas kini data dalam log geganti dan melaksanakannya untuk mencapai konsistensi data antara perpustakaan induk dan hamba.

Prinsip replikasi tuan-hamba

Sebab mengapa replikasi tuan-hamba perlu dilaksanakan sebenarnya ditentukan oleh senario aplikasi sebenar. Faedah yang boleh dibawa oleh replikasi tuan-hamba adalah:

1. Sandaran data di luar tapak dicapai melalui replikasi Apabila pangkalan data induk gagal, pangkalan data hamba boleh ditukar untuk mengelakkan kehilangan data.

2. Seni bina boleh dikembangkan Apabila volum perniagaan menjadi lebih besar dan lebih besar dan kekerapan akses I/O terlalu tinggi, storan berbilang pangkalan data boleh digunakan untuk mengurangkan kekerapan akses I/O cakera dan menambah baik. I/O prestasi mesin tunggal.

3. Ia dapat merealisasikan pemisahan membaca dan menulis, supaya pangkalan data dapat menyokong keselarasan yang lebih besar.

4. Laksanakan pengimbangan beban pelayan dengan membahagikan beban pertanyaan pelanggan antara pelayan induk dan pelayan hamba.

Ringkasan

Pangkalan data MySQL harus dianggap sebagai salah satu teknologi yang mesti dikuasai oleh pengaturcara. Sama ada semasa proses projek atau semasa temu duga, MySQL adalah pengetahuan asas yang sangat penting. Walau bagaimanapun, terdapat terlalu banyak perkara untuk MySQL. Semasa saya menulis artikel ini, saya merujuk banyak maklumat dan mendapati bahawa semakin saya tidak faham, semakin saya tidak faham. Ia benar-benar sesuai dengan pepatah itu:

Lebih banyak anda tahu, lebih banyak anda tidak tahu.

Artikel ini memfokuskan pada menganalisis prinsip asas transaksi asas MySQL dan sistem pengelogan dari perspektif teori saya cuba mengelak daripada menggunakan kod sebenar untuk menerangkannya apabila menerangkannya. Malah artikel dengan hampir 10,000 perkataan dan hampir 20 ilustrasi lukisan tangan ini tidak dapat menganalisis sepenuhnya keluasan dan kedalaman MySQL.

Tetapi saya percaya bahawa untuk pemula, teori ini boleh memberi anda persepsi keseluruhan tentang MySQL dan memberi anda pemahaman yang lebih jelas tentang soalan "apa itu pangkalan data relasional" dan Bagi mereka yang mahir dalam MySQL, mungkin artikel ini juga boleh membangkitkan asas teori asas anda yang telah lama hilang, dan ia juga akan membantu untuk temu duga anda yang seterusnya.

Tiada hak atau salah mutlak dalam teknologi Mohon maaf jika terdapat sebarang kesilapan dalam artikel dan dialu-alukan untuk berbincang dengan saya. Pemikiran bebas sentiasa lebih berkesan daripada penerimaan pasif.

Pembelajaran yang disyorkan: tutorial video mysql

Atas ialah kandungan terperinci Mari analisa log transaksi MySQL bersama-sama. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!