Kuasai sepenuhnya proses menulis Log Binari dalam MySql

Artikel ini membawa anda pengetahuan yang berkaitan tentang proses menulis Log Binari dalam mysql, termasuk isu yang berkaitan dengan "sync_binlog", "binlog_cache_size" dan "max_binlog_cache_size".

Proses penulisan Log Perduaan

Mari kita lihat dulu penerangan dokumen rasmi tentang konfigurasi sync_binlog.

sync_binlog

命令行格式	--sync-binlog=#
系统变量	sync_binlog
影响范围	Global
动态的	Yes
SET_VAR提示适用	No
类型	Integer
默认值	1
最小值	0
最大值	2^32=4294967295

Kawal kekerapan pelayan MySQL menyegerakkan log binari ke cakera.

• sync_binlog=0: Melumpuhkan pelayan MySQL daripada menyegerakkan log binari ke cakera. Sebaliknya, pelayan MySQL bergantung pada sistem pengendalian untuk membuang log binari ke cakera dari semasa ke semasa, sama seperti ia akan melakukan mana-mana fail lain. Tetapan ini memberikan prestasi terbaik, tetapi sekiranya berlaku kegagalan kuasa atau ranap sistem pengendalian, pelayan mungkin telah melakukan transaksi yang masih belum dibuang.

• sync_binlog=1: Dayakan penyegerakan log binari ke cakera sebelum melakukan transaksi. Ini adalah tetapan paling selamat, tetapi mungkin mempunyai kesan negatif terhadap prestasi disebabkan peningkatan penulisan cakera. Sekiranya berlaku kegagalan kuasa atau kemalangan sistem pengendalian, urus niaga yang hilang dalam log binari hanya dalam keadaan yang disediakan. Ini membolehkan pemulihan automatik biasa untuk melancarkan urus niaga, sekali gus menjamin urus niaga tidak akan hilang daripada log binari.

• sync_binlog=N, iaitu nilai selain daripada 0 atau 1: Selepas N kumpulan penyerahan log binari dikumpulkan, log binari akan disegerakkan ke cakera. Sekiranya berlaku kegagalan kuasa atau ranap sistem pengendalian, pelayan mungkin telah melakukan transaksi yang masih belum dialihkan ke log binari. Tetapan ini mungkin mempunyai kesan negatif terhadap prestasi disebabkan peningkatan penulisan cakera. Nilai yang lebih tinggi meningkatkan prestasi tetapi meningkatkan risiko kehilangan data.

InnoDBUntuk mendapatkan ketahanan dan ketekalan yang terbaik dalam persediaan replikasi yang digunakan dengan transaksi, gunakan persediaan berikut:

• sync_binlog =1.
• innodb_flush_log_at_trx_commit=1.

AMARAN

Banyak sistem pengendalian dan beberapa perkakasan cakera menipu semasa curahan ke cakera beroperasi. Mereka mungkin memberitahu mysqld bahawa penyegaran telah berlaku walaupun ia belum berlaku lagi. Dalam kes ini, ketahanan transaksi tidak dijamin walaupun dengan tetapan yang disyorkan, dan dalam kes yang paling teruk, gangguan bekalan elektrik mungkin merosakkan data anda. Menggunakan cache cakera bersandarkan bateri dalam pengawal cakera SCSI atau cakera itu sendiri mempercepatkan penyegaran fail dan menjadikan operasi lebih selamat. Anda juga boleh cuba melumpuhkan caching penulisan cakera dalam cache perkakasan. InnoDB

Ringkasan

