< HomePage | Снимки
<- Вторник, 20 Май 2008 | Начална страница | Четвъртък, 22 Май 2008 ->
Сряда, 21 Май 2008

Грубо си припомних защо не мога да понасям mysql и защо смятам, че който си повери данните на тази "база данни", заслужава всичко, което неизбежно ще му се случи.

Тестово бях пуснал един mysql, като на същият диск по една или друга причина имам и postgres база данни. Поради недоглеждане, ако така може да се нарече използването на стандартен предоставен от mysql конфигурационен файл my-medium.cnf, дискът се запълни и двете бази данни, разбира се спряха да обслужват някои от заявките. Дотук всичко е горе-долу едно и също и за двете. Но пък разликите в продължението са впечатляващи.

Освободих аз място на диска, postgresql продължи да работи без да го пипам (дори не го рестартирах!), а mysql упорито не искаше да обслужва заявки. Спрях го, пуснах го - всичко уж наред. След малко гледам, че сървъра работи обаче нито една заявка към него не се изпълнява.

Логвам се на конзолата пускам select на една малките таблици и ме посреща чудесно съобщение "1033 - Incorrect information in file: './ads/ox_acl.frm'". Потърсих за mysql error 1030 и открих, че има около половин милион страници и всички са горе-долу на една тема...

Видите ли това съобщение посягайте към архивните копия, защото няма оправия.

Е аз към бекъпите не посегнах, защото mysql още го тествах и данните не ми бяха толкова важни, но пък направих shred на всякакви mysql неща, пуснах тъпия OpenX да работи с postgres и се припсувах наум, че съм си въобразил, че mysql става за нещо. Горките му потребители.

Та така, no disk space + mysql = сигурна загуба на данни. Enterprise чудо, чудо. Сравнете описаното за shitsql с действията на истинската ACID база данни.

[ Коментари: 9 ]
Коментари

backup + binlogs = solution; а приложение, което пише в базата и не се интересува дали СУБД-то му е върнало грешка или не, си заслужава да му бъдат загубени данните.

Написа Георги Тодоров на 22-May-2008 22:00


Чорбаджийски, прав си по принцип за mysql-а, ама и в същото време не съвсем. MySQL има едно много важно предимство пред Postgres-a - БЪРЗА е. Ако пробваш PG с пълнотекстово търсене (примерно) - TSearch2 - ще ти се отели вола докато върне някакви резултати. Верно, наистина използват по-голяма част от теорията за релационните бази, но има още какво да подобряват.

Иначе Адаша Тодоров намеква за репликация, което решава доста проблеми :)

Написа Георги (www) на 22-May-2008 22:45


За да се скапе .frm Файла има една единствена причина - самият той (т.е. структурата на базата данни) е бил променян след като диска вече се е препълнил. Нищо фатално няма да стане, ако дискът се запълни при работа с ДАННИТЕ, т.е. при обичайна работа на енджина. Може и да се начука базата, но поправимо. Случвало ми се е много пъти.

Написа mitko.com (www) на 23-May-2008 00:11


@георги1: принципа е ясен, но в конректния случай имах подобни приложения и различни бази, едната се скапа при пълен диск, другата не. За мен случаят е ясен.

@георги2: не съм провал tsearch2, но ще се учудя ако при натоварване е по-бавен от подобното куцо решение на mysql. Да се твърди, че mysql е "по-бърз" е доста подвеждащо особено при факта, че всички тестове при които се ползват повече от няколко паралелни заявки към едни данни показват, че postres-а рита задника на mysql отвсякъде. Ако ще си говорим за скорост на една заявка, може пък да е по-бърз, ама то в такъв случай по-добре ползвай sqlite3 :)

@митко: не е променяна структурата, софтуера, който ползваше mysql върти основно select и insert заявки. Няма alter, няма подобни чудеса.

