Ваш MySQL - то еще Г...

Сегодня с утра один из моих сайтов запел, что Table '..../cache_block' is marked as crashed and should be repaired

Ну я ее, конечно REPAIR TABLE, но осадок остался. MySQL несколько месяцев никто не перезапускал, сервер тоже не падал:

12:21PM up 124 days, 21:33, 1 user, load averages: 3,48 3,59 3,63

Надо ли говорить, что на гораздо более интенсивной эксплуатации другой опенсорсной базы я на такие грабли не наступал.....

Поставить mysqlcheck в крон?

Comments

>Поставить mysqlcheck в крон?
Это сделать проще, чем даже написать этот пост. Почему бы не сделать этого сразу?

Потому что задачи у поста и крона разные
- crontab (возможно) решает проблему (но и то, не могу же я пускать check раз в 5 минут, значит даунтайм разумно малым сделать не выходит)
- а пост напоминает... см. тайтл

Я у себя в кроне как раз на случай таких подлянок держу проверку error_log, и как только туда приходит что-то от DBD::mysql, дергаю mysqlcheck с той или иной степенью суровости, в зависимости от сообщения.

А может это, перевести все проекты на другую опенсурсную базу, а mysql в /dev/null, где ему самое место?

Да, блин, друпаловские модули пишут индусы, там с совместимостью с постгресом не везде хорошо (в core - более-менее хорошо)

Попробую innodb, как тут советуют, это вроде бы совсем дешево.

надо сказать, что эти <s>придурки</s> <s>индурки</s> о! индусы не в курсе, что во всяких странных странах default client encoding (поставленная где-то в конфигурации для legacy code) может не совпадать с кодировкой базы.

В том смысле, что написать в доке "база данных должна быть в UTF-8" они не забыли, а вот set client_encoding=UTF8 при коннекте к базе - не делают.
В-принципе, правильно не делают, хотя вот MT - делает.

С постгресом, кстати, получается раза в два быстрее на insert чем на innodb (и сильно медленнее чем на myisam, но myisam как нам пишут - разваливается).

Вот не было печали - перетащить готовый друпальный сайт вместе с контентом на другую DB может оказаться тем еще гемороем....

перейти на innodb

Потестировал в песочнице.

Так ведь медленно очень.....

innodb_buffer_pool_size сколько стоит?
Основные преимущества innodb: есть построчная блокировка и не падает так как myisam.

Буфер стоит 256мегабайт, это вдвое больше самой базы.

Надо сказать, что при попытке загнать в мучаемый друпал 5000 публикаций - все испортилось на номере 2765.
Испортилось - это в смысле MySQL заткнулся и не отзывался даже на попытку останова.
Конечно 5.1, релиз-кандидатами не надо пользоваться, наверное.

А в логах что? В innodb_data_file_path достаточные размеры для 5000 публикаций стоят?

Ну после рестарта всего - оно же дальше стало работать.

Потом, даже если мы уперлись в размер - это не повод вставать колом.

Дальше стало - т.е. база догрузилась?

У MySQL это так. Если написано в конфиге 2Gb, значит ни байтом больше.
Администратору ведь виднее на каких дисках сколько он места под базу предусмотрел. На одном массиве может 100 гиг, а на других все 500.

Да, откатило последнюю транзакцию, после чего я туда еще тыщонку текстов налил, файл стал ~110 мегов, значит ограничение до того - не работало.

Причем, я ведь не против самого ограничения - это правильно, что tablespace можно управлять и что одна таблица может быть размазана по разным storage.

Я протестую против вставания колом.

Вот получается у меня пока, что на write постгрес чуть не вдвое быстрее чем innodb.

Вот после подобной фигни стараюсь везде postfix, а где нельзя - innodb.

> <i>Вот после подобной фигни стараюсь везде postfix, а где нельзя - innodb.</i>

Постфикс?

Сорри, PostgreSQL

POSIX!

Хотел тебя на HL++ сегодня заловить, и пожаловаться как пострадавший от MySQL пострадавшему же :-), но че-то не сложилось. Расскажу ссылкой: http://groups.google.com/group/ror2ru/browse_thread/thread/5595aa18bc220f95
Я там конечно резковато, но уж как есть, был не в себе от негодования :)

Я еще завтра буду. С самого сранья, ибо попадаю туда к 9 утра.

Но - я пожаловался Зайцеву на жизнь, благо мы знакомы уже лет 8-9.
Ответ меня... удивил
1) Использовать - innodb
2) innodb с дефолтными настройками работает хреново
3) и пункт 2 очень хорош MySQL-ным консультантам :)

на самом деле, все конечно правильно - использовать надо ту базу, которую умеешь. Я понадеялся на то, что миллионы леммингов не могут быть неправы, отчего сейчас вот сижу и ковыряю скрипты, которые обещают конверсию mysql-ного дампа в постгресный, но не работают как хотелось бы.

Я же вот не говорю, что постгрес вообще не падает. Он "у меня не падает", во всяком случае последние лет 5-6, дальше не помню.

Про первое мне уже все рассказали.

"2) innodb с дефолтными настройками работает хреново"

Фига се! Неожиданно. Нафиг-нафиг.

Но по факту - мне ж не performance пиковый нужен иногда, мне чтоб по дефолту оно не падало с потерей данных хотя бы если нет пропаданий питания. Но теперь уж оставлю консультантам искать их хлеб ("советуем перейти на InnoDB") где-нть в другом месте. При всем уважении к разработчикам легендарного продукта для леммингов.

Я для себя вопрос с MySQL закрыл пару лет назад навсегда, поняв, что он не поддерживаем выборку с использвоаинем нескольких индексов одновременно. Это был шок.

В пятерке вроде бы уже не так.
Вообще, оно уже похоже на настоящее. Ну и для вебовских задач query cache экономит огромный кусок мозга.

Да меня с тех пор firebird сильно не разочаровывал, чтобы заново просмотреть имеющиеся SQL-бд.
Хотя я находил у него какие-то грабли, но это было во времена уж очень извращенного проекта, а в простых прикладнухах не сталкивался с сильными гемороями.

моду он завел регистрацию забывать
:)

>Поставить mysqlcheck в крон?
уж тогда ребут по крону, там при старте mysqlcheck выполняться должен;)
не знаю, никогда такого не видел, правда мюскль у меня старенький..

Я, Алексей, был уверен, что у вас будет разумный ответ на мой вопрос:-)

Но отказываться от MySQL это все равно, что отказываться от бензинового двигателя внутреннего сгорания. Вроде как и не удобный, грязный, и нефти мало, и есть отличные, более хорошие замены, типа водорода. Но зато в любом городе заправка есть, да и починить его просто - на любом автосервисе.

Если бы я был клиентом дешевого виртуального хостинга, я бы конечно от MySQL никуда не делся бы :)

Пожалуй, надо дописать
- mysqlcheck решением не является, ибо нельзя его раз в 5 минут ставить.....
- innodb возможно является решением, но мне удалось его поставить колом за полчаса нагрузки на запись (тут, в комментах, есть про это). Конечно, нагрузка много больше возможной реальной, однако ж
- Postgresql в чистом виде тоже не является решением т.к. дает меньшую (на полпорядка-порядок) скорость на чтении (и большую чем innodb на запись) - там нет query cache, отчего все медленнее по меньшей мере в тестах.

Решением является таки Postgres, но с наложенным внешним кэшированием. К несчастью, у друпала это внешнее кэширование тоже кривое (cache_router) и надо его исправлять, но хотя бы известно что где и как.

Для Drupal наилучшее решение - класть часть баз на innoDB, а часть оставлять на ISAM.
Те таблицы, что интенсивно изменяется (и подвержено падению) - на innoDB (кэши, сессии, логи).

А версия mysql какая?

5.1-последняя (28-я, кажется)

У меня при запуске mysql идёт проверка целостности

И часто вы его перезапускаете? У меня то штука стояла несколько месяцев без перезапуска.

А вы не юзайте на продакшене советских... эээ... нестабильных версий ;)

Последний MySQL - 5.0.67

И что, MyISAM который 10 лет подряд разваливался - это делать перестал?

У меня как-то оракл потерял данные в таблице. Подробности не помню, пару-тройку лет назад было, вылечилось пересбором статистики с таблицы, я как-то хитро её порушил, фактически штатным образом. Означает ли это, что мне надо было перейти на PG? :)

Антон, я же возражаю против собственной ситуации - когда unattended сервис вдруг перестал работать без какого-либо вмешательства со стороны (если бы у сервера ресет случился - я бы меньше возражал, транзакций в хранилище нет и все такое).

А порушеная статистика - это же ручная работа, при ручной работе надо за собой проверять, да.

Я прекрасно понимаю, что mysql не должно было развалиться на настолько отработаном движке. Но ведь ты сам сказал, что это 5.1 версия, которая, насколько я помню, экспериментально-девелоперская и вполне ожидаемо может содержать баги. Мне самому mysql не нравится, но я просто не ожидаю от неё "бесперебойного сервиса", поэтому не разочаровываюсь :) PG как-то у меня не сложилось использовать, во времена 6-й версии он был тормоз, потом медленно ускорялся, в итоге я его пропустил совсем. Поэтому у меня две крайности: mysql и oracle. PG использовал один раз только в одном проекте, и как-то мне показалось его нетривиально настроить, чтобы эффективно работал. С тех пор не особо смотрел на него.

1) 5.1 - это релиз-кандидат
2) MyISAM-у уже лет 10, можно бы и починить
3) MySQL-консультанты (в лице Зайцева) на прямой вопрос не удивляются, а говорят, ну да, есть такая проблема.
4) REPAIR TABLE - штатная конструкция. Т.е. это не "бага беты", а предусмотренная конструкция.

4-го пункта достаточно, я с таким недоразумением работать не желаю. Оно же прямо в ответ на запрос пишет "я тут развалилсо, надо repair table сказать".

> 4) REPAIR TABLE - штатная конструкция. Т.е. это не "бага беты", а предусмотренная конструкция.

Это как раз понятно, чинить бывает надо по разным причинам. Когда драйвер NVIDIA вешает машину напроч, то фалы на XFS могут просто не выжить, чего уж говорить про таблицы myisam.

Я согласен с тезисом, что mysql -- г-но. Я с конца 90х с ним работаю, никогда не воспринимал его как нечто большее, чем "sql надстройка над dbf", поэтому я тоже не удивляюсь, что там что-то развалилось. Я скорее удивляюсь, что есть люди, которые этому удивляются :)

Кстати, долго добавляющиеся комментарии в этот блог (секунд 10), это не следствие перехода на PG? :)

Не, этот блог исходно на постгресе, но тормозят там всякие DNS-лукапы, которые проверяют не спамер ли ты.

а что именно за лукапы, если не секрет?

а что именно за лукапы, если не секрет?

ps: сорри за пост в корень, нечаянно вышло

А когда у другой опенсорсной базы таблички зашкаливают за 100G, при том, что данных в них есть хорошо если на 10M - нормально? Везде своих тараканов хватает.

PS: Ни то, ни другое - не админю, и не хочу :-P

Не хочешь админить - включи autovacuum (при том, что по дефолту он там включен, значит кто-то поадминил и выключил)

Так засада была в том, что такое безобразие творилось только в двух таблицах из более чем сотни. Причем не самых частоиспользуемых. Так что тараканов везде хватает.

> при том, что по дефолту он там включен
Разве?

Re: > при том, что по дефолту он там включен
В 8.3 - да.

Re: > при том, что по дефолту он там включен
<span style="font-style: italic">autovacuum (boolean) Controls whether the server should start the autovacuum subprocess. <span style="font-weight: bold">This is off by defaul</span>t.</span>

http://www.postgresql.org/docs/8.1/static/runtime-config-autovacuum.html

Re: > при том, что по дефолту он там включен
8.3 давно вышла :)

Не, я на самом деле autovacuum не люблю т.к. он включается обычно очень невовремя. Но для тех кто "админить не любит" - это место починено из коробки, скоро будет год тому как.

Re: > при том, что по дефолту он там включен
да я знаю, что давно вышла, сам пользую (кстати av выключен) :)
просто хотел показать игорю, откуда ноги растут.

Re: > при том, что по дефолту он там включен
Я могу понять, тех кто сидит до сих пор на 7.x потому что в свое время надевелопили такого SQL, который семерка понимает, а 8-ка - нет (у самих такие проекты были). Да и то, этих тоже не могу понять, восьмерке лет пять уже.

Но вот тех, кто сидит на 8.0-8.2 и не перелезает на 8.3 откровенно понять не могу, ибо 8.3 быстрее и лучше.

Re: > при том, что по дефолту он там включен
плюсадин. уже и 8.4 на самом деле потихоньку пробуем. пока туда-сюда, наступит весна и выйдет.

Re: > при том, что по дефолту он там включен
Я почитал wiki по CommitFest-2008-11, пусть сначала 8.4.1 выйдет и только тогда, несмело, начну фигачить на тестовые сервера.

Хотя пробовать где-то в уголочке наверное после нового года будет можно. И HotStanby из коробки - отличная новость.

Re: > при том, что по дефолту он там включен
глюкануло, до конца не дописал,

<a href="http://www.postgresql.org/docs/8.3/static/runtime-config-autovacuum.html">
http://www.postgresql.org/docs/<span style="font-weight: bold">8.3</span>/static/runtime-config-autovacuum.html</a>

This is on by default; however, track_counts must also be turned on for autovacuum to work.

А в 8.3 - да :)

Народ незнаю почему у вас MYSQL падает
но про себя скажу так

я создал сканер сайтов ну типа спайдер
он пашет в 70 потоков
каждый сайт пишется в MEMORY TABLE (ну если учесть что сайт в среднем по 1000-10000 страниц)
Объем бд колеблется в пределах 2-3 гигабайт
нагрузка идет колосальная
Использую только INSERT и проверяю на ошибку (типо чтоб не юзать UPDATE хотя он очень нужен)
Так вот за год юзания а это порядка 1терабайта прокаченой инфы в месяц
MYSQL не падал

Перезагрузите 1 раз его в процессе записи в таблицы MyISAM - это хватит.

Add new comment