Настройка бэкэнд-db для приложения с географически разнообразными пользователями

Question

Встроенное программное обеспечение, в котором я работаю, подключается непосредственно к серверу mysql здесь, в нашем офисе, через наш центр разработки (XPO). Производительность отличная.

Мы открываем еще один офис ... по пересеченной местности. Производительность: не очень. Требование состоит в том, чтобы программное обеспечение было столь же отзывчивым в обоих офисах, как и в этом офисе, и чтобы данные из одного офиса были доступны другому «в режиме реального времени».

Что-то в этом масштабе совершенно для меня совершенно. Я не прочь привлечь консультанта, который раньше делал что-то подобное, но сначала хотел бы получить хорошее представление о вариантах. Я уверен, что это обычная ситуация.

Репликация хорошая идея? Это достаточно быстро? достаточно стабильный?

Существуют ли шаблоны разработки, которые решают такую ​​ситуацию, если репликация не будет работать?

Heck, я даже не знаю, как помечать, так что если кто-то знает лучше ... пожалуйста, не стесняйтесь повторно тег

EDIT> Подробная информация о данных

Я думаю, по сравнению с некоторыми корпоративными программами, мы не переносим много данных. Программное обеспечение управляет учетными записями клиентов, встречами и т. Д., И каждый пользователь работает примерно на 2-5 отдельных учетных записей в минуту (50 пользователей в настоящее время, 200-400 после запланированного расширения), каждый раз обновляя данные.

В режиме реального времени вступает в игру, когда кто-то в офисе A создает встречу для кого-то в офисе B, который, в идеале, должен немедленно просмотреть свои данные (< 2 минуты). Тем не менее, каждая запись обычно только мутируется максимум 5 раз в день. Но это только то, что я подозреваю; На самом деле у меня нет статистики использования.

Answer 1

Вы не можете использовать асинхронную репликацию в обоих направлениях без создания конфликтов репликации, которые невозможно разрешить и нарушить.

Таким образом, ваш очевидный выбор заключается в использовании разделения чтения/записи - приложение делает некритические чтения из локальной базы данных (только для чтения) и направляет все записи в мастер. Недостатком этого является то, что это будет означать, что вы не можете сразу прочитать свои собственные записи.

Репликация MySQL не идеальна и требует определенных усилий для настройки и непрерывного мониторинга для поддержания; вы должны часто проверять, что данные одинаковы для подчиненных. Некоторые запросы реплицируются неправильно; вам нужно будет понять их и избежать.

Answer 2

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

Имея данные в реальном времени, зависит от данных, я пропустил подробное описание, например, сколько данных мы говорим о каждом запросе (то есть о том, насколько велики объекты), насколько быстро вы подключаетесь к Интернету (может быть, шея бутылки?), это сервер mysql и вся инфраструктура, между которыми вы хорошо управляете? Как статические/динамические данные, если данные в реальном времени становятся мутированными один раз в день, или они становятся мутированными по zillion раз в день, важно для «решения»