Comments 4
Я бы категорически не рекомендовал использовать эту схему — отправьте 2 запроса подряд, которые меняют одни и те же данные несовместимым образом, и все — репликация встала. После того, как репликация встанет, чинить такой мастер-мастер будет тем сложнее, чем дольше продолжается то, что запросы раскидываются по разным мастерам — если приложение заранее к такому не подготовлено, количество конфликтов у вас будет продолжать расти.
Если вам не слишком критична latency записи, я бы рекомендовал решения с синхронной репликацией — например, Galera Cluster или Percona XtraDB Cluster.
Если же скорость выполнения insert/update критична, то лучше использовать master-slave (который можно сконфигурировать и как master-master, чтобы восттанавливаться из слейва было проще). В этом случае переключение с мастера на слейв нужно делать вручную, для сохранения консистентности данных
Если вам не слишком критична latency записи, я бы рекомендовал решения с синхронной репликацией — например, Galera Cluster или Percona XtraDB Cluster.
Если же скорость выполнения insert/update критична, то лучше использовать master-slave (который можно сконфигурировать и как master-master, чтобы восттанавливаться из слейва было проще). В этом случае переключение с мастера на слейв нужно делать вручную, для сохранения консистентности данных
+9
Спасибо за рекомендации. Попробуем применить.
0
Например можно выставить в настройках HA-proxy активный сервер и пассивный.
Тогда все запросы пойдут на одну ноду, но если что — то вот вам резервная нода.
Главное следить во все глаза за статусом обоих мастеров :)
Тогда все запросы пойдут на одну ноду, но если что — то вот вам резервная нода.
Главное следить во все глаза за статусом обоих мастеров :)
0
Sign up to leave a comment.
Балансировка MySQL