Comenzile MySQL FLUSH: Referință Completă pentru Administratorii de Baze de Date

Instrucțiunea `FLUSH` din MySQL forțează serverul să reîncarce cache-urile interne, să închidă și să redeschidă fișierele de log, să reseteze contoarele de stare și să sincronizeze starea din memorie cu structurile de pe disc — fără a necesita repornirea serverului. Aceasta o face una dintre cele mai critice familii de comenzi operaționale disponibile unui administrator de baze de date.

Înțelegerea fiecărei variante, a domeniului său precis și a efectelor secundare nu este o cunoștință opțională pentru mediile de producție. Utilizarea greșită a `FLUSH TABLES WITH READ LOCK` pe un sistem OLTP aglomerat, de exemplu, poate cauza blocaje de scriere la nivel de aplicație care durează minute întregi. Această referință acoperă fiecare variantă semnificativă `FLUSH`, inclusiv diferențele de comportament între MySQL 5.7 și 8.x, implicațiile specifice InnoDB, riscurile de replicare și cerințele de privilegii.

De ce contează comenzile FLUSH în producție

Serverul MySQL menține numeroase structuri în memorie pentru a accelera operațiunile: cache-ul conexiunilor de gazdă, cache-urile tabelelor de drepturi, descriptorii de tabele deschise, cache-urile rezultatelor interogărilor și pool-urile de buffere ale motoarelor de stocare. Aceste cache-uri sunt autoritare în timpul execuției. Când un administrator face modificări în afara benzii — editând direct tabelele de drepturi cu `INSERT`/`UPDATE`, rotind fișierele de log la nivel de OS sau mutând fișiere `.ibd` — viziunea serverului din memorie devine depășită. Comenzile `FLUSH` reconciliază această divergență.

Categorii operaționale cheie unde `FLUSH` este indispensabil:

• Propagarea privilegiilor fără repornirea `mysqld`
• Backup-uri online consistente folosind snapshot-uri bazate pe blocare
• Rotația log-urilor integrată cu `logrotate` sau scripturi personalizate
• Resetarea bazei de referință pentru performanță înainte de benchmarking
• Invalidarea cache-ului de gazdă după modificări ale topologiei de rețea
• Aplicarea durabilității motorului de stocare înainte de ferestre de mentenanță

Privilegii necesare

Majoritatea variantelor `FLUSH` necesită privilegiul `RELOAD`. `FLUSH TABLES WITH READ LOCK` necesită în plus `LOCK TABLES`. În MySQL 8.0+, au fost introduse privilegii dinamice granulare (`FLUSH_OPTIMIZER_COSTS`, `FLUSH_STATUS`, `FLUSH_TABLES`, `FLUSH_USER_RESOURCES`), permițând un control al accesului mai granular fără a acorda privilegiul larg `RELOAD`. Aplicați întotdeauna principiul privilegiului minim când atribuiți acestea conturilor de aplicații sau monitorizare.

Referință completă: comenzile MySQL FLUSH

1. FLUSH PRIVILEGES

“`sql

FLUSH PRIVILEGES;

“`

Această comandă reîncarcă tabelele de drepturi din memorie din baza de date de sistem `mysql` (`mysql.user`, `mysql.db`, `mysql.tables_priv`, `mysql.columns_priv`, `mysql.procs_priv`). Serverul citește aceste tabele la pornire și le stochează în cache. Orice DML direct (`INSERT`, `UPDATE`, `DELETE`) asupra acelor tabele ocolește mecanismul normal `GRANT`/`REVOKE`, lăsând cache-ul depășit până când `FLUSH PRIVILEGES` este executat.

Când să utilizați:

• După editarea manuală a tabelelor de drepturi cu SQL brut în loc de instrucțiuni `GRANT`/`REVOKE`
• După importarea unui mysqldump care include inserări directe în `mysql.user`
• După restaurarea unui backup parțial al schemei `mysql`

Nuanță critică: Când utilizați instrucțiunile `GRANT`, `REVOKE`, `CREATE USER` sau `DROP USER`, MySQL reîncarcă automat tabelele de drepturi. `FLUSH PRIVILEGES` este necesar doar când ocoliți complet acele instrucțiuni. Rularea sa inutilă este inofensivă, dar adaugă o blocare scurtă pe cache-ul tabelelor de drepturi.

