В последние пол года у меня создается двойственное впечатление от использования MySQL. Не хочется давать оценку работе проведённой Oracle, как управляющей компанией, но очень хочется высказаться по поводу того, что уже 5 релизов не могу дождать стабильной версии MySQL которая позволит нормально работать.
5.5.19
Вышел долгожданный релиз в котором пофиксили багу bugs.mysql.com/bug.php?id=56299, благодаря которой каждое переключение логов на нашей БД приходилось мониторить, в виду возможного зависания прода из-за репликации bugs.mysql.com/bug.php?id=61186.
Пока тестировали релиз поняли, что при использовании партиций MySQL безбожно течет. Разработчики утверждают, что это не он течет, а память фрагментируется blogs.innodb.com/wp/2011/12/improving-innodb-memory-usage-continued
А! т.е. если у меня операционка не может использовать память, которой попользовался MySQL, это конечно не мускуль виновать а ОС.
5.5.21
Дождался фикса бага bugs.mysql.com/bug.php?id=57480. Бэкпортом с 5.3.6 пришел фикс, благодаря которому MySQL не надо перегружать каждый месяц, ввиду заполнения swap. Но тут возник новый сюрприз! Который конечно старый, но для PCI DSS асессеров является красной тряпкой, ибо в БД можно попасть без пароля: seclists.org/oss-sec/2012/q2/493. Проблема была хорошо освещена на хабре habrahabr.ru/post/145641/. Все версии до 5.5.22 уязвимы. Сами мы не быстрые, тестируемся, качаем исходники патчим.
5.5.25
Пока патчим и тестим выходит 5.5.25. Ну вроде фиксов там много, решили её ставить. Месяц назад запустили процесс тестирования данной версии. Пишу тикет, тут бах сюрприз! Исходники этой версии пропали с сайта. Патч есть, собрать не можем, ибо качать исходники неоткуда. Причина тривиальна bugs.mysql.com/bug.php?id=65745. Update первичного ключа (не знаю кому в голову пришло update'тить первичный ключ) вызывает рекурсивное изменение данных, что приводит к заполнению всего места на HDD.
5.5.25a
Ура вышла новая версия. Уж там то все должно работать. Проверяем работу: внезапно один из разработчиков говрит, что у него MySQL падает на любом запросе. Проверяем. И правда, если из партиционированной таблицы запросить данные за несуществующий период, то MySQL падает с ошибкой
12:06:58 UTC - mysqld got signal 8 ;
This could be because you hit a bug.
...
Thread pointer: 0x4169f30
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7ff9fa384e58 thread_stack 0x30000
/opt/mysql-5.5.25a/bin/mysqld(my_print_stacktrace+0x29)[0x75feb9]
...
/opt/mysql-5.5.25a/bin/mysqld(pfs_spawn_thread+0x54)[0x879cf4]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7efc)[0x7ffa669e8efc]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7ffa65d5b59d]
Проверяем — уязвимы все версии до 5.5.22, но в 5.5.22 можно зайти без пароля. Что делать не знаю. Сидим чешем репу. У меня к примеру после запуска этого скрипта (который мы методом тыка писали целый день) перегружается Ubuntu.
use test_mysql_crash;
drop table if exists test_table;
create table test_table (
agad_id int(10) unsigned not null auto_increment,
partition_key int(8) not null default '0',
caaf_caaf_id int(10) unsigned default null,
primary key (agad_id,partition_key),
key idx_1 (partition_key),
key idx_2 (caaf_caaf_id)
) engine=innodb
partition by range (partition_key)
(partition test_table_20120717 values less than (20120718) engine = innodb,
partition test_table_20120718 values less than (20120719) engine = innodb,
partition test_table_20120719 values less than (20120720) engine = innodb,
partition test_table_20120720 values less than (20120721) engine = innodb,
partition test_table_20120721 values less than (20120722) engine = innodb);
drop procedure if exists ui_test_mysql_crash;
delimiter $$
create procedure ui_test_mysql_crash()
main_sql:
begin
declare v_sql_core text;
set v_sql_core =
concat(
' explain select caaf_caaf_id, ',
' partition_key ',
' from test_table ',
' where partition_key between ? and ? ',
' group by caaf_caaf_id, partition_key'
);
set @sv_ddl_statement = v_sql_core;
set @sv_partition_key_from = 20120801;
set @sv_partition_key_to = 20120831;
prepare v_stmt from @sv_ddl_statement;
execute v_stmt using @sv_partition_key_from, @sv_partition_key_to;
deallocate prepare v_stmt;
end
$$
delimiter ;
call ui_test_mysql_crash;
Ну что ж комментим баг bugs.mysql.com/bug.php?id=65587 и ждем…
P.S. конечно все события не хронологичны, просто хотелось описать, что во всех последних версиях что-то не так…
Автор: snevsky
