MySQL FLUSH команди: Повний довідник для адміністраторів баз даних

Оператор `FLUSH` у MySQL змушує сервер перезавантажувати внутрішні кеші, закривати та повторно відкривати файли журналів, скидати лічильники стану та синхронізувати стан у пам’яті зі структурами на диску — без необхідності перезапуску сервера. Це робить його одним із найважливіших з операційної точки зору сімейств команд, доступних адміністратору бази даних.

Розуміння кожного варіанту, його точної області дії та побічних ефектів є обов’язковим знанням для виробничих середовищ. Неправильне використання `FLUSH TABLES WITH READ LOCK` у завантаженій OLTP-системі, наприклад, може спричинити загальносистемні затримки запису тривалістю в кілька хвилин. Цей довідник охоплює всі значущі варіанти `FLUSH`, включаючи відмінності в поведінці між MySQL 5.7 та 8.x, специфіку InnoDB, ризики реплікації та вимоги до привілеїв.

Чому команди FLUSH важливі у виробничому середовищі

Сервер MySQL підтримує численні структури в пам’яті для прискорення операцій: кеш підключень хостів, кеші таблиць привілеїв, дескриптори відкритих таблиць, кеші результатів запитів та буферні пули рушія зберігання. Ці кеші є авторитетними під час виконання. Коли адміністратор вносить зміни поза основним потоком — редагує таблиці привілеїв безпосередньо за допомогою `INSERT`/`UPDATE`, ротує файли журналів на рівні ОС або переміщує файли `.ibd` — уявлення сервера в пам’яті стає застарілим. Команди `FLUSH` усувають це розходження.

Ключові операційні категорії, де `FLUSH` є незамінним:

• Поширення привілеїв без перезапуску `mysqld`
• Узгоджені онлайн-резервні копії з використанням знімків на основі блокувань
• Ротація журналів у поєднанні з `logrotate` або власними скриптами
• Скидання базових показників продуктивності перед бенчмаркінгом
• Інвалідація кешу хостів після змін мережевої топології
• Примусове забезпечення довговічності рушія зберігання перед вікнами технічного обслуговування

Необхідні привілеї

Більшість варіантів `FLUSH` вимагають привілею `RELOAD`. `FLUSH TABLES WITH READ LOCK` додатково вимагає `LOCK TABLES`. У MySQL 8.0+ були введені детальні динамічні привілеї (`FLUSH_OPTIMIZER_COSTS`, `FLUSH_STATUS`, `FLUSH_TABLES`, `FLUSH_USER_RESOURCES`), що дозволяють більш гранульований контроль доступу без надання широкого привілею `RELOAD`. Завжди застосовуйте принцип найменших привілеїв при їх призначенні обліковим записам застосунків або моніторингу.

Повний довідник: команди MySQL FLUSH

1. FLUSH PRIVILEGES

“`sql

FLUSH PRIVILEGES;

“`

Ця команда перезавантажує таблиці привілеїв у пам’яті з системної бази даних `mysql` (`mysql.user`, `mysql.db`, `mysql.tables_priv`, `mysql.columns_priv`, `mysql.procs_priv`). Сервер зчитує ці таблиці під час запуску та кешує їх. Будь-який прямий DML (`INSERT`, `UPDATE`, `DELETE`) для цих таблиць обходить звичайний механізм `GRANT`/`REVOKE`, залишаючи кеш застарілим до виконання `FLUSH PRIVILEGES`.

Коли використовувати:

• Після ручного редагування таблиць привілеїв за допомогою чистого SQL замість операторів `GRANT`/`REVOKE`
• Після імпорту mysqldump, що містить прямі вставки в `mysql.user`
• Після відновлення часткової резервної копії схеми `mysql`

