Пользователь
0,0
рейтинг
16 ноября 2012 в 00:27

Разработка → Переход на Percona XtraDB Cluster. Часть I. Одна из возможных конфигураций

Итак, я начал внедрять в своей организации Percona XtraDB Cluster — переводить базы данных с обычного MySQL сервера в кластерную архитектуру.


Коротко о задаче и вводные данные


В кластере нам нужно держать:
  • БД нескольких веб-сайтов с пользователями
  • БД со статистическими данными этих пользователей
  • БД для тикет-систем, систем управления проектами и прочая мелочь

Иными словами, БД практически всех наших проектов, из тех что крутятся у нас на MySQL, теперь должны жить в кластере.

Большинство проектов мы держим удаленно в ДЦ, поэтому и кластер будет находится там.
Задача разнести кластер географически по разным дата-центрам не стоит.

Для построения кластера используются 3 сервера одинаковой конфигурации: HP DL160 G6, 2X Xeon E5620, 24 GB RAM, 4x SAS 300GB в аппаратном RAID 10. Неплохое брендовое железо, которое я использую уже давно и которое меня пока не подводило.


Почему Percona?


— синхронная true multi-master репликация (Galera)
— возможность коммерческой поддержки от Percona
— форк MySQL c внушительным списком оптимизаций


Схема кластера


В кластере 3 ноды, для каждой вышеописанный физический сервер (OS Ubuntu 12.04).

Используется прозрачный коннект к одному виртуальному IP-адресу, разделяемому между всеми 3 серверами при помощи keepalived. Для балансировки нагрузки на ноды используется HAProxy, конечно же установленный на каждом сервере, чтобы в случае отказа одного из них, нагрузку благодаря VIP продолжал балансировать другой. Мы намеренно решили использовать для LB и VIP те же железки, что и для кластера.

Node A используется в качестве Reference (Backup) Node, которую не будут загружать запросами наши приложения. При этом она будет полноправным членом кластера, и участвовать в репликации. Это делается в связи с тем, что в случае сбоя в кластере или нарушения целостности данных мы будем иметь ноду, которая почти наверняка содержит наиболее консистентные данные, которые приложения просто не могли порушить из-за отсутствия доступа. Возможно, это выглядит расточительным расходованием ресурсов, но для нас 99% надежность данных все же важнее чем доступность 24/7. Именно эту ноду мы будем использовать для SST — State Snapshot Transfer — автоматического слива дампа на присоединяемую к кластеру новую ноду или поднимаемую после сбоя. Кроме того, Node A — отличный кандидат для сервера, откуда мы будем снимать стандартные периодические резервные копии.

Схематично это все можно изобразить примерно так:


Node B и Node C это рабочие лошадки, которые держат нагрузку, но при этом операции записи берет на себя только одна из них. Такова рекомендация многих специалистов, и ниже я остановлюсь на этом вопросе подробно.


HAProxy и детали балансировки


Запросы, приходящие на порт 3306, HAProxy раскидывает по Round Robin между нодами B и C.
То, что приходит на 3307, проксируется только на Node B. При этом если Node B вдруг упадет, запросы перейдут на указанную в качестве резервной Node C.

Для реализации нашей идеи (писать только на одну из нод) приложения должны быть написаны так, чтобы запросы на чтение шли через соединение с 10.0.0.70:3306 (10.0.0.70 — наш VIP), а запросы на запись направлялись на 10.0.0.70:3307.

В нашем случае это потребует некоторой работы по созданию в конфиге PHP приложения нового коннекта, и замене имени переменной-DBHandler на другое значение. В целом, это не так сложно для тех приложений, которые написаны нами. Для сторонних проектов, чьи базы тоже будут в кластере, мы просто укажем порт 3307 по умолчанию. Нагрузку эти проекты создают небольшую, и потеря возможности распределенного чтения не так критична.

Конфиг HAProxy (/etc/haproxy/haproxy.cfg):
global
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
maxconn 4096
chroot /usr/share/haproxy
daemon

defaults
log global
mode http
option tcplog
option dontlognull
retries 3
option redispatch
maxconn 2000
contimeout 5000
clitimeout 50000
srvtimeout 50000

frontend pxc-front
bind 10.0.0.70:3306
mode tcp
default_backend pxc-back

frontend stats-front
bind *:81
mode http
default_backend stats-back

frontend pxc-onenode-front
bind 10.0.0.70:3307
mode tcp
default_backend pxc-onenode-back

