mysql néha leáll az éjszaka folyamán

Ubuntu Linux

Sziasztok.

Van 2 db szerver (Ubuntu 16.04) amin időnként leáll a mysql. Semmi logika nincs a leállásokban, szabálytalan időközönként áll le és a két szerver között sincs összefüggés a leállások tekintetében. Csak azt vesszük észre, hogy nem fut egy alkalmazás amely a mysql-t használja és mikor megnézzük a processzek között nem fut a mysql. Ha kézzel utána elindítjuk akkor minden rendben, amíg újra le nem áll x nap múlva.
Mit érdemes megnézni, milyen logokat és abban mire érdemes figyelni hogy megtaláljuk a hibát?

  • 1905 megtekintés

( uid_17626 | 2018. 06. 27., sze – 21:41 )

log fájl mérete elérte a fájlrendszer maximumát?

( mauzi v | 2018. 06. 27., sze – 21:45 )

Oom killer?
Mi fut még a gépen a MySQL mellett?

( KicsiBocs | 2018. 06. 27., sze – 21:48 )

Minden reggel munkakezdés előtt a cron leállítaná és újraindítaná??? Tudom ez csak tűzoltás.

( banyek | 2018. 06. 28., cs – 04:57 )

En ket dolgot neznek, a mysql error logjat, hogy ha a process maga hal le, akkor kiir-e valamit, illetve a kernelet, hogy nem-e az oomkiller verte fejbe.
A tobbi ez utan johet. Ha teszel be logokat, segitek.

( uid_18247 | 2018. 06. 28., cs – 06:52 )

nem a kötekedés a célom, teljesen komolyan, de ezt nem tudom másképp megfogalmazni. hogy lehet úgy üzemeltetni egy mysql-t használó valamit, hogy egy egész csapatnak fogalma sincs, hol vannak a logok? ha FS korrupció van, akkor hány napig tart megtalálni a dmesget? ha betelik az inode-tábla, hány napba telik megtalálni a df kellő kapcsolóját? (-i)

tényleg elnézést kérek, tudom, hogy bántó, amit írtam, és peched van, amiért pont nálad gurult el a gyógyszerem, nem mintha én itt valami kurva nagy aduász lennék, aki mindenhez ért. ez egy hatalmas nagy red flag. remélem, hogy sosem kerülök e cég közelébe.

----------------------------------
szélsőségesen idealista, fősodratú hozzászólás

Multkor kerdeztem alap dolgokat valakitol, aki linux expertnek mondta magat. Ilyen kerdeskre kell gondolni:

- Mi tortenik a rendszerben, amikor egy filerendeszeren belul egy allomanyt atmozgatsz egy masik nevre ugyanabban a konyvtarban (mv alma korte)? Es mi tortenik, ha masik konyvtarba mozgatod at?
- Mit csinalnal, ha a lost+found konyvtarban egy boot utan talalsz egy "hosszuszam" nevu allomanyt? Mi az a szam?
- Mi az a sys,user,wait CPU time a "top" parancsban? Mit jelentenek?
- (!!!) Leall egy szolgalatatsod, hogy keresned meg hogy mi a hiba? (kisertetiesen hasonlit a fenti esetre :D)

Total homaly minden kerdesre. Es o expertnek gondolja magat. Es korulbelul igy van ez a jelentkezok 90%-val. Lepett be mar Linux-ra, hogy a runbook szerint elinditson egy parancsot, tehat o expert.
Egy windows felhasznalo sem expert a windows szerverekhez!!! Azert mert WoW-ozott meg nem biztos, hogy tud AD-t managelni.
De mindenki ert a Linux-hoz, mert a gnome-ban reptette mar az ablakokat. :D

Nem szokásom ilyen üzenetekre reagálni, de:
- Milyen alapon minősítesz Te engemet? Halvány lila gőzöd sincs, mivel foglalkozom, mennyire értek a Linux vagy az azon futó alkalmazások üzemeltetéséhez.
- Egy szóval nincs említve a fenti postban, hogy én vagy a cég ahol dolgozom üzemeltetné, így kicsit merész kijelentés a "sosem kerülök e cég közelébe".
- Az általunk fejlesztett alkalmazást használják melynek szüksége van egy RDBMS-re. Ennyi! De az alkalmazás mivel néha leáll a mysql nem használható. Jó ideje nem tudnak mit kezdeni a problémával, így gondoltam megpróbálok én tenni valamit az ügyben (mint mezei Linux felhasználó).
- Hogy bántó e amit írtál nézőpont kérdése. Számomra nem, mert nem az én kompetenciám érteni hozzá és megoldani a problémát. Számomra igen mert anélkül, hogy tisztában lennél a háttérrel minősítesz.
- Hozzászóltál a posthoz de a megoldáshoz nem sokkal vittél közelebb.