Важливий нюанс: При використанні операторів `GRANT`, `REVOKE`, `CREATE USER` або `DROP USER` MySQL автоматично перезавантажує таблиці привілеїв. `FLUSH PRIVILEGES` необхідний лише тоді, коли ви повністю обходите ці оператори. Виконання його без потреби є нешкідливим, але додає короткочасне блокування кешу таблиць привілеїв.

Примітка щодо реплікації: `FLUSH PRIVILEGES` записується до бінарного журналу та реплікується на репліки за замовчуванням. Зазвичай це бажана поведінка при управлінні користувачами в топології реплікації.

2. FLUSH TABLES

“`sql

FLUSH TABLES;

FLUSH TABLES tbl1, tbl2;

“`

Ця команда закриває всі поточно відкриті дескриптори файлів таблиць та видаляє їх із кешу визначень таблиць (TDC). При наступному зверненні MySQL повторно відкриває файли таблиць з диска. Це необхідно після будь-яких маніпуляцій із файлами поза основним потоком.

Коли використовувати:

• Після копіювання або заміни файлів `.frm`, `.ibd` або `.MYD`/`.MYI` на рівні ОС
• Для звільнення пам’яті кешу таблиць на серверах із дуже великим значенням `table_open_cache`
• Як передумова перед використанням `IMPORT TABLESPACE` в операціях із переносними табличними просторами InnoDB

Міркування щодо продуктивності: На сервері з тисячами відкритих таблиць `FLUSH TABLES` ненадовго отримує глобальне блокування. У системах із високим паралелізмом це може спричинити помітний стрибок затримки. Надавайте перевагу формі для конкретної таблиці (`FLUSH TABLES tbl1, tbl2`), щоб мінімізувати вплив.

3. FLUSH TABLES WITH READ LOCK (FTWRL)

“`sql

FLUSH TABLES WITH READ LOCK;

— perform backup operations

UNLOCK TABLES;

“`

Це один із найпотужніших і потенційно найбільш руйнівних варіантів `FLUSH`. Він закриває всі відкриті таблиці, очищає кеш запитів та отримує глобальне блокування читання, яке запобігає будь-яким операціям запису в усіх базах даних. Блокування зберігається до виконання `UNLOCK TABLES` або завершення сесії.

Коли використовувати:

• Перед створенням фізичної резервної копії за допомогою таких інструментів, як `mysqldump –single-transaction` (для баз даних лише з InnoDB це не потрібно — див. нижче)
• Перед використанням `mysqlpump` або `xtrabackup` у середовищах без InnoDB
• Для створення узгодженого знімка на певний момент часу для змішаних рушіїв зберігання (InnoDB + MyISAM)

Критична пастка — бази даних лише з InnoDB: Для баз даних, що використовують виключно таблиці InnoDB, `FTWRL` майже ніколи не потрібен. `mysqldump –single-transaction` відкриває транзакцію з повторюваним читанням, що забезпечує узгоджений знімок без блокування записів. Використання `FTWRL` у цьому сценарії спричиняє непотрібні затримки запису.

Ризик реплікації: Якщо `FTWRL` виконується на репліці, це блокує потік застосування SQL, спричиняючи накопичення відставання реплікації на час дії блокування. Завжди відстежуйте `Seconds_Behind_Master` після зняття блокування.

Взаємодія з блокуванням метаданих: У MySQL 5.7+ `FTWRL` очікує завершення всіх активних транзакцій перед отриманням глобального блокування. На завантаженому сервері з тривалими транзакціями це очікування може бути нескінченним. Використовуйте `SHOW PROCESSLIST` для виявлення блокуючих транзакцій перед виконанням `FTWRL`.

4. FLUSH HOSTS

“`sql

FLUSH HOSTS;

“`

MySQL підтримує кеш хостів, що фіксує історію спроб підключення, включаючи кількість невдалих автентифікацій. Коли хост накопичує більше `max_connect_errors` послідовних невдалих підключень, MySQL блокує всі наступні підключення з цього хоста до очищення запису кешу.

