it-swarm-eu.dev

Jak správně zabít MySQL?

Mám nainstalovaný CentOS 64bit s CPanel a používám:

service mysql stop

To jen udržuje tikání období a nikdy se zdá, že se zastaví. V protokolech to jen posílá spoustu:

130303 17:42:38 [Warning] /usr/sbin/mysqld: Forcing close of thread

V err.log soubor, vidím spoustu z nich:

[Warning] /usr/sbin/mysqld: Forcing close of thread

Bylo to okamžité. Nějaký nápad, proč to dělá a jak to opravit?

Teď musím udělat killall -9 mysql ale existuje lepší způsob?

Server je také velmi velmi aktivní.

Je to problém s konfigurací? Mám nastavení paměti příliš vysoké?

[mysqld]
default-storage-engine=MyISAM
local-infile=0
symbolic-links=0
skip-networking
max_connections = 500
max_user_connections = 20
key_buffer = 512M
myisam_sort_buffer_size = 64M
join_buffer_size = 64M
read_buffer_size = 12M
sort_buffer_size = 12M
read_rnd_buffer_size = 12M
table_cache = 2048
thread_cache_size = 16K
wait_timeout = 30
connect_timeout = 15
tmp_table_size = 64M
max_heap_table_size = 64M
max_allowed_packet = 64M
max_connect_errors = 10
query_cache_limit = 1M
query_cache_size = 64M
query_cache_type = 1
low_priority_updates=1
concurrent_insert=ALWAYS
log-error=/var/log/mysql/error.log
tmpdir=/home/mysqltmp
myisam_repair_threads=4
[mysqld_safe]
open_files_limit = 8192
log-error=/var/log/mysql/error.log

[mysqldump]
quick
max_allowed_packet = 512M

[myisamchk]
key_buffer = 64M
sort_buffer = 64M
read_buffer = 16M
write_buffer = 16M
31
Tiffany Walker

Nejkrásnější způsob, jak vypnout mysql, když to dělá, je prostě spustit

mysqladmin -uroot -p -h127.0.0.1 --protocol=tcp shutdown

Zde je proč:

Soubor služeb mysql (/etc/init.d/mysql) spoléhá na přítomnost souboru soketu. Historicky vzato, až k MySQL 4.0, soubor soketu někdy nevysvětlitelně zmizí. To brání standardní service mysql stop z práce.

Nestačí to říct

mysqladmin -uroot -p -h127.0.0.1 shutdown

protože mysqld nasměruje uživatele přicházejícího jako [email protected] to [email protected] pokud TCP/IP není explicitně povoleno. Ve výchozím nastavení vybere mysqld nejmenší cestu odporu a připojí [email protected] to [email protected] prostřednictvím souboru soketu. Pokud však neexistuje soubor soketu, [email protected] se nikdy nepřipojí.

Dokonce i dokumentace MySQL na mysqladmin říká toto:

Pokud při připojení k lokálnímu serveru pomocí souboru soketu Unix provedete vypnutí mysqladminu, mysqladmin počká, dokud nebude odstraněn soubor ID procesu serveru, aby se zajistilo, že se server správně zastavil.

Proto je nezbytné povolit TCP/IP:

mysqladmin -uroot -p -h127.0.0.1 --protocol=tcp shutdown

Zpět 30. září 2011 jsem si vytvořil vlastní verzi mysqld_multi s názvem mysqlservice (Viz můj příspěvek: Spuštění více instancí na stejném hostiteli ). Slouží jako virtuální stroj pro připojení k mysqld z různých portů. Musíte si přinést vlastní my.cnf s přizpůsobenými parametry. V tomto skriptu vydávám vypínání takto:

stop() {
  ${ECHO} -n $"Stopping ${PROGNAME}"
  ${MYSQLD_STOP}
  ATTEMPTS=0
  STOPPING_MYSQLD=1
  MINUTES_TO_TRY=10
  (( TICKS_TO_TRY = MINUTES_TO_TRY*240 ))
  while [ ${STOPPING_MYSQLD} -eq 1 ]
  do
    ${ECHO} -n "."
    ${SLEEP} 0.25
    MYSQLD_HAS_BEEN_SHUTDOWN=`${TAIL} ${MYSQL_ERROR_LOG} | ${GREP} -c "Shutdown complete$"`
    (( ATTEMPTS++ ))
    if [ ${ATTEMPTS} -eq ${TICKS_TO_TRY}   ] ; then STOPPING_MYSQLD=0 ; fi
    if [ ${MYSQLD_HAS_BEEN_SHUTDOWN} -eq 1 ] ; then STOPPING_MYSQLD=2 ; fi
  done
  ${ECHO}
  if [ ${STOPPING_MYSQLD} -eq 2 ]
  then
    ${ECHO} "Stopped ${PROGNAME}"
  else
    ${TAIL} -30 ${MYSQL_ERROR_LOG}
  fi
}

Co je ale ${MYSQLD_STOP}?

MYSQL_CONN="-uroot -p<rootpassword> -P${MYSQLD_PORT} -h127.0.0.1 --protocol=tcp"
MYSQLD_STOP="${MYSQLADMIN} ${MYSQL_CONN} shutdown"

Všimněte si prosím, že používám 127.0.0.1 a explicitní port. Tímto způsobem se nespoléhám na soubor soketu.

Vždy jsem používal mysqladmin --protocol=tcp shtudown jako správná alternativa k vypínání mysql, pokud service mysql stop visí. Děláme kill -9 na mysqld and mysqld_safe mělo by být poslední z posledních středisek. (Ano, řekl jsem třikrát).

Mysqld mnohokrát smazal mysql.sock bez varování. Ostatní lidé měli tento problém také v průběhu let:

EPILOG

Tajemství je stejné, jak jsem uvedl: Připojte se k mysql pomocí mysqladmin přes TCP/IP (--protocol=tcp) a vydejte shutdown. To musí fungovat, protože oprávnění k vypnutí je v mysql.user za výhradním účelem ověřených vypínání. Tím se můj pracovní den několikrát zachránil, když jsem byl schopen vypnout vzdálené vypnutí z mého počítače Windows, když jsem vypínal mysqld na Linuxovém serveru.

AKTUALIZACE 2013-03-06 22:48 EST

Pokud máte obavy z toho, co se děje během vypínání, existuje způsob, jak manipulovat s vypínacím časem a způsobem, jakým jsou data propláchnuta na disk, zejména pokud máte ve vyrovnávací paměti spoustu dat InnoDB.

NÁVRH # 1

Pokud máte hodně špinavých stránek, můžete snížit innodb_max_dirty_pages_pct na 0:

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Nastavte toto asi 15-30 minut před vypnutím. To umožní mysqld co nejmenšímu počtu špinavých stránek zapsat na disk.

NÁVRH # 2

Ve výchozím nastavení innodb_fast_shutdown je 1. Pro tuto možnost existují tři hodnoty

  • 0: InnoDB provede před vypnutím pomalé vypnutí, úplné vymazání a vložení vyrovnávací paměti.
  • 1: InnoDB přeskočí tyto operace při vypnutí, což je proces známý jako rychlé vypnutí.
  • 2: InnoDB propláchne své protokoly a vypne se za studena, jako by došlo k selhání MySQL; nedojde ke ztrátě žádných potvrzených transakcí, ale operace obnovy po havárii prodlouží další spuštění.

Dokumentace dále říká toto:

Pomalé vypnutí může trvat i minuty nebo dokonce hodiny v extrémních případech, kdy je stále velké množství dat ve vyrovnávací paměti. Před upgradem nebo downgradováním mezi hlavními vydáními MySQL použijte techniku ​​pomalého vypnutí, takže všechny datové soubory jsou plně připraveny v případě, že proces aktualizace aktualizuje formát souboru.

Použijte innodb_fast_shutdown = 2 v případě nouze nebo řešení problémů, abyste dosáhli absolutně nejrychlejšího vypnutí, pokud jsou data ohrožena poškozením.

Výchozí hodnoty pro innodb_max_dirty_pages_pct a innodb_fast_shutdown by ve většině případů měly být v pořádku.

38
RolandoMySQLDBA

Zní to, jako by se vaše otázka netýkala „jak“ vypnout MySQL a více o tom, proč se vaše vypíná tak pomalu.

V moje odpověď na podobnou otázk , jsem nabídl několik návrhů pro hladký restart, které pomáhají snížením množství aktivity, které se musí stát poté, co požádáte o zahájení MySQL proces vypnutí .

Pokud nejste častým uživatelem SHOW FULL PROCESSLIST; to je položka # 1, protože musíte mít představu o tom, co se děje na vašem serveru, což způsobuje tak pomalé vypínání. Pokud existují dlouhodobé dotazy, které lze bezpečně přerušit, můžete je zabít pomocí KILL <thread-id>.

Shrnutí dalších návrhů:

Nastavení globální proměnné innodb_fast_shutdown = 1 (výchozí) urychlí část vypnutí InnoDB. To je pouze bezpečné, pokud však vypínáte server z důvodů, které nesouvisejí s prováděním upgradu. Pokud vypínáte upgrade, musí být toto nastaveno na 0.

Použitím FLUSH TABLES; elegantně zavře všechny otevřené tabulky. Budou znovu otevřeny, pokud se na ně budou odkazovat následující dotazy, ale tato akce by měla nakonec nakonec zkrátit dobu, která uplyne mezi časem, kdy požadujete vypnutí, a časem, kdy je vypnutí ukončeno, protože to provádí nějaké předčasné úklidové práce, a co je důležitější, určuje fázi pro poslední krok ...

FLUSH TABLES WITH READ LOCK; zavře všechny otevřené tabulky a získá exkluzivní zámek ve vlastnictví vašeho aktuálního připojení klienta, který zabrání zápisu jiného připojení do jakékoli tabulky na celém serveru. Nebudete mít svůj mysql> Dotaz zpět, dokud nevlastníte tento zámek, kdy můžete vydat požadavek na vypnutí - ale neodpojujte se od této relace.

Na zaneprázdněném serveru by tyto kroky měly snížit úroveň aktivity na serveru, měly by věci mnohem tišší a měly by pomoci hladšímu vypnutí nebo restartu.

5

Je pravděpodobné, že MySQL není čistě uzamčeno, ale při vypínání provádí čištění (vrácení zpět atd.). Pokud to nedovolíte, aby to všechno při vypínání, často budete muset počkat, až se rozběhne.

Zde je něco, na co se podívat: Vypněte mysql v jednom terminálovém okně a sledujte protokol chyb (tail -f [yourerror.log]) v jiném terminálovém okně. Protokol chyb vám ukáže, co MySQL dělá.

Je mi líto, že jsem slyšel o vašich zkušenostech a doufám, že vám moje zkušenosti s hloupými scénáři MySQL, podobné tomuto, vám mohou pomoci.

Namísto pokusu zjistit, jak zabít službu MySQL ze serveru, v některých případech budete muset zkontrolovat zdraví vašeho systému pomocí následujícího, abyste zjistili, zda došlo ke zneužití služby ( ) předpoklad je založen na představě o prostředí CentOS/RHEL ):

 /usr/bin/iostat
 /usr/bin/uptime
 top -c

K určení průměrného zatížení systému a nejnáročnějších zdrojů v systému použijte následující.

Budete také muset nainstalovat mytop, abyste získali celkový pohled na příkazy SQL, které systém zpracovává.

Chcete-li nainstalovat mytop, jednoduše proveďte následující:

 cd /root
 wget http://jeremy.zawodny.com/mysql/mytop/mytop-1.6.tar.gz
 tar -zxvf /root/mytop-1.6.tar.gz
 cd /root/mytop-1.6
 Perl Makefile.pl
 make
 make install
 chmod 644 /usr/local/bin/mytop
 vi /usr/local/bin/mytop 

(použijte libovolný textový editor, který dáváte přednost)

Hledat "long|!" => \$config{long_nums},

Přidejte komentář jako #"long|!" => \$config{long_nums},

chmod 555 /usr/local/bin/mytop

A je dobré jít s mytop. Použijte jej pro kontrolu příkazů MySQL, které jsou ve vaší službě MySQL, a zastavte je.

Provedení výše uvedených pokynů vám poskytne následující možnosti:

  • Diagnostika stavu/stavu vašeho serveru
  • Diagnóza příčiny úzkého hrdla

Jakmile odstraníte příčinu úzkého hrdla, měli byste mít snazší den, když se pokusíte restartovat službu MySQL. Doufám, že výše uvedené informace najdete jako užitečné.

Poznámka:mytop je starověké a neudržované. Pravděpodobně byste měli použít innotop na moderním systému.

1
Michael Feng

Standardní implementace iniciačního skriptu MySQL signalizuje MySQL pomocí SIGTERM a čeká určitou dobu, než se MySQL vypne.

MySQL poté, co obdrží SIGTERM, nejprve přestane přijímat nová připojení a poté dokončí provádění všech nevyřízených dotazů (to může chvíli trvat, v závislosti na vaší pracovní zátěži a počtu souběžných klientů), pak začněte proplachovat data na disk (to může trvat dlouhou dobu, opět v závislosti na vaší pracovní zátěži, konfiguracích, dostupné paměti a možnostech úložiště). Po dokončení veškerého propláchnutí dat MySQL poté přidělí jakoukoli paměť, která byla přidělena během inicializační fáze (může to také chvíli trvat, v závislosti na množství paměti přidělené MySQL), zavřít všechny otevřené popisovače souborů a poté zavolat "exit (0)".

Pokud po vaší žádosti o vypnutí MySQL trvá dlouho, než se vypne, je docela možné, že dokončení jedné nebo více těchto fází trvá dlouho. Pokud máte čas, důrazně doporučujeme počkat na dokončení procesu (při opakovaném spuštění instance databáze se vyhnete ztrátě dat nebo dlouhým procesům obnovy).

Ve vaší otázce bohužel není dostatek informací, které by mi umožnily navrhnout správné řešení vašeho problému. Doufám, že to pomůže pochopit problém.

0
LMC