В заключение ползвам postgres от 8-9 години и никога не ми е губил данни, а mysql-а с ползване на *препоръчан от тях конфигурационен файл*, си скапа структурата след една седмица. Да бекъпите и репликацията щяха да ме спасят (макар че за mysql репликацията не ми се отваря дума, там колко страдание има), а пък съм виждал и невъстановими mysql бекъпи, защото някой не е сложил магическа опция указваща encoding на mysqldump. Мъка, мъка.

Написа Георги Чорбаджийски (www) на 23-May-2008 00:22


@георги2: То това за бързия mysql май беше преди години ;)

В днешно време нещата са доста по-различни.

Написа Божо на 23-May-2008 00:47


@георги2

tsearch2 с gin индекси е доста по бърз от търсенето на mysql.

Написа akademik nedelchev на 23-May-2008 07:50


offtopic: http://www.zoitz.com/comics/analogies.png

:)

Написа 12 на 23-May-2008 11:41


По повод не енкодингите на mysql, аз от блога на Григор Гатчев разбрах че default-а е latin1_swedish. Като се замисля, ми се струва напълно обосновано ;)

Написа Иван на 24-May-2008 01:57


@георги: Мисля, че прибързваш, като обвиняваш Mysql за проблема.

Първо защото Mysql има една особеност, която трябва да се има предвид, когато се правят квалификации и сравнения - можеш да имаш различни storage engines. Един е transaction safe, друг не е. Един lock-ва редове, друг - цели таблици и т.н. Трябва да се съобразява и какви са ти конкурентните заяваки - ако са select & select е едно, ако е select и update друго, а ако е select и insert е съвсем друго. Това, че mysql с myisam storage се е скапал не означава, че е щял да се скапе по същия начин, ако си бил избрал друг storage (innodb например). Същото важи и за производителността - за някои таблици един storage ще даде по-добри резултати от друг.

Второ защото не е сигурно дали не е имало и страничен ефект, който да не се забелязва лесно. Например заради увисналите в очакване на място процеси може да се е бил изчерпал още някакъв ресурс на ОС-а (open files, open sockets, orphаn sockets ...), а този недостиг на ресурси от своя страна да е объркал някое приложение и то да е взело грешно решение. Например OpenX може да е решил, че някакво inconsistency в базата е причинено от разлика във версиите и да се е опитал да си alter-не някоя таблица. Може самия mysqld да се е крашнал, да се е рестартирал, да се е пробвал да си repair-не таблиците, но заради липса на ресурс да е станало по-лошо. Т.е. много и най-различни неща биха могли да се случат в една такава ситуация, без да е ясно на пръв (а и на втори) поглед какво е станало и защо.

Иначе аз пък ползвам mysql от 12 години, като през това време не е бил изключван и за 5 минути (освен при дълги power outages) и колкото и пъти да се е скапвал, данни не е губил. Виж кога е инсталиран ОС-а:

[root@mail mitko]# ls -lad /usr/local/src
drwxr-xr-x 2 root root 4096 Dec 21 1996 /usr/local/src

А конкретното приложение (OpenX) го ползвам върху Mysql от не знам колко години, но със сигурност повече от 4 (тогава се казваше phpadsnew или нещо такова) и не се е скапвало, а е било подлагано на неистови натоварвания. На моменти е имало по над 300 посетителя в секунда, което означава около 1000 реклами в секунда, а броят на едновременните заявки към mysql също е достигал 1000 и то при максимално използване на memcached и други кеширащи и non-blocking техники (например замяна на update с insert във временни таблици и асинхронно консолидиране на няколко промени в една заявка с едно локване на таблицата) и сравнително приличен хардуер (Xeon, SCSI RAID, etc.). Т.е. mysql безгрижно си работи при здрави натоварвания. Което не значи, че Postgre няма да се справи също толкова или дори по-добре - нямам опит и не мога да коментирам. Само (пак) казвам, че прибързваш с "обвиненията".

Написа mitko.com (www) на 25-May-2008 15:06


Valid XHTML 1.0! Valid CSS!