Kontrole stanu MySQL

Ta strona jest oryginalną dokumentacją PmaControl. Zachowuje praktyczną strukturę indeksu do pracy nad optymalizacją MySQL, bez kopiowania treści zewnętrznych i bez zależności od zewnętrznego produktu.

Cel

Health check MySQL sprawdza, czy serwer jest zdrowy operacyjnie: dostępność, pojemność, spójność limitów, brak sygnałów krytycznych i minimalną jakość konfiguracji.

Najważniejsze kontrole

1. Uptime i ostatnie restarty.
2. Saturacja połączeń względem max_connections.
3. Udział odczytów z dysku względem buffer pool.
4. Tabele tymczasowe tworzone na dysku.
5. Błędy połączeń i Aborted_clients.
6. Długie blokady, deadlocki i zapytania oczekujące.
7. Wolne miejsce dla datadir, logów binarnych i redo logów.

Podstawowy SQL

SHOW GLOBAL STATUS LIKE 'Uptime';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';
SHOW ENGINE INNODB STATUS\G

Interpretacja

Health check nie powinien zwracać tylko listy czerwone/zielone. Musi wyjaśniać wpływ, priorytet i sposób potwierdzenia diagnozy.

Zacznij od identyfikacji i aktualnych danych

Zapisz nazwę hosta, wersję, rolę, czas obserwacji i wpływ na aplikację. Sprawdź całą drogę od aplikacji przez proxy do bazy: udane połączenie SQL nie dowodzi, że klienci trafiają do właściwego serwera zapisującego. Ustal ostatni zdrowy okres i powiąż restarty z wdrożeniami, zdarzeniami hosta oraz dziennikiem błędów.

SELECT NOW() AS observed_at, @@hostname AS hostname,
       VERSION() AS server_version, @@global.read_only AS read_only;
SHOW GLOBAL VARIABLES WHERE Variable_name IN (
  'max_connections', 'datadir', 'tmpdir', 'log_error'
);
SHOW GLOBAL STATUS WHERE Variable_name IN (
  'Uptime', 'Threads_connected', 'Threads_running',
  'Max_used_connections', 'Connection_errors_max_connections',
  'Aborted_clients', 'Aborted_connects', 'Innodb_log_waits',
  'Innodb_buffer_pool_reads', 'Innodb_buffer_pool_read_requests',
  'Created_tmp_tables', 'Created_tmp_disk_tables'
);

Analizuj przyrosty i presję, nie same sumy

Dla liczników rosnących używaj dwóch próbek z tego samego nieprzerwanego okresu. Udział odczytów fizycznych = ΔInnodb_buffer_pool_reads / ΔInnodb_buffer_pool_read_requests przy dodatnim mianowniku. To odczyty poza buforem, nie ocena stanu dysku; porównaj też odczyty na sekundę i opóźnienie dysku. Max_used_connections to maksimum od resetu, a Threads_connected to stan bieżący. Uśpione połączenia i aktywne zadania mają różne koszty.

Udział tabel tymczasowych na dysku jest tylko wskazówką. Przepełnienie MySQL TempTable do plików mapowanych nie jest w pełni widoczne w Created_tmp_disk_tables; niski udział nie dowodzi pracy wyłącznie w RAM. Wzrost przerwanych połączeń wymaga sprawdzenia aplikacji, limitów czasu i sieci przed uznaniem winy bazy.

Sprawdź transakcje, repliki i hosta

SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id,
       trx_rows_locked, trx_rows_modified
FROM information_schema.innodb_trx
ORDER BY trx_started
LIMIT 20;
SHOW ENGINE INNODB STATUS\G

Długa transakcja może być bezczynna, a nadal utrzymywać blokady lub opóźniać purge. Ustal właściciela i operację biznesową przed jej zatrzymaniem; wycofanie może potrwać. Na replice MySQL 8.0.22+ sprawdź SHOW REPLICA STATUS\G: odbieranie, aplikowanie, ostatnie błędy i opóźnienie. MariaDB i starszy MySQL mają polecenia oraz pola zależne od wersji. Zerowe opóźnienie nie gwarantuje świeżości; sprawdź znacznik aplikacyjny i każdy kanał.

df -h /var/lib/mysql
df -i /var/lib/mysql
vmstat 1 5

Zastąp przykładową ścieżkę rzeczywistym datadir i sprawdź osobne systemy plików dla plików tymczasowych oraz binlogów. Oceń wolne bajty, i-węzły, opóźnienie I/O, presję pamięci i aktywność swap. Pomijaj pierwszy raport vmstat przy porównywaniu okresów. Potwierdź kopie udanym odtworzeniem, zmierzonym czasem odzyskania i wymaganym punktem odzyskiwania, nie samym zakończeniem zadania.

Ustal priorytety ustaleń

Dalsza diagnostyka

• W ocenie wydajności zapisz właściciela, dowody i termin przeglądu.

Oficjalne źródła

• MySQL replication status
• MySQL internal temporary tables