Вы абсодютно правы, Read-Through "обертка" над Cache-Aside. Но у них есть отличие - Cache-Aside, приложение само проверяет кеш. Если данных нет, приложение идет в БД, получает данные, кладет их в кеш и использует. При Read-Through, приложение всегда обращается только к провайдеру кеша. Если данных в кеше нет, то провайдер идет в БД, загружает данные, сохраняет их у себя и возвращает приложению. Приложение как бы не знает, откуда пришли данные – напрямую из кеша или их только что подгрузили из БД. Других паттернов именно для заполнения кеша при чтении не выделяют.
Такой бэкап на новый мастер будет без плясок. И GTID значительно упрощает настройку репликации от этого нового мастера к другим репликам. Но, если реплика отставала на момент бэкапа, самые последние транзакции с предыдущего мастера в бэкап не войдут.
Насчет фильтрации прямо на мастере – технически такая опция есть (binlog-do-db), но не советую её использовать. Потому что, если транзакция затрагивает несколько баз, она может записаться в лог не полностью, и с GTID могут быть сложности. Лучше и правильнее делать как вы и описали: мастер пишет все изменения, а уже на реплике вы настраиваете фильтры (replicate-do-db и подобные), чтобы она применяла только то, что нужно.
Да, такая возможность есть - Multi-Source Replication. На одной реплике вы можете настроить несколько "каналов" репликации, каждый будет тянуть данные со своего мастера. Это удобно для сбора данных из разных источников (с разных шардов) в одном месте для аналитики или бэкапов.
то есть я ответил
Потому что наш бизнес и платформа достигла такого масштаба, что продолжать на монолите будет слишком сложно и неэффективно.
Вы абсодютно правы, Read-Through "обертка" над Cache-Aside. Но у них есть отличие - Cache-Aside, приложение само проверяет кеш. Если данных нет, приложение идет в БД, получает данные, кладет их в кеш и использует. При Read-Through, приложение всегда обращается только к провайдеру кеша. Если данных в кеше нет, то провайдер идет в БД, загружает данные, сохраняет их у себя и возвращает приложению. Приложение как бы не знает, откуда пришли данные – напрямую из кеша или их только что подгрузили из БД. Других паттернов именно для заполнения кеша при чтении не выделяют.
Согласен с вами, для простых сценариев "сначала в БД, потом в кеш" проще сделать и он будет более безопасным.
Такой бэкап на новый мастер будет без плясок. И GTID значительно упрощает настройку репликации от этого нового мастера к другим репликам. Но, если реплика отставала на момент бэкапа, самые последние транзакции с предыдущего мастера в бэкап не войдут.
Насчет фильтрации прямо на мастере – технически такая опция есть (binlog-do-db), но не советую её использовать. Потому что, если транзакция затрагивает несколько баз, она может записаться в лог не полностью, и с GTID могут быть сложности. Лучше и правильнее делать как вы и описали: мастер пишет все изменения, а уже на реплике вы настраиваете фильтры (replicate-do-db и подобные), чтобы она применяла только то, что нужно.
Да, такая возможность есть - Multi-Source Replication. На одной реплике вы можете настроить несколько "каналов" репликации, каждый будет тянуть данные со своего мастера. Это удобно для сбора данных из разных источников (с разных шардов) в одном месте для аналитики или бэкапов.
MaxScale лучше использовать для MariaDB - они его и разрабатывают. Для MySQL лучше выбрать ProxySQL, но всё зависит от требований проекта.
еще рекомендую - Database Internals Петрова
Теперь любой материал будут считать, что он от нейронок - https://antigpt.ru, https://aidetectorwriter.com/ru.
Лучший автор на всём Хабре! Читаю только её. Спасибо за статью. Желаю всем здоровья и счастья!