Коли використовувати:

• Коли легітимний хост клієнта заблокований через перевищення `max_connect_errors`
• Після вирішення мережевої проблеми, що спричинила повторні збої TCP-підключень
• Після зміни DNS-записів, що впливають на те, як сервер розпізнає імена хостів клієнтів

Альтернатива для MySQL 8.0: У MySQL 8.0+ можна також безпосередньо очистити таблицю кешу хостів:

“`sql

TRUNCATE TABLE performance_schema.host_cache;

“`

Це досягає того самого результату і є більш прозорим в автоматизованих скриптах.

Проактивне налаштування: Замість реактивного використання `FLUSH HOSTS` встановіть `max_connect_errors` на більше значення (наприклад, `10000`) або встановіть `host_cache_size = 0`, щоб повністю вимкнути кеш хостів у довірених внутрішніх мережах.

5. FLUSH STATUS

“`sql

FLUSH STATUS;

“`

Скидає більшість змінних стану сесії та глобального стану до нуля. Це включає лічильники, такі як `Com_select`, `Handler_read_rows`, `Innodb_buffer_pool_reads`, `Threads_connected` та сотні інших, доступних через `SHOW STATUS` або `performance_schema`.

Коли використовувати:

• Безпосередньо перед контрольованим бенчмарком для встановлення чистої базової лінії вимірювань
• Після зміни конфігурації (наприклад, налаштування `innodb_buffer_pool_size`) для ізоляції впливу на метрики введення-виведення
• При написанні скриптів для тестів регресії продуктивності, що порівнюють дельти лічильників до/після

Важливе обмеження: `FLUSH STATUS` не скидає всі лічильники. Змінні, такі як `Uptime`, `Uptime_since_flush_status` та певні внутрішні метрики InnoDB, не зачіпаються. Для комплексного моніторингу використовуйте безпосередньо таблиці `performance_schema`, які пропонують деталізацію за потоками та подіями, яку `FLUSH STATUS` не може забезпечити.

6. FLUSH LOGS

“`sql

FLUSH LOGS;

FLUSH BINARY LOGS;

FLUSH ERROR LOGS;

FLUSH GENERAL LOGS;

FLUSH SLOW LOGS;

FLUSH RELAY LOGS;

“`

`FLUSH LOGS` закриває та повторно відкриває всі файли журналів сервера. MySQL 5.7.2+ запровадив можливість окремого очищення конкретних типів журналів, що є значно кращим варіантом для виробничого середовища.

Коли використовувати:

• Як частина скрипту post-rotate для `logrotate`, щоб сигналізувати MySQL про відкриття нового файлу журналу після ротації старого
• Для примусового створення нового файлу бінарного журналу (еквівалент `FLUSH BINARY LOGS`), що збільшує порядковий номер бінарного журналу
• Перед архівуванням старих журналів для забезпечення запису всіх очікуваних даних на диск

Специфіка бінарного журналу: `FLUSH BINARY LOGS` створює новий файл бінарного журналу та записує `Rotate_event` до старого файлу. Це правильний спосіб сегментування бінарних журналів для архівування відновлення на певний момент часу (PITR). Поточний файл бінарного журналу та позицію можна підтвердити за допомогою `SHOW MASTER STATUS` (MySQL 5.7) або `SHOW BINARY LOG STATUS` (MySQL 8.4+).

Приклад інтеграції з 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;

“`

Попередження про застарілість: Кеш запитів MySQL був визнаний застарілим у MySQL 5.7.20 та повністю видалений у MySQL 8.0. Якщо ви використовуєте MySQL 8.0 або новішу версію, ця команда не існує.

Для середовищ MySQL 5.6/5.7, де кеш запитів ще активний:

• `FLUSH QUERY CACHE` дефрагментує пам’ять кешу запитів без видалення кешованих результатів
• `RESET QUERY CACHE` повністю видаляє всі кешовані результати запитів

Коли використовувати (лише MySQL 5.6/5.7):

• Після великої пакетної модифікації даних, що інвалідує значну частину кешованих результатів
• Коли `Qcache_free_blocks` є високим відносно `Qcache_total_blocks`, що вказує на фрагментацію
• Перед вимкненням кешу запитів (`SET GLOBAL query_cache_size = 0`) для чистого звільнення пам’яті

Сучасна альтернатива: У MySQL 8.0+ використовуйте прогрів буферного пулу InnoDB (`innodb_buffer_pool_dump_at_shutdown`, `innodb_buffer_pool_load_at_startup`) та `performance_schema` для аналізу на рівні запитів.

8. FLUSH USER_RESOURCES

“`sql

FLUSH USER_RESOURCES;

“`

Скидає лічильники ресурсів для кожного користувача, що відстежуються вбудованим обмежувачем швидкості MySQL. Ці лічильники забезпечують дотримання обмежень, визначених в операторах `CREATE USER` або `GRANT`:

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

Коли використовувати:

• Коли користувач вичерпав свою годинну квоту запитів і потребує негайного відновлення доступу до природного скидання лічильника на початку наступної години
• Після збільшення ресурсних лімітів користувача для негайного набрання чинності новими лімітами
• Під час розробки/тестування для скидання квот між тестовими запусками

Примітка: Ця команда скидає лічильники для всіх користувачів одночасно. На рівні `FLUSH` немає деталізації за окремими користувачами. Якщо потрібно скинути лічильники конкретного користувача, єдиний варіант — змінити його обліковий запис за допомогою `ALTER USER` та потім виконати `FLUSH USER_RESOURCES`.

9. FLUSH ENGINE LOGS

“`sql

FLUSH ENGINE LOGS;

“`

Примушує всі рушії зберігання скинути свої буфери очікуваних записів до відповідних файлів журналів. Для InnoDB це означає скидання буфера журналу повторного виконання (`innodb_log_buffer_size`) до файлів журналу повторного виконання InnoDB на диску.

Коли використовувати:

• Перед створенням холодної резервної копії файлів даних InnoDB для забезпечення узгодженості журналу повторного виконання
• Під час усунення несправностей рушія зберігання для виключення невідповідностей даних, пов’язаних із буфером
• Як частина контрольного списку перед обслуговуванням перед зупинкою служби MySQL

Контекст довговічності InnoDB: Параметр `innodb_flush_log_at_trx_commit` InnoDB контролює агресивність скидання журналу повторного виконання при кожному фіксуванні транзакції. `FLUSH ENGINE LOGS` є ручним перевизначенням, що примусово виконує скидання незалежно від цього параметра. Це корисно в сценаріях, де потрібна гарантована контрольна точка довговічності без фіксування транзакції.

10. FLUSH DES_KEY_FILE

“`sql

FLUSH DES_KEY_FILE;

“`

Перезавантажує файл ключів шифрування DES, вказаний параметром запуску сервера `–des-key-file`. Цей файл ключів використовувався функціями `DES_ENCRYPT()` та `DES_DECRYPT()`.

Попередження про застарілість: Функції `DES_ENCRYPT()` та `DES_DECRYPT()` були визнані застарілими у MySQL 5.7.6 та видалені у MySQL 8.0. Тому ця команда актуальна лише для застарілих інсталяцій MySQL 5.6/5.7.

Сучасна альтернатива шифрування: Використовуйте нативне шифрування даних у стані спокою MySQL (шифрування табличного простору InnoDB через `ALTER TABLE … ENCRYPTION='Y'`) у поєднанні з плагінами MySQL Keyring (`keyring_file`, `keyring_okv`, `keyring_aws`) для виробничих вимог до шифрування.

Порівняльна таблиця команд FLUSH

Реплікація та FLUSH: що реплікується

Не всі команди `FLUSH` реплікуються на сервери-репліки. Розуміння цього розмежування є критичним у топологіях HA та реплікації:

Реплікується за замовчуванням:

• `FLUSH PRIVILEGES`
• `FLUSH LOGS` (записується як `Rotate_event` у бінарний журнал)
• `FLUSH USER_RESOURCES`

Не реплікується (локальне для сесії або явно виключено):

• `FLUSH TABLES WITH READ LOCK` — ніколи не записується до бінарного журналу
• `FLUSH STATUS` — впливає лише на лічильники локального сервера
• `FLUSH HOSTS` — лише локальний кеш хостів
• `FLUSH ENGINE LOGS` — лише локальний стан рушія

Щоб запобігти реплікації конкретної команди `FLUSH` навіть тоді, коли вона зазвичай реплікується, використовуйте модифікатор `LOCAL` або `NO_WRITE_TO_BINLOG`:

“`sql

FLUSH NO_WRITE_TO_BINLOG PRIVILEGES;

FLUSH LOCAL PRIVILEGES; — equivalent shorthand

“`

Це корисно при незалежному управлінні привілеями на репліці (наприклад, додавання користувачів моніторингу, яких не повинно бути на первинному сервері).

Автоматизація операцій FLUSH за допомогою mysqladmin

Багато операцій `FLUSH` можна ініціювати з командного рядка без відкриття сесії клієнта MySQL, що корисно в завданнях cron та скриптах обслуговування:

“`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

“`

Для виробничих середовищ зберігайте облікові дані в `~/.my.cnf` з `chmod 600` замість інтерактивного передавання `-p`, або використовуйте механізм `–login-path` MySQL з `mysql_config_editor`.

Міркування щодо хостингового середовища

Можливість виконання команд `FLUSH` значною мірою залежить від хостингового середовища та рівня наданого доступу до бази даних. На плані VPS Hosting у вас зазвичай є повний root-доступ до екземпляра MySQL, що означає можливість виконання будь-якого варіанту `FLUSH`, зміни `my.cnf` та безпосереднього управління ротацією журналів. Це мінімально рекомендоване середовище для будь-якої серйозної роботи з адміністрування баз даних.

На Shared Web Hosting доступ до бази даних зазвичай обмежений непривілейованим користувачем без привілею `RELOAD`, що робить більшість команд `FLUSH` недоступними. Якщо ваш застосунок вимагає управління привілеями, контролю ротації журналів або узгоджених знімків для резервного копіювання, спільне середовище стане жорстким обмеженням.

Для високонавантажених робочих навантажень баз даних — особливо тих, що передбачають часті операції `FLUSH ENGINE LOGS` або великі буферні пули InnoDB — Dedicated Servers забезпечують пропускну здатність введення-виведення та пропускну здатність пам’яті, необхідні для того, щоб ці операції не порушували роботу. `FLUSH TABLES WITH READ LOCK` на сервері з 256 ГБ даних буферного пулу займає помітно більше часу, ніж на сервері зі швидким NVMe-сховищем та виділеними каналами введення-виведення.

Якщо ви керуєте екземпляром MySQL разом із веб-панеллю управління, VPS with cPanel надає кероване середовище, де деякі операції `FLUSH` (зокрема ротація журналів та перезавантаження привілеїв) обробляються автоматично рівнем управління базами даних панелі управління, зменшуючи потребу в ручному втручанні.

Для застосунків на основі баз даних, що потребують повної екосистеми панелі управління, перегляд доступних VPS Control Panels допоможе визначити, яка панель найкраще інтегрується з вашим робочим процесом адміністрування MySQL.

Контрольний список ключових висновків

Використовуйте цю матрицю рішень перед виконанням будь-якої команди `FLUSH` у виробничому середовищі:

• Перед `FLUSH TABLES WITH READ LOCK`: Переконайтеся, що немає активних тривалих транзакцій (`SHOW PROCESSLIST`). Перевірте, чи ваша база даних використовує лише InnoDB — якщо так, використовуйте натомість `–single-transaction`.
• Перед `FLUSH PRIVILEGES`: Переконайтеся, що ви використовуєте прямий DML для таблиць привілеїв. Якщо ви використовували `GRANT`/`REVOKE`, ця команда є надлишковою.
• Перед `FLUSH LOGS`: Переконайтеся, що ваш скрипт ротації журналів вже перемістив/перейменував старий файл журналу перед тим, як сигналізувати MySQL про його повторне відкриття.
• Перед `FLUSH HOSTS`: Спочатку визначте першопричину збоїв підключення. Очищення кешу хостів без усунення основної проблеми призведе до повторного блокування хоста.
• У MySQL 8.0+: Видаліть будь-які виклики `FLUSH QUERY CACHE` або `FLUSH DES_KEY_FILE` зі скриптів — ці команди не існують і спричинять помилки.
• У топологіях реплікації: Використовуйте `FLUSH LOCAL` або `FLUSH NO_WRITE_TO_BINLOG`, коли операція не повинна поширюватися на репліки.
• Для автоматизації: Використовуйте команди `mysqladmin flush-*` у скриптах замість відкриття повних сесій клієнта MySQL.
• Аудит привілеїв: Надавайте перевагу динамічним привілеям MySQL 8.0 (`FLUSH_STATUS`, `FLUSH_TABLES` тощо) над широким привілеєм `RELOAD` для облікових записів моніторингу та резервного копіювання.

Часті запитання

Чи потрібно виконувати FLUSH PRIVILEGES після кожного оператора GRANT або REVOKE?

Ні. `GRANT`, `REVOKE`, `CREATE USER` та `DROP USER` автоматично перезавантажують таблиці привілеїв у пам’яті. `FLUSH PRIVILEGES` необхідний лише після прямих DML-модифікацій системних таблиць `mysql` (наприклад, `UPDATE mysql.user SET …`).

Чи може FLUSH TABLES WITH READ LOCK спричинити простій застосунку?

Так. Він отримує глобальне блокування запису, що блокує всі операції `INSERT`, `UPDATE`, `DELETE` та DDL у кожній базі даних на сервері. У завантаженій OLTP-системі навіть кілька секунд `FTWRL` можуть вичерпати пули підключень та спричинити каскадні помилки застосунку. Для баз даних лише з InnoDB використовуйте `mysqldump –single-transaction`, щоб повністю уникнути цього.

Чи є FLUSH STATUS еквівалентом перезапуску сервера MySQL для цілей бенчмаркінгу?

Ні. `FLUSH STATUS` скидає більшість лічильників стану, але не очищає буферний пул InnoDB, не скидає стани підключень та не впливає на накопичену статистику `performance_schema`. Для справді чистого бенчмарку точнішим є перезапуск сервера в поєднанні з очищенням буферного пулу, хоча це непрактично у виробничому середовищі.

Чому FLUSH HOSTS не існує як окрема команда в деякій документації MySQL 8.0?

`FLUSH HOSTS` все ще працює в MySQL 8.0, але кращим методом є `TRUNCATE TABLE performance_schema.host_cache`, який є більш явним і може виконуватися без привілею `RELOAD`, якщо користувач має `DELETE` для `performance_schema`. Обидва досягають однакового результату.

Що відбувається, якщо FLUSH ENGINE LOGS виконується під час пікового навантаження запису на InnoDB?

Це примушує синхронне скидання буфера журналу InnoDB на диск, що може спричинити короткочасну затримку запису, якщо файли журналу повторного виконання знаходяться на повільному сховищі. На серверах із NVMe вплив зазвичай складає менше мілісекунди. На обертових дисках або сильно навантаженому SAN-сховищі це може спричинити помітні стрибки затримки. За можливості плануйте цю операцію на час низького трафіку.