Comments 7
Спасибо. В контексте управления Failover был упомянут такой инструмент как ProxySQL, но еще есть MaxScale - можете что-нибудь про него сказать?
Описание
Классическая схема: мастер пишет события в бинарный лог (binlog), слейвы (реплики) периодически читают этот лог и применяют изменения.
Плюсы
Максимальная производительность: мастер не ждёт подтверждения от реплик.
Простота настройки: встроена «из коробки».
Гибкость: можно добавлять/удалять реплики на-лету.
Минусы
Потеря данных: при крахе мастера незаписанные в binlog транзакции теряются, а неподтянутые слейвы «отстают».
Нет гарантий консистентности: чтения на репликах могут «прыгать» по времени.
Когда подходит
Отказоустойчивость важна, но некритична потеря нескольких последних секунд данных.
Пара вопросиков (возможно плохо искал, но не нашел)
При "классической схеме" мастер отправляет на слейв все изменения из всех баз. А на слейве я отфильтровываю только нужную мне БД. А можно фильтр переместить на мастер и отправлять только данные одной БД? И что для этого нужно, если эта схема не реализуется на обычном Mysql?
И в продолжении. А можно на один слейв отправлять реплики с нескольких мастеров? Можете подсказать где почитать если "да"
Насчет фильтрации прямо на мастере – технически такая опция есть (binlog-do-db), но не советую её использовать. Потому что, если транзакция затрагивает несколько баз, она может записаться в лог не полностью, и с GTID могут быть сложности. Лучше и правильнее делать как вы и описали: мастер пишет все изменения, а уже на реплике вы настраиваете фильтры (replicate-do-db и подобные), чтобы она применяла только то, что нужно.
Да, такая возможность есть - Multi-Source Replication. На одной реплике вы можете настроить несколько "каналов" репликации, каждый будет тянуть данные со своего мастера. Это удобно для сбора данных из разных источников (с разных шардов) в одном месте для аналитики или бэкапов.
MySQL репликация: проблемы, решения, практические рекомендации