Изпечатай

[Hapkoc]

Добър вечер.

Имам следния тъп проблем - на машината ми се клати mysql, но често се случва да се рестартира или изключва компютъра от копчето и при такава ситуация последните промени в базата се губят. Поради каква именно причина би могла да става таз мизерия и как може да се предотврати ми е питането.

Благодаря предварително на всички, които са си загубили времето да му четат простотиите.

debian sarge
kernel 2.6.5 custom
mysql 4.0.23
базата е с myisam таблици

[laskov]

Сигурно може да се каже на сървъра да записва на диска всяка промяна в данните веднага (инъче те стоят в разните кешове (не)известно време), но според мен не това е решението - ти винаги можеш да го изненадаш и да го ресетнеш баш като пише. По този начин можеш да изгубиш не само данни от MySQL, но и да си навлечеш и други неприятности, така че - не го спирай/ресетвай по този начин.

[Hapkoc]

Номера е друг - на мене ми е пределно ясно, че не бива да се спира или рестартира така, обаче не мога да го обясня на сина ми, който е на година и 8 месеца почти. Доставя му адски кеф да ръчка копчетата на компа.

Освен това си мисля, че би трябвало да има решение за тоз проблем, т.к. винаги може да се случи да спре тока, да гръмне захранването или нещо от тоя род и не би било много желателно да се загубят данни при такава ситуация.

Така че - ако някой има идеи - моля да сподели.

[laskov]

Откачаш кабелите от лицевия панел към дъното, ... слагаш UPS, ...  '> , даваш на сина си една клавиатура и всеки път, когато натисне бутон викаш "Недей, моля те недей!!!" и той (и ти) се кефите максимално  '>  '>  '>

[dope_hat]

Да ви кажа честно, този проблем го имам и аз със един от сървърите. Машината има mySQL ( ver. 3.23.49 ) и когато спре тока или се рестартира хардуерно, се троши базата зверски.
Но имам следните наблюдения:
Машината не е с много мощен хардуер, и самата версия на mySQL е стара ( 3.23.49 ). Процесора е AMD Athlon 1700+ върви на 1400 със 256 РАМ. OS - Debian.
Проведените тестове на моята машина която е малко по - слаба от тази AMD - 1000 със 256 РАМ, OS - FreeBSD 5.4 със версия на mySQL 14.7 Distrib 5.0.2-alpha го няма изобщо този проблем. При други машини със по - нова версия на базата от по-горепосочената също го няма този проблем. Логично достигам до извода, че просто това си идва от версиите.
Не твърдя че проблема се състои само във версиите, понеже може и да е хардуер ( хард или нещо друго ). Но това е което съм тествал аз и каквото съм видял =)
Ще е интересно да намерим вид разрешение на проблема.

P.S Тестове са правени и със Slackware 10.0 и последна стейбъл версия на mySQL. Резултатите са че пак не се чупи базата. Което пък вече ме навежда на мисълта че просто има хардуерен проблем и той идва от HDD.

[Йордан]

dope_hat можеш ли да кажеш какви са файловите системи ?

значи според мен проблема е в:
1. клиентския софтуер който ползва MySQL-а
2. файловата система - някъде бях чел че е хубаво /var дяла да е с ext2

от две години в нашата фирма работи точно MySQL 3.23.49 на P3-900MHz - 256 RAM - ext2 fs Mandrake 8.2 (не е смешно), за този период е гаснал тока 3-4 пъти но БД не се е чупила (да чукна на дърво). Клиентския софтуер обаче след всяка комплексна операция (няколко запитвания) затваря курсора и ДБ:
на Python:
db = MySQLdb.connect(....)
c=db.cusror()
....
c.close()
db.close

[Йордан]

Цитат (Guest @ Юни 17 2005,22:01)

значи според мен проблема е в: 1. клиентския софтуер който ползва MySQL-а 2. файловата система - някъде бях чел че е хубаво /var дяла да е с ext2 от две години в нашата фирма работи точно MySQL 3.23.49 на P3-900MHz - 256 RAM - ext2 fs Mandrake 8.2 (не е смешно), за този период е гаснал тока 3-4 пъти но БД не се е чупила (да чукна на дърво). Клиентския софтуер обаче след всяка комплексна операция (няколко запитвания) затваря курсора и ДБ: на Python: db = MySQLdb.connect(....) c=db.cusror() .... c.close() db.close

ext2 не е журнална файлова система или се лъжа ?  Според мене е по-логично да е ext3, reiserfs или някоя друга журнална. Аз за това попитах какви са файловите системи, защото имах съмнение, че не са журнални и за това се чупи базата

Цитат (GigaVolt @ Юни 17 2005,22:08)

ext2 не е журнална файлова система или се лъжа ?  Според мене е по-логично да е ext3, reiserfs или някоя друга журнална. Аз за това попитах какви са файловите системи, защото имах съмнение, че не са журнални и за това се чупи базата

не, не е журнална, по него време тя не беше разпространена много...
Но точно журналните системи май чупят таблиците на сървъра...

[dope_hat]

Файловата система на Дебиан-а е ReiserFS , на Slackware беше също такава. Според мен проблема не идва от там. Преди 1-2 месеца имах ситуация, единия от сървърите беше на място където в продължение на една - две седмици, тока спираше внезапно, хардуерен рестарт претърпяваше от време на време, накрая проблема идваше от големите амплитуди които даваше контакта ( от 200 V падаше на 120 или пък рязко се качваше на 230 - 240 V слава богу нищо не успя да изгори ), но въпреки всичко това mySQL на машината не се чупеше. Там файловата система беше ext3 сега е ReiserFS, и се държи много добре.
Това са ми дотук наблюденията.

[zeridon]

Ако не клатиш някакъв огромен трафик през базата в my.cnf закоментирай skip-locking Така ще ти заключва файловете по харда което комбинирано с журнал помга при такива ситуации
Ако не се лъжа имаше и опция implicit-flush или нещо подобно.

Също така при гаснене на токата базата се чупи доста честичко ако приложението използва persistent connections.

[Hapkoc]

Благодаря на всички за интереса и отговорите.

Сега - файловата система е ext3 на дяла където е базата. Клиента е php, като връзките се затварят след съответните заявки. Не се използват persistent connections. Проблема мисля, че не е хардуерен, т.к. важи само за mysql - т.е. нищо друго не се чупи, само базата. Натоварването на сървъра е доста скромно може да се каже.

Това с implicit-flush и skip-locking ще го погледна, дано свърши работа. Благодаря за съветите.