Архитектура базы данных мастер-мастер и мастер-подчиненный?

Я слышал о двух типах архитектур баз данных.

• мастер-мастер

• ведущий-ведомый

Разве master-master не более подходит для сегодняшней сети, потому что он похож на Git, у каждого модуля есть полный набор данных, и если один из них выйдет из строя, это не имеет особого значения.

Мастер-подчиненный напоминает мне SVN (который мне не нравится), где у вас есть один центральный блок, который обрабатывает вещи.

Вопросы:

1. Каковы плюсы и минусы каждого из них?

2. Если вы хотите иметь локальную базу данных на своем мобильном телефоне, например, iPhone, какая из них вам больше подходит?

3. Является ли выбор одного из этих факторов решающим фактором, который следует тщательно рассмотреть?

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

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

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

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

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

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

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

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

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

Недостатки

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

• Системы активной репликации сложны и вызывают некоторую задержку связи.

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

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

1. Репликация Master-Slave
2. Мастер-Мастер Репликация
3. Кластер MySQL

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

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

Pros

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

Cons

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

2. Репликация мастер-мастер

Pros

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

Cons

• Слабо последовательный
• Не так просто, как master-slave настроить и развернуть

3. Кластер MySQL

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

См. MySQL Cluster 101 для получения дополнительной информации.

Pros

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

Cons

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

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