BiTel

Кхе-кхе... Хочу поделиться одной неприятной неприятностью...

A. Если апгрейд с MS 5.5 до PS 5.6 ведётся каноническим способом:

1. mysqldump -uroot -pxxxxxx --skip-opt --single-transaction --flush-logs --add-drop-database --create-options --add-drop-table --quick --set-charset --verbose --databases bgbilling 2> mydump.txt > bgb.sql
2. apt-get remove mysql-server-5.5
3. rm -rf {/etc/mysql;/var/lib/mysql}
4. apt-get install percona-server-server-5.6

Б. Если после инсталляции Вы по какой-то причине решили "рекретить" ibdata1 и ib_log* в /var/lib/mysql, путём их удаления и рестарта сервера и потом залили базу БЖБ mysql -v -uroot -ppassword < bgb.sql

В. То при работе сервера вы получите в логах вал ерророк вида:"InnoDB: Error: Table "mysql"."innodb_table_stats" not found."

Горькая и сермяжная правда жизни состоит в том, что 5.6(что в PS , что в MS ) в каталоге mysql (в котором со времён царя Соломона все таблицы были на движке myisam) затесались
innodb_index_stats,innodb_table_stats,slave_master_info,slave_relay_log_info,slave_worker_info на движке innodb и диктионарием в ibdata1 естественно.
Вы его грохнули - таблицы потерялись.
Все воркэранунды, разбросанные в инете сильно не помогают, поэтому если вы по каким-то причинам изменили сайзы или кол-во ibdata и ib_log в my.cnf, то в начале потрудитесь сделать так:

mysqldump bgbilling > bgb.sql #выливаем базу
rm -rf /var/lib/mysql/
mkdir /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql/
chmod -R 775 /var/lib/mysql/
mysql_install_db --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --user=mysql # Воссоздаём каталог /var/lib/mysql
dpkg-reconfigure percona-server-server-5.6 #задаем пароли root-a и debian-sys-maint-a
mysql_secure_installation #грохаем анонимуса и тестовую базу
mysql < bgb.sql # вливаем базу взад

К слову говоря иметь innodb-таблицы в mysql каталоге хреноватенько, потому как при восстановлении базы, придётся копировать не только каталог mysql , но и подставлять соответствующий им ibdata1.
Поэтому в свеже-установленном PS 5.6, перед заливкой дампа БЖБ потрудитесь с помощью show create table снять структуру этих таблиц, грохнуть их( так как они по началу пустые ), и перелить их в базу изменив на ENGINE=MyISAM

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

MariaDB percona никак несовместимы ? Я лично пока начинаю склонятся больше к тому, чтобы пока сменить mariadb как рекомендуемую базу для (новых клиентов как минимум), поскольку в основных дистрибутивах уже едет mariadb как замена mysql и она развивается лучше (как минимум баги фиксят).

Недавно открыл для себя , что в Марии в качестве основного движка базы используется самая последняя версия xtradb от Перконы ( естественно со всеми её вкусными плюшками ).
И что не может не порадовать адептов всяких-разных отличных от линуксов ОС-ов - бинарные инсталляторы существуют почти для всех ( в отличие от Перконы). Так что можно даже дерзнуть и обьявить Марию "любимой и единственной женой" для БЖБ ибо PCRE Regular Expressions ( яко сулящие кучу профита для разработчиков) поддерживаются только в ней.

P.S. На тему регеспов, есть о чём задуматься:

http://www.psce.com/blog/2012/03/31/mys ... th-regexp/

P.S2. На тему перевода базы на utf-8, тоже не всё однозначно шоколадно:

https://www.adayinthelifeof.nl/2010/12/ ... -in-mysql/

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

последнюю ссылку не понял, в чём проблема то там? банальности какие-то описаны вроде.

_________________
I'm clever. I've got a computer.

у нас нужен такой like "%иванов%" поэтому индекс все равно не работает. C regexp кстати обошлось, там у нас ошибка была, пока работает вроде в utf8.

подскажите как на перконе делать горячий бекап?

http://wiki.bitel.ru/index.php/Simple_DB_backup же...

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

спасибо, я проморгал вот это Счастливым обладателям mysql 5.6

Походу заинтересовались траснпортабельными тейблспейсами....
Хм, немного подправил статейку в этом пункте, а то много воды уж утекло со времени её первого описания.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

На Галера-Кластер будет работать база ?

в итоге рекомендуем mariadb?

да. На сегодняшний день это оптимальный вариант.

Я так полагаю что речь идёт от MariaDB 10.0 ?
Немного настораживает вот это :

https://mariadb.com/kb/en/mariadb/syste ... -mysql-56/

Может быть разработчики приложат в документацию типовой конфиг my.cnf , которым они пользуются в повседневной работе ?

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

В повседневной работе у нас вообще может быть что угодно . У нас нет больших нагрузок во время разработки. Типовой конфигурации для mariadb пока нет, к сожалению. Есть только для mysql на вики, да и та уже устарела.

В своё время Ув. Разработчики ключевым аргументом перехода на "Машу" назвали переходящий из года в год баг reg.exp c utf8 в стоковом mysql.

Посему вопрос к Ув.Разработчикам - реально используете-ли Вы pcre reg.exp встроенные в "Машу" ?

Если да - то mariadb как база по умолчанию остаётся для БЖБ без вариантов.
Если нет - то я лучше поставлю оракловский 5.7 , который на днях зарелизился на конец-то в GA....

P.S. "Маша" неожиданно упала при дефрагментации бжб-табличек "inet_session_log..." командой "alter table engine innodb..." унеся с собой все партиции и оставив тока головную таблицу. С тех пор я её стал немного меньше любить...

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

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

_________________
I'm clever. I've got a computer.

На самом деле без разницы, и новый мускуль пойдёт. БД используется исключительно как keyvalue - хранилище.
И на старом мускуле могло бы работать, но со старыми есть разные проблемы, но почти все 100% из них всего это какие-то дремучие баги, потому надо просто новые mysql-совместимые и всё.

_________________
I'm clever. I've got a computer.

По нашему ощущению там лучше исправляются баги. И всякие сомнительные фичи типа " если перезагрузить сервер, то автоинкремент сбрасывается в MAX(id)+1". И многие баги не исправлены нигде , даже в самых новых версиях и возможно, не будут исправлены никогда.

В плане надежности тут конечно мы мало что можем сказать, сами мы обычно базу не сопровождаем . Тут статистика актуальная больше у вас. Не исключено, что ванильный mysql более надежен потому что меняется меньше.

Хотя про автоинкремент возможно и там и там не работает, я могу ошибаться. Но есть другие фичи, которые в mariadb реализованы логичнее. Вспомнил - округление миллисекунд например там реализовано правильнее. Сейчас мы вынуждены писать код в расчете на mysql (и иногда на старую версию). Даже если что-то уже работает нормально в mariadb(тоже самое округление миллисекунд), то нам приходится все равно писать код в расчете на mysql (округлять вручную).

Это трижды правильно, писать код под стоковый mysql и рекомендовать "Машу".
Хотя в доке на форки mysql и пишется что они типа drop-in replacement, в доке на "Машу" можно найти различия в синтаксисе в различных функциях и операторах. Сейчас составляю список таких отличий, когда закончу - выложу.
А пока "сухой" остаток на сегодня такой (ИМХО):

1. Percon-у не рассматриваем потому как нет бинарных сборок под фрю и Вынь.
2. Стоковый мускул - не инновационно.
3. "Маша" - имеет место быть .

Если так , то что посоветуете конкретно для этих случаев :

a. https://mariadb.com/kb/en/mariadb/serve ... egex_flags -Какое значение должно иметь ?
b. https://mariadb.com/kb/en/mariadb/old-mode/ - Надо ли выставлять переменную ZERO_DATE_TIME_CAST ?

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

никто особо перкону-сервер и не рекомендовал, вроде. а перкона хтрадб (как innodb с блекджеком) в марии как раз дефолтным движком давно включена и называется там innodb

_________________
I'm clever. I've got a computer.

Т.е правильнее было бы писать код под только машу и бросить остальных на произвол судьбы? В смысле мы пишем такой код, который работает и в mysql и mariadb, но mysql требует иногда дополнительных усилий, в отличии от mariadb.

нет, не надо выставлять.

Извините. Прошло 2 года....

Собираюсь мигрировать на mysql 5.7 / Percona 5.7 . ( пока не решил на какой из них именно... )

Основная причина перехода на 5.7 - "человеческая" возможность восстановления партицированных таблиц в базе по отдельности от всей базы..

Пока склоняюсь к Percon-e из-за :
https://www.percona.com/doc/percona-ser ... cking.html как простой альтернативе репликации.

Но в 5.7 по сравнению с 5.6 уж слишком много Incompatible changes в самом sql:
https://dev.mysql.com/doc/refman/5.7/en ... ql-changes .

(
В 5.6 в основном изменился только формат представления TIMESTAMP и увеличилось количество зарезервированных слов.
https://dev.mysql.com/doc/refman/5.6/en ... ql-changes
)
Посему вопросы :

Вопрос к участникам форума:

Есть ли у кого опыт работы на 5.7 с боевой базой БЖБ ?

Вопрос к разработчикам :

Какой версией и видом mysql Вы используетесь в данный момент разрабатывая БЖБ версий 6.2-7.0 ?

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

У нас пока древняя



Т.е пока новое мы не используем сами, но клиенты вроде ставят. Видел 5.7 у кого-то .

У нас Percona 5.6

Аналогично)