Comments 13
1.1.1.1 — это IP-адрес публичного DNS-сервера CloudFlare. Просто вспомнилось.
Знаете, нам очень зашёл galera cluster на mariadb. Минусы, конечно, есть: master-master обязан считать транзакцию завершенной только тогда, когда ее совершили все ноды, однако конкретно у нас сеть (основной источник латентности) в порядке, и потому проблем не доставляет. Зато все остальное… Голова совершенно не болит. Никто не мешает остальных мастеров использовать как read only, не внося при этом конфликтов данных уровня кластера. Вот maxscale для балансировки вносил проблемы, было дело. Сейчас этот кластер собран на банальном keepalived и одну реальную аварию (не тесты) прекрасно пережил. Рекомендую, если у вас условия позволяют. Как готовить — статьи на хабре есть.
master-master обязан считать транзакцию завершенной только тогда, когда ее совершили все ноды
А если одна из нод выйдет из строя, то что в этом случае произойдёт?
Ничего не произойдёт. Если keepalived публиковал её как мастера, то адрес переедет на другую ноду. Они все мастер. Когда нода поднимется, произойдёт full state transfer (если остановка была длительной), либо incremental state transfer, если остановка была недолгой (патч-корд по ошибке выдернули). А потом keepalived вернёт адрес на место.
Основное уловие: в работающем состоянии — нечётное число нод, либо «наблюдатель» при чётном числе нод, во избежании возникновения т.н. split brain состояния. Наблюдатель — galera arbitrator, ресурсов для работы практически не требует.
Если вопрос был про транзакцию — она откатится, вернув ошибку на уровень приложения, которое должно будет её повторить. Также есть настройка, сколько раз пытаться закоммитить транзакцию (3 по-умолчанию). Как правило, до ошибок уровня приложения не доходит: со второй попытки транзакция падает в «усечённый» кластер.
Основное уловие: в работающем состоянии — нечётное число нод, либо «наблюдатель» при чётном числе нод, во избежании возникновения т.н. split brain состояния. Наблюдатель — galera arbitrator, ресурсов для работы практически не требует.
Если вопрос был про транзакцию — она откатится, вернув ошибку на уровень приложения, которое должно будет её повторить. Также есть настройка, сколько раз пытаться закоммитить транзакцию (3 по-умолчанию). Как правило, до ошибок уровня приложения не доходит: со второй попытки транзакция падает в «усечённый» кластер.
master-master обязан считать транзакцию завершенной только тогда, когда ее совершили все ноды
Я не уверен как реализовано в MariaDB Galera, но в классическом Galera Cluster и Percona GC это не так. Каждая транзакция валидируется на всех нодах при коммите на отсутствие конфликтов, а репликация самих изменений выполняется уже после коммита.
Про сравнение galera cluster и InnoDB Cluster рекомендую прочитать комментарии под постом lefred.be/content/mysql-group-replication-is-sweet-but-can-be-sour-if-you-misunderstand-it. Если кратко, то они немного про разное. galera пытается сделать вид что она синхронная и это почти всегда удается, кроме некоторых крайних случаев, за счет производительности. mysql говорит, раз формальной синхронности нет, не будем и пытаться зато выдадим производительность, как следствие при неудачных обстоятельствах ноды могут разбежаться на тысячи транзакций. И ваше приложение должно быть к этому готово, т.е. данные всегда консистентны, но не всегда свежи.
Если прямо нужен честный, межнодовый read_your_own_writes можно посмотреть на MySQL NDB Cluster и список его ограничений появившихся не на пустом месте.
dev.mysql.com/doc/refman/5.7/en/mysql-cluster-limitations.html
Если прямо нужен честный, межнодовый read_your_own_writes можно посмотреть на MySQL NDB Cluster и список его ограничений появившихся не на пустом месте.
dev.mysql.com/doc/refman/5.7/en/mysql-cluster-limitations.html
Sign up to leave a comment.
Собираем InnoDB cluster из mysql 5.7 на centos 7