Sziasztok!
Van egy ubuntu szerverem, amin zabbix fut.
Ma reggel azzal örvendeztetett meg, hogy nem megy a zabbix, mégpedig mysql hiba miatt:
10079:20091102:123421 [Z3005] Query failed: [2013] Lost connection to MySQL server during query [select num,value_min,value_avg,value_max from trends_uint where itemid=22395 and clock=1257159600]
Ebből van tonnányi.
Érdekes, hogy máshonnan, pl. phpmyadminból, mysql parancssorból elérem a mysql-t.
Ha lekérdezéseket futtatok, akkor pár lefut, de pár nem ezzel a hibával:
ERROR 2006 (HY000): MySQL server has gone away
Mi baja lehet? A /var/log/mysql.err üres, a mysql.log szintén.
Minek nézzek utána? Kínomban túl vagyok egy apt-get ugprade-en és egy do-release -upgrade-en, de rollbackelhető :)
Kösz
Greybear
- 1547 megtekintés
Hozzászólások
Próbáltad már újraindítani a mysql-t? A fájlrendszereken van szabad hely/inode?
- A hozzászóláshoz be kell jelentkezni
Már mindent újraindítottam, többször.
df:
Fájlrendszer 1K-blokk Foglalt Szabad Fo.% Csatl. pont
/dev/sda1 60492100 5867940 51551332 11% /
udev 249224 144 249080 1% /dev
none 249224 0 249224 0% /dev/shm
none 249224 68 249156 1% /var/run
none 249224 0 249224 0% /var/lock
none 249224 0 249224 0% /lib/init/rw
szóval van hely.
- A hozzászóláshoz be kell jelentkezni
Egy helyen a hírlevélküldő ilyen jellegű (MySQL server has gone away) problémáját a wait_timeout megfelelő beállítása oldotta meg.
- A hozzászóláshoz be kell jelentkezni
Ezt most bookmarkolom, tobb szerveren elmegy kirandulni a MySQL szerver.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
/var/log/mysql.err üres
Nem lehet, hogy a /var/log/mysql/ alatt vannak a logok?
Próbáltad kézzel indítani a mysql-t és nem init scripttel?
Hát ha ott több hibaüzenetet ad.
- A hozzászóláshoz be kell jelentkezni
Szia,
Erdekes, a hiba.
Nezz egy show status like 'uptime' uzenetet minden ilyen lost connection utan. ha az uptime kicsi akkor konyen lehet rafuttottal valami bug-ra vagy rosz a config es siman elszall a mysql (innodb-vel fordul elo folleg).
Ha a mysql-t elered bizonyos helyekrol es mashonnan nem az tobb dolog miatt lehet.
Az elso kerdes, mit valtoztattal a configon?
A gone away ahogy masok is irtak rendszerint timeout miatt van, de lehet script is ami kigyilkolja a threadeket, de amit irtam, hogy bug vagy rosz conig miatt elofordul hogy a mysql siman ujra indul. Erdemes megnezni.
Ha az uptime-al nincs baj, vagy fut es megis gone away van, eloszor show variables like '%time%'; es nezd meg a timeoutokat.
Ha azok is rendben vannak, nezd meg a sysctl tcp timeoutra vonatkozo dolgokat. (Bar ha parancssorbol is kapod ami ugye socketen at megy, ez valoszinutlen).
Ha minden rendben van ezekkel is, probald meg kitalalni, nincs e valami scripted ami gyilkolja a threadeket (mkill/mk-kill vagy akar sajat).
Az error log csomo minden miatt lehet ures, elosszor is a configba log-warnings = 2. Az segithet. Debian/ubuntu alatt rendszeresen hasznalja a mysql a syslogot errorlognak (cat /var/log/syslog | grep -i mysql), talan ott tobbet talalsz.
Szerintem a legvaloszinubb valami bug/hibas config lehet amitol ujra indul de azert erosits meg plz.
BTW a topic can't connect trough socket nem ugyan az mint a gone away. Ha can't connect trough socket akkor bizony aza mysql megallt.
drk
- A hozzászóláshoz be kell jelentkezni
Egyre ertekesebb lesz ez a topic.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
A configon semmit nem módosítottam, gyakorlatilag default.
Módosítok a felálláson: gyakorlatilag bármilyen connection képes elszállni, mint a győzelmi zászló 3-ból egyszer.
Az uptime-ot megnézem, máris referálok.
Próbáltam állítani a wait_timeout-ot 1 percre és a max_connections-t 300-ra, az eredmény egy halom [mysqld_safe] processz lett...
Nyilván a syslogban vannak a logok :P Ezt leltem benne:
Nov 3 10:12:12 zab01 mysqld: 091103 10:12:12 InnoDB: Error: space id and page n:o stored in the page
Nov 3 10:12:12 zab01 mysqld: InnoDB: read in are 2847492:0, should be 0:86598!
Nov 3 10:12:12 zab01 mysqld: InnoDB: Database page corruption on disk or a failed
Nov 3 10:12:12 zab01 mysqld: InnoDB: file read of page 86598.
Nov 3 10:12:12 zab01 mysqld: InnoDB: You may have to recover from a backup.
Nov 3 10:12:12 zab01 mysqld: 091103 10:12:12 InnoDB: Page dump in ascii and hex (16384 bytes):
[itt vágok, dump jön]
Nov 3 10:12:12 zab01 mysqld: ;InnoDB: End of page dump
Nov 3 10:12:12 zab01 mysqld: 091103 10:12:12 InnoDB: Page checksum 39442583, prior-to-4.0.14-form checksum 1499557648
Nov 3 10:12:12 zab01 mysqld: InnoDB: stored checksum 0, prior-to-4.0.14-form stored checksum 0
Nov 3 10:12:12 zab01 mysqld: InnoDB: Page lsn 2920960798 86598, low 4 bytes of lsn at page end 0
Nov 3 10:12:12 zab01 mysqld: InnoDB: Page number (if stored to page already) 0,
Nov 3 10:12:12 zab01 mysqld: InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 2847492
Nov 3 10:12:12 zab01 mysqld: InnoDB: Page may be an 'inode' page
Nov 3 10:12:12 zab01 mysqld: InnoDB: Database page corruption on disk or a failed
Nov 3 10:12:12 zab01 mysqld: InnoDB: file read of page 86598.
Nov 3 10:12:12 zab01 mysqld: InnoDB: You may have to recover from a backup.
Nov 3 10:12:12 zab01 mysqld: InnoDB: It is also possible that your operating
Nov 3 10:12:12 zab01 mysqld: InnoDB: system has corrupted its own file cache
Nov 3 10:12:12 zab01 mysqld: InnoDB: and rebooting your computer removes the
Nov 3 10:12:12 zab01 mysqld: InnoDB: error.
Nov 3 10:12:12 zab01 mysqld: InnoDB: If the corrupt page is an index page
Nov 3 10:12:12 zab01 mysqld: InnoDB: you can also try to fix the corruption
Nov 3 10:12:12 zab01 mysqld: InnoDB: by dumping, dropping, and reimporting
Nov 3 10:12:12 zab01 mysqld: InnoDB: the corrupt table. You can use CHECK
Nov 3 10:12:12 zab01 mysqld: InnoDB: TABLE to scan your table for corruption.
Nov 3 10:12:12 zab01 mysqld: InnoDB: See also http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
Nov 3 10:12:12 zab01 mysqld: InnoDB: about forcing recovery.
Nov 3 10:12:12 zab01 mysqld: InnoDB: Ending processing because of a corrupt database page.
Nov 3 10:12:12 zab01 kernel: [78425.626886] zabbix_server[7305]: segfault at e ip 00007f94e6c28735 sp 00007fff6870bb90 error 4 in libmysqlclient.so.15.0.0[7f94e6bae000+1b4000]
Nov 3 10:12:12 zab01 mysqld_safe: Number of processes running now: 0
Nov 3 10:12:12 zab01 mysqld_safe: mysqld restarted
Nov 3 10:12:12 zab01 kernel: [78425.748494] type=1503 audit(1257239532.554:2455): operation="open" pid=10204 parent=6353 profile="/usr/sbin/mysqld" requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0 name="/sys/devices/system/cpu/"
Nov 3 10:12:12 zab01 mysqld: 091103 10:12:12 [Note] Plugin 'FEDERATED' is disabled.
Nov 3 10:12:12 zab01 mysqld: InnoDB: Log scan progressed past the checkpoint lsn 43 2014560866
Nov 3 10:12:12 zab01 mysqld: 091103 10:12:12 InnoDB: Database was not shut down normally!
Nov 3 10:12:12 zab01 mysqld: InnoDB: Starting crash recovery.
Nov 3 10:12:12 zab01 mysqld: InnoDB: Reading tablespace information from the .ibd files...
Nov 3 10:12:12 zab01 mysqld: InnoDB: Restoring possible half-written data pages from the doublewrite
Nov 3 10:12:12 zab01 mysqld: InnoDB: buffer...
Nov 3 10:12:12 zab01 mysqld: InnoDB: Doing recovery: scanned up to log sequence number 43 2014562771
Nov 3 10:12:12 zab01 mysqld: 091103 10:12:12 InnoDB: Starting an apply batch of log records to the database...
Nov 3 10:12:13 zab01 mysqld: InnoDB: Progress in percents: 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
Nov 3 10:12:13 zab01 mysqld: InnoDB: Apply batch completed
Nov 3 10:12:13 zab01 mysqld: 091103 10:12:13 InnoDB: Started; log sequence number 43 2014562771
Nov 3 10:12:13 zab01 mysqld: 091103 10:12:13 [Note] Event Scheduler: Loaded 0 events
Nov 3 10:12:13 zab01 mysqld: 091103 10:12:13 [Note] /usr/sbin/mysqld: ready for connections.
Nov 3 10:12:13 zab01 mysqld: Version: '5.1.37-1ubuntu5-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
Jól érzem, hogy beszoptam? Már csak abból gondolom, hogy database page corruption és You may have to restore from backup...
Mint megtudtam a drága kolléga előidézett néhány unexpected shutdownt a host gépen (a linux virtuális).
Olyan scriptem, ami gyilkolja a threadeket, nincs.
Megpróbálom kidumpolni az adatbázist, ha megint elszáll meg fogom tudni vizsgálni show status like 'uptime'-ot.
Kösz
Greybear
- A hozzászóláshoz be kell jelentkezni
Nos, a mysqldump elszállt egy idő után:
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `trends_uint` at row: 330448
Az uptime leesett - tehát a mysql újraindult.
Gyakorlatilag azt logolta a syslogba, amit feljebb beillesztettem, plusz egy csomó InnoDB: Rolling back trx with id... sort.
Van bármi, amit tehetnék az adatok visszanyerése érdekében? (nyilván nincs friss mentésem - tudom, megyek téglával szétzúzni a tökömet...)
- A hozzászóláshoz be kell jelentkezni
A fentiek mellett amit irtam mikor ezt meg nem lattam (tudom tudom feluletesseg), van.
Szerintem verziot upgradeltel. Valamit tettel amitol elkezdett elszalni.
Fogsz egy masik gepet,vm-et, jail-t, barmit.
Teszel olyan mysql-t ami itt volt elotte.
Atmasolod oda a /var/lib/mysql -t (ha default config ez eleg) UPDATE: A /var/lib/mysql/mysql -t ne :) 5.0 v 5.1 mas a struktura :) sry
Atmasolod a config file-t.
(nyilvan a mysql ne fusson)
Elinditod a masik gepen a korabbi verzioval.
Elvileg menni fog. figyelj a jogosultsagokra es a configra.
drk
- A hozzászóláshoz be kell jelentkezni
Nem kell uptime, egyertelmu :) A mysql -ed elszall.
Na ha a config default, akkor bizony ez szivas :)
Mindig mondom, 5.1 -et hiaba adtak ki, bizony kaki szvsz :)
Opciok:
- Vissza allni 5.0-ra (altalaban nem szeretik es ez "megfutamodas" :) )
- Kitalalni mi valtozott miota elszal. Nagy valoszinuseggel eleg lesz azt rendbe rakni vagy rollbackelni vagy akarmi tortent viszacsinalni.
- Megprobalhatod leallitani a mysql, atmasolni masik gepre az egesz mindenseget(ami mysql), a configot is (!) es elinidtani masik gepen (igy kizarod hogy ezzel van a baj).
- teszel masik mysql-t (javaslom ourdelta-t ami eleg stabil (debian/ubuntu buildekkel http://ourdelta.org/ vagy percona build -eket xtradb-vel ami bar nem annyira neveznem stabilnak, ennel sokkal jobb lesz ill xtradb + percona patchek miatt irdatlan gyors tud lenni :) http://www.percona.com/mysql/)
Nem tudom mennyire vagy otthon a mysql temaban ezert irtam ezeket. Alapbol arra tippelnek upgradeltel 5.0.x -rol 5.1.x -re majd ez tortenik. A legokosabb vissza allni ilyenkor vagy megprobalni ourdelta vagy percona patchelt verziot. Ill innodb plugint kezzel beleeroltetni. Bar azt allitja debian/ubuntu tud o upgradelni 5.0-rol 5.1-re, ez eddig sosem ment ilyen siman (downgrade-et akarhanyszor probaltam buktam :) ). Valszeg masfajta innodb verzio elfekteti a mysql-t. Elofordul :)
A dumpolas es az "ures" mysqlbe belehuzas jo otlet. Ha kidumpoltad, mysql leallit, innodb tablespace fileok (ibdata*) es logok(ib_log*) torol, elindit, var es utana toltsd vissza (ha nem hasznalsz file-per-table-t). Igy tutira uj verziohoz rebuildeli a tablespace-t.
Ami fontos lehet, ha dumpolni tud, akkor amig a dump megy, ne engedj ra semmilyen forgalmat. Mert ha megint egy ilyen query elfekteti akkor ujraindul.
Ha nagyon nem akar jolenni es nincs masik mysql-ed ahonnan dumpolhatsz es ujra huzhatod ezt, akkor dumpot megprobalhatod mk-paralel-dump -al, esetleg masik mysql-t felhuzni egy masik gepen es maatkit cuccokkal atsyncelni.
Szooval osszevissza mondok mindent ami eszembe jut, a legegyszerubb ha megtalalod mi valtozott es visszacsinalod :)
drk
- A hozzászóláshoz be kell jelentkezni
mysqldump sem tud lefutni, mert elszáll: mysqldump: Couldn't execute 'show table status like 'history\_str\_sync'': Lost connection to MySQL server during query (2013)
pedig minden mysql-t használó processzt lelőttem és iptablessel megszűrtem a 3306-ot.
MyISAM-al mintha csináltam volna olyat anno régen, hogy kimásoltam a fileokat és bemókoltam egy másik mysql alá. Ezt InnoDB-vel meg lehet tenni? Hátha...
Ha egy nyomorult dumpom lenne már kivágtam volna ezt a szervert és előrántok egy tiszta image-et. (5.0-s mysql-el...)
- A hozzászóláshoz be kell jelentkezni
figy innodb egy eleg erdekes allat. ugycsinal mint aki nagyon finnyas (pl ezek a megdoglesek) de igazabol ez csak hiszti.
A hiba az lesz, hogy megupgradelted a mysql-t valszeg uj innodb is.
1x a megoldas.
1. allitsd le mysql-t.
2. csinalj backup-ot. (lvm snapshot vagy sima targz)
3. fogd me, szedd le mysql-t. Ne finomkodj total purge-old a francba az osszes csomagot mindent torolj (backup legyen a configrol is !! fontos)
4. tedd vissza a regiverziot ami korabban volt (aszem 5.0, de ha nem akkor is azzal probald).
5. Masold visza a backupot (elotte alllitsd le mysql-t, ubuntu ugyis elinditja install utan)
6. inditsd el mysql-t es (elvileg) lass csodat :) Mint mondtam innodb egy hisztis r1b*nc, de azert birja a gyurodest :)
UI: ha az adat nagyon fontos volt esetleg tudok segiteni MAXIMALISAN sajat felelosegedre viszarangatni (for free, ha nem boldogulnal)
drk
- A hozzászóláshoz be kell jelentkezni
OK.
Most kivágtatok egy ügyfélhez aztán megpróbálom.
Mit szólsz ehhez a menethez:
1) clean ubuntu install
2) mysql50 install
3) config, adatfile-ok átmásolása
4) mysql start - meglássuk...
Ha helyreállna a rend, akkor marad ez a szerver az éles.
Szerinted?
Kösz
Greybear
- A hozzászóláshoz be kell jelentkezni
Pontosítok: ha sikerül ezután kidumpolni az adatbázist, akkor azért a biztonság kedvéért abból visszaállítok egy adatbázist és az lesz az éles.
(és konfolok normális mentést...)
- A hozzászóláshoz be kell jelentkezni
Teljesen jol hangzik :)
Sok sikert!
drk
- A hozzászóláshoz be kell jelentkezni
Egyébként igen, volt egy verzió upgrade. De most betöltöttem azt az image-et, ami előtte készült és az is dobálta a hibákat :(
- A hozzászóláshoz be kell jelentkezni
Ha verzió upgrade, akkor backup->upgrade->mysql_upgrade a helyes metódus szerintem. Csinálj bináris backupot, ha nem fut semmi, és próbáld meg esetleg lefuttatni a mysql_upgrade parancsot, lehet hogy helyre rakja. De csak akkor, ha valaki itt a threadbe ezt megerősíti, hátha hülyeséget javasolok :)
Egyébként:
http://dev.mysql.com/doc/refman/5.0/en/mysql-upgrade.html
- A hozzászóláshoz be kell jelentkezni
Voltam akkora állat, hogy rábíztam magam az ubuntura egy fáradt pillanatomban és nem tudom miért, de nem snapshotoltam.
- A hozzászóláshoz be kell jelentkezni
Esetleg meg innodb_force_recovery=4-gyel megprobalni elinditani az adatbazist es ugy megprobalni kidumpolni, ha ez nem megy, akkor innodb_force_recovery=6, de ezzel vigyazz, es olvasd el mit csinal, mert mar destruktiv, elotte offline lemasolnam a datafileokat.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Meg fogom nézni, köszi!
- A hozzászóláshoz be kell jelentkezni