Gyerekek! Ez egy szakmai fórum! Szakmai kérdéseket tesznek fel. Tudsz a problémára megoldást írd le! Hülyének nézed a kérdezőt! Tartsd meg magadnak! De ne szemeteld tele a postot mert lehet valaki leírja a megoldást, és a későbbiekben ha valaki hasonló problémába fut be és megtalálja ezt a topicot, akkor ne 170 anyázós bejegyzés közül keljen kiválasztania azt az egyet amiben le van írva a megoldás

Köszönöm.
És köszönöm a szakmai hozzászólásokat is.

Megoldás: hozzáértő üzemeltetőt szerezni. A probléma ugyanis ott van, hogy a "melyik logot nézzük meg és hol" kérdés is felmerült.
A másik megoldás az, hogy ha már valami production-ben megy, akkor nem célszerű automatice cserélgetni komponenseket, pláne nem DB-t, pláne nem akkor, amikor az automatikus frissítés úgy gondolja, hogy itt az ideje... (Eddig nem csapott agoyn a frissítés semilyen háttérfolyamatot, felhasználói interakciót, de legközelebb akár ilyenbe is bele lehet rongyolni, hogy olyankor állítja le a DB-t, amikor nagyon fáj).

Ezeket le lehet írni a telepítési/üzemeltetési leírásban, hogy az alkalmazás indításakor elérhetőnek kell lennia a megfelelően konfigurált DB-nek, illetve ha a DB leáll, akkor az újraindítása után az alkalmazásszervert is újra kell indítani. (Én most reszelek egy scriptet (systemd-s unithoz), ami hasonlóképp a DB elérhetőségétől függően indítja/állítja le a tőle függő Java-s vackokat)

( bodnarj | 2018. 06. 28., cs – 09:10 )

A problémát úgy néz ki sikerült megoldani:
Az egyik init.d sciptből hiányzott a 


### BEGIN INIT INFO
...
### END INIT INFO

bejegyzés így éjszaka mikor az apt frissített, és volt mysql frissítés, leállította a mysqld-t. A fenti bejegyzés miatt hibára futott a frissítés, és nem indította vissza a mysql-t.
Úgy néz ki ez volt a hiba oka. ha jön a következő frissítés kiderül tényleg ez volt-e.

Na ezek már hasznos infó morzsák!
Javaslatom: a Glassfish által generált scriptet le kell gyalulni és visszarakni a gyári mysql scriptet (ugyanis ahhoz képest updatel az apt!).
Nincs okom kételkedni sem a szakértelmedben sem a jóhiszeműségedben.
Az én gyakorlatomban az appserver (mint a glassfish) egy akármilyen limitált userrel fut saját kis /opt/glassfish -ében, szó nincs arról hogy mysql indító scriptet írogasson.

Gyanítom hogy valami részlet még kimaradt a beszámolóból...

--
Gábriel Ákos

A GlassFish által (asadmin crete-service) generált GlassFish-t indító scriptből hiányzott ez az infó. MySql scripthet nem lett piszkálva.
De mégis mivel nem volt benne a fenti bejegyzés ezért kavart be az apt.
Erre úgy jöttem rá, hogy kézzel indítottam egy apt-get upgrad-et és panaszkodott a GF indító scriptre.

ja igen a beszámoló alapján az unattended-upgrade fut.
annak a logjában meg kéne találni a hibára futás tényét.
már persze ha a loglevel nincs elállítva.

célszerűnek látszik továbbá unattended upgrade-ben blacklistre tenni (vagy apt-ben pin-elni a megfelelő verziót) a mysqld csomagot, hogy ne állítgassa le az unattended upgrade - nem tesz jót a rendelkezésreállásnak ugye.
meg persze akármilyen incompatible change bejöhet és akkor csak nézel hogy tegnap még ment, ma meg már nem.
--
Gábriel Ákos

Nem üzemeltetés, egyáltalán nem profizmus, csak sima mezei felhasználói logika: amikor egy program elkezd "furán" viselkedni, elsőként mindig megnézem, hogy mikor telepítettem - azaz már egy régóta fenn levő verzió, vagy pedig mostanában frissült, és a furaság esetleg nem-e az új verzióval jött be.
Aztán az eredmény függvényében lépek tovább :)