Notă privind replicarea: `FLUSH PRIVILEGES` este scris în log-ul binar și replicat către replici în mod implicit. Acesta este în general comportamentul dorit la gestionarea utilizatorilor într-o topologie de replicare.

2. FLUSH TABLES

“`sql

FLUSH TABLES;

FLUSH TABLES tbl1, tbl2;

“`

Această comandă închide toți descriptorii de fișiere de tabele deschise în prezent și îi elimină din cache-ul definițiilor de tabele (TDC). La următorul acces, MySQL redeschide fișierele de tabele de pe disc. Aceasta este esențială după orice manipulare de fișiere în afara benzii.

Când să utilizați:

• După copierea sau înlocuirea fișierelor `.frm`, `.ibd` sau `.MYD`/`.MYI` la nivel de OS
• Pentru a elibera memoria cache-ului de tabele pe servere cu o valoare `table_open_cache` foarte mare
• Ca o condiție prealabilă înainte de utilizarea `IMPORT TABLESPACE` în operațiunile de tablespace transportabil InnoDB

Considerație de performanță: Pe un server cu mii de tabele deschise, `FLUSH TABLES` achiziționează pe scurt o blocare globală. Pe sisteme cu concurență ridicată, aceasta poate cauza o creștere vizibilă a latenței. Preferați forma specifică tabelului (`FLUSH TABLES tbl1, tbl2`) pentru a minimiza impactul.

3. FLUSH TABLES WITH READ LOCK (FTWRL)

“`sql

FLUSH TABLES WITH READ LOCK;

— perform backup operations

UNLOCK TABLES;

“`

Aceasta este una dintre cele mai puternice și potențial perturbatoare variante `FLUSH`. Închide toate tabelele deschise, golește cache-ul de interogări și achiziționează o blocare globală de citire care împiedică orice operațiuni de scriere în toate bazele de date. Blocarea persistă până când `UNLOCK TABLES` este emis sau sesiunea se încheie.

Când să utilizați:

• Înainte de a face un backup fizic cu instrumente precum `mysqldump –single-transaction` (pentru bazele de date exclusiv InnoDB, aceasta este inutilă — vezi mai jos)
• Înainte de utilizarea `mysqlpump` sau `xtrabackup` în medii non-InnoDB
• Pentru a crea un snapshot consistent la un moment dat între motoare de stocare mixte (InnoDB + MyISAM)

Capcană critică — baze de date exclusiv InnoDB: Pentru bazele de date care utilizează exclusiv tabele InnoDB, `FTWRL` nu este aproape niciodată necesar. `mysqldump –single-transaction` deschide o tranzacție cu citire repetabilă care oferă un snapshot consistent fără a bloca scrierile. Utilizarea `FTWRL` în acest scenariu cauzează blocaje de scriere inutile.

Risc de replicare: Dacă `FTWRL` este executat pe o replică, blochează firul de aplicare SQL, cauzând acumularea de lag de replicare pe durata blocării. Monitorizați întotdeauna `Seconds_Behind_Master` după eliberarea blocării.

Interacțiunea cu blocările de metadate: În MySQL 5.7+, `FTWRL` așteaptă finalizarea tuturor tranzacțiilor active înainte de a achiziționa blocarea globală. Pe un server aglomerat cu tranzacții de lungă durată, această așteptare poate fi nedefinită. Utilizați `SHOW PROCESSLIST` pentru a identifica tranzacțiile blocante înainte de a executa `FTWRL`.

4. FLUSH HOSTS

“`sql

FLUSH HOSTS;

“`

MySQL menține un cache de gazde care înregistrează istoricul tentativelor de conexiune, inclusiv numărul de autentificări eșuate. Când o gazdă acumulează mai mult de `max_connect_errors` conexiuni eșuate consecutive, MySQL blochează toate conexiunile ulterioare de la acea gazdă până când intrarea din cache este ștearsă.

Când să utilizați:

• Când o gazdă client legitimă este blocată din cauza depășirii `max_connect_errors`
• După rezolvarea unei probleme de rețea care a cauzat eșecuri repetate ale conexiunilor TCP
• După modificarea înregistrărilor DNS care afectează modul în care serverul rezolvă numele de gazdă ale clienților

