Automatycznie uruchom ponownie mysql, gdy umiera

Mam serwer typu rack, który wynajmowałem, aby realizować moje osobiste projekty. Ponieważ jestem tani, ma 256 MB pamięci RAM i szczerze mówiąc, nie mogę sobie z tym poradzić. Od czasu do czasu, gdy następuje gwałtowny wzrost ruchu, serwer decyduje się na rozpoczęcie procesu zabijania i wydaje się, że mysqld jest popularnym narzędziem do zabijania. Próbuję odwiedzić moją witrynę i zostaje mi przywitany komunikat o błędzie podczas nawiązywania połączenia z bazą danych. Przegląd dzienników ujawnia, że ​​mysqld został zabity z powodu braku pamięci.

Ponieważ wciąż jestem tak biedny jak wczoraj i nie chcę uaktualniać pamięci RAM maszyny Wirtualnej w przestrzeni dyskowej, czy jest sposób, aby powiedzieć mu, aby automatycznie uruchamiała mysqld po jego śmierci?

Mam pomysł, aby użyć czegoś takiego jak crontab, ale niestety, nie wiem też dokładnie, co tam zrobić. Wydaje mi się, że jestem produktem generacji „Linux na twoim pulpicie”, ponieważ mogę robić większość rzeczy na moim komputerze stacjonarnym i laptopie (który działa prawie wyłącznie na Linuksie), ale wciąż brakuje wielu umiejętności administrowania serwerami w systemie Linux.

Serwer działa w CentOS 6.3

To nie jest czyste rozwiązanie, oczywiście lepiej byłoby przede wszystkim uniknąć problemu. W każdym razie nie jestem pewien, jak CentOS zarządza usługami, ale myślę, że z nich korzysta service. Jeśli tak, możesz sprawdzić, czy mysqlusługa działa

/sbin/service mysql status

To polecenie zakończy się pomyślnie, jeśli mysqljest uruchomione, i zwróci stan wyjścia inny niż 0, jeśli ja nie. Możesz zatem uruchomić usługę, jeśli nie jest uruchomiona za pomocą tego polecenia:

/sbin/service mysql status || service mysql start

Możesz dodać ten wiersz, aby /etc/crontabco minutę uruchamiać polecenie:

* * * * * /sbin/service mysql status || service mysql start

To trochę niepokojące.

mysqld jest zawsze restartowany przez mysqld_safe, ponieważ w dolnej części znajduje się nieskończona pętla,mysqld_safeaby sprawdzić nieprawidłowe zamykanie. Jeśli błąd jest zbyt poważny, nawetmysqld_safenie będzie mógł zrestartować sięmysqldprzy kolejnych próbach.

Biorąc pod uwagę tę sytuację, dla której mysqld_safezostała zaprojektowana, wymuszenie mysqlduruchomienia może nie być dobrym pomysłem, jeśli mysqld_safei tak ją odrzuci.

Musisz zlokalizować dziennik błędów w my.cnf, który będzie poniżej

[mysqld]
log-error=log-filename

lub

[mysqld_safe]
log-error=log-filename

Przeczytaj plik tekstowy (prawdopodobnie przez uruchomienie tail -30 log-filename) i znajdź źródło zamykania przetwarzania mysqld.

W próbie brutalnej siły, aby utrzymać rzeczy i działa na VPS niskiej pamięci, użyłem modyfikację terdom za odpowiedź sprawdzić i restart MySQL.

/sbin/service mysqld status || service mysqld restart

Musiałem się zmienić, mysqlżeby mysqldgo uruchomić. Bez niego dostałbym błąd „ ERROR! MySQL is running but PID file could not be found”.

W moim systemie CentOS 7.2 /sbin/serviceprzekierowuje do /bin/systemctl status, więc szybsze wykonanie następującego polecenia jest szybsze.

/bin/systemctl status  mysqld.service || /bin/systemctl start  mysqld.service

Skończyło się na dodaniu następującej linii do crontab systemu root. Sprawdza co minutę, czy MySQL jest uruchomiony i przekierowuje standardowe wyjście na zero. Uruchomienie usługi niczego nie wyświetli, chyba że coś pójdzie nie tak, więc nie trzeba dodawać przekierowania zerowego do ostatniego polecenia.

* * * * * /bin/systemctl status mysqld.service > /dev/null || /bin/systemctl start  mysqld.service

Podwójna rura ||oznacza ORi wykona 2. polecenie, jeśli pierwsze polecenie jakoś się nie powiedzie. (Zwraca kod wyjścia większy niż zero.)

To tak, jakby powiedzieć: „Uruchom pierwszą komendę lub , jeśli pierwsza komenda jakoś się nie powiedzie, uruchom drugą komendę”.

Jest to odmienne od podwójnego znaku handlowego i , &&który jest jak powiedzenie: „Uruchom pierwsze polecenie i , tylko jeśli pierwsze polecenie zakończyło się powodzeniem, uruchom drugie polecenie”.

Następujące dane pochodzą z witryny jonnyreeves.co.uk :

A winowajcą jest php-fpm! Szybki Google znalazł kolejnego klienta Wordpress cierpiącego na podobne objawy; rada polegała na poprawieniu konfiguracji puli php-fpm (/etc/php-fpm.d/www.conf) i poprawieniu konfiguracji pm. Główną zmianą było przejście od pm = dynamiccelu pm = ondemando pm.max_childrenwartości 5(w oparciu o obserwację ~ 5% zużycie pamięci na pracownika). Po zmianie konfiguracji zrestartowałem wszystkie usługi i sprawdziłem użycie pamięci.

service php-fpm restart
service nginx restart
service mariadb restart

Po ponownym uruchomieniu zużycie pamięci było znacznie niższe.