Mam CentOS 64bit z zainstalowanym CPanel i używam:

service mysql stop

Po prostu utrzymuje tykające okresy i nigdy nie wydaje się, że przestaje. W dziennikach po prostu publikuje wiele:

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

W err.logpliku widzę wiele z nich:

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

Kiedyś było natychmiast. Wiesz, dlaczego to robi i jak to naprawić?

Teraz muszę to zrobić, killall -9 mysqlale czy jest lepszy sposób?

Serwer jest również bardzo bardzo aktywny.

Czy to problem z konfiguracją? Czy mam zbyt wysokie ustawienia memroy?

[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

Najszybszym sposobem na zamknięcie mysql, kiedy to robi, jest po prostu uruchomienie

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

Oto dlaczego:

Plik usługi mysql ( /etc/init.d/mysql) zależy od obecności pliku gniazda. Mówiąc historycznie, sięgając wstecz do MySQL 4.0, plik gniazda czasami znika w niewytłumaczalny sposób. Utrudnia to normalne service mysql stopdziałanie.

Nie wystarczy powiedzieć

mysqladmin -uroot -p -h127.0.0.1 shutdown

ponieważ trasa mysqld woli użytkownik najbliższych jak [email protected]na root@localhostrazie TCP / IP nie jest jawnie włączone. Domyślnie mysqld wybiera najmniejszą ścieżkę oporności i łączy [email protected]się root@localhostza pomocą pliku gniazda. Jednak jeśli nie ma pliku gniazda, root@localhostnigdy się nie łączy.

Nawet dokumentacja MySQL na mysqladmin mówi:

Jeśli wykonasz zamknięcie mysqladmin podczas łączenia się z lokalnym serwerem przy użyciu pliku gniazda Unix, mysqladmin czeka na usunięcie pliku identyfikatora procesu serwera, aby upewnić się, że serwer zatrzymał się poprawnie.

Dlatego konieczne jest włączenie protokołu TCP / IP:

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

W dniu 30 września 2011 r. Napisałem własną wersję skryptu o mysqld_multinazwie mysqlservice(Zobacz mój post: Uruchamianie wielu instancji na tym samym hoście ). Służy jako wirtualny silnik do łączenia się z mysqld z różnych portów. Musisz tylko przynieść własne my.cnfz niestandardowymi parametrami. W tym skrypcie uruchamiam zamknięcia w następujący sposób:

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
}

Ale co to jest ${MYSQLD_STOP}?

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

Proszę zauważyć, że używam 127.0.0.1i wyraźny port. W ten sposób nie polegam na pliku gniazda.

Zawsze używałem mysqladmin --protocol=tcp shtudownjako właściwej alternatywy dla zamykania mysql, jeśli service mysql stopzawiesza się. Robi kill -9on mysqldi mysqld_safepowinien ostatni ostatni z ostatnich ośrodków. (Tak, powiedziałem ostatnie trzy razy).

Wiele razy mysqld usunął mysql.sock bez ostrzeżenia. Inne osoby również miały ten problem przez lata:

• Problem z zamknięciem
  • Oryginalny post: http://forums.freebsd.org/showthread.php?t=28924
  • Rozwiązanie wykorzystujące mysqladmin shutdown: http://forums.freebsd.org/showpost.php?s=8d095ca69da3daf2ad4b157c8ad95f1f&p=161653&postcount=10
• http://forums.cpanel.net/f354/cant-connect-local-mysql-server-through-socket-var-lib-mysql-mysql-sock-111-a-78444.html

EPILOG

Sekret jest taki, jak powiedziałem: Połącz się z mysql za pomocą mysqladmin przez TCP / IP ( --protocol=tcp) i wydaj shutdown. Musi to działać, ponieważ przywilej wyłączania jest mysql.userwyłącznym celem uwierzytelnionych wyłączeń. To zaoszczędziło mi kilka dni roboczych, kiedy mogłem zdalnie zamknąć komputer z systemem Windows podczas zamykania mysqld na serwerze Linux.

AKTUALIZACJA 2013-03-06 22:48 EST

