it-swarm-eu.dev

Klient vyprší časový limit, zatímco dotaz MySQL zůstává spuštěn?

Zažili jsme problém, ve kterém dotaz jen pro čtení, který proběhl přes pracovní stůl MySQL, vypršel z perspektivy uživatelského rozhraní uživatele a zůstal spuštěn na serveru (a zjevně spotřebovával stále více a více zdrojů), dokud jsme nedopatřili.

Otázky

  • Existuje standardní způsob řešení tohoto problému v MySQL?
  • Existuje zásadní důvod, kterému se musíme vyhnout?
9
asthasr

Musíte se podívat, jaké výchozí hodnoty jsou platné pro vypršení časového limitu:

mysql> show variables like '%timeout';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| connect_timeout            | 10    |
| delayed_insert_timeout     | 300   |
| innodb_lock_wait_timeout   | 50    |
| innodb_rollback_on_timeout | OFF   |
| interactive_timeout        | 60    |
| net_read_timeout           | 30    |
| net_write_timeout          | 60    |
| slave_net_timeout          | 3600  |
| table_lock_wait_timeout    | 50    |
| wait_timeout               | 60    |
+----------------------------+-------+
10 rows in set (0.00 sec)

Obvykle sleduji několik proměnných časového limitu. To je velmi důležité, pokud používáte MySQL vzdáleně od MySQL Workbench, mysql klienta nebo PHP aplikace na aplikačním serveru kontaktujícím MySQL na DB serveru).

Zde je to, co dokumentace MySQL říká jedno toto nastavení:

  • wait_timeout (výchozí 28800 [8 hodin]): Počet sekund, po které server čeká na aktivitu na neinteraktivním připojení, než je uzavře. Tento časový limit platí pouze pro připojení souborů soketů TCP/IP a Unix, nikoli pro připojení vytvořená pomocí pojmenovaných kanálů nebo sdílené paměti. Při spuštění podprocesu je hodnota wait_timeout relace inicializována z globální hodnoty wait_timeout nebo z globální interaktivní_timeout hodnoty v závislosti na typu klienta (jak je definováno možností CLIENT_INTERACTIVE connect to mysql_real_connect ()). Viz také interaktivní_timeout.
  • interactive_timeout (výchozí 28800 [8 hodin]): Počet sekund, po které server čeká na aktivitu na interaktivním připojení, než ji uzavře. Interaktivní klient je definován jako klient, který používá možnost CLIENT_INTERACTIVE k mysql_real_connect (). Viz také wait_timeout.
  • net_read_timeout (výchozí 30): Počet sekund, po které se čeká na další data z připojení před přerušením čtení. Když server čte z klienta, hodnota net_read_timeout je hodnota časového limitu určující, kdy se má zrušit. Když server zapisuje klientovi, je hodnota časového limitu určující, kdy se má zrušit, net_write_timeout. Viz také slave_net_timeout.
  • net_write_timeout (výchozí 60): Počet sekund, než bude blokování zapsáno do spojení před přerušením zápisu. Viz také net_read_timeout.

Ujistěte se, že jsou tyto časové limity nastaveny dostatečně vysoko, aby vyhovovaly dotazům, které mohou běžet velmi dlouhou dobu, což může zahrnovat:

  • Hmotnost UPDATEs
  • Hmotnost DELETEs
  • ENABLE KEYS na velkém MyISAMu

Chcete-li se vypořádat s dotazy, které zůstávají spuštěny i poté, co s nimi ztratíte kontakt, musíte spustit [~ # ~] kill [~ # ~] proti ID procesu dlouhodobě spuštěného dotazu. Dokonce i s příkazem KILL budete muset čekat na jakýkoli dotaz, který je uprostřed kroků náročných na disk nebo probíhá interní mutexes.

11
RolandoMySQLDBA