Приветствую

Может и немного ОТ в данном списке...

Есть база данных ~90G, есть очень нагруженный сайт. БД периодически
проседает под нагрузкой.

Необходимо решение для обеспечения отказоустойчивости и LB.

Посмотрел на mysql-proxy чтобы разделить запросы на чтеине и запись
между master и slave. Смущает надпись на сайте, то что он в режиме альфа
находится, хотя Google выдает много положительных откликов.

Еще как вариант установить multimaster replication и разруливать запросы
на уровне приложения.


Есть другие варианты?


Спасибо.

mysql proxy вносит:
а) доп точку отказа
б) доп точку задержки

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

11 января 2011 г. 23:41 пользователь Sergey Kobzar
<sergey.kobzar@mail.ru>написал:

> Приветствую
>
> Может и немного ОТ в данном списке...
>
> Есть база данных ~90G, есть очень нагруженный сайт. БД периодически
> проседает под нагрузкой.
>
> Необходимо решение для обеспечения отказоустойчивости и LB.
>
> Посмотрел на mysql-proxy чтобы разделить запросы на чтеине и запись между
> master и slave. Смущает надпись на сайте, то что он в режиме альфа
> находится, хотя Google выдает много положительных откликов.
>
> Еще как вариант установить multimaster replication и разруливать запросы на
> уровне приложения.
>
>
> Есть другие варианты?
>
>
> Спасибо.
>



--
Think before you print.
Best regards, Alexey Bobok.

Использовали между серверами master-slave или multi-master репликацию?

Я еще рассматриваю вариант вынести CREATE/UPDATE на мастер, а SELECT и
на slave.

Вообще интересно, насколько существенна (видна) задержка с введением
mysql-proxy?

On 01/12/11 00:02, Алексей Бобок wrote:
> mysql proxy вносит:
> а) доп точку отказа
> б) доп точку задержки
>
> Если база и ПО сайта спроектированы верно, то разбросать запросы на
> разные сервера не составит проблем.
> можно в штатном режиме простые запросы обрабатывать на одном сервере, а
> тяжелые на другом. в моей практике добавление 2-го сервера увеличило
> общую производительность более чем в 2 раза, так как запросы друг друга
> не тормозили.
>
> 11 января 2011 г. 23:41 пользователь Sergey Kobzar
> <sergey.kobzar@mail.ru <mailto:sergey.kobzar@mail.ru>> написал:
>
> Приветствую
>
> Может и немного ОТ в данном списке...
>
> Есть база данных ~90G, есть очень нагруженный сайт. БД периодически
> проседает под нагрузкой.
>
> Необходимо решение для обеспечения отказоустойчивости и LB.
>
> Посмотрел на mysql-proxy чтобы разделить запросы на чтеине и запись
> между master и slave. Смущает надпись на сайте, то что он в режиме
> альфа находится, хотя Google выдает много положительных откликов.
>
> Еще как вариант установить multimaster replication и разруливать
> запросы на уровне приложения.
>
>
> Есть другие варианты?
>
>
> Спасибо.
>
>
>
>
> --
> Think before you print.
> Best regards, Alexey Bobok.

в моем случае master-slave. на это быстрее было переехать, чем на
master-master. в окончательном варианте будет master-master.

зависит от соотношения write к read операций. у меня ничтожно мало записи
по-сравнению с read.

я встречал цифру в 30% уменьшения производительности mysql сервера. это в
случае когда бекендов за mysql-proxy только 1 сервер. модель естественно
лабораторная и глупая, но показывает примерную стоимость ввода
балансировщика. Лично и под нагрузкой я не тестировал mysql-proxy. для меня
более важный параметр стабильность работы ПО в частности и решения в целом.

12 января 2011 г. 0:09 пользователь Sergey Kobzar
<sergey.kobzar@mail.ru>написал:

