@boss_lexa

Синхронная репликация: MySQL NDB Cluster, Percona XtraDB, MariaDB Galera, mysql group replication (innodb cluster). В чем отличия?

Есть 3 идентичных VPS на SSD в разных ДЦ в Москве, пинг между ними до 5мс
Нужна синхронная репликация чтобы было не менее 2ух копий данных.
Нужно переживать падение 1 сервера из 3, если 2 сервера упали - режим только чтение.
Писать и читать будем только с одного сервера.

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

В чем основные различия озвученных в заголовке решения?
Как они ведут себя при падении 1-го сервера?

Если кластер узнал о падении 3-го сервера только во время записи (не получили от него подтверждения) пройдет запись? Или запись будет отклонена и потом 3-ий сервер по таймауту выходит из списка кластера, и только потом начнут проходить записи?

У Percona как я понял преимущество в их тюнинге движка + утилита копирования.

Mysql group replication (innodb cluster) относительно недавно появился, но привлекает в нем протокол консенсуса paxos, Есть положительный опыт с ним?
  • Вопрос задан
  • 1477 просмотров
Пригласить эксперта
Ответы на вопрос 2
@vlarkanov
Сравнивать все вышеизложенное не могу, т.к. не все пробовал, поделюсь схемой которая год в проде.

Используется Galera-кластер на базе Percona Xtradb. В нем две физические ноды (база живет на SSD в mdadm RAID1), разнесенные по городам (~200км) + арбитратор на виртуалке (нужен для кворума т.к. кластер не должен содержать четное кол-во нод). Любой INSERT\UPDATE\DELETE апрувится всеми нодами и только тогда считается закоммиченым. Запросы разруливаются с помощью живущего на виртуалке прокси Maxscale. Одна из нод является мастером, на нее идут запросы на запись, вторая - слейв, получает запросы на чтение. В случае падения одной из нод вторая автоматически берет на себя ее функции (точнее, сами ноды о своих ролях знать не знают, рулит процессом Maxscale). Когда нода поднимается, она всасывает в себя произошедшие с момента падения изменения IST (Incremental State Transfer) если объем произошедших изменений не превышает размер galera cache (просто файл, размер указывается в конфиге mysql) или, в худшем случае загружается вся база. При этом нода-донор продолжает обрабатывать запросы клиентов как ни в чем не бывало. Присоединившаяся нода становится слейвом, т.к. смена мастера приводит к обрыванию соединений и ее лучше делать вручную, ночью.

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

Если есть вопросы - задавайте, постараюсь ответить.
Ответ написан
@boss_lexa Автор вопроса
Судя по следующей презентации Percona выигрывает
https://www.slideshare.net/Grypyrg/percona-xtradb-...

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

Но при этом указано что group replication не рекомендуется для WAN.

Еще статья в пользу Percona опять же
https://www.percona.com/blog/2017/02/24/battle-for...
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы