Re: [freebsd] Необычный дамп базы mysql
On 03/14/2012 11:26 PM, Alexandr Kovalenko wrote: Спасибо, вроде бы неплохая штука, попробую. Штука крайне полезная. Особенно крута если у вас нет myisam. В портах будет как только мы договоримся с перконой о размещении части исходников (я пока на свой сервер их положил), думаю это будет в ближайшее время. Советую посмотреть на xtrabackup. Я сделал порт последней версии, доступен (пока) тут: http://redports.org/browser/samm/databases/xtrabackup А можно с этого места поподробнее? Куда/что/зачем? Да особо нечего рассказывать - в линуксе в процессе сборки бинарника используется bzr. Возможно в бинарных системах такое и можно себе позволить, но в портах фри - это явных перебор. Я выкачал недостающие исходники, положил их на свой сервер и сделал новый порт. Но коммитить его в таком виде не хотел. Сейчас решили вопрос их размещения у апстрима и я сегодня-завтра оформлю update PR.
Re: [freebsd] Необычный дамп базы mysql
On 03/12/2012 04:01 PM, skeletor wrote: 12.03.2012 15:39, Alex Samorukov пишет: Советую посмотреть на xtrabackup. Я сделал порт последней версии, доступен (пока) тут: http://redports.org/browser/samm/databases/xtrabackup Спасибо, вроде бы неплохая штука, попробую. Штука крайне полезная. Особенно крута если у вас нет myisam. В портах будет как только мы договоримся с перконой о размещении части исходников (я пока на свой сервер их положил), думаю это будет в ближайшее время.
Re: [freebsd] Необычный дамп базы mysql
12.03.2012 15:39, Alex Samorukov пишет: Советую посмотреть на xtrabackup. Я сделал порт последней версии, доступен (пока) тут: http://redports.org/browser/samm/databases/xtrabackup Спасибо, вроде бы неплохая штука, попробую.
Re: [freebsd] Необычный дамп базы mysql
Советую посмотреть на xtrabackup. Я сделал порт последней версии, доступен (пока) тут: http://redports.org/browser/samm/databases/xtrabackup On 03/12/2012 02:32 PM, skeletor wrote: 12.03.2012 15:13, Владислав Продан пишет: У мну подобный скрипт работает, типы и размер баз разные.. Только в момент создания снапшота иногда теряется одно активное соединение. Подобный это в смысле без лока? Я вот только что попробовал без лока - с первого раза не удалось распределить innodb_pool, вообщем mysql поднялся. Ещё нашёл mysql cluster. Кто-то его использует? Там вроде бы репликация получше, чем стандартная.
Re: [freebsd] Необычный дамп базы mysql
12.03.2012 15:13, Владислав Продан пишет: У мну подобный скрипт работает, типы и размер баз разные.. Только в момент создания снапшота иногда теряется одно активное соединение. Подобный это в смысле без лока? Я вот только что попробовал без лока - с первого раза не удалось распределить innodb_pool, вообщем mysql поднялся. Ещё нашёл mysql cluster. Кто-то его использует? Там вроде бы репликация получше, чем стандартная.
Re: [freebsd] Необычный дамп базы mysql
У мну подобный скрипт работает, типы и размер баз разные. Только в момент создания снапшота иногда теряется одно активное соединение. --- Исходное сообщение --- От кого: "skeletor" Кому: freebsd@uafug.org.ua Дата: 12 марта 2012, 14:27:10 Тема: Re: [freebsd] Необычный дамп базы mysql > 09.02.2012 13:10, skeletor пишет: > > Ещё раз всем привет. > > Провёл я указанную операцию (lock;snapshot;unlock) и скажу, что всё > > успешно перенеслось и заработало. > > Хотел бы рассказать о некоторых моментах (возможно кому-то помогут) > > > Всем привет ещё раз. > В процессе тестирования выявил такую проблему: скрипт подвисает. То есть > база лочиться и после этого должен делаться снапшот zfs, но он не > делается. Как итог - сайт лежит (так как база залочена). В процессах > ничего не успел увидеть, так как нужно было в ручном режиме быстро > разлочивать базу. По сему итог: из (примерно) 25 попыток 1 попытка > привела к такому результату. > > По сему вопрос: может ещё есть какие-то методы? > > Сейчас тестирую метод влоб (понимаю, что это неправильно) делать снапшот > Zfs без лока базы. -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE
Re: [freebsd] Необычный дамп базы mysql
On 03/12/12 14:26, skeletor wrote: 09.02.2012 13:10, skeletor пишет: Ещё раз всем привет. Провёл я указанную операцию (lock;snapshot;unlock) и скажу, что всё успешно перенеслось и заработало. Хотел бы рассказать о некоторых моментах (возможно кому-то помогут) Всем привет ещё раз. В процессе тестирования выявил такую проблему: скрипт подвисает. То есть база лочиться и после этого должен делаться снапшот zfs, но он не делается. Как итог - сайт лежит (так как база залочена). В процессах ничего не успел увидеть, так как нужно было в ручном режиме быстро разлочивать базу. По сему итог: из (примерно) 25 попыток 1 попытка привела к такому результату. По сему вопрос: может ещё есть какие-то методы? Сейчас тестирую метод влоб (понимаю, что это неправильно) делать снапшот Zfs без лока базы. Лок не может быть выставлен, пока не выполнятся все текущие запросы изменяющие данные. Отсюда вывод.
Re: [freebsd] Необычный дамп базы mysql
09.02.2012 13:10, skeletor пишет: Ещё раз всем привет. Провёл я указанную операцию (lock;snapshot;unlock) и скажу, что всё успешно перенеслось и заработало. Хотел бы рассказать о некоторых моментах (возможно кому-то помогут) Всем привет ещё раз. В процессе тестирования выявил такую проблему: скрипт подвисает. То есть база лочиться и после этого должен делаться снапшот zfs, но он не делается. Как итог - сайт лежит (так как база залочена). В процессах ничего не успел увидеть, так как нужно было в ручном режиме быстро разлочивать базу. По сему итог: из (примерно) 25 попыток 1 попытка привела к такому результату. По сему вопрос: может ещё есть какие-то методы? Сейчас тестирую метод влоб (понимаю, что это неправильно) делать снапшот Zfs без лока базы.
Re: [freebsd] Необычный дамп базы mysql
On Thu, Feb 09, 2012 at 01:10:21PM +0200, skeletor wrote: > Хотел бы рассказать о некоторых моментах (возможно кому-то помогут) к чорту подробности, страна-то какая? В смысле - операционная система? > 2) переносить лучше НЕ используя mbuff, так как при этом он опять же будет в частности и в этом вот месте загадка. > Alex
Re: [freebsd] Необычный дамп базы mysql
Ещё раз всем привет. Провёл я указанную операцию (lock;snapshot;unlock) и скажу, что всё успешно перенеслось и заработало. Хотел бы рассказать о некоторых моментах (возможно кому-то помогут) 1) снапшот делается быстро (на нагруженом сервере минуты 3, на не очень - пару секунд) . Естественно, что в это время сайт лежит. 2) переносить лучше НЕ используя mbuff, так как при этом он опять же будет сильно нагружать диски. Лично я переносил и сразу делал receive пайпом (zfs send -R rpool/db@backup | ssh skele...@xx.xx.xx.xx "sudo /usr/sbin/zfs receive -Fd rpool") , что бы сразу разкатывать zfs. 3) старт mysql происходит минут 5, так как он долго делает InnoDB: Doing recovery: scanned up to log sequence number а потом ещё InnoDB: Progress in percents: 0 1 2 3 4 Но это нормально, так как мы делали снапшот наживую. После всего этого нормально запускается. Кстати, перенос делался с zfs 28 версии на zfs 29 версию. И ещё - следите внимательно за свойствами zfs: они могут носить характер received. Спасибо всем за помощь.
Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Tue, Feb 07, 2012 at 06:52:36PM +0400, Sergey Rudenko wrote: > > напишите вместо этого одиночный селект. from forum,forum_t, вместе с id. > Если вас не затруднит, напишите пример такого запроса я уже практически написал. Да, он вернет гораздо больше чем надо - ну и что? > Джоимов может быть 20 штук и более, предлагаете все данные в одну таблицу > пихать? если их двадцать штук и это не раз в час, а на каждый запрос - предлагаю предварительно прописать бамбуковую палку по пяткам тому кто придумал такую структуру данных. В одну или в несколько - думать головой. Вот фэйсбук, как видим, в нее не только ест, и у них джойнов нету. Не думаю что ваши данные сильно сложнее фейсбучных. На днях как раз такой сон разума переделывал (крошечный, но работать с ним было неудобно). От полутора десятков (не помню сколько, но что-то совсем безобразное) таблиц осталось две, джойна ни одного потому что единственное поле ради которого джойнили - наличествует теперь просто в обоих таблицах и достаточно простого where id=id , а запрос занимает пол-строчки, а не пять. Ну и вот зачем этот бред изначально городили? Правильно: аффтар начитался детских книжек про нормальную форму. > Alex
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
Сорри, отсутствовал. 2Sergey Rudenko > Неужели БД "тупее" приложения будет? Не тупее, но у грузовика задача перевозить много картофеля, а у мазерати быстро до сотни разгоняться. БД пусть хранит и выбирает данные, т.е. то под что она оптимизирована. 2Alex Korchmar > > Я работаю с клиентами у которых > бюджет ограничен и которые понимают что такое управление рисками, и не > афиллирован с конторами по впариванию железа (увы ;-) Работайте. Дайте Ваш контакт в личку - буду давать при случае. Кстати, я не аффилирован ни с кем. Я даю ТТХ, а заказчик закупает сам в удобных ему местах. Просто я не вкладываю свой интерес в железо и не занижаю стоимость своей работы) > Ну или делать такую структуру тазы банных, чтобы ей не были нужны join'ы Именно так. 2Sayetsky Anton > Расскажите это разрабочтикам на "труъ ынтырпрайз оракуле", которые > бОльшую часть логики пишут в БД, и оно там как-то работает. Без разницы какая БД. Разница в том КАК оно в итоге работает и сколько ресурсов требует. 2Alex Samorukov > Я, конечно, не модератор - но друзья, при чём тут BSD? Для этого есть > множество sql и non-sql форумов. Алекс(-ей,-андр?), Вы абсолютно правы. Просто коллегу возмутило, что кто-то зарабатывает деньги, требуя нормальное железо и сам выбирает себе заказчиков, а кто-то работает со всеми подряд. -- Think before you print. Best regards, Alexey Bobok.
[freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
7 февраля 2012 г. 17:24 пользователь Denis Zhdanov написал: > Мегаоффтоп - но разве ФБ хайрит кого то из за рубежа? Вроде раньше у > них была политика "брать только своих". Сам себе отвечу - да, похоже политика поменялась, в 2011 программеров по крайней мере набирали, и с России и с Укрины тоже. Мало-мало, но есть... Ж)
[freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
7 февраля 2012 г. 17:15 пользователь Alex Samorukov написал: > Кстати, facebook активно нанимал MySQL DBA недавно (Ирландия или > Калифорния), так что если у кого есть желание узнать как оно там внутри - у > меня где-то контакты их HR`а сохранились ;-) Мегаоффтоп - но разве ФБ хайрит кого то из за рубежа? Вроде раньше у них была политика "брать только своих".
Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On 02/07/2012 03:52 PM, Sergey Rudenko wrote: просто селект в данном случае тот-же джоин. именно. _ваш_ селект - тот же джойн, только, вероятно, еще и хуже автооптимизирующийся. Ну так не делайте таких селектов. select thread_name, (SELECT forum_name FROM forum WHERE forum_id = thread_forum_id) from forum_t напишите вместо этого одиночный селект. from forum,forum_t, вместе с id. Если вас не затруднит, напишите пример такого запроса Я, конечно, не модератор - но друзья, при чём тут BSD? Для этого есть множество sql и non-sql форумов. И да, вариант архитектуры facebook - просто 1 из вариантов архитектуры, не более. Они и репликацию мискла не используют, чтобы в сериализованный бинлог не упираться, но это не значит, что так надо делать всем. Все зависит от множества факторов, и, кстати, read only selects можно неплохо масштабировать, если речь не идет о транзакциях, конечно. Кстати, facebook активно нанимал MySQL DBA недавно (Ирландия или Калифорния), так что если у кого есть желание узнать как оно там внутри - у меня где-то контакты их HR`а сохранились ;-)
[freebsd] Re: [freebsd] Необычный дамп базы mysql
07 февраля 2012, 18:40 от Alex Korchmar <4spa...@linux.e-moe.ru>: > On Tue, Feb 07, 2012 at 02:50:53PM +0400, Sergey Rudenko wrote: > > > Я вас правильно понял, > повторяю: вы ничего не поняли. > > > просто селект в данном случае тот-же джоин. > именно. _ваш_ селект - тот же джойн, только, вероятно, еще и хуже > автооптимизирующийся. Ну так не делайте таких селектов. > > > select thread_name, > > (SELECT forum_name FROM forum WHERE forum_id = thread_forum_id) > > from forum_t > напишите вместо этого одиночный селект. from forum,forum_t, вместе с id. Если вас не затруднит, напишите пример такого запроса > Дальше два варианта - либо вы фронтендом вручную сортируете результат, если > его немного, это неудобно программировать зато фронтендов может быть много, > либо меняете структуру базы данных - складываете свой 'forum_name' в forum_t, > и забываете всю глубокомысленную ерунду которой вас учили в институте. Джоимов может быть 20 штук и более, предлагаете все данные в одну таблицу пихать? > Целостность данных придется поддерживать либо триггером, либо опять же > фронтендом, ничего особенно ужасного в этом, обычно, нет. > > > Alex > >
Re: [freebsd] Re[2]: [freebsd] Re[2]: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Tue, Feb 07, 2012 at 02:50:53PM +0400, Sergey Rudenko wrote: > Я вас правильно понял, повторяю: вы ничего не поняли. > просто селект в данном случае тот-же джоин. именно. _ваш_ селект - тот же джойн, только, вероятно, еще и хуже автооптимизирующийся. Ну так не делайте таких селектов. > select thread_name, > (SELECT forum_name FROM forum WHERE forum_id = thread_forum_id) > from forum_t напишите вместо этого одиночный селект. from forum,forum_t, вместе с id. Дальше два варианта - либо вы фронтендом вручную сортируете результат, если его немного, это неудобно программировать зато фронтендов может быть много, либо меняете структуру базы данных - складываете свой 'forum_name' в forum_t, и забываете всю глубокомысленную ерунду которой вас учили в институте. Целостность данных придется поддерживать либо триггером, либо опять же фронтендом, ничего особенно ужасного в этом, обычно, нет. > Alex
[freebsd] Re: [freebsd] Необычный дамп базы mysql
Безотносительно системы, но посмотрите сюда http://www.percona.com/software/percona-xtrabackup/ Пользуемся сами на критичных серверах именно для бекапов Слепок с 600г данных делается 4ч Восстановление с такого бекапа - порядка 2-3ч On Feb 6, 2012, at 15:07 , skeletor wrote: > Есть сервер в продакшине и с него нужно сделать дамп баз. Базы большие (50 Гб > каждая). Проблема в том, что при дампе идёт сильная нагрузка на диски и в > итоге - основной сайт лежит. > > Какие средства пробовались: > - обычный дамп через mysqldump на другие диски > - дамп через mysqldump по сети сразу на другой хост > > Но даже и в этом случае диски нагружаются достаточно, что бы сайт не отвечал. > > ПС. Сам сайт и БД лежат на разных серверах и фраза "сайт лежит" означает, что > истекает таймаут при подключении к БД. > > Может есть варианты ещё как-то сделать дамп или выставить поменьше нагрузку > на диски. nice/renice - не помогают, так как сервак не настолько нагружен, > что бы приоритет влиял на это. > > Заранее спасибо. >
[freebsd] Re[2]: [freebsd] Re[2]: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
Я вас правильно понял, просто селект в данном случае тот-же джоин. Не думаю, что в ФБ они заменили джоины на селекты и этим добились большей производительности Специально протестировал на mysql таблица 4 записей, большей под рукой сейчас нет Первое значение это первый запрос, второе после того как он закешировался select thread_name, (SELECT forum_name FROM forum WHERE forum_id = thread_forum_id) from forum_t SQL запросов: 1, время mysql: 0.538739, всего затрачено: 0.615614 секунд !Процент времени на MySQL: 87.51% SQL запросов: 1, время mysql: 0.013977, всего затрачено: 0.089507 секунд !Процент времени на MySQL: 15.62% SELECT forum_t.thread_name, forum.forum_name FROM forum_t LEFT JOIN forum ON(forum_id = thread_forum_id) SQL запросов: 1, время mysql: 0.301786, всего затрачено: 0.368958 секунд !Процент времени на MySQL: 81.79% SQL запросов: 1, время mysql: 0.013766, всего затрачено: 0.082863 секунд !Процент времени на MySQL: 16.61% 07 февраля 2012, 12:37 от Alex Korchmar <4spa...@linux.e-moe.ru>: > On Tue, Feb 07, 2012 at 12:26:39PM +0400, Sergey Rudenko wrote: > > > Отвечу цитатой > А из чего цитата? А то оно как-то резко расходится со здравым смыслом и > реальностью данной в ощущениях. > > Если, как подсказывает гугель, > http://skahin.blogspot.com/2009/10/left-join-select.html > - то там логотип ms sql как бе намекает... > > ну и я говорил не о синтаксической, а о логической замене join'ов. Вы, похоже, > так и не поняли. > > > Alex > >
[freebsd] Re: [freebsd] Необычный дамп базы mysql
7 февраля 2012 г. 11:50 пользователь Vladimir Mevsha написал: > Да, это чисто солярисовская заморочка, на собственных тестах проблем > с производительностью не заметил. Тем не менее, mbuffer в портах топика есть. Кстати, я вот подумал... а какого хрена тема имеет метку [freebsd], а не [freebsd-beer]?
Re: [freebsd] Необычный дамп базы mysql
07.02.2012 11:39, Alex Korchmar пишет: On Tue, Feb 07, 2012 at 11:14:43AM +0200, skeletor wrote: Ага, но лучше это делать не в лоб send/receive, а через mbuff а не чисто-солярисовая ли это заморочка? Да, это чисто солярисовская заморочка, на собственных тестах проблем с производительностью не заметил. -- Vladimir Mevsha
Re: [freebsd] Необычный дамп базы mysql
07.02.2012 11:39, Alex Korchmar пишет: On Tue, Feb 07, 2012 at 11:14:43AM +0200, skeletor wrote: Ага, но лучше это делать не в лоб send/receive, а через mbuff а не чисто-солярисовая ли это заморочка? Alex Видимо да.
Re: [freebsd] Необычный дамп базы mysql
On Tue, Feb 07, 2012 at 11:14:43AM +0200, skeletor wrote: > Ага, но лучше это делать не в лоб send/receive, а через mbuff а не чисто-солярисовая ли это заморочка? > Alex
Re: [freebsd] Необычный дамп базы mysql
07.02.2012 10:23, Vladimir Mevsha пишет: В таком случае советую посмотреть еще и на zfs send/receive (в случае, если БД будет в отдельном dataset). Ага, но лучше это делать не в лоб send/receive, а через mbuff Здесь на примере показано как это сделать http://www.nest.org.ru/2011/05/11/%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D1%8B-%D1%81-%D0%BF%D1%80%D0%BE%D0%B8%D0%B7%D0%B2%D0%BE%D0%B4%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C%D1%8E-%D0%BF%D0%B0%D1%80%D1%8B-zfs/ Скоро отпишусь о результатах.
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
6 февраля 2012 г. 22:49 пользователь Алексей Бобок написал: > Вся логика - в приложении. Задача БД - хранить данные и быстро выбирать. Расскажите это разрабочтикам на "труъ ынтырпрайз оракуле", которые бОльшую часть логики пишут в БД, и оно там как-то работает.
Re: [freebsd] Необычный дамп базы mysql
07.02.2012 10:28, Alex Korchmar пишет: On Tue, Feb 07, 2012 at 10:23:20AM +0200, Vladimir Mevsha wrote: Пока сейчас вижу способ с lock table и zfs snapshot В таком случае советую посмотреть еще и на zfs send/receive а вот кто расскажет, по личным впечатлениям - насколько оно все встает колом при создании снапшота? И не сказывается ли его наличие-удаление на скорости работы с диском? Если на глазок, то создание снапшота в zfs и его наличие не влияет на производительность операций с диском. при заявленных размерах базы или чуть поболее, про базки в сотни мегабайт неинтересно. Alex -- Vladimir Mevsha
Re: [freebsd] Re: [freebsd] Re[2]: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Tue, Feb 07, 2012 at 10:35:40AM +0200, Denis Zhdanov wrote: > А мужики в FB не знают... :) > Тогда вопрос - чего ж тогда такой бум NoSQL сейчас? ну типа, кризис, становятся модными системы из говн...зачеркнуто, облачные структуры... > В них тоже джойнов нет, и особой серверной логики тоже - максимум > примитивы, типа SORT зато сервера получаются дешевые и много. > Alex
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
6 февраля 2012 г. 21:35 пользователь Sergey V. Dyatko написал: > сколько из 92Г весят бинлоги, например?:) # du -hs /var/lib/mysql/ 92G /var/lib/mysql/ # find /var/lib/mysql/ -name \*bin\* # Как бы 0 байт бинлоги весят. ЗЫЖ Тоже 1 база. ЗЗЫЖ И это не фаллометрия, а пример БД на мускуле, которая весит более 50 гиг, что опровергает изречение одного из предыдущих ораторов.
Re: [freebsd] Re[2]: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Tue, Feb 07, 2012 at 12:26:39PM +0400, Sergey Rudenko wrote: > Отвечу цитатой А из чего цитата? А то оно как-то резко расходится со здравым смыслом и реальностью данной в ощущениях. Если, как подсказывает гугель, http://skahin.blogspot.com/2009/10/left-join-select.html - то там логотип ms sql как бе намекает... ну и я говорил не о синтаксической, а о логической замене join'ов. Вы, похоже, так и не поняли. > Alex
[freebsd] Re: [freebsd] Re[2]: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
7 февраля 2012 г. 10:26 пользователь Sergey Rudenko написал: > Отвечу цитатой > > Вывод: В условиях многоядерных серверов LEFT JOIN имеет неоспоримые > преимущества > А мужики в FB не знают... :) Тогда вопрос - чего ж тогда такой бум NoSQL сейчас? В них тоже джойнов нет, и особой серверной логики тоже - максимум примитивы, типа SORT
Re: [freebsd] Необычный дамп базы mysql
On Tue, Feb 07, 2012 at 10:23:20AM +0200, Vladimir Mevsha wrote: >> Пока сейчас вижу способ с lock table и zfs snapshot > В таком случае советую посмотреть еще и на zfs send/receive а вот кто расскажет, по личным впечатлениям - насколько оно все встает колом при создании снапшота? И не сказывается ли его наличие-удаление на скорости работы с диском? при заявленных размерах базы или чуть поболее, про базки в сотни мегабайт неинтересно. > Alex
[freebsd] Re[2]: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
Отвечу цитатой При выборке в секции SELECT требуется дополнительное время на слияние основной выборки и подзапроса. Вышло 1% от общего времени.(+ LEFT JOIN / - SELECT) Оказалось, что каждый LEFT JOIN выполняется отдельным потоком! В то время как подзапросы выполняются последовательно после основной выборки. (+ LEFT JOIN / - SELECT) Каждый LEFT JOIN объединяется в результирующую выборку, что требует дополнительной памяти. В то время как подзапрос вернет нам одно значение на каждую строку, т.е. для получения результата нам нужно меньше памяти. (- LEFT JOIN / + SELECT) Вывод: В условиях многоядерных серверов LEFT JOIN имеет неоспоримые преимущества 07 февраля 2012, 01:07 от Alex Korchmar <4spa...@linux.e-moe.ru>: > On Tue, Feb 07, 2012 at 12:38:51AM +0400, Sergey Rudenko wrote: > > > Я возможно далёк, но хотел-бы услышать как можно избавиться от join, > > хотя-бы каким методом > сделать select без join и тупо отфильтровать нужное? > Идея что фронтендов вы можете понапихать до бесконечности, если они не > справляются с сортировкой, а добавить еще одно процессорное ядро в сервер с > БД может оказаться уже физически неодолимой задачей. > > Ну или делать такую структуру тазы банных, чтобы ей не были нужны join'ы > или были нужны крайне редко (в том числе - отказываясь от нормализации и > дублируя часть данных, диски и линки нынче дешевы, cpu не совсем). > > Редкие операции выносятся на отдельный сервер и во время тихое. > > > Alex > >
Re: [freebsd] Необычный дамп базы mysql
06.02.2012 17:11, skeletor пишет: 06.02.2012 17:01, Sayetsky Anton пишет: Вдогонку: Ежели фря - mysql + hast + heartbeat Нет, не фря. Но простой даже минуты очень критичен. Имеется несколько серверов с репликацией, сделанных намного ранее, когда БД и сайт были не такими большими и можно было банально выполнить mysqldump и сайт не ложился. Сейчас добавляется ещё один такой сервер и делать дамп со слейва - не хотелось бы. Пока сейчас вижу способ с lock table и zfs snapshot В таком случае советую посмотреть еще и на zfs send/receive (в случае, если БД будет в отдельном dataset).
Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Tue, Feb 07, 2012 at 12:38:51AM +0400, Sergey Rudenko wrote: > Я возможно далёк, но хотел-бы услышать как можно избавиться от join, > хотя-бы каким методом сделать select без join и тупо отфильтровать нужное? Идея что фронтендов вы можете понапихать до бесконечности, если они не справляются с сортировкой, а добавить еще одно процессорное ядро в сервер с БД может оказаться уже физически неодолимой задачей. Ну или делать такую структуру тазы банных, чтобы ей не были нужны join'ы или были нужны крайне редко (в том числе - отказываясь от нормализации и дублируя часть данных, диски и линки нынче дешевы, cpu не совсем). Редкие операции выносятся на отдельный сервер и во время тихое. > Alex
Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
> Когда нет денег на бекап - нет и бизнеса. Это несерьезная хрень какая-то. > Потому мои клиенты или покупают то, что я говорю или идут к другому хорошо, можете смело давать им мой адрес. Я работаю с клиентами у которых бюджет ограничен и которые понимают что такое управление рисками, и не афиллирован с конторами по впариванию железа (увы ;-) (я, правда, очень не люблю клиентов с freebsd и mysql, но вдруг кому-то повезет) > специалисту, который потом создает триды в рассылках типа "помогите > восстановить.. ", "как без простоя внедрить..." и т.д. Если это в конечном итоге решает их проблему - значит вы нагрели тех кто "купил что вы говорите", вероятно, дважды - сперва они зазря заплатили более дорогому специалисту, а потом еще и за более дорогие лекарства которые он прописал. Если вдруг опаньки - это был их риск, бизнес без риска не бывает. И, поверьте, есть еще такие, которые просто знают, как. Поскольку вопросов в рассылках они не задают, вы о них не в курсе. > Alex
[freebsd] Re[2]: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
Неужели БД "тупее" приложения будет? 07 февраля 2012, 00:50 от Алексей Бобок : 6 февраля 2012 г. 22:38 пользователь Sergey Rudenko написал: Я возможно далёк, но хотел-бы услышать как можно избавиться от join, хотя-бы каким методом Легко, имея соответствующую архитектуру приложения. Необходимо выбирать нужные данные, обработать в приложении и выдать конечный результат. Вся логика - в приложении. Задача БД - хранить данные и быстро выбирать. -- Think before you print. Best regards, Alexey Bobok.
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
6 февраля 2012 г. 22:38 пользователь Sergey Rudenko написал: > Я возможно далёк, но хотел-бы услышать как можно избавиться от join, > хотя-бы каким методом > > Легко, имея соответствующую архитектуру приложения. Необходимо выбирать нужные данные, обработать в приложении и выдать конечный результат. Вся логика - в приложении. Задача БД - хранить данные и быстро выбирать. -- Think before you print. Best regards, Alexey Bobok.
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
Я возможно далёк, но хотел-бы услышать как можно избавиться от join, хотя-бы каким методом 07 февраля 2012, 00:24 от Алексей Бобок : Мммм. Переформулируем так - ФБ использует более 2500 серверов с MySQL, которые являются основным хранилищем данных ФБ, несмотря на то что они не используют join и используют ее только как справочник - это именно то "основное", на чем оно и крутится. Использовать join и rlike и вообще производить сложные вычисления посредством БД - это плохо. Это прошлый век и это на нагрузке приведет к тому, что БД остановится на процессоре. В частности, потому, что очень во многих случаях лавочку можно смело закрывать, если она встанет на то время, которое занимает восстановление с такого бэкапа О_о А нормальная система с бэкапами и фэйловером стоит у вас, скажем - пять, которые надо вырвать из бизнеса немедленно, навсегда, и еще и доливать по мере роста Когда нет денег на бекап - нет и бизнеса. Это несерьезная хрень какая-то. Потому мои клиенты или покупают то, что я говорю или идут к другому специалисту, который потом создает триды в рассылках типа "помогите восстановить.. ", "как без простоя внедрить..." и т.д. А вообще, так как этот оффтоп на 50 писем спровоцировал походу я, потому я же и предлагаю закончить. Все равно все при своем мнении остануться) А к топикстартеру просьба рассказать, чем закончилось для будущих поколений. PS Пользуясь случаем, предаю поздравления Бобу Марли) -- Think before you print. Best regards, Alexey Bobok.
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
> > Мммм. Переформулируем так - ФБ использует более 2500 серверов с MySQL, > которые являются основным хранилищем данных ФБ, несмотря на то что они > не используют join и используют ее только как справочник - это именно > то "основное", на чем оно и крутится. Использовать join и rlike и вообще производить сложные вычисления посредством БД - это плохо. Это прошлый век и это на нагрузке приведет к тому, что БД остановится на процессоре. В частности, потому, что очень во многих случаях лавочку можно смело > закрывать, если она встанет на то время, которое занимает восстановление > с такого бэкапа О_о А нормальная система с бэкапами > и фэйловером стоит у вас, скажем - пять, которые надо вырвать из бизнеса > немедленно, навсегда, и еще и доливать по мере роста Когда нет денег на бекап - нет и бизнеса. Это несерьезная хрень какая-то. Потому мои клиенты или покупают то, что я говорю или идут к другому специалисту, который потом создает триды в рассылках типа "помогите восстановить.. ", "как без простоя внедрить..." и т.д. А вообще, так как этот оффтоп на 50 писем спровоцировал походу я, потому я же и предлагаю закончить. Все равно все при своем мнении остануться) А к топикстартеру просьба рассказать, чем закончилось для будущих поколений. PS Пользуясь случаем, предаю поздравления Бобу Марли) -- Think before you print. Best regards, Alexey Bobok.
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
6 февраля 2012 г. 19:21 пользователь Sergey Rudenko написал: > "ИМХО справочники" - относилось к ФБ > Если они не используют там join то вывод один - это справочники, которые не > такие и большие > А на чем основное крутится совсем не понятно Мммм. Переформулируем так - ФБ использует более 2500 серверов с MySQL, которые являются основным хранилищем данных ФБ, несмотря на то что они не используют join и используют ее только как справочник - это именно то "основное", на чем оно и крутится. Аналогичная ситуация в Твиттере и Википедии - у них тысячи серверов с MySQL и размер каждой БД вполне сравним с десятками Гб - имхо не такие уж это и космические цифры, при современной то технике - особенно если джойны то не использовать...
Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Mon, Feb 06, 2012 at 11:18:11PM +0400, Andrey Kopeyko wrote: > Нет, не одному вам. вы тоже DBA-теоретик? > У меня, к примеру, несколько "не складываются" две другие вещи > - простои критичны > - отсутствуют регулярные полные бэкапы базы. сплошь и рядом. В частности, потому, что очень во многих случаях лавочку можно смело закрывать, если она встанет на то время, которое занимает восстановление с такого бэкапа. При том что особо ценной информации там внутри может и 1% нет. Разумеется, вместо него обычно есть стройная система костылей и подпорок, как-то позволяющая отложить процесс банкротства до следующего месяца, но часто и она оказывается слегка отставшей от развития и уже маложизнеспособной. > На мой взгляд, второе прямо и недвусмысленно говорит о том, что простои > таки совершенно нестрашны. или что приняты меры чтобы они были маловероятны, а затыкать буде все же выйдут - будут административным путем. ну, грубо утрируя - если у вас там счета клиентов и оно хряпсь - тупо пересоздаем их все, добавляя на каждый денег по пол-лимона. Ни один ведь не пожалуется? (ок - трое пожалуются и каждый отсудит по два, но через три года пока будет тянуться судебная волокита. А нормальная система с бэкапами и фэйловером стоит у вас, скажем - пять, которые надо вырвать из бизнеса немедленно, навсегда, и еще и доливать по мере роста. Для кого-то и это вполне приемлемый риск.) Все совпадения и имена случайны, поэтому не надо гадать где именно лежат ваши два лимона ;-) Поверьте, у контор есть куда больше способов накрываться медным тазом, особенно у стартапных. И далеко не всегда этот - наиболее вероятный. Прецедент я обслуживал с 2005-го (когда как раз навернулось и оказалось что бэкапа нет) до 2008, когда наступили опаньки совсем-совсем по другой причине. Причем оно протрепыхалось уже как бесплатный проект еще пару лет, потеряв в том числе и бэкап и фэйловер (потому что нечем было платить), и в конечном итоге сдохло - вполне обратимо, в целом, но практического смысла в оживлении уже не было. > Alex
Re: [freebsd] Re[2]: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Mon, 06 Feb 2012 23:56:33 +0400 Sergey Rudenko wrote: > Вы не теми попугаями меряете, что у вас в директории лежит одна или > 500 баз? Вес тут роли не играет, а у гражданина одна база на 50 гиг > 2шт. та что mysql и та что рабочая (это mysql-slave) > > 06 февраля 2012, 23:35 от "Sergey V. Dyatko" > : > > On Mon, 6 Feb 2012 18:17:32 +0200 > > Sayetsky Anton wrote: > > > > > 6 февраля 2012 г. 18:15 пользователь Vasiliy P. Melnik > > > написал: > > > > может одному мне кажется что мускуль, 50 гигов и простои > > > > критичны между собой не вяжутся. Совсем не вяжутся - тут ораклы > > > > всякие, постгресы и прочие тяжеловесы нужны > > > > > да ладно;-) > > > > > # du -hs /var/lib/mysql/ > > > 92G /var/lib/mysql/ > > > > > > Работает, не чешется. > > > > сколько из 92Г весят бинлоги, например?:) > > > > раз уж мерянья начались, машинка, которую трогать страшно: > > archive-db# du -shx /var/db/mysql/ > > 147G/var/db/mysql/ > > > > archive-db# ll -h /var/db/mysql/ibdata1 > > -rw-rw 1 mysql wheel 105G Feb 6 22:33 /var/db/mysql/ibdata1 > > > > -- > > wbr, tiger > > -- wbr, tiger
[freebsd] Re[2]: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
Вы не теми попугаями меряете, что у вас в директории лежит одна или 500 баз? Вес тут роли не играет, а у гражданина одна база на 50 гиг 06 февраля 2012, 23:35 от "Sergey V. Dyatko" : > On Mon, 6 Feb 2012 18:17:32 +0200 > Sayetsky Anton wrote: > > > 6 февраля 2012 г. 18:15 пользователь Vasiliy P. Melnik > > написал: > > > может одному мне кажется что мускуль, 50 гигов и простои критичны > > > между собой не вяжутся. Совсем не вяжутся - тут ораклы всякие, > > > постгресы и прочие тяжеловесы нужны > > > да ладно;-) > > > # du -hs /var/lib/mysql/ > > 92G /var/lib/mysql/ > > > > Работает, не чешется. > > сколько из 92Г весят бинлоги, например?:) > > раз уж мерянья начались, машинка, которую трогать страшно: > archive-db# du -shx /var/db/mysql/ > 147G/var/db/mysql/ > > archive-db# ll -h /var/db/mysql/ibdata1 > -rw-rw 1 mysql wheel 105G Feb 6 22:33 /var/db/mysql/ibdata1 > > -- > wbr, tiger >
Re: [freebsd] Re[2]: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Mon, Feb 06, 2012 at 09:26:40PM +0400, Sergey Rudenko wrote: > На порядок - это умножить на 10 ) да, я, представьте себе, знаю что такое порядок. Пол-терабайта - хорошая, годная БД, уже можно себе без шуток писать в поле профессия - DBA, даже если это "всего лишь" mysql. > А правильные запросы и код писать это шаманство, которое требует > чёткого понимания. контроля оно требует, контроля. Пониманием тут не отделаешься. > Alex
Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Mon, 6 Feb 2012 18:17:32 +0200 Sayetsky Anton wrote: > 6 февраля 2012 г. 18:15 пользователь Vasiliy P. Melnik > написал: > > может одному мне кажется что мускуль, 50 гигов и простои критичны > > между собой не вяжутся. Совсем не вяжутся - тут ораклы всякие, > > постгресы и прочие тяжеловесы нужны > да ладно;-) > # du -hs /var/lib/mysql/ > 92G /var/lib/mysql/ > > Работает, не чешется. сколько из 92Г весят бинлоги, например?:) раз уж мерянья начались, машинка, которую трогать страшно: archive-db# du -shx /var/db/mysql/ 147G/var/db/mysql/ archive-db# ll -h /var/db/mysql/ibdata1 -rw-rw 1 mysql wheel 105G Feb 6 22:33 /var/db/mysql/ibdata1 -- wbr, tiger
[freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
6 февраля 2012 г. 21:18 пользователь Andrey Kopeyko написал: > У меня, к примеру, несколько "не складываются" две другие вещи > - простои критичны > - отсутствуют регулярные полные бэкапы базы. > +1 > > Чем быстрее вы её исправите - тем легче вам будет дышать в будущем. > +1 > > Да, будет даунтайм, обязательно, - но не стоит его бояться, ибо > - он будет управляемым (вами, а не вызван падением сервера) > - он будет лишь один раз +2 ) > > -- > Best regards, > Andrey Kopeyko > -- Think before you print. Best regards, Alexey Bobok.
Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
06.02.2012 20:15, Vasiliy P. Melnik пишет: может одному мне кажется что мускуль, 50 гигов и простои критичны между собой не вяжутся. Нет, не одному вам. У меня, к примеру, несколько "не складываются" две другие вещи - простои критичны - отсутствуют регулярные полные бэкапы базы. На мой взгляд, второе прямо и недвусмысленно говорит о том, что простои таки совершенно нестрашны. Совсем не вяжутся - тут ораклы всякие, постгресы и прочие тяжеловесы нужны Это зависит от того, чего мы здесь не знаем - схемы, ограничений, триггеров, характера нагрузки, etc. Может, и нужны постгрес\оракл - а быть может что и нет; тут надо детально разбираться. 6 февраля 2012 г. 17:11 пользователь skeletor написал: 06.02.2012 17:01, Sayetsky Anton пишет: Вдогонку: Ежели фря - mysql + hast + heartbeat Нет, не фря. Но простой даже минуты очень критичен. Имеется несколько серверов с репликацией, сделанных намного ранее, когда БД и сайт были не такими большими и можно было банально выполнить mysqldump и сайт не ложился. Сейчас добавляется ещё один такой сервер и делать дамп со слейва - не хотелось бы. Всё-таки у вас архитектурная, по-видимому, ошибка - раз для таких важных, как вы пишете, данных ни бэкапа ни резервирования в вашей конструкции не предусмотрено... Чем быстрее вы её исправите - тем легче вам будет дышать в будущем. Да, будет даунтайм, обязательно, - но не стоит его бояться, ибо - он будет управляемым (вами, а не вызван падением сервера) - он будет лишь один раз Пока сейчас вижу способ с lock table и zfs snapshot Всем спасибо, после результатов отпишусь. -- Best regards, Andrey Kopeyko
[freebsd] Re[2]: [freebsd] Re: [freebsd] Необычный дамп базы mysql
На порядок - это умножить на 10 ) А правильные запросы и код писать это шаманство, которое требует чёткого понимания. Если всё это учесть то и результат будет соответствующий 06 февраля 2012, 21:23 от Alex Korchmar <4spa...@linux.e-moe.ru>: > On Mon, Feb 06, 2012 at 06:15:32PM +0200, Vasiliy P. Melnik wrote: > > > может одному мне кажется что мускуль, 50 гигов и простои критичны > видимо, одному. > > между собой не вяжутся. Совсем не вяжутся - тут ораклы всякие, > > постгресы и прочие тяжеловесы нужны > более того, я как раз зассал бы такого размера и критичное к простоям делать > на оракле (я верю что он - может, но к нему надо трех очень дорогих админов, > живущих совершенно свою, отдельную от моей профессиональную жизнь, да и сам > такой оракл со всеми, вероятно, нужными, тем админам, причиндалами тоже > может оказаться вне бюджета проекта с 50гиг и критичностью к простоям), > и точно не стал бы - на postgres, его какие-то совершенно не от > мира сего чуваки пишут. > > А mysql'ные конструкции я видел и на порядок большего объема. Разумеется, это > не было простой и приятной в поддержке системой, но и супер-гуру рядом тоже не > наблюдалось. А уж 50G на нем - совсем не требуют никакого сильного > колдунства, тем более если до сих пор проблема только с эффективным бэкапом. > (то ли кто-то умеет писать запросы, то ли мощности переизбыток, то ли у > кого-то хорошая бамбуковая палка) > > > Alex > >
Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Mon, Feb 06, 2012 at 06:15:32PM +0200, Vasiliy P. Melnik wrote: > может одному мне кажется что мускуль, 50 гигов и простои критичны видимо, одному. > между собой не вяжутся. Совсем не вяжутся - тут ораклы всякие, > постгресы и прочие тяжеловесы нужны более того, я как раз зассал бы такого размера и критичное к простоям делать на оракле (я верю что он - может, но к нему надо трех очень дорогих админов, живущих совершенно свою, отдельную от моей профессиональную жизнь, да и сам такой оракл со всеми, вероятно, нужными, тем админам, причиндалами тоже может оказаться вне бюджета проекта с 50гиг и критичностью к простоям), и точно не стал бы - на postgres, его какие-то совершенно не от мира сего чуваки пишут. А mysql'ные конструкции я видел и на порядок большего объема. Разумеется, это не было простой и приятной в поддержке системой, но и супер-гуру рядом тоже не наблюдалось. А уж 50G на нем - совсем не требуют никакого сильного колдунства, тем более если до сих пор проблема только с эффективным бэкапом. (то ли кто-то умеет писать запросы, то ли мощности переизбыток, то ли у кого-то хорошая бамбуковая палка) > Alex
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
"ИМХО справочники" - относилось к ФБ Если они не используют там join то вывод один - это справочники, которые не такие и большие А на чем основное крутится совсем не понятно 06 февраля 2012, 21:14 от Denis Zhdanov : > 6 февраля 2012 г. 19:07 пользователь Sergey Rudenko > написал: > > Не оффтопа ради, а ради спаведливости > > "ФБ MySQL -- используется как хранилище пар ключ-значение, никаких join'ов" > А кто спорит? Вопрос был о больших базах на мускуле. Ответ - они есть и > юзаются. > > > ИМХО справочники > > "ВК Собственная СУБД на C, созданная <<лучшими умами>> России" > С ВК все непонятно, как я уже и говорил. > > > Я уже молчу, что это всё из проверенных источникофф ))) > Ну тут вопрос - верить или не верить самим разработчикам сервисов. В > отличие от ВК западные девы архитектуру не скрывают - инфы в Инете > полно, на Insight-IT она просто собрана в одном месте. > Вот еще инфа к размышлению - > http://www.quora.com/Quora-Infrastructure/Why-does-Quora-use-MySQL-as-the-data-store-instead-of-NoSQLs-such-as-Cassandra-MongoDB-CouchDB-etc > (Adam D'Angelo - бывший техдир ФБ) >
[freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
6 февраля 2012 г. 19:07 пользователь Sergey Rudenko написал: > Не оффтопа ради, а ради спаведливости > "ФБ MySQL -- используется как хранилище пар ключ-значение, никаких join'ов" А кто спорит? Вопрос был о больших базах на мускуле. Ответ - они есть и юзаются. > ИМХО справочники > "ВК Собственная СУБД на C, созданная <<лучшими умами>> России" С ВК все непонятно, как я уже и говорил. > Я уже молчу, что это всё из проверенных источникофф ))) Ну тут вопрос - верить или не верить самим разработчикам сервисов. В отличие от ВК западные девы архитектуру не скрывают - инфы в Инете полно, на Insight-IT она просто собрана в одном месте. Вот еще инфа к размышлению - http://www.quora.com/Quora-Infrastructure/Why-does-Quora-use-MySQL-as-the-data-store-instead-of-NoSQLs-such-as-Cassandra-MongoDB-CouchDB-etc (Adam D'Angelo - бывший техдир ФБ)
[freebsd] [freebsd] Re: [freebsd] Необычный дамп базы mysql
Не оффтопа ради, а ради спаведливости "ФБ MySQL — используется как хранилище пар ключ-значение, никаких join’ов" ИМХО справочники "ВК Собственная СУБД на C, созданная «лучшими умами» России" Я уже молчу, что это всё из проверенных источникофф ))) 06 февраля 2012, 20:49 от Denis Zhdanov : > 6 февраля 2012 г. 18:37 пользователь Sergey Rudenko > написал: > > Это одна из СУБД которую они используют и не факт, что она основная > Оффтоп и флейм конечно, но, справедливости ради - > http://www.insight-it.ru/masshtabiruemost/arkhitektura-facebook/ - у > ФБ точно основная > http://www.insight-it.ru/masshtabiruemost/arkhitektura-vkontakte/ - > тут непонятно, но данные ВК там точно хранятся, в тексте есть. > И вообще - http://www.insight-it.ru/tag/mysql/ - там есть и Dropbox, и > Twitter (и именно там MySQL основное хранилище, на Cassandra им так и > не удалось перейти) и много чего еще. > В этом смысле у PostgreSQL успехи намного скромнее - > http://www.insight-it.ru/tag/postgresql/ - Disqus разве что... >
[freebsd] Re: [freebsd] Re[2]: [freebsd] Re: [freebsd] Необычный дамп базы mysql
6 февраля 2012 г. 18:37 пользователь Sergey Rudenko написал: > Это одна из СУБД которую они используют и не факт, что она основная Оффтоп и флейм конечно, но, справедливости ради - http://www.insight-it.ru/masshtabiruemost/arkhitektura-facebook/ - у ФБ точно основная http://www.insight-it.ru/masshtabiruemost/arkhitektura-vkontakte/ - тут непонятно, но данные ВК там точно хранятся, в тексте есть. И вообще - http://www.insight-it.ru/tag/mysql/ - там есть и Dropbox, и Twitter (и именно там MySQL основное хранилище, на Cassandra им так и не удалось перейти) и много чего еще. В этом смысле у PostgreSQL успехи намного скромнее - http://www.insight-it.ru/tag/postgresql/ - Disqus разве что...
[freebsd] Re[2]: [freebsd] Re: [freebsd] Необычный дамп базы mysql
Это одна из СУБД которую они используют и не факт, что она основная 06 февраля 2012, 20:30 от Alexey Bobok : > Очень даже вяжется) ФБ и ВК на мускуле. Так что это оффтоп) только надо > строить правильно. > > -- > Best regards, > Alexey Bobok > > 06.02.2012, в 18:23, Sergey Kobzar написал(а): > > > On 02/06/12 18:15, Vasiliy P. Melnik wrote: > >> может одному мне кажется что мускуль, 50 гигов и простои критичны > >> между собой не вяжутся. Совсем не вяжутся - тут ораклы всякие, > >> постгресы и прочие тяжеловесы нужны > > > > Да ладно ;) >
Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
Очень даже вяжется) ФБ и ВК на мускуле. Так что это оффтоп) только надо строить правильно. -- Best regards, Alexey Bobok 06.02.2012, в 18:23, Sergey Kobzar написал(а): > On 02/06/12 18:15, Vasiliy P. Melnik wrote: >> может одному мне кажется что мускуль, 50 гигов и простои критичны >> между собой не вяжутся. Совсем не вяжутся - тут ораклы всякие, >> постгресы и прочие тяжеловесы нужны > > Да ладно ;)
Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On 02/06/12 18:15, Vasiliy P. Melnik wrote: может одному мне кажется что мускуль, 50 гигов и простои критичны между собой не вяжутся. Совсем не вяжутся - тут ораклы всякие, постгресы и прочие тяжеловесы нужны Да ладно ;)
[freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
6 февраля 2012 г. 18:15 пользователь Vasiliy P. Melnik написал: > может одному мне кажется что мускуль, 50 гигов и простои критичны > между собой не вяжутся. Совсем не вяжутся - тут ораклы всякие, > постгресы и прочие тяжеловесы нужны # du -hs /var/lib/mysql/ 92G /var/lib/mysql/ Работает, не чешется.
[freebsd] Re: [freebsd] Необычный дамп базы mysql
может одному мне кажется что мускуль, 50 гигов и простои критичны между собой не вяжутся. Совсем не вяжутся - тут ораклы всякие, постгресы и прочие тяжеловесы нужны 6 февраля 2012 г. 17:11 пользователь skeletor написал: > 06.02.2012 17:01, Sayetsky Anton пишет: > >> Вдогонку: >> Ежели фря - mysql + hast + heartbeat > > > Нет, не фря. Но простой даже минуты очень критичен. Имеется несколько > серверов с репликацией, сделанных намного ранее, когда БД и сайт были не > такими большими и можно было банально выполнить mysqldump и сайт не ложился. > Сейчас добавляется ещё один такой сервер и делать дамп со слейва - не > хотелось бы. > > Пока сейчас вижу способ с lock table и zfs snapshot > > Всем спасибо, после результатов отпишусь.
Re: [freebsd] Необычный дамп базы mysql
06.02.2012 17:01, Sayetsky Anton пишет: Вдогонку: Ежели фря - mysql + hast + heartbeat Нет, не фря. Но простой даже минуты очень критичен. Имеется несколько серверов с репликацией, сделанных намного ранее, когда БД и сайт были не такими большими и можно было банально выполнить mysqldump и сайт не ложился. Сейчас добавляется ещё один такой сервер и делать дамп со слейва - не хотелось бы. Пока сейчас вижу способ с lock table и zfs snapshot Всем спасибо, после результатов отпишусь.
Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On 02/06/12 18:46, Vasiliy P. Melnik wrote: В случае выхода из строя мастера вместе со всеми данными на слейве > будет свежая копия данных, к тому же готовая к использованию. не понял На сервере 2 винта? Очень редко, но бывают ситуации, когда два винта не спасают. Например неисправность железа, из за которой с диска мы читаем не то, что записали (встречал такое на определенном сочетании материнской платы и stat-контроллера, но точные модели уже не вспомню). В случае ZFS это теоретически должно обнаруживаться по контрольным суммам. Но с ZFS боюсь не исключен другой вариант - при определенных условиях проявляется какой нибудь баг из за которого повреждается fs (например ОС падает в панику в не подходящий момент). Все это конечно менее вероятно, чем выход из строя одного из дисков в зеркале. К тому же наличие слейва уменьшает downtime, если на мастере умер не один из дисков, а например матернка. Превратить слейва в новый мастер можно быстро и удаленно. Переставить диски из сдохшей платформы в запасную дольше и нужно еще иметь запасную платформу, в которую эти диски можно вставить. Поднять mater-slave репликацию в mysql сравнительно несложно, так что при наличии сервера, где можно его поднять, это имеет смысл сделать, если данные представляют какую то ценность. -- Anton Yuzhaninov
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
6 февраля 2012 г. 16:58 пользователь Sayetsky Anton написал: > 6 февраля 2012 г. 16:57 пользователь skeletor написал: >> Как написал, Anton Yuzhaninov, мне нужна просто свежая копия базы, точнее >> полная копия работающего сервера с БД. > > mysql + drbd + heartbeat > > Или dual-direction replication, но говорят, что оно не работает. Вдогонку: Ежели фря - mysql + hast + heartbeat
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
> > 06.02.2012 14:10, Anton Yuzhaninov пишет: > > > Чтобы получить работающий slave, надо сначала получить dump мастера. >> >> Именно! Вот как раз и в этом состоит и проблема. > Это действительно настолько недопустимая ситуация? Я не представляю себе существование базы, которая не может не работать в течении получаса. А если она настолько критична и, осознавая это, допущена архитектура без репликации и резервирования, то сейчас самое время провести модернизацию Вашего хранилища. А что будет, если сервер выйдет из строя (материнка умерла)? Простой в сутки не страшен? А так Вы сможете сделать дополнительно резервный сервер с БД и будете спокойно спать. Я веду к тому, что крик "вы что?! у нас недопустимы простои!!!" есть исключительно следствие чьих-то комплексов и амбиций, которые тушатся обоснованными аргументами реальной необходимости. Ну или да, придумывайте сложносочлененные схемы с ZFS, gmirror и тд, если это база с миллиардными финансовыми потоками, которые льются ежесекундно) -- Think before you print. Best regards, Alexey Bobok.
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
6 февраля 2012 г. 16:57 пользователь skeletor написал: > Как написал, Anton Yuzhaninov, мне нужна просто свежая копия базы, точнее > полная копия работающего сервера с БД. mysql + drbd + heartbeat Или dual-direction replication, но говорят, что оно не работает.
Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
06.02.2012 16:46, Vasiliy P. Melnik пишет: На сервере 2 винта? А какое отношение имеет количество винтов на сервере к выходу сервера из строя? Как написал, Anton Yuzhaninov, мне нужна просто свежая копия базы, точнее полная копия работающего сервера с БД.
Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Mon, Feb 06, 2012 at 06:44:00PM +0400, Anton Yuzhaninov wrote: > On 02/06/12 18:35, Vasiliy P. Melnik wrote: > >так если есть винт с базой зачем тогда мускуль поднимать и что-то еще - > >файлы базы запаковать и на длительное хранение. Винт вернуть на место в рейд > > Файл базы запакованный на длительное хранение, содержит старые > данные. А бэкап обычно хочется иметь максимально свежий. > > В случае выхода из строя мастера вместе со всеми данными на слейве > будет свежая копия данных, к тому же готовая к использованию. не понял На сервере 2 винта? > > -- > Anton Yuzhaninov -- --- Vasiliy P. MelnikVPM-UANIC
Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On 02/06/12 18:35, Vasiliy P. Melnik wrote: так если есть винт с базой зачем тогда мускуль поднимать и что-то еще - файлы базы запаковать и на длительное хранение. Винт вернуть на место в рейд Файл базы запакованный на длительное хранение, содержит старые данные. А бэкап обычно хочется иметь максимально свежий. В случае выхода из строя мастера вместе со всеми данными на слейве будет свежая копия данных, к тому же готовая к использованию. -- Anton Yuzhaninov
Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
так если есть винт с базой зачем тогда мускуль поднимать и что-то еще - файлы базы запаковать и на длительное хранение. Винт вернуть на место в рейд On Mon, Feb 06, 2012 at 04:28:31PM +0400, Anton Yuzhaninov wrote: > On 02/06/12 16:18, skeletor wrote: > >06.02.2012 14:10, Anton Yuzhaninov пишет: > > > >>Чтобы получить работающий slave, надо сначала получить dump мастера. > >> > >Именно! Вот как раз и в этом состоит и проблема. > > Как она решается в треде уже написано. Напишу более подробно. > > 1. Включть в mysql заись binary log > Проверить через show master status, что логи пишутся. > > 1. в mysql > FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS > > 2. В OS > sync > sleep 5 > делаем ZFS snapshot (или gmirror remove если нет ZFS) > > 3. в mysql > UNLOCK TABLES > > 4. Копируем данные из папки снапшота на будущий слейв. Это может > идти долго, но будущий мастер в этот момент работает, даунтайма нет. > Чтобы копироание не грузило диски, можно использовать scp -l > > 5. На будущем слейве запускает mysql и выполняем команду > > CHANGE MASTER TO master_host="master.example.ru", > master_user="usr_repl", master_password="xxx", > master_log_file="master-bin.000123", master_log_pos=12345; > > где имя лога и позицию в нем, указываем как показал SHOW MASTER > STATUS при создании снапшота. > > После этого слейв начнем медленно догонять мастер. Если на мастере > шла активная запись, то догонять будет долго, но на работу мастера > это не влияет, нагрузка от наличия слейва будет очень небольшая. > Прогресс смотреть по SHOW SLAVE STATUS. > > После того как слейв догонит, на нем можно делать бэкапы с помощью > mysqldump и мучить его другими способами. > > -- > Anton Yuzhaninov -- --- Vasiliy P. MelnikVPM-UANIC
[freebsd] Re: [freebsd] Необычный дамп базы mysql
6 февраля 2012 г. 13:07 пользователь skeletor написал: > Но даже и в этом случае диски нагружаются достаточно, что бы сайт не > отвечал. Это не нагрузка на диски. Это LOCK TABLES во время дампа. А диски - лишь следствие, но не причина.
Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On 02/06/12 16:18, skeletor wrote: 06.02.2012 14:10, Anton Yuzhaninov пишет: Чтобы получить работающий slave, надо сначала получить dump мастера. Именно! Вот как раз и в этом состоит и проблема. Как она решается в треде уже написано. Напишу более подробно. 1. Включть в mysql заись binary log Проверить через show master status, что логи пишутся. 1. в mysql FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS 2. В OS sync sleep 5 делаем ZFS snapshot (или gmirror remove если нет ZFS) 3. в mysql UNLOCK TABLES 4. Копируем данные из папки снапшота на будущий слейв. Это может идти долго, но будущий мастер в этот момент работает, даунтайма нет. Чтобы копироание не грузило диски, можно использовать scp -l 5. На будущем слейве запускает mysql и выполняем команду CHANGE MASTER TO master_host="master.example.ru", master_user="usr_repl", master_password="xxx", master_log_file="master-bin.000123", master_log_pos=12345; где имя лога и позицию в нем, указываем как показал SHOW MASTER STATUS при создании снапшота. После этого слейв начнем медленно догонять мастер. Если на мастере шла активная запись, то догонять будет долго, но на работу мастера это не влияет, нагрузка от наличия слейва будет очень небольшая. Прогресс смотреть по SHOW SLAVE STATUS. После того как слейв догонит, на нем можно делать бэкапы с помощью mysqldump и мучить его другими способами. -- Anton Yuzhaninov
Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On 02/06/12 14:18, skeletor wrote: 06.02.2012 14:10, Anton Yuzhaninov пишет: Чтобы получить работающий slave, надо сначала получить dump мастера. Именно! Вот как раз и в этом состоит и проблема. Остановить базу, сделать копию на уровне ФС, запустьть базу, вылить копию на слэйв. Если остановка базы на пол часа неприемлема - залочить базу на запись, и проделать то же самое что выше.
Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
06.02.2012 14:10, Anton Yuzhaninov пишет: Чтобы получить работающий slave, надо сначала получить dump мастера. Именно! Вот как раз и в этом состоит и проблема.
Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On 02/06/12 16:05, Алексей Бобок wrote: Данные сливать на slave посредством родной sql-репликации, dump делать со slave. Чтобы получить работающий slave, надо сначала получить dump мастера. -- Anton Yuzhaninov
[freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
6 февраля 2012 г. 13:15 пользователь Sergey Rudenko написал: > > Поднять ещё один сервер БД, настроить репликацию и сделать дамп уже с него? > > Коллега предложил самый простой, железный и действенный способ. Данные сливать на slave посредством родной sql-репликации, dump делать со slave. Но нужно понимать насколько много записи в базу, чтобы между процедурами дампа slave успевал отрпелицировать все (помним, что до версии mysql, кажется, 5.5 на слейв изменения льются в 1 поток, в 5.5 или какой-то новой можно включать отдельные потоки per-database). -- Think before you print. Best regards, Alexey Bobok.
Re: [freebsd] Необычный дамп базы mysql
06.02.2012 13:47, Andrey Kopeyko пишет: Проблема нагрузки на винты - в данном случае это фигня по сравнению с проблемой целостности базы: вы сильно рискуете получить неконсистентное нечто, ибо в zfs snapshot не попадут накопленные в буферах mysqld изменения данных. Надо до снапшота надо флашить таблицы, как-то так: FLUSH TABLES WITH READ LOCK zfs shapshot UNLOCK TABLES Кстати, да. Этот момент тоже нужно учесть.
Re: [freebsd] Необычный дамп базы mysql
06.02.2012 15:33, Alexander Panyushkin пишет: On 06.02.2012 13:07, skeletor wrote: Есть сервер в продакшине и с него нужно сделать дамп баз. Базы большие (50 Гб каждая). Проблема в том, что при дампе идёт сильная нагрузка на диски и в итоге - основной сайт лежит. Какие средства пробовались: - обычный дамп через mysqldump на другие диски - дамп через mysqldump по сети сразу на другой хост Но даже и в этом случае диски нагружаются достаточно, что бы сайт не отвечал. ПС. Сам сайт и БД лежат на разных серверах и фраза "сайт лежит" означает, что истекает таймаут при подключении к БД. Может есть варианты ещё как-то сделать дамп или выставить поменьше нагрузку на диски. nice/renice - не помогают, так как сервак не настолько нагружен, что бы приоритет влиял на это. Заранее спасибо. Если база на ZFS, делаем snapshot, потом делаем видимым snapdir, заходим в него и копируем всю папку базы целеком куда нужно. Но не факт, что будет меньше наргузка на винты. Проблема нагрузки на винты - в данном случае это фигня по сравнению с проблемой целостности базы: вы сильно рискуете получить неконсистентное нечто, ибо в zfs snapshot не попадут накопленные в буферах mysqld изменения данных. Надо до снапшота надо флашить таблицы, как-то так: FLUSH TABLES WITH READ LOCK zfs shapshot UNLOCK TABLES -- Best regards, Andrey Kopeyko
Re: [freebsd] Необычный дамп базы mysql
On 02/06/12 15:39, skeletor wrote: Тип InnoDB. Даже при таком способе с сервера на сервер данные будет долго передаваться. :( Долго но, спешить уже не нужно будет: downtime базы составит 5-10 секунд между LOCK и UNLOCK Если делать mysqldump, то на большой базе downtime будет несколько часов или даже суток. Как уже упоминали в соседнем письме вместо gmirror remove можно использовать ZFS snapshot - если у вдруг использует ZFS, но в остальном последовательность действий такая же: lock, shapshot, unlock UFS shapshot использовать не рекомендую - на больших дисках слишком долго блокирует запись на диск (и чтение тоже блокирует, но чуть меньше по времени). -- Anton Yuzhaninov
Re: [freebsd] Необычный дамп базы mysql
On Mon, 06 Feb 2012 13:33:04 +0200 Alexander Panyushkin wrote: > On 06.02.2012 13:07, skeletor wrote: > > Есть сервер в продакшине и с него нужно сделать дамп баз. Базы > > большие (50 Гб каждая). Проблема в том, что при дампе идёт сильная > > нагрузка на диски и в итоге - основной сайт лежит. > > > > Какие средства пробовались: > > - обычный дамп через mysqldump на другие диски > > - дамп через mysqldump по сети сразу на другой хост > > > > Но даже и в этом случае диски нагружаются достаточно, что бы сайт > > не отвечал. > > > > ПС. Сам сайт и БД лежат на разных серверах и фраза "сайт лежит" > > означает, что истекает таймаут при подключении к БД. > > > > Может есть варианты ещё как-то сделать дамп или выставить поменьше > > нагрузку на диски. nice/renice - не помогают, так как сервак не > > настолько нагружен, что бы приоритет влиял на это. > > > > Заранее спасибо. > > Если база на ZFS, делаем snapshot, потом делаем видимым snapdir, > заходим в него и копируем всю папку базы целеком куда нужно. > Но не факт, что будет меньше наргузка на винты. > snapshots есть и в ufs, точно также можно монтировать куда угодно и таскать. -- wbr, tiger
Re: [freebsd] Необычный дамп базы mysql
06.02.2012 13:33, Alexander Panyushkin пишет: On 06.02.2012 13:07, skeletor wrote: Если база на ZFS, делаем snapshot, потом делаем видимым snapdir, заходим в него и копируем всю папку базы целеком куда нужно. Но не факт, что будет меньше наргузка на винты. А вот это уже интересно. База на zfs.
Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
06.02.2012 15:31, skeletor пишет: 06.02.2012 13:25, Sergey V. Dyatko пишет: каким образом предлагаете делать слейв?;-) насколько я понял, опускать сайт нельзя. Думаю делать так: поднять slave и начать репликацию. Учтите, что репликация будет переносить на slave лишь изменения в базе, возникшие _после_ момента начала записи бинари-лога (т.е. после настройки репликации на мастере). На "прошлые данные" это не повлияет - т.е. они не перенесутся на ваш новый слейв. В противном случае это называлось бы "синхронизацией". > При этом возникает такой момент: данных очень много и поэтому, пока будет делаться дамп и заливка на slave насобирается очень много данных, которые потом должны будут реплицироваться - и не получиться ли так, что в этот момент нагрузка на диски опять возростёт. IMHO, самый действующий способ описан Антоном Южаниновым. -- Best regards, Andrey Kopeyko
Re: [freebsd] Необычный дамп базы mysql
06.02.2012 13:30, Anton Yuzhaninov пишет: Если база использует myisam лежит на зеркале (gmirror), то: 1. в mysql FLUSH TABLES WITH READ LOCK 2. В OS sync sleep 5 gmirror remove data da0x 3. в mysql UNLOCK TABLES После этого fsck_ffs /dev/da0x смонтировать его в /mnt и скопировать файлы базы данных на другой сервер. Способ неоднократно проверен на практике. Для innodb не пробовал, но тут http://dev.mysql.com/doc/refman/5.0/en/lock-tables.html пишут, что тоже возможно, но есть особенности, искать по слову innodb_max_dirty_pages_pct Тип InnoDB. Даже при таком способе с сервера на сервер данные будет долго передаваться. :(
Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Mon, 06 Feb 2012 13:31:34 +0200 skeletor wrote: > 06.02.2012 13:25, Sergey V. Dyatko пишет: > > > каким образом предлагаете делать слейв?;-) насколько я понял, > > опускать сайт нельзя. > > > > Думаю делать так: поднять slave и начать репликацию. При этом > возникает такой момент: данных очень много и поэтому, пока будет > делаться дамп и заливка на slave насобирается очень много данных, > которые потом должны будут реплицироваться - и не получиться ли так, > что в этот момент нагрузка на диски опять возростёт. у меня почему-то есть чувство что Вы репликацию mysql ни разу не настраивали. Откуда "начать репликацию" ? -- wbr, tiger
Re: [freebsd] Необычный дамп базы mysql
On 06.02.2012 13:07, skeletor wrote: Есть сервер в продакшине и с него нужно сделать дамп баз. Базы большие (50 Гб каждая). Проблема в том, что при дампе идёт сильная нагрузка на диски и в итоге - основной сайт лежит. Какие средства пробовались: - обычный дамп через mysqldump на другие диски - дамп через mysqldump по сети сразу на другой хост Но даже и в этом случае диски нагружаются достаточно, что бы сайт не отвечал. ПС. Сам сайт и БД лежат на разных серверах и фраза "сайт лежит" означает, что истекает таймаут при подключении к БД. Может есть варианты ещё как-то сделать дамп или выставить поменьше нагрузку на диски. nice/renice - не помогают, так как сервак не настолько нагружен, что бы приоритет влиял на это. Заранее спасибо. Если база на ZFS, делаем snapshot, потом делаем видимым snapdir, заходим в него и копируем всю папку базы целеком куда нужно. Но не факт, что будет меньше наргузка на винты.
Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
06.02.2012 15:15, Sergey Rudenko пишет: Поднять ещё один сервер БД, настроить репликацию и сделать дамп уже с него? Ха-ха: дабы поднять репликацию не с рождения базы, на будущем слейве вам надо будет развернуть дамп базы, для чего на будущем мастере его предстоит сделать... Получаем "сказку про белого бычка". Если вы уж как-то сумели дорасти до 50Гб _без_бэкапов_ - то придётся вам запланировать 3-5 часов даунтайма, дабы сделать бэкап. 06 февраля 2012, 15:07 от skeletor: Есть сервер в продакшине и с него нужно сделать дамп баз. Базы большие (50 Гб каждая). Проблема в том, что при дампе идёт сильная нагрузка на диски и в итоге - основной сайт лежит. Какие средства пробовались: - обычный дамп через mysqldump на другие диски - дамп через mysqldump по сети сразу на другой хост Но даже и в этом случае диски нагружаются достаточно, что бы сайт не отвечал. ПС. Сам сайт и БД лежат на разных серверах и фраза "сайт лежит" означает, что истекает таймаут при подключении к БД. Может есть варианты ещё как-то сделать дамп или выставить поменьше нагрузку на диски. nice/renice - не помогают, так как сервак не настолько нагружен, что бы приоритет влиял на это. Заранее спасибо. -- Best regards, Andrey Kopeyko
Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
06.02.2012 13:25, Sergey V. Dyatko пишет: каким образом предлагаете делать слейв?;-) насколько я понял, опускать сайт нельзя. Думаю делать так: поднять slave и начать репликацию. При этом возникает такой момент: данных очень много и поэтому, пока будет делаться дамп и заливка на slave насобирается очень много данных, которые потом должны будут реплицироваться - и не получиться ли так, что в этот момент нагрузка на диски опять возростёт.
Re: [freebsd] Необычный дамп базы mysql
On 02/06/12 15:07, skeletor wrote: Какие средства пробовались: - обычный дамп через mysqldump на другие диски - дамп через mysqldump по сети сразу на другой хост Но даже и в этом случае диски нагружаются достаточно, что бы сайт не отвечал. ПС. Сам сайт и БД лежат на разных серверах и фраза "сайт лежит" означает, что истекает таймаут при подключении к БД. Может есть варианты ещё как-то сделать дамп или выставить поменьше нагрузку на диски. nice/renice - не помогают, так как сервак не настолько нагружен, что бы приоритет влиял на это. Если база использует myisam лежит на зеркале (gmirror), то: 1. в mysql FLUSH TABLES WITH READ LOCK 2. В OS sync sleep 5 gmirror remove data da0x 3. в mysql UNLOCK TABLES После этого fsck_ffs /dev/da0x смонтировать его в /mnt и скопировать файлы базы данных на другой сервер. Способ неоднократно проверен на практике. Для innodb не пробовал, но тут http://dev.mysql.com/doc/refman/5.0/en/lock-tables.html пишут, что тоже возможно, но есть особенности, искать по слову innodb_max_dirty_pages_pct -- Anton Yuzhaninov
[freebsd] Re[2]: [freebsd] Re: [freebsd] Необычный дамп базы mysql
Насколько я понял пару раз его уже опускали, от ещё одного думаю ничего не случится, за-то потом проблем не будет 06 февраля 2012, 15:25 от "Sergey V. Dyatko" : > On Mon, 06 Feb 2012 15:15:10 +0400 > Sergey Rudenko wrote: > > > > > Поднять ещё один сервер БД, настроить репликацию и сделать дамп уже с > > него? > > > каким образом предлагаете делать слейв?;-) насколько я понял, опускать > сайт нельзя. > > > 06 февраля 2012, 15:07 от skeletor : > > > Есть сервер в продакшине и с него нужно сделать дамп баз. Базы > > > большие (50 Гб каждая). Проблема в том, что при дампе идёт сильная > > > нагрузка на диски и в итоге - основной сайт лежит. > > > > > > Какие средства пробовались: > > > - обычный дамп через mysqldump на другие диски > > > - дамп через mysqldump по сети сразу на другой хост > > > > > > Но даже и в этом случае диски нагружаются достаточно, что бы сайт не > > > отвечал. > > > > > > ПС. Сам сайт и БД лежат на разных серверах и фраза "сайт лежит" > > > означает, что истекает таймаут при подключении к БД. > > > > > > Может есть варианты ещё как-то сделать дамп или выставить поменьше > > > нагрузку на диски. nice/renice - не помогают, так как сервак не > > > настолько нагружен, что бы приоритет влиял на это. > > > > > > Заранее спасибо. > > > > > -- > wbr, tiger >
Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Mon, 06 Feb 2012 15:15:10 +0400 Sergey Rudenko wrote: > > Поднять ещё один сервер БД, настроить репликацию и сделать дамп уже с > него? > каким образом предлагаете делать слейв?;-) насколько я понял, опускать сайт нельзя. > 06 февраля 2012, 15:07 от skeletor : > > Есть сервер в продакшине и с него нужно сделать дамп баз. Базы > > большие (50 Гб каждая). Проблема в том, что при дампе идёт сильная > > нагрузка на диски и в итоге - основной сайт лежит. > > > > Какие средства пробовались: > > - обычный дамп через mysqldump на другие диски > > - дамп через mysqldump по сети сразу на другой хост > > > > Но даже и в этом случае диски нагружаются достаточно, что бы сайт не > > отвечал. > > > > ПС. Сам сайт и БД лежат на разных серверах и фраза "сайт лежит" > > означает, что истекает таймаут при подключении к БД. > > > > Может есть варианты ещё как-то сделать дамп или выставить поменьше > > нагрузку на диски. nice/renice - не помогают, так как сервак не > > настолько нагружен, что бы приоритет влиял на это. > > > > Заранее спасибо. > > -- wbr, tiger
[freebsd] Re: [freebsd] Необычный дамп базы mysql
Поднять ещё один сервер БД, настроить репликацию и сделать дамп уже с него? 06 февраля 2012, 15:07 от skeletor : > Есть сервер в продакшине и с него нужно сделать дамп баз. Базы большие > (50 Гб каждая). Проблема в том, что при дампе идёт сильная нагрузка на > диски и в итоге - основной сайт лежит. > > Какие средства пробовались: > - обычный дамп через mysqldump на другие диски > - дамп через mysqldump по сети сразу на другой хост > > Но даже и в этом случае диски нагружаются достаточно, что бы сайт не > отвечал. > > ПС. Сам сайт и БД лежат на разных серверах и фраза "сайт лежит" > означает, что истекает таймаут при подключении к БД. > > Может есть варианты ещё как-то сделать дамп или выставить поменьше > нагрузку на диски. nice/renice - не помогают, так как сервак не > настолько нагружен, что бы приоритет влиял на это. > > Заранее спасибо. >
[freebsd] Необычный дамп базы mysql
Есть сервер в продакшине и с него нужно сделать дамп баз. Базы большие (50 Гб каждая). Проблема в том, что при дампе идёт сильная нагрузка на диски и в итоге - основной сайт лежит. Какие средства пробовались: - обычный дамп через mysqldump на другие диски - дамп через mysqldump по сети сразу на другой хост Но даже и в этом случае диски нагружаются достаточно, что бы сайт не отвечал. ПС. Сам сайт и БД лежат на разных серверах и фраза "сайт лежит" означает, что истекает таймаут при подключении к БД. Может есть варианты ещё как-то сделать дамп или выставить поменьше нагрузку на диски. nice/renice - не помогают, так как сервак не настолько нагружен, что бы приоритет влиял на это. Заранее спасибо.