Alternativă MySQL 8.0: În MySQL 8.0+, puteți de asemenea trunchia direct tabelul cache-ului de gazde:

“`sql

TRUNCATE TABLE performance_schema.host_cache;

“`

Aceasta obține același rezultat și este mai transparentă în scripturile automatizate.

Configurare proactivă: În loc să vă bazați reactiv pe `FLUSH HOSTS`, setați `max_connect_errors` la o valoare mai mare (de ex., `10000`) sau setați `host_cache_size = 0` pentru a dezactiva complet cache-ul de gazde pe rețelele interne de încredere.

5. FLUSH STATUS

“`sql

FLUSH STATUS;

“`

Resetează majoritatea variabilelor de stare ale sesiunii și globale la zero. Aceasta include contoare precum `Com_select`, `Handler_read_rows`, `Innodb_buffer_pool_reads`, `Threads_connected` și sute de altele expuse prin `SHOW STATUS` sau `performance_schema`.

Când să utilizați:

• Imediat înainte de un benchmark controlat pentru a stabili o bază de măsurare curată
• După o modificare de configurare (de ex., ajustarea `innodb_buffer_pool_size`) pentru a izola efectul asupra metricilor I/O
• La scrierea testelor de regresie a performanței care compară deltele contorului înainte/după

Limitare importantă: `FLUSH STATUS` nu resetează toate contoarele. Variabile precum `Uptime`, `Uptime_since_flush_status` și anumite metrici interne InnoDB nu sunt afectate. Pentru monitorizare cuprinzătoare, utilizați direct tabelele `performance_schema`, care oferă granularitate per-fir și per-eveniment pe care `FLUSH STATUS` nu o poate furniza.

6. FLUSH LOGS

“`sql

FLUSH LOGS;

FLUSH BINARY LOGS;

FLUSH ERROR LOGS;

FLUSH GENERAL LOGS;

FLUSH SLOW LOGS;

FLUSH RELAY LOGS;

“`

`FLUSH LOGS` închide și redeschide toate fișierele de log ale serverului. MySQL 5.7.2+ a introdus posibilitatea de a goli tipuri specifice de log-uri individual, ceea ce este mult preferabil în producție.

Când să utilizați:

• Ca parte a unui script post-rotire `logrotate` pentru a semnala MySQL să deschidă un nou fișier de log după ce cel vechi a fost rotat
• Pentru a forța un nou fișier de log binar (echivalent cu `FLUSH BINARY LOGS`), care incrementează numărul de secvență al log-ului binar
• Înainte de arhivarea log-urilor vechi pentru a asigura că toate scrierile în așteptare sunt golite pe disc

Specificații log binar: `FLUSH BINARY LOGS` creează un nou fișier de log binar și scrie un `Rotate_event` în fișierul vechi. Aceasta este modalitatea corectă de a segmenta log-urile binare pentru arhivarea recuperării la un moment dat (PITR). Fișierul curent de log binar și poziția pot fi confirmate cu `SHOW MASTER STATUS` (MySQL 5.7) sau `SHOW BINARY LOG STATUS` (MySQL 8.4+).

Exemplu de integrare logrotate:

“`bash

/etc/logrotate.d/mysql

/var/log/mysql/mysql-slow.log {

daily

rotate 7

missingok

compress

postrotate

mysqladmin -u root -p flush-logs

endscript

}

“`

7. FLUSH QUERY CACHE

“`sql

FLUSH QUERY CACHE;

RESET QUERY CACHE;

“`

Avertisment de depreciere: Cache-ul de interogări MySQL a fost depreciat în MySQL 5.7.20 și eliminat complet în MySQL 8.0. Dacă rulați MySQL 8.0 sau o versiune ulterioară, această comandă nu există.

Pentru mediile MySQL 5.6/5.7 unde cache-ul de interogări este încă activ:

• `FLUSH QUERY CACHE` defragmentează memoria cache-ului de interogări fără a elimina rezultatele stocate în cache
• `RESET QUERY CACHE` elimină complet toate rezultatele de interogări stocate în cache

Când să utilizați (doar MySQL 5.6/5.7):

