Сравнение архитектуры высокой доступности MySQL

MySQL

Архитектуры высокой доступности MMM, MHA и MGR имеют следующие общие черты:

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

MMM

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

image-20190402160607794

Необходимые основные ресурсы:

ресурс количество инструкция
основная БД 2 Первичная-основная репликация для активного-резервного режима
из БД 0~N единиц N подчиненных серверов можно настроить по мере необходимости
айпи адрес 2n+1 N - количество серверов MySQL
следить за пользователями 1 Пользователь MySQL, который следит за состоянием базы данных (репликация)
прокси-пользователь 1 Используется агентом MMM для изменения состояния read_only

Шаги аварийного переключения:

  • Операции на подчиненном сервере
    • Завершите восстановление журнала, которое было реплицировано на исходном мастере.
    • Настройте новый Master, используя команду member Master
  • Работа на главном сервере
    • отключить только чтение
    • Перенести VIP на новый главный сервер

преимущество:

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

недостаток:

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

Применимая сцена:

  • И чтение, и запись требуют высокой доступности
  • Репликация на основе точки журнала

MHA

image-20190402162734119

Требуются ресурсы:

ресурс количество инструкция
основная БД 2 Первичная-основная репликация для активного-резервного режима
из БД 2 ~ N комплектов N подчиненных серверов можно настроить по мере необходимости
айпи адрес n+2 N - количество серверов MySQL
следить за пользователями 1 Пользователь MySQL, который следит за состоянием базы данных (репликация)
скопировать пользователя 1 Пользователь, используемый для настройки репликации MySQL

MHA использует мастер, выбранный из слейва, отказоустойчивость:

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

преимущество:

  • В дополнение к поддержке репликации точек журнала MHA также поддерживает метод GTID
  • По сравнению с MMM, MHA попытается восстановить старый двоичный журнал со старого Мастера, но это может не каждый раз быть успешным. Если вам нужно меньше сценариев потери данных, рекомендуется использовать архитектуру MHA.

недостаток:

MHA необходимо разработать собственные сценарии VIP-трансферов.

MHA отслеживает только состояние Master и не отслеживает состояние Slave.

MGR

MGR — это подключаемый модуль репликации, основанный на существующей архитектуре MySQL, который может реализовать несколько мастеров для изменения данных и репликации с использованием протокола paxos, который отличается от кластера репликации с несколькими мастерами асинхронной репликации.

Он поддерживает Multi-Master Mode, но должностные лица рекомендуют один основной режим:

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

image-20190402165047454

// 查看MGR的组员
select * from performance_schema.replication_group_members;
// 查看MGR的状态
select * from performance_schema.replication_group_member_stats;
// 查看MGR的一些变量
show variables like 'group%';
// 查看服务器是否只读
show variables like 'read_only%';

преимущество:

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

недостаток:

  • поддерживает только innodb
  • Может использоваться только в режиме GTID, а формат журнала — формат строки.

Применимые бизнес-сценарии:

  • Чувствителен к задержке ведущий-ведомый
  • Я надеюсь обеспечить высокую доступность службы записи, но не хочу устанавливать стороннее программное обеспечение.
  • Сценарии с высокой согласованностью данных

Большая проблема считывания и записи нагрузки

Нагрузка большая:

  • увеличить раб

  • Добавить средний уровень (MyCat, ProxySQL, Maxscale)

  • разделение чтения-записи

Что касается большой нагрузки на запись:

  • Подбиблиотека и подтаблица
  • Добавить средний слой

Наконец

Обратитесь к курсам МООК,s.imooc.com/S8KFBvs

Категории