Комментарии 46
Ну а почему бы форк не попробовать? (перкона/мария)
Ядро данных СУБД то же самое, только выходит с задержкой в месяц после оригинального MySQL, ибо надо успеть наложить свои патчи на то, что написано. Так что и баги у них практически всегда аналогичны.
Зато если вы зарепортите баги той самой Percona, большой шанс что они пофиксят и отправят патчи в Oracle.
Поддержка платная? Прецеденты были?
Если вы будете использовать их сервер и репортить баги, то они будут заинтересованы в том, что бы его пофиксить.
Можете заказать у них поддержку, тогда они вам будут править баги как своим клиентам, т.к. это то, на чём они собственно и зарабатывают.
Как клиент дела с ними не имел, но я с их работниками общался (приглашал на конфу с докладами, они приезжали) и я не удивлюсь, если баги они поправят и отправят фиксы в апстрим.
Можете заказать у них поддержку, тогда они вам будут править баги как своим клиентам, т.к. это то, на чём они собственно и зарабатывают.
Как клиент дела с ними не имел, но я с их работниками общался (приглашал на конфу с докладами, они приезжали) и я не удивлюсь, если баги они поправят и отправят фиксы в апстрим.
afaik они пофиксят (если есть договор о поддержке), но в оракл они отправляют крайне редко.
ну, некоторые баги у нас все-таки другие :)
и некоторые из MySQL уже у нас исправлены.
Хотя в InnoDB/partitioning обычно все совпадает.
Но вот в случае с 5.5.25 у нас бага bug#65745 не было.
и некоторые из MySQL уже у нас исправлены.
Хотя в InnoDB/partitioning обычно все совпадает.
Но вот в случае с 5.5.25 у нас бага bug#65745 не было.
новый код — новые баги. Звучит вполне логично :)
партиции это вообще какой-то кошмар, уже 100 раз пожалел, что использую эту технологию в MySQL, больше забот, чем выигрыша производительности, пару месяцев назад убрал почти все партиционированные таблицы из системы, ибо реально только вред и никакой пользы.
думаю исправление бага до его нахождения скорее в основе исключение нежели правило, но конечно исключнием приятное
партиции это вообще какой-то кошмар, уже 100 раз пожалел, что использую эту технологию в MySQL, больше забот, чем выигрыша производительности, пару месяцев назад убрал почти все партиционированные таблицы из системы, ибо реально только вред и никакой пользы.
думаю исправление бага до его нахождения скорее в основе исключение нежели правило, но конечно исключнием приятное
В форке все точно также 8(
<offtopic>Позвольте полюбопытствовать, если у вас «с Mysql все по-взрослому», то почему не www.percona.com/?
</offtopic>
</offtopic>
… выше ответил
Разработчики сервера Percona, используют за основу тот же самый код. Накладывают на него свои патчи по usability и немного расширяют функциональность в плане мониторинга и бэкапирования. Вот и все. Три раза натыкаясь на баги MySQL искал их решение в перконе. После третьего, больше не ищу, хотя часть их кода считаю полезной.
Разработчики сервера Percona, используют за основу тот же самый код. Накладывают на него свои патчи по usability и немного расширяют функциональность в плане мониторинга и бэкапирования. Вот и все. Три раза натыкаясь на баги MySQL искал их решение в перконе. После третьего, больше не ищу, хотя часть их кода считаю полезной.
А может взять что-то помимо MySQL?! Я пользуюсь PostgreSQL, стабильность радует.
1. Система большая переписать сложно
2. В каждой системе свои проблемы, я оптимист, MySQL вроде стабильно идет вперед, иногда долго, иногда медлено, иногда в обратную сторону, но я надеюсь на лучшее
3. Новый проект пишем под PostgreSQL
2. В каждой системе свои проблемы, я оптимист, MySQL вроде стабильно идет вперед, иногда долго, иногда медлено, иногда в обратную сторону, но я надеюсь на лучшее
3. Новый проект пишем под PostgreSQL
Я вот тоже думаю перейти на PostgreSQL.
4 часа ночью пытался понять почему filesort в хотя индекс есть. Оказалось что не до конца дочитал мануал. DESC индексы поддерживаются только в команде, а на самом деле создает ASC.
Очень хотелось расстрелять кого-нибудь.
4 часа ночью пытался понять почему filesort в хотя индекс есть. Оказалось что не до конца дочитал мануал. DESC индексы поддерживаются только в команде, а на самом деле создает ASC.
Очень хотелось расстрелять кого-нибудь.
А как PostgreSQL ведет себя когда много мелких запросов? Оно умеет делать 100K+ req/sec?
www.facebook.com/notes/mysql-at-facebook/can-innodb-do-100k-iops/10150907613720933
Оно может конкурировать с handlersocket (750K req/sec)?
www.facebook.com/notes/mysql-at-facebook/can-innodb-do-100k-iops/10150907613720933
Оно может конкурировать с handlersocket (750K req/sec)?
нет, у меня была идея написать небольшой демон под PqSQL на подобии HS
к сожалению pg не поддерживает технологию plugins, по этому это должен бить либо патч,
либо внешнее решение.
к сожалению, пока нет свободного времени, хотя по документации API вполне можно разобраться.
к сожалению pg не поддерживает технологию plugins, по этому это должен бить либо патч,
либо внешнее решение.
к сожалению, пока нет свободного времени, хотя по документации API вполне можно разобраться.
Тут дело даже не только в HS.
Там по ссылке показано, что даже без HS mysql держит 100K+ запросов в секунду. Причем 5.6 будет еще быстрее.
Это значит, что в большинстве случаев можно отказаться от мемкеша — а это значительно упрощает разработку. Инвалидация кеша — одна из сложнейших вещей при разработке.
Вот стоит постгресс того, чтобы на него переходить и всегда перед ним мемкеш сувать?
Там по ссылке показано, что даже без HS mysql держит 100K+ запросов в секунду. Причем 5.6 будет еще быстрее.
Это значит, что в большинстве случаев можно отказаться от мемкеша — а это значительно упрощает разработку. Инвалидация кеша — одна из сложнейших вещей при разработке.
Вот стоит постгресс того, чтобы на него переходить и всегда перед ним мемкеш сувать?
Однажды мне повезло присутствовать на докладе Петра Зайцева о перспективах развития MySQL.
В конце доклада задавали вопросы, в духе: Когда же в Mysql будет тот-то?
А когда это?
На что в половине случаев был ответ, что мол, если вам нужны такие штуки, смотрите на альтернативные решения (PostgreSQL, Oracle).
Вот именно этот доклад заставил меня разобраться с Postgres :)
В конце доклада задавали вопросы, в духе: Когда же в Mysql будет тот-то?
А когда это?
На что в половине случаев был ответ, что мол, если вам нужны такие штуки, смотрите на альтернативные решения (PostgreSQL, Oracle).
Вот именно этот доклад заставил меня разобраться с Postgres :)
Ну ничто не идеально. Есть альтернативы. Может кто-то прочитав вашу статью начнет разрабатывать свой проект на другой СУБД, что-бы небыло «1. Система большая переписать сложно». Уверен, что у других БД есть свои баги
>у что ж комментим баг bugs.mysql.com/bug.php?id=65587 и ждем…
дождались
дождались
[11 Jun 22:02] Miguel Solorzano
I was able to repeat with older source 5.2.25 however not repeatable anymore with today source:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.5.26-debug Source distribution
Ну как бы тут наверное Оракл намекает в сторону большого брата. Мол мы делаем, что можем, но увы. Но тут вот рядом, совершенно случайно, у нас есть другая отличная база данных! У нее фактически нет минусов, только лицензия дофига денюжек стоит
Прошу прощения, не обратил внимания на Expiration…


