Master-master vs master-slave архитектура базы данных? - PullRequest
98 голосов
/ 17 сентября 2010

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

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

  • подчиненные

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

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

Вопросы:

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

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

  3. Является ли выбор одного из них критическим фактором для тщательного рассмотрения?

Ответы [ 2 ]

76 голосов
/ 25 июля 2014

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

  1. Репликация главный-подчиненный
  2. Мастер-Мастер Репликация
  3. MySQL Cluster

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

1. Репликация главный-подчиненный

Плюсы

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

Против

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

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

Плюсы

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

Против

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

3. MySQL Cluster

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

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

Плюсы

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

Против

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

75 голосов
/ 17 сентября 2010

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...