backend pxc-back
mode tcp
balance leastconn
option httpchk
server c1 10.0.0.106:33061 check port 9200 inter 12000 rise 3 fall 3
server c2 10.0.0.107:33061 check port 9200 inter 12000 rise 3 fall 3

backend stats-back
mode http
balance roundrobin
stats uri /haproxy/stats
stats auth haproxy:password

backend pxc-onenode-back
mode tcp
balance leastconn
option httpchk
server c1 10.0.0.106:33061 check port 9200 inter 12000 rise 3 fall 3
server c2 10.0.0.107:33061 check port 9200 inter 12000 rise 3 fall 3 backup

backend pxc-referencenode-back
mode tcp
balance leastconn
option httpchk
server c0 10.0.0.105:33061 check port 9200 inter 12000 rise 3 fall 3


Для того, чтобы HAProxy мог определить жив ли узел кластера, используется утилита clustercheck, (входит в пакет percona-xtradb-cluster), которая выводит сведения о состоянии ноды (Synced / Not Synced) в виде HTTP ответа. На каждом из узлов должен быть настроен xinetd сервис:

/etc/xinetd.d/mysqlchk
service mysqlchk
{
        disable = no
        flags           = REUSE
        socket_type     = stream
        port            = 9200
        wait            = no
        user            = nobody
        server          = /usr/bin/clustercheck
        log_on_failure  += USERID
        only_from       = 0.0.0.0/0
        per_source      = UNLIMITED
}

/etc/services
... 
# Local services
mysqlchk 9200/tcp # mysqlchk


HAProxy поднимает веб-сервер и предоставляет скрипт для просмотра статистики, что очень удобно для визуального мониторинга состояния кластера.
URL выглядит так:
http://VIP:81/haproxy/stats
Порт, а также логин и пароль для Basic авторизации указываются в конфиге.

Хорошо рассмотрен вопрос настройки кластера с балансировкой через HAProxy здесь: www.mysqlperformanceblog.com/2012/06/20/percona-xtradb-cluster-reference-architecture-with-haproxy


Keepalived и VIP


$ echo "net.ipv4.ip_nonlocal_bind=1" >> /etc/sysctl.conf && sysctl -p

/etc/keepalived/keepalived.conf
vrrp_script chk_haproxy {               # Requires keepalived-1.1.13
        script "killall -0 haproxy"     # cheaper than pidof
        interval 2                      # check every 2 seconds
        weight 2                        # add 2 points of prio if OK
}

vrrp_instance VI_1 {
        interface eth0
        state MASTER           # SLAVE on backup
        virtual_router_id 51
        priority 101           # 101 on master, 100 and 99 on backup
        virtual_ipaddress {
            10.0.0.70
        }
        track_script {
            chk_haproxy
        }
}



Конфигурация нод


На хабре уже есть статья об установке и тестировании PXC: habrahabr.ru/post/152969, где оба вопроса рассмотрены подробно, поэтому установку я опускаю. Но опишу конфигурирование.

В первую очередь, не забудьте синхронизировать время на всех нодах. Я упустил этот момент, и довольно долго не мог понять, почему у меня намертво подвисает SST — он начинался, висел в процессах, но по факту ничего не происходило.

my.cnf на Node A (в моих конфигах это node105):
[mysqld_safe]
wsrep_urls=gcomm://10.0.0.106:4567,gcomm://10.0.0.107:4567

# wsrep_urls=gcomm://10.0.0.106:4567,gcomm://10.0.0.107:4567,gcomm://
# закомментированый параметр - тот, что нужно использовать 
# при инициализации кластера, т.е. первом запуске первой ноды
# это важный момент, и он будет рассмотрен ниже 

[mysqld]
port=33061
bind-address=10.0.0.105
datadir=/var/lib/mysql
skip-name-resolve
log_error=/var/log/mysql/error.log

binlog_format=ROW
wsrep_provider=/usr/lib/libgalera_smm.so
wsrep_slave_threads=16
wsrep_cluster_name=cluster0
wsrep_node_name=node105
wsrep_sst_method=xtrabackup
wsrep_sst_auth=backup:password

innodb_locks_unsafe_for_binlog=1
innodb_autoinc_lock_mode=2
innodb_buffer_pool_size=8G
innodb_log_file_size=128M
innodb_log_buffer_size=4M
innodb-file-per-table


Дальше — только отличающиеся параметры:

Node B (node106)
[mysqld_safe]
wsrep_urls=gcomm://10.0.0.105:4567

[mysqld]
bind-address=10.0.0.106
wsrep_node_name=node106
wsrep_sst_donor=node105


Node C (node107)
[mysqld_safe]
wsrep_urls=gcomm://10.0.0.105:4567

[mysqld]
bind-address=10.0.0.107
wsrep_node_name=node107
wsrep_sst_donor=node105


В последних двух конфигах мы недвусмысленно сообщаем серверу, где нужно искать первую ноду в кластере (которая знает где живут все члены группы), и что именно с нее, а не с другой из доступных, нужно забирать данные для синхронизации.

Именно на такой конфигурации я остановился сейчас, и собираюсь постепенно переводить проекты в кластер. Планирую продолжить писать о своем опыте и дальше.


Проблемные вопросы


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

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

Когда я впервые увидел эту рекомендацию, то очень расстроился. Я представлял себе multi-master таким образом, что можно ни о чем не заботясь писать на любой узел, и изменения гарантированно применятся синхронно на всех нодах. Но суровые реалии жизни таковы, что при таком подходе возможно повление cluster-wide deadlocks. Особенно велика вероятность в случае параллельного изменения одних и тех же данных в длинных транзакциях. Т.к. я не являюсь пока экспертом в этом вопросе, не могу объяснить этот процесс на пальцах. Но есть хорошая статья, где эта проблема освещена подробнейшим образом: Percona XtraDB Cluster: Multi-node writing and Unexpected deadlocks

Мои собственные тесты показали, что при агрессивной записи на все ноды они ложились одна за другой, оставляя рабочей только Reference Node, т.е. по факту можно сказать, что кластер прекращал работу. Это, безусловно минус такой конфигурации, ведь третий узел мог бы в этом случае взять нагрузку на себя, но зато мы уверены, что данные там в целости и сохранности и в самом крайнем случае мы можем вручную запустить его в работу в режиме одиночного сервера.


Как правильно указать IP адреса существующих в кластере нод при подключении новой?

Для этого есть 2 директивы:
[mysqld_safe]
wsrep_urls 

[mysqld]
wsrep_cluster_address 

Первая, если я правильно понял, была добавлена Galera сравнительно недавно для возможности указать сразу несколько адресов нод. Больше принципиальных отличий нет.

Значения этих директив поначалу у меня вызвали особую путаницу.
Дело в том, что многие мануалы советовали на первой ноде кластера оставлять пустое значение gcomm:// в wsrep_urls.
Оказалось, что это неправильно. Наличие gcomm:// означает инициализацию нового кластера. Поэтому сразу после старта первой ноды в ее конфиге нужно удалять это значение. В противном случае после рестарта этого узла вы получите два разных кластера, один из которых будет состоять только из первой ноды.

Для себя я вывел порядок конфигурации при запуске и перезапуске кластера (уже описанный выше более подробно)
1. Node A: запуск c gcomm://B,gcomm://C,gcomm://
2. Node A: удаление gcomm:// в конце строки
3. Nodes B,C: запуск с gcomm://A

NB: нужно обязательно указывать номер порта для Group Communication запросов, по умолчанию это 4567. То есть, правильная запись: gcomm://A:4567


Можно ли с неблокирующим xtrabackup в качестве SST method писать на ноду-донор?

Во время SST clustercheck на доноре будет выдавать HTTP 503, соответственно для HAProxy или другого LB, который использует эту утилиту для определения статуса, нода-донор будет считаться недоступной, равно как и нода, на которую делается трансфер. Но это поведение можно изменить правкой clustercheck, который по сути обычный bash-скрипт.
Это делается следующей правкой:

/usr/bin/clustercheck
#AVAILABLE_WHEN_DONOR=0
AVAILABLE_WHEN_DONOR=1 

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



Полезные ссылки