Jeśli martwisz się o to, co dzieje się podczas zamykania, istnieje sposób na manipulowanie czasem zamykania i sposobem, w jaki dane są opróżniane na dysk, szczególnie jeśli masz dużo danych InnoDB w puli buforów

SUGESTIA # 1

Jeśli masz dużo brudnych stron, możesz obniżyć innodb_max_dirty_pages_pct do 0:

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Ustaw to około 15-30 minut przed wyłączeniem. To da mysqld najmniejszą możliwą ilość brudnych stron do zapisania na dysku.

SUGESTIA # 2

Domyślnie innodb_fast_shutdown wynosi 1. Istnieją trzy wartości dla tej opcji

• 0: InnoDB wykonuje powolne zamykanie, pełne czyszczenie i bufor wstawiania łączy się przed zamknięciem.
• 1: InnoDB pomija te operacje podczas zamykania, proces znany jako szybkie zamykanie.
• 2: InnoDB opróżnia logi i zamyka się na zimno, jakby MySQL się zawiesił; żadne zatwierdzone transakcje nie zostaną utracone, ale operacja odzyskiwania po awarii powoduje, że następne uruchomienie trwa dłużej.

Dokumentacja mówi dalej:

Powolne zamykanie może potrwać minuty, a nawet godziny w skrajnych przypadkach, gdy znaczne ilości danych są nadal buforowane. Użyj techniki powolnego zamykania przed aktualizacją lub obniżeniem wersji między głównymi wersjami MySQL, aby wszystkie pliki danych były w pełni przygotowane na wypadek, gdyby proces aktualizacji zaktualizował format pliku.

Użyj innodb_fast_shutdown = 2 w sytuacjach awaryjnych lub rozwiązywania problemów, aby uzyskać absolutnie najszybsze zamknięcie, jeśli dane są narażone na uszkodzenie.

Domyślne ustawienia dla innodb_max_dirty_pages_pct i innodb_fast_shutdown powinny być w większości przypadków w porządku.

Wygląda na to, że twoje pytanie nie dotyczy „jak” zamknąć MySQL, a więcej o tym, dlaczego twoje tak szybko się zamyka.

W mojej odpowiedzi na podobne pytanie przedstawiłem kilka sugestii dotyczących płynnego restartu, które pomagają poprzez zmniejszenie ilości aktywności, która musi nastąpić po zażądaniu od MySQL rozpoczęcia procesu zamykania .

Jeśli nie jesteś częstym użytkownikiem SHOW FULL PROCESSLIST;tego elementu # 1, ponieważ musisz wiedzieć, co dzieje się na twoim serwerze, co powoduje, że zamykanie jest tak wolne. Jeśli istnieją długo działające zapytania, które można bezpiecznie przerwać, możesz je zabić KILL <thread-id>.

Podsumowując inne sugestie:

Ustawienie zmiennej globalnej innodb_fast_shutdown = 1(domyślna) przyspieszy część zamknięcia programu InnoDB. Jest to jednak bezpieczne tylko w przypadku zamykania serwera z powodów niezwiązanych z przeprowadzaniem aktualizacji. Jeśli chcesz wyłączyć aktualizację, musisz ustawić ją na 0.

Korzystanie z FLUSH TABLES;wdziękiem zamyka wszystkie otwarte stoły. Zostaną one ponownie otwarte, jeśli zostaną do nich powołane kolejne zapytania, ale ta czynność powinna ostatecznie ostatecznie skrócić czas, który upływa między momentem żądania zamknięcia a czasem, w którym zamknięcie jest zakończone, ponieważ wykonuje pewne wczesne porządki i, co ważniejsze, ustawia etap na ostatni krok ...

FLUSH TABLES WITH READ LOCK;zamyka wszystkie otwarte tabele i uzyskuje wyłączną blokadę posiadaną przez bieżące połączenie klienta, która zapobiega zapisywaniu dowolnego innego połączenia do dowolnej tabeli na całym serwerze. Nie otrzymasz odpowiedzi z mysql>powrotem, dopóki nie będziesz właścicielem tej blokady, w którym to momencie możesz wysłać żądanie zamknięcia - ale nie rozłączaj się z tą sesją.

Na zajętym serwerze kroki te powinny zmniejszyć poziom aktywności na serwerze, znacznie ciszej i pomóc w sprawniejszym wyłączaniu lub ponownym uruchomieniu.

Jest prawdopodobne, że MySQL nie jest wyłącznie zamknięty, ale wykonuje czynności czyszczenia (wycofywania itp.) Podczas zamykania. Jeśli nie pozwolisz na to wszystko podczas zamykania, często będziesz musiał poczekać podczas uruchamiania.

Oto coś do obejrzenia: Zamknij mysql w jednym oknie terminala, oglądając dziennik błędów (tail -f [yourerror.log]) w innym oknie terminala. Dziennik błędów pokazuje, co robi MySQL.

Przykro mi, że słyszę o twoim doświadczeniu i mam nadzieję, że moje doświadczenie ze głupimi scenariuszami MySQL, podobnymi do tego, może ci pomóc.

Zamiast próbować wymyślić, jak zabić usługę MySQL z serwera, w niektórych przypadkach konieczne będzie sprawdzenie stanu systemu w następujący sposób, aby ustalić, czy występuje nadużycie usługi ( założenie jest oparte na pojęciu Środowisko CentOS / RHEL ):

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

Skorzystaj z poniższych informacji, aby określić średnie obciążenie systemu i najbardziej zużywające się zasoby w systemie.

Będziesz także musiał zainstalować, mytopaby uzyskać ogólny widok instrukcji SQL przetwarzanych przez system.

Aby zainstalować mytop, po prostu wykonaj następujące czynności:

 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 

(użyj dowolnego edytora tekstu, który wolisz)

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

Skomentuj go jako #"long|!" => \$config{long_nums},

chmod 555 /usr/local/bin/mytop

I dobrze jest iść z Mytopem . Użyj go, aby przejrzeć instrukcje MySQL, które blokują twoją usługę MySQL i zatrzymać je.

Wykonanie powyższych instrukcji zapewni ci następujące możliwości:

• Diagnoza stanu / kondycji twojego serwera
• Diagnoza przyczyny wąskiego gardła

Po wyeliminowaniu przyczyny wąskiego gardła powinieneś mieć łatwiejszy dzień przy próbie ponownego uruchomienia usługi MySQL. Mam nadzieję, że powyższe informacje okażą się przydatne.

Uwaga: mytop jest starożytny i nieobsługiwany. Prawdopodobnie powinieneś używać innotopna nowoczesnym systemie.

Standardowa implementacja skryptu inicjującego MySQL sygnalizuje MySQL za pomocą SIGTERM i czeka pewien czas na zamknięcie MySQL.

MySQL, po otrzymaniu SIGTERM, najpierw przestanie odbierać nowe połączenia, a następnie dokończy wykonywanie wszelkich wciąż oczekujących zapytań (może to chwilę potrwać, w zależności od obciążenia i liczby współbieżnych klientów), a następnie rozpocznie opróżnianie danych na dysk (może to zająć długi czas, znowu w zależności od obciążenia, konfiguracji, dostępnej pamięci i wyboru silnika pamięci masowej). Po zakończeniu czyszczenia danych MySQL następnie cofnie przydział pamięci przydzielonej podczas etapu inicjalizacji (może to również chwilę potrwać, w zależności od ilości pamięci przydzielonej przez MySQL), zamknąć wszystkie otwarte uchwyty plików, a następnie wywołać „exit (0)”.

Jeśli po Twojej prośbie o zamknięcie MySQL zajmuje dużo czasu, jest całkiem możliwe, że ukończenie jednego lub więcej z tych etapów zajmuje dużo czasu. Jeśli masz czas, zdecydowanie zalecamy poczekanie na zakończenie procesu (pozwoli to uniknąć utraty danych lub długich procesów odzyskiwania po ponownym uruchomieniu instancji bazy danych).

Niestety w twoim pytaniu nie ma wystarczających informacji, aby pozwolić mi zaproponować właściwe rozwiązanie twojego problemu. Mam nadzieję, że to pomoże zrozumieć problem.