Мастер-мастер против архитектуры базы данных "ведущий-ведомый"?

Ответ 1

Мы торгуем наличием, согласованностью и сложностью. Сначала обратиться к последнему вопросу: имеет ли это значение? Да очень! Выбор, касающийся того, как ваши данные должны управляться, абсолютно фундаментален, и нет "лучшей практики", уклоняющейся от решений. Вы должны понимать ваши конкретные требования.

Существует фундаментальное напряжение:

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

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

Мастер-мастер: хорошо, если вы можете заставить его работать, то он, кажется, предлагает все, ни единой точки отказа, каждый может работать все время. Проблема в том, что очень трудно сохранить абсолютную согласованность. Подробнее см. статью в википедии.

Википедия, похоже, хорошо описывает преимущества и недостатки

Преимущества

• Если один мастер выходит из строя, другие мастера будут продолжать обновлять базы данных.

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

Недостатки

• Большинство систем репликации с несколькими ведущими устройствами являются только непротиворечивыми,  т.е. ленив и асинхронно, нарушая свойства ACID.

• Ожидаемые системы репликации сложны и вводят некоторые  латентность связи.

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

Ответ 2

При исследовании различных архитектур баз данных. Я собрал хорошую информацию, которая может быть уместна для кого-то другого, исследующего в будущем. Я наткнулся на

• Репликация ведущего-ведомого
• Репликация Master-Master
• MySQL Cluster

Я решил согласиться на использование MySQL Cluster для моего варианта использования. Однако, пожалуйста, см. Ниже различные плюсы и минусы, которые я скомпилировал

1. Репликация ведущего-ведомого

Доводы

• Аналитические приложения могут считывать с ведомого (-ов) без воздействия на главный
• Резервные копии всей базы данных относительно не влияют на мастер
• Ведомые устройства могут быть отправлены в автономном режиме и синхронизированы с сервером без простоя.

против

• В случае сбоя, раб должен быть повышен до уровня хозяина, чтобы занять его место. Нет автоматического переключения после сбоя.
• Время простоя и, возможно, потеря данных при сбое мастера
• Все записи также должны быть сделаны мастеру в проекте "ведущий-ведомый"
• Каждое дополнительное подчиненное устройство добавляет некоторую нагрузку на мастер, поскольку двоичный журнал должен быть прочитан, а данные скопированы на каждый подчиненный
• Возможно, потребуется перезапустить приложение.

2. Репликация Master-Master

Доводы

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

против

• Непротиворечивый
• Не так просто, как master-slave для настройки и развертывания

3. MySQL Cluster

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

Подробнее см. MySQL Cluster 101

Доводы

• (Высокая доступность) Нет единой точки отказа
• Очень высокая пропускная способность
• 99,99% времени безотказной работы
• Авто-Sharding
• Отзыв в режиме реального времени
• Операции on-line (изменения схемы и т.д.)
• Распространенные записи

против

• См. известные ограничения

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