Jenis tetapan sync_binlog ialah Integer tidak ditandatangani.
• Secara amnya ia tidak akan ditetapkan kepada 0. 0 bergantung pada operasi sistem dan fsync yang tidak teratur Ia lebih berbahaya apabila berlaku kegagalan kuasa atau ranap sistem - transaksi diserahkan tetapi Log Binari tiada.
• Adalah lebih selamat untuk menetapkannya kepada 1 untuk mendapatkan ketahanan dan konsistensi maksimum yang mungkin, dan untuk memastikan replikasi dan pemulihan tuan-hamba seterusnya. Walau bagaimanapun, ia memudaratkan prestasi dan boleh ditetapkan apabila IOPS yang diperlukan oleh perniagaan tidak tinggi.
• Tujuan menetapkan nilai yang lebih besar daripada 1 adalah untuk meningkatkan prestasi Daripada melakukan transaksi, fsync adalah bersamaan dengan pembilasan kumpulan Ia adalah cara yang bijak, tetapi jika berlaku kegagalan kuasa atau ranap sistem. Log Binari akan hilang Akan ada lagi. Lebih selamat jika cakera itu sendiri menggunakan cache cakera bersandarkan bateri. Oleh itu, ia boleh ditetapkan apabila IOPS yang diperlukan oleh perniagaan adalah agak tinggi, tetapi secara amnya ia tidak akan ditetapkan terlalu besar dan boleh berada dalam julat [100, 1000].

Selain itu, melalui penerangan sync_binlog=0, kita juga secara kasarnya dapat merasakan bahawa sebenarnya, apabila transaksi diserahkan, walaupun tiada fsync serta-merta, ia sebenarnya telah ditulis ke halaman cache sistem fail , maka sebenarnya, mysql juga akan mempunyai cache untuk menyimpan Log Binari yang dijana dalam transaksi apabila transaksi berjalan.

Mari kita teruskan melihat konfigurasi berkaitan cache bagi Log Binari apabila transaksi berjalan.

saiz_cache_binlog

Saiz penimbal memori untuk menyimpan log binari berubah semasa transaksi. Nilai mestilah gandaan 4096.

Apabila pengelogan binari didayakan pada pelayan (pembolehubah sistem log_bin ditetapkan kepada HIDUP), setiap pelanggan diperuntukkan cache log binari jika pelayan menyokong sebarang enjin storan transaksi. Jika data transaksi melebihi ruang dalam penimbal memori, lebihan data disimpan dalam fail sementara. Apabila penyulitan log binari aktif pada pelayan, penimbal memori tidak disulitkan, tetapi (bermula dengan MySQL 8.0.17) mana-mana fail sementara yang digunakan untuk menyimpan cache log binari disulitkan. Selepas setiap transaksi dilakukan, cache log binari ditetapkan semula dengan mengosongkan penimbal memori dan memotong fail sementara (jika digunakan).

Jika anda kerap menggunakan transaksi yang besar, anda boleh meningkatkan saiz cache ini untuk prestasi yang lebih baik dengan mengurangkan atau menghapuskan keperluan untuk menulis fail sementara. Binlog_cache_use (pembolehubah status perkhidmatan - bilangan transaksi menggunakan cache Log Binari) dan Binlog_cache_disk_use (pembolehubah status perkhidmatan - bilangan transaksi menggunakan cache log binari sementara tetapi melebihi nilai binlog_cache_size dan menggunakan fail sementara untuk menyimpan penyata transaksi.) pembolehubah status boleh digunakan untuk melaraskan saiz pembolehubah ini. Lihat Bahagian 5.4.4, “Log Perduaan”.

binlog_cache_sizeHanya menetapkan saiz cache transaksi; saiz cache penyata dikawal oleh pembolehubah sistem binlog_stmt_cache_size.

Ringkasan

• Jenis tetapan binlog_cache_size ialah Integer tidak ditandatangani.
• digunakan untuk menunjukkan saiz yang digunakan untuk cache Log Binari semasa setiap transaksi lalai ialah 32k dan mestilah gandaan 4096. Jika nilai ini melebihi, storan fail sementara akan digunakan.
• Cuba untuk tidak menggunakan transaksi besar dalam perniagaan Jika transaksi terlalu besar, anda perlu mempertimbangkan sama ada ia munasabah. Secara amnya, tidak perlu mengubah suai binlog_cache_size, 32k sudah memadai.
• Apabila binlog_cache_size tidak mencukupi, fail sementara akan digunakan untuk penyimpanan, tetapi prestasi akan menjadi lebih rendah. Kami boleh menetapkan max_binlog_cache_size=binlog_cache_size supaya fail sementara tidak akan digunakan, yang akan diperkenalkan di bawah.

saiz_cache_binlog_maks

命令格式	--max-binlog-cache-size=#
系统变量	max_binlog_cache_size
范围	Golbal
动态的	Yes
SET_VAR提示适用	No
类型	Integer
默认值	2^64=18446744073709547520
最小值	4096
最大值	2^64=18446744073709547520
块大小	4096

Jika transaksi memerlukan lebih daripada banyak bait memori ini, pelayan akan menjana transaksi berbilang penyata yang memerlukan lebih daripada 'max_binlog_cache_size' bait ralat storan. Nilai minimum ialah 4096. Nilai maksimum yang mungkin ialah 16EiB (exbibait). Nilai maksimum yang disyorkan ialah 4GB ini kerana MySQL pada masa ini tidak boleh mengendalikan lokasi log binari yang lebih besar daripada 4GB. Nilai mestilah gandaan 4096.

max_binlog_cache_sizeHanya menetapkan saiz cache transaksi; had atas cache penyata dikawal oleh pembolehubah sistem max_binlog_stmt_cache_size.

Keterlihatan sesi max_binlog_cache_size sepadan dengan keterlihatan pembolehubah sistem binlog_cache_size, dengan kata lain, menukar nilainya hanya akan menjejaskan sesi baharu yang dimulakan selepas nilai ditukar.

Ringkasan

• max_binlog_cache_size ialah nilai selamat, biasanya ditetapkan mengikut memori yang boleh diperuntukkan oleh pelayan.

Ikhtisar

Daripada konfigurasi di atas, kita boleh membuat kesimpulan bahawa proses penulisan Log Binari adalah secara kasar:

1. Transaksi ditukar kepada runtime, put ke dalam cache Log Binari bagi setiap transaksi.
2. Selepas transaksi diserahkan, ia dilakukan mengikut konfigurasi Jika sync_binlog=1, cache akan dikeluarkan setiap kali fsync dilakukan. Jika sync_binlog=0, ia akan ditulis terus ke cache halaman fail sistem, bergantung pada sistem pengendalian untuk membuang log binari dari semasa ke semasa. Jika sync_binlog=N (N>1), ia bersamaan dengan pembilasan kelompok Sudah tentu, cache binlog yang dipegang oleh setiap transaksi akan dikeluarkan.

Jadi proses umum adalah seperti berikut:

Ringkasan

Setakat ini kita mempunyai pemahaman umum tentang proses menulis Mysql ke Binari Melalui: cache binlog yang dipegang oleh setiap transaksi -> Strategi pelaksanaan khusus boleh dikawal melalui sync_binlog.

Gunakan

• sync_binlog: Jika anda perlu mendapatkan ketahanan dan konsistensi maksimum, tetapkan kepada 1. Bagi isu prestasi, anda boleh melaraskan perkakasan dan kaedah lain jika anda menjalankan log binari, benarkan kerugian Atau jika anda kehilangan kawalan melalui kaedah lain dan ingin mengoptimumkan berdasarkan sumber pelayan semasa, tetapkannya dalam julat [100,1000].
• binlog_cahe_size: Seperti yang dinyatakan sebelum ini, perhatian perlu diberikan untuk mengawal butiran transaksi dalam perniagaan sebenar Dalam kebanyakan kes, 32k lalai sudah mencukupi.

Pembelajaran yang disyorkan: tutorial video mysql

Atas ialah kandungan terperinci Kuasai sepenuhnya proses menulis Log Binari dalam MySql. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!