• După o modificare mare de date în lot care invalidează o parte semnificativă a rezultatelor stocate în cache
• Când `Qcache_free_blocks` este ridicat față de `Qcache_total_blocks`, indicând fragmentare
• Înainte de dezactivarea cache-ului de interogări (`SET GLOBAL query_cache_size = 0`) pentru a elibera memoria în mod curat

Alternativă modernă: Pe MySQL 8.0+, utilizați încălzirea pool-ului de buffere InnoDB (`innodb_buffer_pool_dump_at_shutdown`, `innodb_buffer_pool_load_at_startup`) și `performance_schema` pentru analiza la nivel de interogare în schimb.

8. FLUSH USER_RESOURCES

“`sql

FLUSH USER_RESOURCES;

“`

Resetează contoarele de resurse per utilizator urmărite de limitarea ratei încorporată în MySQL. Aceste contoare aplică limitele definite în instrucțiunile `CREATE USER` sau `GRANT`:

• `MAX_QUERIES_PER_HOUR`
• `MAX_UPDATES_PER_HOUR`
• `MAX_CONNECTIONS_PER_HOUR`
• `MAX_USER_CONNECTIONS`

Când să utilizați:

• Când un utilizator și-a epuizat cota orară de interogări și are nevoie de acces imediat restaurat înainte ca contorul să se reseteze natural la limita orei următoare
• După creșterea limitelor de resurse ale unui utilizator și dorind ca noile limite să intre în vigoare imediat
• În timpul dezvoltării/testării pentru a reseta cotele între rulările de test

Notă: Această comandă resetează contoarele pentru toți utilizatorii simultan. Nu există granularitate per utilizator la nivelul `FLUSH`. Dacă trebuie să resetați contoarele unui singur utilizator, singura opțiune este să modificați contul acestuia cu `ALTER USER` și apoi să emiteți `FLUSH USER_RESOURCES`.

9. FLUSH ENGINE LOGS

“`sql

FLUSH ENGINE LOGS;

“`

Forțează toate motoarele de stocare să golească bufferele de scriere în așteptare în fișierele lor de log respective. Pentru InnoDB, aceasta înseamnă golirea bufferului de log redo (`innodb_log_buffer_size`) în fișierele de log redo InnoDB de pe disc.

Când să utilizați:

• Înainte de a face un backup la rece al fișierelor de date InnoDB pentru a asigura consistența log-ului redo
• În timpul depanării motorului de stocare pentru a exclude inconsistențele de date legate de buffer
• Ca parte a unei liste de verificare pre-mentenanță înainte de oprirea serviciului MySQL

Contextul durabilității InnoDB: Setarea `innodb_flush_log_at_trx_commit` a InnoDB controlează cât de agresiv este golit log-ul redo la fiecare commit de tranzacție. `FLUSH ENGINE LOGS` este o suprascriere manuală care forțează o golire indiferent de acea setare. Aceasta este utilă în scenariile în care aveți nevoie de un punct de control garantat de durabilitate fără a comite o tranzacție.

10. FLUSH DES_KEY_FILE

“`sql

FLUSH DES_KEY_FILE;

“`

Reîncarcă fișierul de chei de criptare DES specificat de opțiunea de pornire a serverului `–des-key-file`. Acest fișier de chei era utilizat de funcțiile `DES_ENCRYPT()` și `DES_DECRYPT()`.

Avertisment de depreciere: Funcțiile `DES_ENCRYPT()` și `DES_DECRYPT()` au fost depreciate în MySQL 5.7.6 și eliminate în MySQL 8.0. Această comandă este prin urmare relevantă doar pe instalațiile MySQL 5.6/5.7 moștenite.

Alternativă modernă de criptare: Utilizați criptarea nativă a datelor în repaus din MySQL (criptarea tablespace InnoDB prin `ALTER TABLE … ENCRYPTION='Y'`) combinată cu plugin-urile MySQL Keyring (`keyring_file`, `keyring_okv`, `keyring_aws`) pentru cerințele de criptare în producție.

Tabel comparativ al comenzilor FLUSH

Replicare și FLUSH: ce se replică

Nu toate comenzile `FLUSH` sunt replicate pe serverele replică. Înțelegerea acestei distincții este critică în topologiile HA și de replicare:

Replicate implicit:

• `FLUSH PRIVILEGES`
• `FLUSH LOGS` (scris ca `Rotate_event` în log-ul binar)
• `FLUSH USER_RESOURCES`

Nu se replică (locale sesiunii sau excluse explicit):

• `FLUSH TABLES WITH READ LOCK` — nu este niciodată scris în log-ul binar
• `FLUSH STATUS` — afectează doar contoarele serverului local
• `FLUSH HOSTS` — doar cache-ul local de gazde
• `FLUSH ENGINE LOGS` — doar starea locală a motorului

Pentru a împiedica replicarea unei comenzi `FLUSH` specifice chiar și atunci când în mod normal ar fi replicată, utilizați modificatorul `LOCAL` sau `NO_WRITE_TO_BINLOG`:

“`sql

FLUSH NO_WRITE_TO_BINLOG PRIVILEGES;

FLUSH LOCAL PRIVILEGES; — equivalent shorthand

“`

Aceasta este utilă la gestionarea independentă a privilegiilor pe o replică (de ex., adăugarea utilizatorilor de monitorizare care nu ar trebui să existe pe primar).

Automatizarea operațiunilor FLUSH cu mysqladmin

Multe operațiuni `FLUSH` pot fi declanșate din shell fără a deschide o sesiune client MySQL, ceea ce este util în job-urile cron și scripturile de mentenanță:

“`bash

Flush binary logs

mysqladmin -u root -p flush-logs

Flush privileges

mysqladmin -u root -p flush-privileges

Flush host cache

mysqladmin -u root -p flush-hosts

Flush status counters

mysqladmin -u root -p flush-status

“`

Pentru mediile de producție, stocați credențialele în `~/.my.cnf` cu `chmod 600` în loc să transmiteți `-p` interactiv, sau utilizați mecanismul `–login-path` al MySQL cu `mysql_config_editor`.

Considerații privind mediul de hosting

Capacitatea de a executa comenzi `FLUSH` depinde în mare măsură de mediul de hosting și de nivelul de acces la baza de date acordat. Pe un plan de Hosting VPS, aveți de obicei acces root complet la instanța MySQL, ceea ce înseamnă că puteți executa orice variantă `FLUSH`, modifica `my.cnf` și gestiona rotația log-urilor direct. Acesta este mediul minim recomandat pentru orice activitate serioasă de administrare a bazelor de date.

Pe Hosting Web Partajat, accesul la baza de date este de obicei restricționat la un utilizator fără privilegii, fără privilegiul `RELOAD`, făcând majoritatea comenzilor `FLUSH` indisponibile. Dacă aplicația dvs. necesită gestionarea privilegiilor, controlul rotației log-urilor sau snapshot-uri consistente pentru backup, un mediu partajat va fi un blocaj definitiv.

Pentru volumuri de lucru cu baze de date cu debit ridicat — în special cele care implică operațiuni frecvente `FLUSH ENGINE LOGS` sau pool-uri mari de buffere InnoDB — Serverele Dedicate oferă debitul I/O și lățimea de bandă a memoriei necesare pentru a face aceste operațiuni non-perturbatoare. Un `FLUSH TABLES WITH READ LOCK` pe un server cu 256 GB de date în pool-ul de buffere durează măsurabil mai mult decât pe un server cu stocare NVMe rapidă și canale I/O dedicate.

Dacă gestionați o instanță MySQL alături de un panou de control web, VPS cu cPanel oferă un mediu gestionat unde unele operațiuni `FLUSH` (în special rotația log-urilor și reîncărcările de privilegii) sunt gestionate automat de stratul de gestionare a bazelor de date al panoului de control, reducând nevoia de intervenție manuală.

Pentru aplicațiile bazate pe baze de date care necesită un ecosistem complet de panou de control, consultarea Panourilor de Control VPS disponibile vă va ajuta să identificați care panou se integrează cel mai bine cu fluxul dvs. de lucru de administrare MySQL.

Listă de verificare a concluziilor cheie

Utilizați această matrice de decizie înainte de a executa orice comandă `FLUSH` în producție:

• Înainte de `FLUSH TABLES WITH READ LOCK`: Confirmați că nu există tranzacții de lungă durată active (`SHOW PROCESSLIST`). Verificați dacă baza dvs. de date este exclusiv InnoDB — dacă da, utilizați `–single-transaction` în schimb.
• Înainte de `FLUSH PRIVILEGES`: Confirmați că utilizați DML brut pe tabelele de drepturi. Dacă ați folosit `GRANT`/`REVOKE`, această comandă este redundantă.
• Înainte de `FLUSH LOGS`: Asigurați-vă că scriptul dvs. de rotație a log-urilor a mutat/redenumit deja fișierul de log vechi înainte de a semnala MySQL să îl redeschidă.
• Înainte de `FLUSH HOSTS`: Identificați mai întâi cauza principală a eșecurilor de conexiune. Golirea cache-ului de gazde fără a remedia problema de bază va duce la blocarea din nou a gazdei.
• Pe MySQL 8.0+: Eliminați orice apeluri `FLUSH QUERY CACHE` sau `FLUSH DES_KEY_FILE` din scripturi — aceste comenzi nu există și vor cauza erori.
• În topologiile de replicare: Utilizați `FLUSH LOCAL` sau `FLUSH NO_WRITE_TO_BINLOG` când operațiunea nu ar trebui să se propage la replici.
• Pentru automatizare: Utilizați comenzile `mysqladmin flush-*` în scripturi în loc să deschideți sesiuni complete de client MySQL.
• Auditarea privilegiilor: Preferați privilegiile dinamice MySQL 8.0 (`FLUSH_STATUS`, `FLUSH_TABLES` etc.) față de privilegiul larg `RELOAD` pentru conturile de monitorizare și backup.

Întrebări frecvente

FLUSH PRIVILEGES trebuie rulat după fiecare instrucțiune GRANT sau REVOKE?

Nu. `GRANT`, `REVOKE`, `CREATE USER` și `DROP USER` reîncarcă automat tabelele de drepturi în memorie. `FLUSH PRIVILEGES` este necesar doar după modificările DML directe ale tabelelor de sistem `mysql` (de ex., `UPDATE mysql.user SET …`).

FLUSH TABLES WITH READ LOCK poate cauza întreruperi ale aplicației?

Da. Achiziționează o blocare globală de scriere care blochează toate operațiunile `INSERT`, `UPDATE`, `DELETE` și DDL în fiecare bază de date de pe server. Pe un sistem OLTP aglomerat, chiar și câteva secunde de `FTWRL` pot epuiza pool-urile de conexiuni și cauza erori în cascadă ale aplicației. Pentru bazele de date exclusiv InnoDB, utilizați `mysqldump –single-transaction` pentru a evita complet acest lucru.

FLUSH STATUS este același lucru cu repornirea serverului MySQL în scopuri de benchmarking?

Nu. `FLUSH STATUS` resetează majoritatea contorelor de stare, dar nu șterge pool-ul de buffere InnoDB, nu resetează stările conexiunilor sau nu afectează statisticile acumulate `performance_schema`. Pentru un benchmark cu adevărat de la zero, o repornire a serverului combinată cu ștergerea pool-ului de buffere este mai precisă, deși impractică în producție.

De ce FLUSH HOSTS nu există ca o comandă de sine stătătoare în unele documentații MySQL 8.0?

`FLUSH HOSTS` funcționează în continuare în MySQL 8.0, dar metoda preferată este `TRUNCATE TABLE performance_schema.host_cache`, care este mai explicită și poate fi executată fără privilegiul `RELOAD` dacă utilizatorul are `DELETE` pe `performance_schema`. Ambele obțin același rezultat.

Ce se întâmplă dacă FLUSH ENGINE LOGS este executat în timpul unui vârf de scriere pe InnoDB?

Forțează o golire sincronă a bufferului de log InnoDB pe disc, ceea ce poate cauza un scurt blocaj de scriere dacă fișierele de log redo se află pe stocare lentă. Pe serverele cu stocare NVMe, impactul este de obicei sub milisecundă. Pe discuri rotative sau stocare SAN puternic încărcată, poate cauza creșteri vizibile ale latenței. Programați această operațiune în ferestre cu trafic redus când este posibil.