Apakah ciri-ciri log transaksi MySQL?

1. Transaksi MySQL

Transaksi ialah ciri penting yang membezakan MySQL daripada NoSQL dan merupakan teknologi utama untuk memastikan konsistensi data dalam pangkalan data hubungan. Unit pelaksanaan asas yang terdiri daripada satu atau lebih pernyataan SQL boleh dianggap sebagai operasi transaksi pada pangkalan data. Apabila pernyataan ini dilaksanakan, sama ada kesemuanya dilaksanakan atau tiada satu pun daripadanya dilaksanakan.

Pelaksanaan urus niaga terutamanya termasuk dua operasi, komit dan pemulangan semula.

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 sama sekali. Ini adalah ciri teras transaksi itu sendiri ditakrifkan oleh atomicity;

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 untuk melaksanakan, pernyataan 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. Kembalikan data

Kegigihan

Ketahanan transaksi bermakna selepas transaksi dilakukan, perubahan dalam pangkalan data harus disimpan secara kekal, bukan sementara. Dalam erti kata lain, tidak kira apa operasi atau masa henti sistem yang berlaku, hasil pelaksanaan asal tidak akan terjejas selepas transaksi diserahkan

Ketahanan transaksi dicapai melalui log semula dalam InnoDB. Enjin penyimpanan. hubungan yang harus dikekalkan antara urus niaga Kesan antara urus niaga mesti diasingkan antara satu sama lain dan operasi setiap urus niaga tidak boleh mengganggu urus niaga lain

Memandangkan transaksi mungkin bukan sahaja mengandungi satu pernyataan SQL kemungkinan besar akan terdapat ralat semasa pelaksanaan transaksi lain mula dilaksanakan Oleh itu, penyelarasan berbilang transaksi memerlukan operasi antara urus niaga agak serupa dengan konsep penyegerakan data antara berbilang rangkaian

Mekanisme kunci

Pengasingan antara transaksi dicapai melalui mekanisme kunci Apabila transaksi perlu mengubah suai baris data tertentu dalam pangkalan data, data perlu dikunci terlebih dahulu; data yang dikunci tidak boleh digunakan oleh urus niaga lain Ia tidak menjalankan operasi dan hanya boleh menunggu urus niaga semasa untuk melakukan atau melancarkan semula untuk melepaskan kunci Dalam banyak senario, kami akan menggunakan kunci yang berbeza untuk melindungi dan menyegerakkan data, jadi mekanisme kunci tidak biasa Konsep Dalam MySQL, kunci juga boleh dibahagikan kepada jenis yang berbeza mengikut piawaian klasifikasi 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 baris semasa dikunci Operasi mengunci seluruh jadual, yang bermaksud kunci halaman; 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.

Dalam senario contoh di atas, apabila transaksi A membaca volum bacaan artikel, ia memperoleh data yang belum diserahkan 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 transaksi A membaca nilai yang diubah suai, 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.

Sebagai contoh, apabila transaksi A membaca data volum bacaan artikel dalam urutan, ia mendapat hasil yang 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.

Selepas menulis semula: Dalam transaksi A, apabila dua pertanyaan pangkalan data dilakukan mengikut keadaan tertentu, bilangan baris dalam hasil pertanyaan adalah berbeza, yang membawa kepada fenomena bacaan hantu. Perkataan asal boleh ditulis semula sebagai: Berbanding dengan bacaan hantu, bacaan tidak berulang adalah lebih seperti perubahan dalam data, iaitu perubahan dalam bilangan baris data.

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.

Kawalan Konkurensi Berbilang Versi, juga dikenali sebagai MVCC, ialah protokol kawalan serentak yang boleh menyokong berbilang versi data.

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. Pada permulaan transaksi, nombor versi sistem akan diberikan nombor versi transaksi untuk perbandingan dengan nombor versi setiap baris rekod yang ditanya.

Setiap transaksi mempunyai nombor versi sendiri Dengan cara ini, apabila operasi data dilakukan dalam transaksi, tujuan kawalan versi data dicapai melalui perbandingan nombor versi.

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

Kunci kekunci seterusnya sebenarnya adalah sejenis kunci baris, kecuali 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, seterusnya menunjukkan bahawa kedua-dua transaksi itu tidak sepenuhnya bebas. Walaupun ia boleh mengelakkan fenomena bacaan hantu, ia tidak mencapai tahap kebolehbersirian.

Syarat yang perlu untuk mencapai tahap pengasingan boleh bersiri adalah untuk mengelakkan bacaan kotor, bacaan tidak boleh berulang dan bacaan hantu, tetapi ini tidak mencukupi. 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 transaksi 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 mempelajari struktur asas MySQL, saya kini mempunyai pemahaman yang agak tepat 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 dan 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 ialah 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. Apa yang dipanggil teknologi pembalakan write-ahead (Write Ahead logging). Teknologi ini boleh mengurangkan kekerapan operasi IO dan meningkatkan kecekapan penyegaran semula data.

Pembilasan data kotor

Perlu diambil perhatian 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 disalurkan 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 dimuat semula secara berkala 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 rosak, data dalam log buat semula boleh dibaca apabila dimulakan semula dan pangkalan data boleh dipulihkan, dengan itu memastikan ketahanan transaksi dan membolehkan pangkalan data memperoleh keupayaan 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.

Apabila menulis, ia juga perlu melalui cache 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 merekodkan semua operasi kemas kini dalam pangkalan data, termasuk perubahan 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.

Walaupun kandungan storan binlog dan log semula kelihatan serupa, ia sebenarnya berbeza. 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 adalah 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 pernyataan kemas kini adalah seperti berikut:

Proses pelaksanaan pernyataan kemas kini MySQL

Seperti yang dapat dilihat daripada rajah di atas, apabila MySQL melaksanakan pernyataan kemas kini, Pernyataan dihuraikan dan dilaksanakan dalam lapisan perkhidmatan, dan data diekstrak dan disimpan dalam lapisan enjin Pada masa yang sama, binlog ditulis dalam lapisan perkhidmatan, dan log buat semula ditulis 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.

Alasan untuk mengatur penyerahan dua peringkat seperti itu secara semula jadi mempunyai alasan tersendiri. Sekarang kita boleh menganggap bahawa daripada menggunakan penyerahan dua peringkat, kita menggunakan penyerahan "peringkat 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. Jika sistem ranap selepas log buat semula ditulis tetapi sebelum binlog ditulis, maka... 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 guling balik (buat asal log)

Enjin InnoDB menyediakan log balik balik, yang digunakan untuk operasi balik balik 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 membaca pernyataan SQL yang mengandungi kemas kini data daripada log geganti dan menjalankan operasi berdasarkan pernyataan ini untuk memastikan bahawa data dalam pangkalan data tuan-hamba kekal konsisten.

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 meningkatkan kecekapan satu mesin prestasi I/O.

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.

Atas ialah kandungan terperinci Apakah ciri-ciri log transaksi MySQL?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!