|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Всем привет!
1)Хочу сделать Galera Cluster на 3 серверах c MariaDB 10.1, каналы между нодами 1Gb. Но есть дополнительная задача - как-то связать по репликации еще несколько MySQL/MariaDB серверов на крайне медленных каналах с одним из MariaDB серверов в кластере. Не включать в кластер, а просто реплика 1 базы (Master-Master) удаленного MariaDB c одним из серверов, которые работают в кластере. Есть ли у кого-нибудь идеи на этот счет? Данных в принципе не много будет, но желательна двухсторонняя связь. Пока в голову приходят только идеи со скриптами через крон..
2)Достаточно одного арбитратора для 3 серверов, или же арбитратор нужен на каждом сервере кластера? Если будет несколько арбитраторов, то будут ли они в автомате договариваться между собой в какой из 3 серверов писать а из каких только чтение, или это будет сумбур?
Неактивен
1. Насколько я понимаю, кластер пишет консистентные бинлоги в стандартном формате, поэтому не должно возникнуть никаких проблем с репликацией. Мастер-мастер, впрочем, реализовать сложно (не только в галере), потому что иначе будут потенциальные разъезжания из-за архитектуры. По возможности, пишите в один мастер.
2. Арбитр не выбирает мастер, он только защищает от split brain. Для записи в один мастер Вам прийдется найти какое-то стороннее решение (обычно используют haproxy).
Неактивен
Функции арбитра я теперь осознал. Почему-то раньше думал, что Haproxy,Maxscale это и есть то, что называется арбитром. Тогда вопрос, в случае 3 серверов mariadb, garbd нужен четвертым? Или он уже лишний?
И по первому вопросу я все равно до конца не уловил сути. Попробую перефразировать. Можно не включать какую-то из баз в Galera Cluster? То есть исключить ее из Galera Cluster, но сделать отдельную реплику только этой базы с каким-то другим MySQL сервером, не входящим в Galera Cluster?
Спасибо за ответ!
Неактивен
Четвертый не нужен, нужно, чтобы в кластере было нечетное количество узлов, тогда всегда можно будет выбрать часть кластера, которая консистентна, и часть, которая не должна принимать записи на себя.
На четырех узлах Вы можете построить такую репликацию, например:
[A B C] -> D
Тут узлы A, B и C включены в кластер, каждый из узлов пишет бинлог, который реплицируется и применяется на отдельностоящем узле D. Конкретно выбирать позицию при падении отдельных узлов из кластера сложно, поэтому в этом месте можно использовать gtid или придумать какую-то другую магию на базе номера транзакции (в галере он эквивалентен gtid).
Неактивен
Спасибо! В основном понятно, но вот по поводу 4 узла так не получится, чтобы лить туда binlog, там слабый канал, а бинлоги кластера очень большие. Да и изменения в остальных базах 4-го узла не касаются, ему нужна только конкретная база и только с ней он будет работать. Буду думать в сторону скриптов наверное..
Неактивен
Можно сделать промежуточный узел на той же площадке, на котором использовать опцию replicate-do-db (она не исключает копирование бинлогов), а с него уже реплицировать на 4-ый.
Неактивен
Как вариант, можно попробовать использовать binlog-do-db на кластере, чтобы писать в бинлоги только нужный поднабор данных.
Неактивен
Страниц: 1