P.S.: это реальные строчки и результаты выполнения, полученные сегодня.
Работаем на американского заказчика и после 3х лет жизни с mysql целиком мигрируем проект на postgresql. Основные причины — ценообразование mysql и достигнутый потолок в оптимизации сложных запросов.
Прошу прощения, за немного вопрос ни к месту. А на MS SQL никто не мигрировал с MySQL? Как он в сравнении с postgresql?
В сравнении у одного из них есть поддержка, а с другим ты наедине.
А как же enterprisedb.com/?
скажу с точки зрения админа и тех и других: mysql — вечный геморой, за которым надо постоянно следить, чтобы не дай бог чего… mssql — поставил и забыл, разве что читай отчеты о успешных бэкапах, хотя, конечно, такая халява заканчивается, когда начинаются кубы, особенно over https, и репортинг.
Полностью отказаться от мускула в пользу постгрес не позволяет только отсутствие у последнего membership API для ASP.NET.
Живем на 5.1.60 и вообще никаких проблем. Расскажите, зачем вам именно _последняя_ версия?
очень активно используем всяческие фичи, партиции, процедуры, разные фичи для PCI DSS, ниже 5.5.7 мы вообще сейчас не можем опуститься. Но сложилось это исторически, постепенно наращивали версию из-за какой-нибудь новой фичи, в итоге почти всегда нужна свежая версия. Надоела эта гонка по версиям уже, но сделать ничего не можем — поздно.
> shagguboy верно отметил — в одном баге написано, что в 5.5.26 последний баг уже исправлен, за что ему спасибо, а я да — опять жду следующую версию (ИМХО крайне символично)
Ну и везение у вас =( Кстати, 5.5.25a вы сами собирали? Если сами, попробуйте собрать с -DCMAKE_BUILD_TYPE=RelWithDebInfo -DWITH_DEBUG=0 -DENABLE_DEBUG_SYNC=0 Оригинальный баг с этими параметрами не повторяется, хотя ваш-то случай повторяется с нашей сборкой. Единственное, Оракловая сборка с -DENABLE_DEBUG_SYNC=1
Но вообще, если бы у вас была платная поддержка от Oracle, вы могли бы попросить hotfix этого бага прямо сейчас, не дожидаясь новой версии =)
Ну и везение у вас =( Кстати, 5.5.25a вы сами собирали? Если сами, попробуйте собрать с -DCMAKE_BUILD_TYPE=RelWithDebInfo -DWITH_DEBUG=0 -DENABLE_DEBUG_SYNC=0 Оригинальный баг с этими параметрами не повторяется, хотя ваш-то случай повторяется с нашей сборкой. Единственное, Оракловая сборка с -DENABLE_DEBUG_SYNC=1
Но вообще, если бы у вас была платная поддержка от Oracle, вы могли бы попросить hotfix этого бага прямо сейчас, не дожидаясь новой версии =)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сдаем позиции?