Am descoperit recent că în configurațiile implicite MySQL 8, binlog.* fișierele sunt aglomerate /var/lib/mysql pe mașinile Ubuntu 20.04.

adică avem o dimensiune a bazei de date de 4,2 GB și aproximativ 500 MB binlog-uri pe zi.

Din acest motiv, rămânem puțin spațiu pe disc.

Sigur că putem dezactiva și șterge binlog-urile, dar ne întrebăm care este motivul acestei configurații implicite și dacă toate vor fi șterse (și trebuie doar să creștem puțin spațiul de stocare pe mașinile noastre).

Bănuim că nu ar trebui să fie păstrate pentru totdeauna în configurația implicită, deoarece atunci ar fi nevoie de stocare infită.

Introducere

Aceasta este de fapt o schimbare în amonte. Unele distribuții ar putea schimba setarea înapoi, dar este posibil ca majoritatea să urmeze doar în amonte.

Baza de cod este găzduită pe https://github.com/mysql/mysql-server Fișierul real în care înregistrarea binară este activată implicit este sql/sys_vars.cc

Săpând prin vina, în cele din urmă am reușit să comitem care a schimbat valoarea implicită: https://github.com/mysql/mysql-server/commit/9fa9504e5aaf68661aef2d735cecbd3c58eb7790

Menționează un articol de jurnal de lucru pentru echipa mysql: #10470. Le poți căuta aici: https://dev.mysql.com/worklog/

The Secțiunea justificare din acel articol Worklog oferă următoarele:

Motivație

Aproape toate instalațiile de producție au jurnalul binar activat pe măsură ce este utilizat pentru replicare și recuperare punct-in-time.

Având în vedere acest lucru, ar trebui să îl avem activat în mod implicit din următoarele motive:

1. Eliminăm un singur pas de configurare pentru utilizatori. 1A. Activarea acestuia mai târziu necesită o repornire mysqld.
2. Primim mai multe teste interne de producție ale serverului.
3. Putem cunoaște mai bine și putem face față impactului de performanță al jurnalului binar

Expirare

În mysql 8.0 expirarea implicită pentru fișierele jurnal este 30 de zile, guvernată de variabilă binlog_expire_logs_seconds, care este implicit 2592000 secunde. Pentru ca o purjare să aibă loc efectiv, trebuie să existe o spălare a buștenilor. Conform documentației, o curățare a jurnalului are loc automat atunci când un fișier jurnal binar este închis și începe unul nou. Dimensiunea maximă a fișierelor individuale poate fi guvernată de max_binlog_size care este max 1 GB. Cu toate acestea, există o avertizare că tranzacțiile nu sunt împărțite în fișiere jurnal și, teoretic, ar putea fi de până la 4 GB. De asemenea, puteți emite un spălați jurnalele sau a curățați jurnalele binare declarație zilnică însuți.

• Curățați jurnalele binare
• Jurnalele de expirare
• Jurnalele serverului

Configurați binlog_expire_logs_seconds. 86400 ar spune să curățați buștenii în fiecare zi. Îmi place să o prelungesc la o săptămână sau două.

Între timp, verifică max_binlog_size. Dacă doriți ca binlogurile să fie curățate zilnic și generați 5MB/zi, vă sugerez să setați acest lucru la 100M.

Purtarea după o zi și 100M ar menține utilizarea discului între 500 și 600M (sau poate este 500M și 1100M, nu știu algoritmul exact).

500 de milioane pe zi par mult. Actualizați frecvent fiecare rând dintr-un tabel mare? Sau altceva?

Sunt de acord că configurația implicită poate să nu fie cea mai bună. Există mai multe situații implicite de luat în considerare, iar instalarea nu vă întreabă ce doriți:

• Replicare (având nevoie de binlog pentru asta). „Expirare” ar fi putut fi implicit.
• Doriți „recuperare la un moment dat”. Din nou, am nevoie de binlog, dar care este o valoare implicită bună?
• Nu este nevoie de binlog.
• alte?