много таблиц в mysql напрашивает mydumper

Разве на таких объёмах mysqldump ещё используют?

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

пользователей шаред хостинга не волнуют консистентные бекапы обычно)

это вы на что намекаете?

gtid

вроде как проще там все даже с дампом

при заливке дампа в пг никто не встречал такое Cannot enlarge string buffer containing 0 bytes by 2064092892 more bytes.

?

гтид к дампу же не имеет никакого отношения )

с гтид можно делать —single-transaction

или независимо от?

это никак не связанные вещи. гтид нужен для автопозиционирования репликации, а сингл-транзакшон - для консистентности бекапа транзакционных таблиц

пользователей шаред хостинга не волнуют консистентные бекапы обычно)

Да вопрос не про консистеность. Вопрос сколько времени это количество мелких табличек будет бекапиться. Файлами всяко быстрее. Да и объем, видимо, немаленький. Сколько сейчас средний размер базы на shared? Кажется, с засильем всяких монструозных CMS, должно быть мегабайт 100.

я бы сказал скорее средний размер около гигабайта

точно не считал

верно, большие объемы лучше xtrabackup делать, однако что потом делать если из него нужно вытащить одного клиента из тысяч?

верно, большие объемы лучше xtrabackup делать, однако что потом делать если из него нужно вытащить одного клиента из тысяч?

File per table спасает В этом случае

каким это образом?

ипортирование тейблспейсов?

Да, метаданные там все равно лежат в общем файле.

Как вариант - можно просто mysql натравить на бекап и сделать тот же дамп только одного клиента. Но может есть способы лучше.

на самом деле, если там где хранятся подготовленные xtrabackup-файлы есть возможность пускать этот бекап - то вынуть оттуда данные быстро - не представляется особой сложности

это никак не связанные вещи. гтид нужен для автопозиционирования репликации, а сингл-транзакшон - для консистентности бекапа транзакционных таблиц

я думал он на основе гтид работает

single-transaction можно было всегда делать, а гтид появился лишь в 5.6

Доброе утро! А кто идет на DevConf на следующей неделе - http://devconf.ru/ru/schedule#storage там чумовая программа смотрю.. PostgreSQL vs MySQL vs Tarantool

лучше бы с енотом сравнивали

а, это не в одном докладе :)

Да каждый кулик свое болото хвалит ? когда PostgreSQL завоюет мир - от представителя муськи странно слышать ?-

лучше бы с енотом сравнивали

А енот че?

не знаю, чо-нить

просто сравнение мускуль вс постгрес вс тарантул, выглядит как сравнение базы данных с енотом

или с котом

просто сравнение мускуль вс постгрес вс тарантул, выглядит как сравнение базы данных с енотом

Ты зря на Енота наезжаешь. Мы ж его обучаем

просто сравнение мускуль вс постгрес вс тарантул, выглядит как сравнение базы данных с енотом

Www.fatracoon.com

а будут все эти записи потом где то?

хотя бы за бабки

Доброй ночи - ищем волонтеров на секцию Storage

http://devconf.ru/ru/schedule#storage

есть ли какойто способ посмотреть что мускул свопит?

помоему тут собрались все такие некомпетенты как мы

ненене

мне по мускулю больше помогли в чяте по плюсам :)

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

точней работает не так ка кдолжен

полнотекстовый индекс мускуля?

просто обычно для этого сторонние штуки юзают

сфинкс там

да, не очень идея использовать для полнотекстового поиска mysql

есть ли какойто способ посмотреть что мускул свопит?

в конфигурации стоит memlock?

в конфигурации стоит memlock?

нет

не очень понятны опасности

что будет если мемлок

и оно там кончится

короче суть такая, отсыпали жирный innodb буфер, но мускул продолжает обильно кушать свопчик

короче, используй memlock, настрой мониторинги, грамотно выдели пул под innodb

"грамотно" тут подробнее

сейчас там грубо говоря размер базы

полнотекстовый индекс мускуля?

ну педивикия же работает как то так?

у них там весь дамп мускульный

https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool-resize.html

надо еще зайцева почитать

что там пишуть

короче суть такая, отсыпали жирный innodb буфер, но мускул продолжает обильно кушать свопчик

По идее mysql тут не причем. Свопить или нет это про ядро:) майскуль это все видит как память. Обычно на серваках с бд ставят опцию vm.swappiness = 10 или даж меньше

Ну мож конечно чего не знаю, но навсеидку способа управлять этим из mysql не знаю

сейчас там грубо говоря размер базы

а база вся в иннодб?

а база вся в иннодб?

д

Фуллтекст + иннодб? И как? Быстро работает? По идее должно адово тормозить;) какой там датасет по размеру?

фултекста там нету

база на шесть гигов

.

Так а значения сваппинесс какие? Пробовали ли их снижать?

нет, все по дефолту

необходимости раньше не было

60, да

60 это дефолтный, ну я бы сильно снизил. До 10 как уже говорил

Это помоему рекомендуют и в хай пердформанч майскуэль;)

свап на сервере с базой это зло

обычно попадание в свап значит что все встает раком навсегда

окей, это я понял

но, тогда вопрос

свап на сервере - это зло

что будет когда кончится рама

и прийдет добрый оом

тупо мониторить раму и жать красную кнопку когда пройдут трешхолды?

он же не течет у тебя. ограничь его в памяти и все

это же не монга которая жрет не в себя)

прикинуть сколько он максимум может сожрать умеет mysqltuner

он уже сказал

так, мне надо только обосновать memlock нормально

не надо тебе никакого мемлок

и прийдет добрый оом

Ну оом чтото еще убьет, не?;) хоть оом и тормознутый. У тебя же скоры для бд настроены?

да никто там не настраивал ) стоит мускул и стоит

он недавно начал нагружаться

ждут туда еще нагрузку

да никто там не настраивал ) стоит мускул и стоит

В дебовских пакетиках инии скрипт сразу с установкой скоров

рпм (