Каковы недостатки использования Galera Cluster вместо Master / Slave Replication?

Каковы недостатки использования Galera Cluster вместо обычной репликации Master / Slave? 0 задержек ведомого Galera, синхронная репликация и отсутствие единой точки отказа кажутся очень привлекательными, тогда почему кластер Galera не так распространен?

— Сэм
источник

Ответы:

Потому что, как и любая другая оптимизация, она не подходит для любой рабочей нагрузки.

Galera может быть перегружена высокой скоростью транзакций или когда транзакции обновляют много строк. Это также может привести к задержкам приложений в COMMIT, поскольку кластер синхронизирован.

Galera также не обновляет другие узлы синхронно. Он просто передает рабочие наборы синхронно. Таким образом, это похоже на стандартную репликацию в полусинхронном режиме. Поэтому существует небольшая вероятность чтения устаревших данных из другого узла кластера. Есть опция, которую вы можете установить, чтобы заставить SELECT ждать, пока очередь рабочих наборов не обновит базу данных, но это означает, что у вас есть задержки в SELECT. И даже шанс получить тупик на SELECT, который кажется нелогичным.

Galera великолепна, но не универсальна для всех. Есть все еще веские причины использовать асинхронную репликацию.

— Билл Карвин
источник

Спасибо, Билл, кстати, я некоторое время читаю твои презентации по Percona.

— Сэм

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

— RolandoMySQLDBA

Методы @RolandoMySQLDBA SST, такие как xtrabackup, точно избегают блокировки донора. Хотя это правда, что в любом случае донор будет иметь ухудшенную производительность, если база данных велика.

— января

@jynus, проблема не в блокировке на узле- доноре , а в том, что принимающий узел находится в автономном режиме и недоступен для любых запросов во время выполнения SST. Поэтому, если вы используете кластер для балансировки нагрузки запросов, запросы, которые отправлялись бы на принимающий узел, должны отправляться на другие узлы до тех пор, пока не будет выполнен SST.

— Билл Карвин

В случае, если кто-то еще ищет, опция, на которую ссылается Билл, wsrep_causal_reads... устанавливается на ON, SET GLOBAL wsrep_causal_reads = 'ON';чтобы получить выборки, чтобы дождаться, пока все наборы записи не будут выполнены.

— Люк Казинс

Некоторые недостатки Galera включают в себя:

Поддержка механизма хранения: ограничена InnoDB / XtraDB (плюс экспериментальная поддержка MyISAM)
Поддержка ОС: только Linux / Unix-подобные Oses

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

По умолчанию (Total Order Isolation) операции DDL блокируют весь кластер до завершения
Каждая таблица должна иметь явный первичный ключ, один или несколько столбцов
Блокировка: некоторые типы явной блокировки не поддерживаются.

Для получения дополнительной информации см. Подробности в Codership (и здесь о блокировке DDL), MariaDB и Percona .

РЕДАКТИРОВАТЬ: Обратите внимание, что некоторые утверждают, что тесно связанные кластеры базы данных, такие как Galera, не должны иметь географически распределенных узлов из-за проблем, связанных с присущей ненадежности сетевого уровня. Вместо этого в этих случаях должны использоваться асинхронные решения. См. Как не использовать MySQL High Availability: географическое распределение узлов с использованием Galera-репликации . Тем не менее, блог Galera утверждает, что (2015):

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

— dbdemon
источник