на mariadb пока то же ни чего
| 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 пока то же ни чего
|
|
| Автор: | 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/ |
|