> Использовали между серверами master-slave или multi-master репликацию?
>
> Я еще рассматриваю вариант вынести CREATE/UPDATE на мастер, а SELECT и на
> slave.
>
> Вообще интересно, насколько существенна (видна) задержка с введением
> mysql-proxy?
>
>
> On 01/12/11 00:02, Алексей Бобок wrote:
>
>> mysql proxy вносит:
>> а) доп точку отказа
>> б) доп точку задержки
>>
>> Если база и ПО сайта спроектированы верно, то разбросать запросы на
>> разные сервера не составит проблем.
>> можно в штатном режиме простые запросы обрабатывать на одном сервере, а
>> тяжелые на другом. в моей практике добавление 2-го сервера увеличило
>> общую производительность более чем в 2 раза, так как запросы друг друга
>> не тормозили.
>>
>> 11 января 2011 г. 23:41 пользователь Sergey Kobzar
>> <sergey.kobzar@mail.ru <mailto:sergey.kobzar@mail.ru>> написал:
>>
>>
>> Приветствую
>>
>> Может и немного ОТ в данном списке...
>>
>> Есть база данных ~90G, есть очень нагруженный сайт. БД периодически
>> проседает под нагрузкой.
>>
>> Необходимо решение для обеспечения отказоустойчивости и LB.
>>
>> Посмотрел на mysql-proxy чтобы разделить запросы на чтеине и запись
>> между master и slave. Смущает надпись на сайте, то что он в режиме
>> альфа находится, хотя Google выдает много положительных откликов.
>>
>> Еще как вариант установить multimaster replication и разруливать
>> запросы на уровне приложения.
>>
>>
>> Есть другие варианты?
>>
>>
>> Спасибо.
>>
>>
>>
>>
>> --
>> Think before you print.
>> Best regards, Alexey Bobok.
>>
>
>


--
Think before you print.
Best regards, Alexey Bobok.

Добрый день,

я использовал MySQL proxy для миграции MySQL 4 -> MySQL5 одного
высоконагруженного приложения, до тех пор пока программисты сами не
исправили кривые запросы (я их вылавливал и правил в LUA). Кроме того
использую его для вылавливания ошибочных запросов при разработке и
некоторых других вкусностей.

Касательно задачи - мне кажется, что если у вас есть доступ к коду -
стоит сделать на уровне приложения. Если у вас большинство запросов
чтение - обычный master => slaves будет вполне достаточным. MySQL proxy
до сих пор не может полноценно разруливать rw, добавляет latency и
кушает ресурсы, так что я бы не советовал использовать его на
высоконагруженном сервере без крайней на то нужды.

On 01/11/2011 10:41 PM, Sergey Kobzar wrote:
> Приветствую
>
> Может и немного ОТ в данном списке...
>
> Есть база данных ~90G, есть очень нагруженный сайт. БД периодически
> проседает под нагрузкой.
>
> Необходимо решение для обеспечения отказоустойчивости и LB.
>
> Посмотрел на mysql-proxy чтобы разделить запросы на чтеине и запись
> между master и slave. Смущает надпись на сайте, то что он в режиме
> альфа находится, хотя Google выдает много положительных откликов.
>
> Еще как вариант установить multimaster replication и разруливать
> запросы на уровне приложения.
>
>
> Есть другие варианты?
>
>
> Спасибо.
>

On 01/11/2011 11:09 PM, Sergey Kobzar wrote:
> Использовали между серверами master-slave или multi-master репликацию?
>
> Я еще рассматриваю вариант вынести CREATE/UPDATE на мастер, а SELECT и
> на slave.
>
> Вообще интересно, насколько существенна (видна) задержка с введением
> mysql-proxy?
Визуально - не особо видна, а вот памяти процесс может кушать немало,
как и CPU. Причем не масштабируется, сабака, печально висит на одном
ядре... Ну и кроме того - вам все равно придется описывать логику на
LUA, как по мне - проще и удобнее это сделать внутри приложения. Не
говоря уж о том, что всяких там SELECT INTO и прочих подводных камней
может быть дофига. Да и не стоит забывать, что не везде селекты можно
безопасно перекладывать на слейв - он 1) может и будет отставать от
мастера и 2) локи мастера на слейв не распространяются, со всеми
вытекающими.

On 01/11/2011 11:25 PM, Алексей Бобок wrote:
> Лично и под нагрузкой я не тестировал mysql-proxy. для меня более
> важный параметр стабильность работы ПО в частности и решения в целом.
Ну стабильность как раз была высокой - при TPS примерно 5-8K/sec он себя
терпимо вел. Очень помог при миграции 4->5 для вылавливания и быстрой
правки broken queries. Падение будет напрямую зависить от характера
нагрузки - чем больше RPS тем больше падение. А вот с масштабированием у
него совсем нехорошо. С другой стороны - интеграция с LUA и возможность
использовать все луа модули - дает возможности просто огромные, и с
намного меньшими времязатратами чем UDF.

On 01/12/11 01:09, Sergey Kobzar wrote:
> Я еще рассматриваю вариант вынести CREATE/UPDATE на мастер, а SELECT и
> на slave.
Если этого окажется достаточно, я бы выбрал именно такой вариант. Если
не решает проблему, спасёт только шардинг (partitioning).

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

12 января 2011 г. 11:30 пользователь Andrey N. Oktyabrski <
a.n.oktyabrski@gmail.com> написал:

> On 01/12/11 01:09, Sergey Kobzar wrote:
>
>> Я еще рассматриваю вариант вынести CREATE/UPDATE на мастер, а SELECT и
>> на slave.
>>
> Если этого окажется достаточно, я бы выбрал именно такой вариант. Если не
> решает проблему, спасёт только шардинг (partitioning).
>

Alex

On 01/12/11 01:16, Alex Samorukov wrote:
> On 01/11/2011 11:09 PM, Sergey Kobzar wrote:
>> Использовали между серверами master-slave или multi-master репликацию?
>>
>> Я еще рассматриваю вариант вынести CREATE/UPDATE на мастер, а SELECT и
>> на slave.
>>
>> Вообще интересно, насколько существенна (видна) задержка с введением
>> mysql-proxy?
> Визуально - не особо видна, а вот памяти процесс может кушать немало,
> как и CPU. Причем не масштабируется, сабака, печально висит на одном
> ядре... Ну и кроме того - вам все равно придется описывать логику на
> LUA, как по мне - проще и удобнее это сделать внутри приложения. Не
> говоря уж о том, что всяких там SELECT INTO и прочих подводных камней
> может быть дофига. Да и не стоит забывать, что не везде селекты можно
> безопасно перекладывать на слейв - он 1) может и будет отставать от
> мастера и 2) локи мастера на слейв не распространяются, со всеми
> вытекающими.

Спасибо за комментарии.
Действиткльно, mysql-proxy не лучшее решение.

Масштабируемость MySQL как оказалось не в лучшем состоянии.

опять таки, если соотношение запись-чтение стремится к 1:1
если там записи 5% от всех запросов - вряд-ли чем-то поможет

12 января 2011 г. 11:30 пользователь Andrey N. Oktyabrski <
a.n.oktyabrski@gmail.com> написал:

> On 01/12/11 01:09, Sergey Kobzar wrote:
>
>> Я еще рассматриваю вариант вынести CREATE/UPDATE на мастер, а SELECT и
>> на slave.
>>
> Если этого окажется достаточно, я бы выбрал именно такой вариант. Если не
> решает проблему, спасёт только шардинг (partitioning).
>



--
Think before you print.
Best regards, Alexey Bobok.

Андрей

On 01/12/11 11:30, Andrey N. Oktyabrski wrote:
> On 01/12/11 01:09, Sergey Kobzar wrote:
>> Я еще рассматриваю вариант вынести CREATE/UPDATE на мастер, а SELECT и
>> на slave.
> Если этого окажется достаточно, я бы выбрал именно такой вариант. Если
> не решает проблему, спасёт только шардинг (partitioning).

Спасибо. Пока это единственное видимое решение... Размазывание MySQL по
нескольким серверам оказалось непростой задачей. Будем делать на уровне
приложения.

On 01/12/11 13:24, Evgeny P wrote:
> Это не та задача, чтоб ее шардингом решать и вообще их ограниченное кол-во.
> В большинстве случаев репликация решит все вопросы с нагрузкой, если
> одна машина не справляется.
Я не увидел достаточно подробного описания задачи, поэтому не могу ни
подтвердить, ни опровергнуть первое высказывание. Могу только сказать,
что второе утверждение достаточно спорно.

Оптимально будет установить mysql-mmm и разруливать запись/чтение в
приложении.

12 января 2011 г. 4:41 пользователь Sergey Kobzar
<sergey.kobzar@mail.ru>написал:

> Приветствую
>
> Может и немного ОТ в данном списке...
>
> Есть база данных ~90G, есть очень нагруженный сайт. БД периодически
> проседает под нагрузкой.
>
> Необходимо решение для обеспечения отказоустойчивости и LB.
>
> Посмотрел на mysql-proxy чтобы разделить запросы на чтеине и запись между
> master и slave. Смущает надпись на сайте, то что он в режиме альфа
> находится, хотя Google выдает много положительных откликов.
>
> Еще как вариант установить multimaster replication и разруливать запросы на
> уровне приложения.
>
>
> Есть другие варианты?
>
>
> Спасибо.
>

On 01/13/11 08:03, Alexey Samoylov wrote:
> Оптимально будет установить mysql-mmm и разруливать запись/чтение в
> приложении.

Я сначала хочу собрать статистику отношения запросов на запись/чтение.
Если кол-во запросов на запись значительно меньше кол-ва запросов на
чтение (есть у меня такое подозрение) и они не тяжелые, то достаточно
будет master-slave replication, а чтение размазать по нескольким slave.
Пока нет идей как его распараллелить на неск. серверов... разве что
несколько A записей в DNS с одинаковым именем, тогда будет roubd-robin,
но без dead peer detection.

Если кому интересно - статистику такую модно получить с пом. Munin - в
нем уже готовые скрипты есть.

Btw, кто нибуть использовал MySQL (NDB) Cluster? Google дает о нем
нелестные отзывы.

> 12 января 2011 г. 4:41 пользователь Sergey Kobzar <sergey.kobzar@mail.ru
> <mailto:sergey.kobzar@mail.ru>> написал:
>
> Приветствую
>
> Может и немного ОТ в данном списке...
>
> Есть база данных ~90G, есть очень нагруженный сайт. БД периодически
> проседает под нагрузкой.
>
> Необходимо решение для обеспечения отказоустойчивости и LB.
>
> Посмотрел на mysql-proxy чтобы разделить запросы на чтеине и запись
> между master и slave. Смущает надпись на сайте, то что он в режиме
> альфа находится, хотя Google выдает много положительных откликов.
>
> Еще как вариант установить multimaster replication и разруливать
> запросы на уровне приложения.
>
>
> Есть другие варианты?
>
>
> Спасибо.
>
>

Кстати сегодня пришло письмо с докой о партицировании mysql.
См. приложение.

13 января 2011 г. 11:40 пользователь Алексей Бобок
<alexey.bobok@gmail.com>написал:

> А есть опыт использщования в продакшне этой софты?
>
> 13 января 2011 г. 8:03 пользователь Alexey Samoylov <
> alexey.samoylov@gmail.com> написал:
>
> Оптимально будет установить mysql-mmm и разруливать запись/чтение в
>> приложении.
>>
>> --
> Think before you print.
> Best regards, Alexey Bobok.
>



--
Think before you print.
Best regards, Alexey Bobok.

А есть опыт использщования в продакшне этой софты?

13 января 2011 г. 8:03 пользователь Alexey Samoylov <
alexey.samoylov@gmail.com> написал:

> Оптимально будет установить mysql-mmm и разруливать запись/чтение в
> приложении.
>
> --
Think before you print.
Best regards, Alexey Bobok.

учитывая что решение бесплатное и функциональное, должны же быть у него и
недостатки :)
работают же на mysql крупные ресурсы - и ничего. свои бока есть. но
решабельны.

а нет - покупайте Oracle за стопицот мильонов))


>> Масштабируемость MySQL как оказалось не в лучшем состоянии.
>



--
Think before you print.
Best regards, Alexey Bobok.

Еще MSSQL предложите ;).

On 01/13/11 11:30, Алексей Бобок wrote:
> учитывая что решение бесплатное и функциональное, должны же быть у него
> и недостатки :)
> работают же на mysql крупные ресурсы - и ничего. свои бока есть. но
> решабельны.
>
> а нет - покупайте Oracle за стопицот мильонов))
>
>
> Масштабируемость MySQL как оказалось не в лучшем состоянии.
>
>
>
>
> --
> Think before you print.
> Best regards, Alexey Bobok.

что для своих задач будет тоже приемлемо)

13 января 2011 г. 18:03 пользователь Sergey Kobzar
<sergey.kobzar@mail.ru>написал:

> Еще MSSQL предложите ;).
>
>
> On 01/13/11 11:30, Алексей Бобок wrote:
>
>> учитывая что решение бесплатное и функциональное, должны же быть у него
>> и недостатки :)
>> работают же на mysql крупные ресурсы - и ничего. свои бока есть. но
>> решабельны.
>>
>> а нет - покупайте Oracle за стопицот мильонов))
>>
>>
>> Масштабируемость MySQL как оказалось не в лучшем состоянии.
>>
>>
>>
>>
>> --
>> Think before you print.
>> Best regards, Alexey Bobok.
>>
>
>


--
Think before you print.
Best regards, Alexey Bobok.