MySQL menulis log ralat gila

Pangkalan data perniagaan teras, versinya ialah MySQL 8.34
Edisi Pelayan Komuniti. Sejak dilancarkan, log ralat pelayan pangkalan data ini telah meningkat dengan sangat pantas (seperti yang ditunjukkan dalam rajah di bawah), meningkat kepada kapasiti lebih daripada 10 G
setiap 24 jam.

Oleh kerana terdapat penggera kerosakan dan ia tidak menjejaskan akses biasa kepada perniagaan, kakitangan yang berkenaan tidak dibenarkan untuk memulakan semula perkhidmatan MySQL

. Memandangkan keadaan ini, saya terpaksa menyediakan tugas berjadual automatik untuk membersihkan log ini pada masa yang ditetapkan setiap malam. Untuk operasi tertentu, laksanakan "crontab -e"

pada baris arahan sistem dan tambah baris teks berikut:

00 01 * * * echo > Simpan dan keluar daripada mod edit Jika anda perlu mengesahkan ketepatan dan kesahihan tugas, anda boleh mengubah suai masa pelaksanaan kepada titik masa yang agak baru-baru ini, dan kemudian membandingkan fail log ralat "mysql.log" sebelum dan selepas. saiz pelaksanaan tugas, dan semak log cron

untuk melihat sama ada tugas yang dijadualkan ini telah dilaksanakan, seperti yang ditunjukkan dalam rajah di bawah.

Sekarang cuti Festival Musim Bunga, semua orang pulang ke rumah untuk menyambut Tahun Baru, dan ini adalah tempoh paling rendah untuk lawatan Dengan mengambil peluang ini, saya bercadang untuk menyelesaikan masalah ini sepenuhnya. Dapatkan pendapat daripada kakitangan yang berkaitan dan tanya sama ada boleh mengubah suai fail MySQL

pilihan untuk menyekat output amaran yang tidak berguna? Jawapannya ialah "

Berapa lama masa yang diperlukan untuk dimulakan semula"

? Jawapannya: "
Beberapa minit sudah memadai"
.

Apakah rekod log ralat yang ditakrifkan ini dalam kuantiti yang banyak? Buka "mysql.log"

fail besar dan mendapati ia penuh dengan mesej amaran Gunakan arahan sistem "tail -f mysql.log"

Output skrin bergolek seperti roda tenaga motor rajah di bawah.

Mesej amaran ini menunjukkan bahawa akaun pengguna menggunakan "mysql_native_password"

yang tidak konsisten dengan kaedah pengesahan lalai "caching_sha2_password"

. Penyelesaiannya ialah sama ada menukar kaedah pengesahan kata laluan semua akaun pengguna kepada "
caching_sha2_password"
, atau fail log ralat "mysql.log"
tidak merekodkan mesej amaran ini. Memandangkan terdapat banyak akaun pengguna dan berbilang perniagaan direka, lebih mudah untuk tidak merekodkan mesej amaran ini tidak berguna lagi (biarkan mereka merekodkan log ralat sebenar, yang akan membantu menyelesaikan masalah).

MySQL

Sistem hos Centos 7 di mana pelayan terletak,

Buka fail pilihan "/etc/my.cnf"

dalam editor teks, dan tambahkan baris teks berikut dalam blok teks [mysqld
].

log-error-verbosity=1

Secara lalai, nilai "log-error-verbosity"

MySQL 8

ialah "3"

, yang bermaksud bahawa semua "
ralat, amaran dan komen"
akan direkodkan dalam log ralat. Nombor "2
" bermaksud mengelog "kesilapan dan amaran", manakala nombor "1
" bermaksud mengelog hanya "kesilapan".

Perlu diingat bahawa sebelum mengubah suai fail pilihan, ingat untuk membuat sandaran fail terlebih dahulu Ini adalah akal dan ubat untuk penyesalan. Selepas menyemak bahawa tiada ralat penulisan, mulakan semula perkhidmatan MySQL

, dan kemudian semak sama ada perkhidmatan MySQL

tempatan adalah normal, sama ada penyegerakan master-slave jauh adalah normal dan sama ada terdapat sebarang kelewatan.

Selepas berjalan selama beberapa minit, semak log ralat MySQL

untuk melihat sama ada ia tidak lagi berkembang pesat. Selepas memerhati untuk satu tempoh masa, memang benar bahawa log amaran MySQL tidak lagi direkodkan, dan kadar pertumbuhan fail juga telah dikurangkan dengan banyak.

Atas ialah kandungan terperinci MySQL menulis log ralat gila. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!