Percona XtraDB Cluster
XtraDB Cluster on mysqlperfomanceblog.com
Percona Community Forums
Percona Discussion Google group
Galera Wiki
Сергей @grobbelaar
карма
17,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (58)

  • 0
    Я правильно понимаю, что единственное отличие от Master-Slave заключается в том, что есть возможность быстрого перекючения ноды С в режим чтения-записи из режима только запись?
    Пробовали ли вы такой случай расматривать:
    1) Нода Б вылетела, нода С проработала сама час/сутки/двое/…
    2) Нода Б вернулась
    3) Произойдёт автоматическое восстановление? Есть несколько возможных проблем, например, если запись на ноду Б происходит не после того, как эта запись была добавлена на ноду А, то есть вероятность, что всплывут записи, о которых система не подозревала и начнутся проблемы индексов…
    • +2
      В описанном вами случае произойдет автоматическое восстановление ноды Б, точнее синхронизация содержащихся в ней данных либо с одной из живых нод, либо с конкретной нодой, если мы укажем это в конфиге.
      Пробовал, и неоднократно — все так и есть. Конечно, случались и некоторые глюки, часть из которых описана в статье.
    • 0
      насчет возможной проблемы из п.3 я пока еще думаю, пытаюсь понять как это возможно
      • 0
        1) INSERT/UPDATE… приходит на ноду Б
        2) нода Б выполняет запись в БД и записывает изменения в лог, в соответствии с которым, остальные ноды в последствии накатывают изменения себе
        3) пыщ-пыщ, нода Б вылетела, а лог никто не успел вычитать
        4) прошло время и нода Б стартует, у неё в базе одно записано, а ей синхронизируют дубли по ИД
        Этого можно избежать, если HAProxy будет запросы на запись слать всем серверам сразу самостоятельно или нода Б будет ждать подтвержения от ноды А о том, что данные она приняла и записала и только после этого записывать у себя, на ноде Б.
        • +2
          Тут другая схема, ноды не ходят друг к другу в лог за изменениями. Каждая транзакция перед физическим локальным коммитом передается на все удаленные ноды. Вот схема: www.percona.com/doc/percona-xtradb-cluster/_images/XtraDBClusterUML1.png
          • 0
            А, вот это меня и интересовало, спасибо.
      • 0
        Так percona синхронная репликация, проблем быть не должно.
      • 0
        >Мы намеренно решили использовать для LB и VIP те же железки, что и для кластера.

        А можно как то более подробно?

        Мне вот кажется логичным LB вынести не отдельные машины, которые будут заниматся балансировкой не только perona, но и например http трафика или чего-то еще.
        • 0
          В идеале да. Но 2 отдельные машины — это все-таки 2 отдельные машины, их тоже нужно просить у руководства. Возможно, когда веб-серверы у нас тоже будут жить в кластере, озаботимся этим вопросом.
          • 0
            Я сейчас как раз озабочен, как правильно сделать кластер из web :)
            Упирается все в нехватки знаний.
            Хочется некое единое место хранение, где хранится контент, или думать как все это хозяйтсво синхронихировать, при выходе новой версии сайта.
            • 0
              git, или банальные пакеты. Раскатывать тем же, чем рулите кластером (puppet, chef). Быстро, удобно, не зависит от количества серверов, легко делать prod-like среду для тестирования.
              • 0
                Да, но если кол-во серверов будет рости, с таким подходом будут определенные проблемы.
                На текущий момент у нас git.
            • 0
              Я тоже слежу за этой темой. Тут основная проблема в user-generated контент, где хранить его.
              Решение чаще всего в кластерных ФС, но эта тема посложнее MySQL кластера будет )
              • 0
                Нормальное кластерная ФС, эта ocfs2. Ну или платные решения.
                Есть еще распределенные ФС типа ceph и glusterfs, но они не кластырные :)
                • 0
                  ну и как, пробовали? годится для размазывания user-generated данных по серверам в синхронном режиме?
                  • 0
                    Пробывал что? если ocfs2, то мы используем для своих вещей. У ocfs2 есть асинхронный режим работы, но мы используем прямой доступ.

                    Если про ceph и gluster, то не использовал. Все у меня в стадии тетирования.
                    Хотя тут habrahabr.ru/post/157029/, человек использует glusterfs.

  • 0
    От себя добавлю:
    Мы перешли на перкона кластер с месяц назад. Переходили под чутким руководством саппорта. Платный саппорт оказался просто отличным.
    • 0
      Спасибо, будем знать.
    • 0
      А можно несколько вопросов?
      1) большой у вас кластер?
      2) пишите тоже на одну ноду в кластере?
      3) для балансировки что используете?
      • 0
        Завтра админа допрошу и в личку скину ответ.
  • 0
    Хорошая работа, раскрыто много нюансов.
    А с проблемой временной рассинхронизации данных не столкнулись?
    Вот тут описывал: habrahabr.ru/post/152969/#comment_5364691
    • 0
      >Почему рекомендуется писать на одну ноду из всех доступных в кластере? Ведь казалось бы, это противоречит идее мульти-мастер репликации.

      Вы пишите на 1 ноду?
      • 0
        именно
        • +1
          кажется понял, это вопрос не ко мне )
      • 0
        Да. И при последующем чтении данные не успевают реплицироваться на другую.
    • 0
      Нет, пока не натыкался. Попробую воспроизвести.
  • 0
    А можете прокомментировать пункт 3 отсюда? Можно ли расположить ноды в разных сетях (потенциально — в разных дц)? Тестировали производительность при наличии некоторой небольшой задержки (единицы миллисекунд) в линках между нодами?
    • 0
      1) падение по записи действительно есть, но на моих тестах все же не в 10 раз, как у автора, сейчас точно не могу сказать, продолжаю эксперименты, планирую покопаться в этом вопросе поглубже
      2) не вижу проблем в размещении в другом ДЦ
      3) пока нет, не думаю что для нас узким местом станет сеть, вернее думаю мы найдем по пути много других граблей, пока дойдем до сети
      • 0
        Ой, простите, пункт 2 конечно же интересовал, в контексте разных ДЦ. Последний мой вопрос — туда же, т.е. на сколько деградирует синхронная запись при увеличении задержки канала между нодами. Есть ощущение, что именно это может стать узким местом.
        • 0
          Ну в случае с разными ДЦ канал наверняка станет узким местом №1.
          Я, кстати, тоже в ближайшее время буду пробовать это, просто ради интереса. Отпишусь.
  • 0
    а mysql_proxy не рассмотривали в качестве балансировщика?
    • 0
      Поначалу приглядывался, но когда понял что HAProxy умеет гораздо больше, рассматривать перестал.
      • 0
        принято, спасибо
        пригляжусь к HAProxy
  • 0
    У меня похожие перезды еще в процессе. Я делаю мастер-мастер(active-passive) из стандартных MySQL-5.5. По факту так же через хапрокси и 200-503 чекер. Отмечу несколько пунктов, которые могут пригодиться.
    1)Пока непонятно как HAProxy себя поведет на середине транзакции, если автоматически бекенд первого мастера выключится и трафик польется в другой. А если их туева хуча?
    2) Пункт #1 весьма важен, т.к. при такой схеме очень удобно делать например запланированые альтеры. А на больших таблицах это проблема.
    3)Всегда чекать консистентность баз, т.к. при малейшем нарушении работы слейвов в какую то сторону получаем недозапись в одной из баз или что-то подобное. Благо pt-table-sync спасает, но не всегда, foreign key и missing index привет.
    4)В амазоне VIP так легко не получится, там свой велосипед.

    Может по завершению тоже напишу статью, если будут время и читатели:)
    • 0
      Я в очередь из читателей! )

      Уточнение: а что, вы ALTER TABLE в транзакции оборачиваете? или я неправильно понял?
      Мне кажется одиночный ALTER на большой таблице при потере ноды HAProxy уже никуда не будет перенаправлять.

      Какой вам видится чекалка консистентности, в каком виде?
      • 0
        Ну кроме моего альтера туда будет литься куча трафика продакшна. Например, как хорошо делать альтер, безболезненно на больших таблицах при мастер-мастер:
        -Делаем альтер на мастер2, ждем завершения.
        -Как только он прошел репликация начинает его выполнять на мастер1
        -В это время нужно переключить трафик на мастер2, что бы лоченая таблица алтером не создавала проблем юзерам.

        Но, в это же время на мастер1 льется трафик, и что будет когда вы сознательно выставите 503 в чекалке, что бы хапрокси переключил трафик? Т.е. отлично, что трафик новый уйдет на мастер2, и тут вы спокойно дождетесь альтера, но те query, что были кроме альтера останутся. Вот тут пока непонятно насколько плачевно хапрокси оборвет эти коннекты, т.к. не о каких коммитах и т.д. он знать не знает.
        В этом случае более привлекательным выглядит как раз mysql-proxy, но у него есть свои минусы.

        Чекалка есть и вполне работает — это pt-table-checksum. И более того по сравнению со старым maatkit percona сделала много хороших изменений в этом пакете очень полезных скриптов:)
  • 0
    Кстати, вчера вышел новый релиз Percona Xtradb Cluster:
    www.mysqlperformanceblog.com/2012/11/15/announcing-percona-xtradb-cluster-5-5-28-23-7/
  • 0
    Кстати, человек которому дал статью, обратил внимание, что нету примера конфигурации keepalived. Человеку помог настроить, но все же можно было бы добавить в статью?
  • 0
    поправте keepalived

    Убежала v

    >rrp_script chk_haproxy {
    vrrp_script chk_haproxy {
    • 0
      поправил, спасибо
      • 0
        Еще кстати вопрос.

        >vrrp_instance VI_1 {
        > interface eth0
        > state MASTER
        >

        Это можно проигнорировать, но не лучше ли на другой машине указать backup :?
        Хотя по сути, это не принцепиально.
  • 0
    У меня тут вопрос возник. Тут вы указываете, что node a знает о всех нодах.
    node b,c знает только о node a.

    те если упадет node a, то все встало? в чем смысл? (ну кроме как распределить нагрузку)
    • 0
      Присоединившись к кластеру, используя любую из уже существующих нод, присоединяемая нода (JOINER) «узнает» обо всех нодах в кластере, а не только о DONOR-е. Это очень легко можно проверить, почитав error_log на JOINER-e.

      В описанной здесь конфигурации проблемное место в том, что если упадет А, потом B и C, то все встанет, пока мы не поднимем A. На самом деле я уже почти отказался от схемы с Reference Node, когда всего 3 ноды в кластере, снимать нагрузку полностью с одного из узлов слишком расточительно. Кстати, мы еще не запустили PXC в продакшен, планирую скоро продолжить цикл статей о том, на какие грабли наступили и как преодолели.
      • 0
        > На самом деле я уже почти отказался от схемы с Reference Node, когда всего 3 ноды в кластере
        И что выбрали?

        у меня на PXC просто время появилось поковырять. Три машины уже поднял. Буду дальше
        Использую в качестве точки взлета статью www.percona.com/doc/percona-xtradb-cluster/howtos/3nodesec2.html
        Там как раз используются все 3 узла.

        Цикл ждем. По крайне мере я точно жду :)
        • 0
          Остановился на том, что все 3 ноды доступны на чтение, а запись только на одну, рулит этим HAProxy.

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

          Рад что у вас появилось время на PXC, надеюсь что будет возможность поделиться мнениями.
          • 0
            Ну я пока что пришел к этой же схеме.

            HAProxy раскидывает чтение по кластеру, запись на 1 из кластеров. Если он падает, пишем в другой.

            Правда я HAProxy сделал на отдельных двух машинах с 4 ip адресами.
            • 0
              Сам по себе haproxy распарсивать запросы чтение/запись не умеет. У Вас приложение умеет обращаться на чтение/запись к разным серверам, или Вы вносили изменения в код и для указывали разные сервера для разных запросов.
              • 0
                HAProxy не умеет этого. Делают обычно разными портами, один на чтение, другой на запись.
                • 0
                  Это понятно, но в таком случае веб-движок должен отправлять запросы на чтение на порт 3306 (например), а на запись на 3307?
                  • 0
                    порт 3306 (например), а на запись на 3307?

                    Да, имено такова стандартная практика.
                    Приложение должно уметь самостоятельно разделять запросы.
                • 0
                  Кстати, а не подскажете или может быть ткнуть что почитать.

                  keepalived на одной машине с HAproxy, keepalived поднят виртуальный интерфейс, но запросы на percona с haproxy приходят с реальных ip, что не совсем хорошо.

                  Может быть есть способ как то сказать haproxy отправлять ip виртуальный на percona?
              • 0
                От себя добавлю, мы ушли от этого. Все как то и так прекрасно работает.
  • 0
    > возможность коммерческой поддержки от Percona
    используете?
    а чем не устраивает коммерческая поддержка от Oracle?
    • 0
      пока не пользуемся
      как только поймем, что готовы запустить кластер в продакшен, скорее всего закажем поддержку
      от руководства принципиальное согласие получено

      у Oracle нет версии mysql сервера с wsrep-хуками и поддержкой Galera

      А вообще я лично никакой платной поддержки продуктов такого уровня не пробовал, не с чем сравнить.
      Будет первый опыт, если повезет.
      • 0
        хорошо бы в последствии услышать об этом информаию и понять на сколько она нужна.
        • 0
          непременно
  • 0
    Непонятно, откуда у вас взялся порт 33061 :) Остатки игр с кофигами?
  • 0
    Какой объем базы?
    Какое количество транзакций/запросов в сутки?
    Прошло почти 1,5 года — были ли сбои? Если да — расскажите о них и как решали.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.