forum.bitel.ru
http://forum.bitel.ru/

Смена рекомендуемой СУБД на Percona
http://forum.bitel.ru/viewtopic.php?f=66&t=9721
Страница 1 из 2

Автор:  Администратор [ 17 сен 2014, 12:33 ]
Заголовок сообщения:  Смена рекомендуемой СУБД на Percona

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

Автор:  zavndw [ 17 сен 2014, 13:41 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

Автор:  ok-2004 [ 17 сен 2014, 13:44 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

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

Автор:  barguzin2 [ 19 сен 2014, 16:17 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

Автор:  snark [ 20 сен 2014, 16:11 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

Код:
# uptime
 14:11:00 up 476 days, 11:25,  1 user,  load average: 0.78, 0.79, 0.70

Автор:  barguzin2 [ 20 сен 2014, 19:45 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

Автор:  snark [ 20 сен 2014, 20:22 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

У меня 5.6
Код:
# yum list installed | grep Percona
Percona-Server-client-56.x86_64          5.6.19-rel67.0.el5            installed
Percona-Server-server-56.x86_64          5.6.19-rel67.0.el5            installed
Percona-Server-shared-56.x86_64          5.6.19-rel67.0.el5            installed
Percona-Server-shared-compat.x86_64      5.1.68-rel14.6.551.rhel5      installed

Автор:  barguzin2 [ 20 сен 2014, 23:26 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

Автор:  Phricker [ 20 сен 2014, 23:46 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

А я на 5.5 не жалуюсь %)
Тогда еще 5.6 как бета была ЕМНИМС
Код:
[root@bill ~]# yum list installed | grep Percona
Percona-Server-client-55.x86_64
Percona-Server-server-55.x86_64
Percona-Server-shared-51.x86_64
Percona-Server-shared-55.x86_64

Автор:  barguzin2 [ 21 сен 2014, 14:52 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

snark писал(а):
У меня 5.6

в my.cnf у тебя чему равен innodb_log_file_size ? Поставил 5.6, спотыкается при завливке дампа на таблице installed_modules
Код:
ERROR 1118 (42000) at line 53: Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.

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

Автор:  barguzin2 [ 21 сен 2014, 15:28 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

Нашел вот чего
Код:
InnoDB Notes

Important Change: Redo log writes for large, externally stored BLOB fields could overwrite the most recent checkpoint. The 5.6.20 patch limits the size of redo log BLOB writes to 10% of the redo log file size. The 5.7.5 patch addresses the bug without imposing a limitation. For MySQL 5.5, the bug remains a known limitation.

As a result of the redo log BLOB write limit introduced for MySQL 5.6, the innodb_log_file_size setting should be 10 times larger than the largest BLOB data size found in the rows of your tables plus the length of other variable length fields (VARCHAR, VARBINARY, and TEXT type fields). No action is required if your innodb_log_file_size setting is already sufficiently large or your tables contain no BLOB data.

Note
In MySQL 5.6.22, the redo log BLOB write limit is relaxed to 10% of the total redo log size (innodb_log_file_size * innodb_log_files_in_group).

(Bug #16963396, Bug #19030353, Bug #69477)


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

Автор:  Phricker [ 21 сен 2014, 17:40 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

Код:
innodb_log_file_size = 256M
innodb_log_files_in_group = 2

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

Автор:  snark [ 22 сен 2014, 15:58 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

barguzin2 писал(а):
в my.cnf у тебя чему равен innodb_log_file_size ?

Код:
# grep ^innodb_log_file_size /etc/my.cnf
innodb_log_file_size            = 1G

Автор:  ok-2004 [ 26 сен 2014, 18:17 ]
Заголовок сообщения:  Re: архивация базы и radius-server

Цитата:
Ага оно как раз для тех, кто выбрал в качестве ОС под БД FreeBSD or Windows....


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

Автор:  barguzin2 [ 26 сен 2014, 21:26 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

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

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

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

Автор:  Cromeshnic [ 16 окт 2014, 07:14 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

Автор:  zavndw [ 16 окт 2014, 08:38 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

Автор:  skyb [ 16 окт 2014, 09:11 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

Автор:  barguzin2 [ 20 окт 2014, 19:28 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

Автор:  dm777 [ 24 окт 2014, 21:14 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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.

Автор:  stark [ 16 ноя 2014, 03:09 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

Тестирование производительности форков Mysql на реальных данных

Автор:  Yagoda [ 09 дек 2014, 12:50 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

# 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

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

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

Автор:  ok-2004 [ 09 дек 2014, 15:22 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

Прошу извинить за кривой подчерк, но из тысяч фич, которые есть в 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"

Автор:  max [ 11 дек 2014, 02:15 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

Автор:  stark [ 21 янв 2015, 17:11 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

Отпишусь тут. В Mysql есть еще проблема : regexp не поддерживает многобайтовые кодировки(utf8). Проблема известна давно:
http://bugs.mysql.com/bug.php?id=30241
Но пока так и не исправили.
А вот в mariadb это исправили
Цитата:
Also, REGEXP/RLIKE, and the new functions, now work correctly with all multi-byte character sets supported by MariaDB, including East-Asian character sets (big5, gb2313, gbk, eucjp, eucjpms, cp932, ujis, euckr), and Unicode character sets (utf8, utf8mb4, ucs2, utf16, utf16le, utf32). In earlier versions of MariaDB (and all MySQL versions) REGEXP/RLIKE works correctly only with 8-bit character sets.

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

Автор:  dimOn [ 21 янв 2015, 18:04 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

Автор:  ok-2004 [ 21 янв 2015, 18:48 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

Автор:  zavndw [ 21 янв 2015, 19:14 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

Автор:  stark [ 21 янв 2015, 19:40 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

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

Автор:  skyb [ 21 янв 2015, 20:12 ]
Заголовок сообщения:  Re: Смена рекомендуемой СУБД на Percona

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

Страница 1 из 2 Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/