BiTel

Из плюсов:
1) готовая система горячего бэкапа;
2) улучшена производительность;
3) мастер-мастер репликация;
4) возможность дополнительной платной поддержки.

на mariadb пока то же ни чего

перкона! тока перкона!, Петя Зайцев плохого не напишет

горячие бэкапы - это ваще песня., ради её можно и Percona XtraDB Cluster поставить
идеология мариадб похожа на опенбсд- всё переписать под чистую в ущерб надёжности и функциональности.

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

а сейчас то её можно под БГ использовать не опасаясь за возможные баги? xtrabackup использую и сейчас для oracle mysql

Уже давно использую перкону вместо стандартного мускула. За время использования никаких глюков замечено не было.

какая версия ? и какую лучше использовать сейчас ? 5.5 ?

У меня 5.6

про mysql 5.6 пишут очень много что в производительности проигрывает версии 5.5. percona 5.6 это не унаследовала ?

Верните быстрый ответ

А я на 5.5 не жалуюсь %)
Тогда еще 5.6 как бета была ЕМНИМС

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

в my.cnf у тебя чему равен innodb_log_file_size ? Поставил 5.6, спотыкается при завливке дампа на таблице installed_modules

Данные рекомендации ROW_FORMAT не помогают (добавлял в текст дампа и пробовал снова заливать). Если поставить innodb_log_file_size=256М, то пролазит. Только не пойму связи и не будет ли сюрпризов в дальнейшем ?

http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-20.html

Нашел вот чего


Судя по этому описанию размер объекта client_zip может быть максимум 10% от размера лог-файла. учитывая, что изначально он был 128М, то объект почти в 13М получается максимальный может быть. Но вроде клиентские зипы не такие уж огромные. Можете прояснить ситуацию ?

ЕМНИМС размер данного лог файла в идеале должен вмещать 30-60 минут работы базы под нагрузкой. Правда и сильно большим нельзя делать.

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

По большому счёту что в перконе, что в оракле DDL и DML одинаковы. Поэтому немного был удивлён, что BiTel-овцы поставили на голосование в "проектах" эту тему. Хотел даже задать им встречный вопрос : Что нового BiTel-овцы жаждут получить от перконы как програмисты, и что нового BiTel-овцы жаждут получить от перконы как администраторы баз данных.
Если они как програмисты заинтересованы в переходе на перкону, тогда - да, переход на перкону никогда не состоится , потому как не каждый согласиться с FreeBSD или Win-ы перейти на Lin.
А если чисто как администраторы - тогда кому какая разница кто как админит и чем админит свою базу : средствами перконы, марриДБ или оракла? Бизнес логика то не поменяется.... Получается тогда , что голосование в проектах на тему перехода - "ни о чём" ?

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

Речь идет только о рекомендациях. Вот сейчас, например, в качестве ОС можно использовать любую, на которой заведется MySQL и JAVA-приложения, но рекомендуемая таки Linux. Java также рекомендуется от Oracle. Однако, не запрещается иcиспользовать Windows, FreeBSD, OpenJDK, пр., что у некоторых вполне таки работает.

Вот и с MySQL тоже самое - можете использовать Oracle MySQL, MariaDB, Percona, но рекомендация будет отдаваться последней в силу определенных доводов. О чем, собственно, и речь. А решать что использовать, в конечном итоге, каждый будет сам по прежнему.

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

Поэтому данное обсуждение имеет место быть и далеко не лишено смысла. Продолжаем...

Перешли на Percona 5.6.20-68.0-log
3 часа полёт нормальный.

мы еще собираем:) и выбираем время

тоже в планах...

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

уже почти месяц...

Your MySQL connection id is 323
Server version: 5.5.36-34.2-648.precise (Ubuntu)

Copyright (c) 2009-2014 Percona LLC and/or its affiliates
Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

# dpkg -l | grep percona
libperconaserverclient18.1 5.6.16-64.2-569.squeeze
percona-server-client-5.6 5.6.16-64.2-569.squeeze
percona-server-common-5.6 5.6.16-64.2-569.squeeze
percona-server-server 5.6.16-64.2-569.squeeze
percona-server-server-5.6 5.6.16-64.2-569.squeeze
percona-xtrabackup 2.1.8-733-1.squeeze

# uname -r
2.6.32-5-amd64

# ./server_status.sh
BGBillingServer v 6.0 build 1811 from 13.11.2014 18:45:59

# uptime
16:43:14 up 223 days, 10:02

Наверное с год уже на перконе. Самый главный стимул был - легкость (для системы) и скорость резервного копирования.
Но в итоге, дополнительно, сильно разгрузили процессор.

Так что всем рекомендую. И для работы и для администрирования (резервное копирование) предпочтительнее.

Прошу извинить за кривой подчерк, но из тысяч фич, которые есть в Percona Server (PS) и которых нет в Oracle Mysql Server(OS) я бы выделил тока несколько наиболее "вкусных" для меня и попытаюсь сгруппировать их как ответы на 2 вопроса:

1. Почему надо переходить на PS ( а не на OS ) ?:

a. Потому что PS поддерживает XtraDB changed page tracking, позволяющую xtrabackup в инкрементальном режиме сканировать тока изменившиеся страницы в таблицах, а не все таблицы целиком.
b. Наличием переменной innodb_pass_corrupt_table, позволяющей не "крашиться" серверу при коррупции отдельных таблиц, и косвенно влияющей на возможность tcpdump-а дампить базу обходя эти таблицы. без запуска mysqld в "аварийном режиме" с innodb_force_recovery=1...6.
c. Наличием переменной innodb_fast_recovery, позволяющей при innodb_log_file_size > 256MB сократить ремонт таблиц в разы а не в процентах.

2. Почему следует переходить на PS 5.6 ( а не на PS 5.5) ?:

a. Потому что он наследует от upstream OS 5.6 "ignore-db-dir=lost+found " позволяющую монтировать отдельную партицию прямо /var/lib/mysql без извращений с "mount-bind".
b. Потому что он наследует от upstream OS 5.6 "Transportable Tablespaces" позволяющую кидать отдельные таблицы innodb из бэкапа в базу БЖБ.
с. Потому что он имеет LOCK BINLOG FOR BACKUP и Log Archiving for XtraDB, позволяющую сделать один раз в сутки полный дамп базы, а потом автоматичекси архивировать тока innodb redo logs во время их ротации
и делать point-in-time recovery без привлечения binlogs и следовательно не снижая производительности сервера.

Чего надо опасаться при переходе с 5.5 ( PS или OS ) на 5.6 ( PS или OS ):

1. В таблице mysql.user стало 43 колонки ( вместо 42 в 5.5 ).
Если mysql_upgrade "не прошлась" по каталогу mysql - можно получить сокраментальную фразу:"ERROR 1045 (28000): Access denied for user 'root'@'localhost'"

2. TIME, DATETIME TIMESTAMP переменные теперь содержат и микросекунды и ваще сменили тип данных с (INT) на (FIXBINARY).
При запуске mysql_upgrade будет делаться alter_table во всех таблицах БЖБ. Но если п.1 будет выполняться после п.2 то получите отлуп от мускула.
Поэтому настоятельно рекомендуется вначале грохнуть базу БЖБ ( естественно сняв дамп ).Потом поставить чистый PS 5.6 грохнув предыдущий 5.5 вместе с каталогом /var/lib/mysql.
Подсунуть к 5.6 старый /var/lib/mysql/mysql . Запусить mysql_upgrade( лучше до этого запустив мускул так :/usr/sbin/mysqld --skip-grant-tables --skip-networking &) . А потом уже скормить дамп базы БЖБ.

3.PERFOMANCE_SHEMA и STRICT_ALL_TABLES(STRICT_TRANS_TABLES) таперича "ON" по дефолту. Первая необосновано грузит мускул, вторая не даст залить вам дамп корректно .

4. Если не хотите проблем с репликацией поставьте в [mysqld]:

innodb_checksum_algorithm=INNODB
binlog_checksum=NONE

5. Возможно придётся бороться с наличием FULLTEXT search Indexes ( в БЖБ вродь не используются, но вырубить эту фичу мне не удалось ).

P.S.

Пара таблиц для модуля Documents к моей досаде содержат FOREIGN KEY_s. Поэтому при заливке дампа лучше сделать "foreign_key_checks = 0"

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

На статью в викки тянет

_________________
Интернет и телефония оптом со склада, или в розницу

Отпишусь тут. В Mysql есть еще проблема : regexp не поддерживает многобайтовые кодировки(utf8). Проблема известна давно:
http://bugs.mysql.com/bug.php?id=30241
Но пока так и не исправили.
А вот в mariadb это исправили

Не смог пока найти как с этим в percona . Кстати у percona нет как будто документации подробной, т.е надо смотреть документацию mysql + фишки percona, они описывают только свои фишки . Из всех 3-х(mysql, mariadb, percona), у mysql самая подробная документация на текущий момент.

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

REGEXP-баг c UNICODE успешно заболтали со статуса "serious" до "feature request" с различными воркэраундами и лимитациями.
У Перконы с этим тоже никак, потому как regexp library им пилить не интересно.
Их цель - мускул с блэкджеком и шлюхами для админов баз данных а не для разработчиков.
Баги в апстриме они фиксят тока если они как-то касаются innodb.
Ихняя дока в основном придерживается правила: "что надо подкрутить на сервере, чтобы галера и xtrabackup работали так как надо - читаем у нас, остальное - на dev.mysql.com"

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

Сегодня перешли на перкона 5.6 правда с mysql 5.5 как то это не совсем понятно прошло. TIME, DATETIME TIMESTAMP это критично для работы?

В inet одна бага вылезла - исправили(на skybe кажется). Больше пока вроде ничего не вылезало.

дада, опять на мне ))) !!!

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений