Comments 59
Я правильно понимаю, что единственное отличие от Master-Slave заключается в том, что есть возможность быстрого перекючения ноды С в режим чтения-записи из режима только запись?
Пробовали ли вы такой случай расматривать:
1) Нода Б вылетела, нода С проработала сама час/сутки/двое/…
2) Нода Б вернулась
3) Произойдёт автоматическое восстановление? Есть несколько возможных проблем, например, если запись на ноду Б происходит не после того, как эта запись была добавлена на ноду А, то есть вероятность, что всплывут записи, о которых система не подозревала и начнутся проблемы индексов…
Пробовали ли вы такой случай расматривать:
1) Нода Б вылетела, нода С проработала сама час/сутки/двое/…
2) Нода Б вернулась
3) Произойдёт автоматическое восстановление? Есть несколько возможных проблем, например, если запись на ноду Б происходит не после того, как эта запись была добавлена на ноду А, то есть вероятность, что всплывут записи, о которых система не подозревала и начнутся проблемы индексов…
В описанном вами случае произойдет автоматическое восстановление ноды Б, точнее синхронизация содержащихся в ней данных либо с одной из живых нод, либо с конкретной нодой, если мы укажем это в конфиге.
Пробовал, и неоднократно — все так и есть. Конечно, случались и некоторые глюки, часть из которых описана в статье.
Пробовал, и неоднократно — все так и есть. Конечно, случались и некоторые глюки, часть из которых описана в статье.
насчет возможной проблемы из п.3 я пока еще думаю, пытаюсь понять как это возможно
1) INSERT/UPDATE… приходит на ноду Б
2) нода Б выполняет запись в БД и записывает изменения в лог, в соответствии с которым, остальные ноды в последствии накатывают изменения себе
3) пыщ-пыщ, нода Б вылетела, а лог никто не успел вычитать
4) прошло время и нода Б стартует, у неё в базе одно записано, а ей синхронизируют дубли по ИД
Этого можно избежать, если HAProxy будет запросы на запись слать всем серверам сразу самостоятельно или нода Б будет ждать подтвержения от ноды А о том, что данные она приняла и записала и только после этого записывать у себя, на ноде Б.
2) нода Б выполняет запись в БД и записывает изменения в лог, в соответствии с которым, остальные ноды в последствии накатывают изменения себе
3) пыщ-пыщ, нода Б вылетела, а лог никто не успел вычитать
4) прошло время и нода Б стартует, у неё в базе одно записано, а ей синхронизируют дубли по ИД
Этого можно избежать, если HAProxy будет запросы на запись слать всем серверам сразу самостоятельно или нода Б будет ждать подтвержения от ноды А о том, что данные она приняла и записала и только после этого записывать у себя, на ноде Б.
Тут другая схема, ноды не ходят друг к другу в лог за изменениями. Каждая транзакция перед физическим локальным коммитом передается на все удаленные ноды. Вот схема: www.percona.com/doc/percona-xtradb-cluster/_images/XtraDBClusterUML1.png
Так percona синхронная репликация, проблем быть не должно.
>Мы намеренно решили использовать для LB и VIP те же железки, что и для кластера.
А можно как то более подробно?
Мне вот кажется логичным LB вынести не отдельные машины, которые будут заниматся балансировкой не только perona, но и например http трафика или чего-то еще.
А можно как то более подробно?
Мне вот кажется логичным LB вынести не отдельные машины, которые будут заниматся балансировкой не только perona, но и например http трафика или чего-то еще.
В идеале да. Но 2 отдельные машины — это все-таки 2 отдельные машины, их тоже нужно просить у руководства. Возможно, когда веб-серверы у нас тоже будут жить в кластере, озаботимся этим вопросом.
Я сейчас как раз озабочен, как правильно сделать кластер из web :)
Упирается все в нехватки знаний.
Хочется некое единое место хранение, где хранится контент, или думать как все это хозяйтсво синхронихировать, при выходе новой версии сайта.
Упирается все в нехватки знаний.
Хочется некое единое место хранение, где хранится контент, или думать как все это хозяйтсво синхронихировать, при выходе новой версии сайта.
git, или банальные пакеты. Раскатывать тем же, чем рулите кластером (puppet, chef). Быстро, удобно, не зависит от количества серверов, легко делать prod-like среду для тестирования.
Я тоже слежу за этой темой. Тут основная проблема в user-generated контент, где хранить его.
Решение чаще всего в кластерных ФС, но эта тема посложнее MySQL кластера будет )
Решение чаще всего в кластерных ФС, но эта тема посложнее MySQL кластера будет )
Нормальное кластерная ФС, эта ocfs2. Ну или платные решения.
Есть еще распределенные ФС типа ceph и glusterfs, но они не кластырные :)
Есть еще распределенные ФС типа ceph и glusterfs, но они не кластырные :)
ну и как, пробовали? годится для размазывания user-generated данных по серверам в синхронном режиме?
Пробывал что? если ocfs2, то мы используем для своих вещей. У ocfs2 есть асинхронный режим работы, но мы используем прямой доступ.
Если про ceph и gluster, то не использовал. Все у меня в стадии тетирования.
Хотя тут habrahabr.ru/post/157029/, человек использует glusterfs.
Если про ceph и gluster, то не использовал. Все у меня в стадии тетирования.
Хотя тут habrahabr.ru/post/157029/, человек использует glusterfs.
От себя добавлю:
Мы перешли на перкона кластер с месяц назад. Переходили под чутким руководством саппорта. Платный саппорт оказался просто отличным.
Мы перешли на перкона кластер с месяц назад. Переходили под чутким руководством саппорта. Платный саппорт оказался просто отличным.
Хорошая работа, раскрыто много нюансов.
А с проблемой временной рассинхронизации данных не столкнулись?
Вот тут описывал: habrahabr.ru/post/152969/#comment_5364691
А с проблемой временной рассинхронизации данных не столкнулись?
Вот тут описывал: habrahabr.ru/post/152969/#comment_5364691
А можете прокомментировать пункт 3 отсюда? Можно ли расположить ноды в разных сетях (потенциально — в разных дц)? Тестировали производительность при наличии некоторой небольшой задержки (единицы миллисекунд) в линках между нодами?
1) падение по записи действительно есть, но на моих тестах все же не в 10 раз, как у автора, сейчас точно не могу сказать, продолжаю эксперименты, планирую покопаться в этом вопросе поглубже
2) не вижу проблем в размещении в другом ДЦ
3) пока нет, не думаю что для нас узким местом станет сеть, вернее думаю мы найдем по пути много других граблей, пока дойдем до сети
2) не вижу проблем в размещении в другом ДЦ
3) пока нет, не думаю что для нас узким местом станет сеть, вернее думаю мы найдем по пути много других граблей, пока дойдем до сети
а mysql_proxy не рассмотривали в качестве балансировщика?
UFO just landed and posted this here
Кстати, вчера вышел новый релиз Percona Xtradb Cluster:
www.mysqlperformanceblog.com/2012/11/15/announcing-percona-xtradb-cluster-5-5-28-23-7/
www.mysqlperformanceblog.com/2012/11/15/announcing-percona-xtradb-cluster-5-5-28-23-7/
Кстати, человек которому дал статью, обратил внимание, что нету примера конфигурации keepalived. Человеку помог настроить, но все же можно было бы добавить в статью?
поправте keepalived
Убежала v
>rrp_script chk_haproxy {
vrrp_script chk_haproxy {
Убежала v
>rrp_script chk_haproxy {
vrrp_script chk_haproxy {
У меня тут вопрос возник. Тут вы указываете, что node a знает о всех нодах.
node b,c знает только о node a.
те если упадет node a, то все встало? в чем смысл? (ну кроме как распределить нагрузку)
node b,c знает только о node a.
те если упадет node a, то все встало? в чем смысл? (ну кроме как распределить нагрузку)
Присоединившись к кластеру, используя любую из уже существующих нод, присоединяемая нода (JOINER) «узнает» обо всех нодах в кластере, а не только о DONOR-е. Это очень легко можно проверить, почитав error_log на JOINER-e.
В описанной здесь конфигурации проблемное место в том, что если упадет А, потом B и C, то все встанет, пока мы не поднимем A. На самом деле я уже почти отказался от схемы с Reference Node, когда всего 3 ноды в кластере, снимать нагрузку полностью с одного из узлов слишком расточительно. Кстати, мы еще не запустили PXC в продакшен, планирую скоро продолжить цикл статей о том, на какие грабли наступили и как преодолели.
В описанной здесь конфигурации проблемное место в том, что если упадет А, потом B и C, то все встанет, пока мы не поднимем A. На самом деле я уже почти отказался от схемы с Reference Node, когда всего 3 ноды в кластере, снимать нагрузку полностью с одного из узлов слишком расточительно. Кстати, мы еще не запустили PXC в продакшен, планирую скоро продолжить цикл статей о том, на какие грабли наступили и как преодолели.
> На самом деле я уже почти отказался от схемы с Reference Node, когда всего 3 ноды в кластере
И что выбрали?
у меня на PXC просто время появилось поковырять. Три машины уже поднял. Буду дальше
Использую в качестве точки взлета статью www.percona.com/doc/percona-xtradb-cluster/howtos/3nodesec2.html
Там как раз используются все 3 узла.
Цикл ждем. По крайне мере я точно жду :)
И что выбрали?
у меня на PXC просто время появилось поковырять. Три машины уже поднял. Буду дальше
Использую в качестве точки взлета статью www.percona.com/doc/percona-xtradb-cluster/howtos/3nodesec2.html
Там как раз используются все 3 узла.
Цикл ждем. По крайне мере я точно жду :)
Остановился на том, что все 3 ноды доступны на чтение, а запись только на одну, рулит этим HAProxy.
В статье, что вы взяли за точку взлета указан только самый минимум действий, чтобы получить работающий кластер. А вот дальше пойдут ньюансы, и вот тут уже дойдете до статей на mysqlperfomanceblog, благо там они есть.
Рад что у вас появилось время на PXC, надеюсь что будет возможность поделиться мнениями.
В статье, что вы взяли за точку взлета указан только самый минимум действий, чтобы получить работающий кластер. А вот дальше пойдут ньюансы, и вот тут уже дойдете до статей на mysqlperfomanceblog, благо там они есть.
Рад что у вас появилось время на PXC, надеюсь что будет возможность поделиться мнениями.
Ну я пока что пришел к этой же схеме.
HAProxy раскидывает чтение по кластеру, запись на 1 из кластеров. Если он падает, пишем в другой.
Правда я HAProxy сделал на отдельных двух машинах с 4 ip адресами.
HAProxy раскидывает чтение по кластеру, запись на 1 из кластеров. Если он падает, пишем в другой.
Правда я HAProxy сделал на отдельных двух машинах с 4 ip адресами.
Сам по себе haproxy распарсивать запросы чтение/запись не умеет. У Вас приложение умеет обращаться на чтение/запись к разным серверам, или Вы вносили изменения в код и для указывали разные сервера для разных запросов.
UFO just landed and posted this here
Это понятно, но в таком случае веб-движок должен отправлять запросы на чтение на порт 3306 (например), а на запись на 3307?
Кстати, а не подскажете или может быть ткнуть что почитать.
keepalived на одной машине с HAproxy, keepalived поднят виртуальный интерфейс, но запросы на percona с haproxy приходят с реальных ip, что не совсем хорошо.
Может быть есть способ как то сказать haproxy отправлять ip виртуальный на percona?
keepalived на одной машине с HAproxy, keepalived поднят виртуальный интерфейс, но запросы на percona с haproxy приходят с реальных ip, что не совсем хорошо.
Может быть есть способ как то сказать haproxy отправлять ip виртуальный на percona?
От себя добавлю, мы ушли от этого. Все как то и так прекрасно работает.
> возможность коммерческой поддержки от Percona
используете?
а чем не устраивает коммерческая поддержка от Oracle?
используете?
а чем не устраивает коммерческая поддержка от Oracle?
пока не пользуемся
как только поймем, что готовы запустить кластер в продакшен, скорее всего закажем поддержку
от руководства принципиальное согласие получено
у Oracle нет версии mysql сервера с wsrep-хуками и поддержкой Galera
А вообще я лично никакой платной поддержки продуктов такого уровня не пробовал, не с чем сравнить.
Будет первый опыт, если повезет.
как только поймем, что готовы запустить кластер в продакшен, скорее всего закажем поддержку
от руководства принципиальное согласие получено
у Oracle нет версии mysql сервера с wsrep-хуками и поддержкой Galera
А вообще я лично никакой платной поддержки продуктов такого уровня не пробовал, не с чем сравнить.
Будет первый опыт, если повезет.
Непонятно, откуда у вас взялся порт 33061 :) Остатки игр с кофигами?
Какой объем базы?
Какое количество транзакций/запросов в сутки?
Прошло почти 1,5 года — были ли сбои? Если да — расскажите о них и как решали.
Какое количество транзакций/запросов в сутки?
Прошло почти 1,5 года — были ли сбои? Если да — расскажите о них и как решали.
Sign up to leave a comment.
Переход на Percona XtraDB Cluster. Одна из возможных конфигураций