В распределенных системах мы часто рассматриваем высокую доступность системы.Для программ без сохранения состояния реализация высокой доступности относительно проста, и ее относительно легко масштабировать по вертикали и горизонтали.Однако для приложений с интенсивным использованием данных, таких как высокая доступность баз данных, Не так хорошо, чтобы расширяться. Когда мы рассматриваем высокую доступность базы данных, основное соображение состоит в том, чтобы поддерживать доступность базы данных в максимально возможной степени, чтобы гарантировать, что бизнес не пострадает в случае неожиданного простоя системы; второе — это резервная база данных, и узел реплики только для чтения должен хранить данные в режиме реального времени с главным узлом Согласованность После переключения базы данных должна поддерживаться согласованность данных, и не будет отсутствующих или несогласованных данных, влияющих на бизнес. Многие распределенные базы данных решили эту проблему, а также могут очень гибко удовлетворять потребности бизнеса, такие как синхронизация, полусинхронизация, количество копий данных, переключение ведущий-ведомый, аварийное переключение и т. д. (упомянутые ниже), однако, Мы Официальная версия сообщества mysql5.7 и предыдущие версии (за исключением других ветвей MySQL, таких как PhxSQL, Percona XtraDB Cluster, MariaDB Galera Cluster), которые обычно используются в сообществе, не очень хорошо обрабатываются в плане поддержки распространения и доступности системы. Ввиду этого ряда проблем, давайте проанализируем, как решить эту проблему.
В течение этого периода была обнаружена и отправлена ошибка, которая объединила мастер онлайн-коммутатора mha и вызвала несогласованность данных между ведущим и подчиненным.
Что такое отказоустойчивость
нестиmhaПеред этим давайте популяризируем его заранееfailover. Что такое аварийное переключение, то есть когда активные службы или приложения неожиданно прекращают работу, быстро позволяя резервным или резервным серверам, системам, оборудованию или сетям взять на себя их работу, аварийное переключение в основном то же самое, что и переключение операций передачи, за исключением того, что аварийное переключение обычно происходит выполняется автоматически, без предупреждения, чтобы сделать это вручную, в то время как перенос подкачки должен выполняться вручную.Для серверов, систем или сетей, требующих высокой доступности и высокой стабильности, разработчики систем обычно проектируют функции аварийного переключения.
Проще говоря, когда определенная служба в системе недоступна, другие сервисные модули в системе могут автоматически продолжать предоставлять услуги.Существует много хорошо разработанных проектов программного обеспечения с открытым исходным кодом, которые автоматически включают аварийное переключение, например балансировка нагрузки nginx, haproxy может поддерживать обнаружение серверной части, резервное копирование. При обнаружении аномалии в восходящей серверной части (конечных точках) он автоматически и плавно переключается на обычное резервное копирование, а затем распределенные приложения с интенсивным использованием данных также включают отработку отказа, включая набор реплик mongdb, выбор узла etcd/zookeeper, набор реплик Elasticsearch и т. д., когда некоторые узлы данных ненормальны, узлы данных выборов являются ведущими/основными/лидерами, и даже очереди сообщений, такие как зеркальные очереди rabbitmq, реплики kafka будут включать отработку отказа.
Ссылка на сайт:
выборы руководителя зоопарка
etcd-raft
etcd-рафт визуализация
набор реплик mongodb
очередь зеркала rabbitmq
кафка ISR и синхронизация
elasticsearch replics
репликация данных
Аварийное переключение упоминалось ранее, поэтому, поскольку система поддерживает аварийное переключение, необходимо обеспечить возможность резервного копирования или реплик для продолжения предоставления услуг в качестве нового «главного» (ведущий/главный/основной в совокупности называются здесь главным). Как упоминалось ранее, многие проекты программного обеспечения с открытым исходным кодом имеют собственную функцию синхронизации данных, то есть все вставка, удаление и обновление данных выполняются на ведущем, а затем данные будут синхронизироваться на ведомом.Короче говоря, это необходимо чтобы сохранить согласованность данных ведущий-ведомый. Синхронизация здесь может быть выполнена какmysql-bin log,mongdb optlogЭто реализовано путем ведения журнала, и такие операции, как update(), delete(), insert(), записываются в журнал, а затем эти операторы пересылаются в каждую подчиненную библиотеку, и каждая подчиненная библиотека анализирует и выполняет оператор SQL, просто как из Данные воспроизводятся из библиотеки по мере поступления клиентских запросов; лог также может сначала записываться на диск путем передачи лога упреждающей записи (wal), такого как движок, реализованный SSTables и деревом LSM, поэтому все журналы представляют собой последовательность байтов только для добавления, содержащую все записи базы данных, можно использовать тот же самый журнал для создания реплики на другом узле, одновременно записывать журнал на диск, мастер может отправлять его по сети на другие подчиненные узлы , такие как Synchronization конечного автомата etcd; Другой способ — напрямую отправить данные, которые необходимо синхронизировать, через процесс внутри кластера, такой как очередь зеркала rabbitmq.
На следующем рисунке показан сценарий применения репликации данных: у пользователя есть операция записи для обновления библиотеки записи, а затем другие пользователи могут считывать данные из подчиненной библиотеки, данные могут быть самыми последними, или подчиненная библиотека может быть не самой последней. последний из-за задержки. , система репликации разделена на несколько методов репликации для этого сценария.
Важная деталь системы репликации: репликацияСинхронный (синхронно) или асинхронный (асинхронно)
О методе копирования:
Синхронная репликация (синхронная):
Синхронная репликация означает, что при отправке запроса на обновление данных на главный узел необходимо убедиться, что операция обновления успешно выполнена на подчиненном узле, прежде чем вернуться к клиенту. Если главная библиотека вдруг выйдет из строя, мы можем быть уверены, что данные все еще можно найти в подчиненной библиотеке, но у этого метода есть и недостатки.Если подчиненная библиотека не отвечает (например, произошел сбой, или есть сбой или по любой другой причине), главная библиотека не сможет обрабатывать операции записи, основная база данных должна заблокировать все операции записи и дождаться, пока синхронная реплика снова станет доступной. В этом процессе база данных не может обновлять и вставлять данные.
Асинхронная репликация (асинхронная):
Асинхронная репликация заключается в том, что при запросе обновленных данных на главный узел основная операция завершается и возвращается клиенту напрямую, без подтверждения ведомого, а ведомый фон обновляет данные от ведущего. Недостаток этого метода заключается в том, что если главная библиотека выходит из строя и не подлежит восстановлению, все записи, которые не были реплицированы в подчиненную библиотеку, будут потеряны, а это означает, что даже если успех был подтвержден клиенту, запись не будет завершена. гарантированно прочный (Durable). Преимущество этого подхода заключается в том, что даже если все подчиненные библиотеки отстают, главная библиотека может продолжать обрабатывать записи, а служба продолжает работать.
Полусинхронная репликация (полусинхронная):
Полусинхронная репликация является промежуточной стратегией.При запросе обновленных данных к ведущему узлу необходимо убедиться, что операция также успешно выполнена на определенном ведомом, прежде чем он будет окончательно возвращен клиенту.Если синхронный подчиненное устройство становится медленным, вы можете сделать асинхронное подчиненное устройство синхронным, чтобы можно было гарантировать надежность при условии обеспечения определенной согласованности данных (это может привести к несогласованности данных и задержке данных).
Полусинхронная репликация mysql (полусинхронная репликация mysql):
Ведущее устройство копирует данные в подчиненное устройство сразу после выполнения операции обновления. Ведомое устройство получает данные и записывает их в журнал реле (выполнять его не нужно) перед возвратом информации об успешном выполнении главному устройству. Ведущее устройство должно получить информацию об успешном выполнении подчиненного устройства перед возвратом ответа клиенту. Только когда репликация данных ненормальна (ведомый узел недоступен или сеть, используемая для репликации данных, ненормальна), мастер делает паузу (по умолчанию mysql составляет около 10 секунд), чтобы ответить на клиент и понизить метод репликации до асинхронной репликации. Когда репликация данных вернется в нормальное состояние, режим репликации вернется к полусинхронной репликации.
синхронизация данных mysql и отказоустойчивость
MySQL поддерживает относительно строгий ACID и является реляционной базой данных с очень хорошей производительностью и стабильностью, но она не очень дружелюбна к распределенной поддержке, хотя и реализуетNDB, но я чувствую, что он не используется широко, а базовый метод репликации master-slave больше используется в Китае. MySQL поддерживает различные методы репликации данных, упомянутые выше, поэтому вам нужно только выбрать соответствующий метод репликации для различных сценариев. Например, могут быть выбраны те, у кого более высокие требования к доступности и более низкие требования к согласованности данных.Асинхронная репликация;Для сценариев, требующих высокой согласованности данных, можно выбрать финансовые сценарии.Сильная синхронная репликация;Интернет-сценарии могут иметь определенные требования к удобству использования и согласованности, но требования не особенно высоки, вы можете выбратьПолусинхронная репликация.Далее кратко описывается логика синхронизации master-slave mysql.
Логика синхронизации master-slave в mysql:
Сначала откройте binlog на мастере mysql, ведомое устройство mysql читает binlog с мастера mysql через поток ввода-вывода, а затем передает его в журнал ретрансляции подчиненного устройства mysql, а затем поток sql подчиненного устройства mysql читает relay из журнала реле. Журнал применяется к базе данных подчиненного устройства mysql, чтобы была реализована функция синхронизации данных ведущий-ведомый.
Однако сам mysql не реализует отказоустойчивость, поэтому, когда мастер неисправен, необходимо разработать стратегию для реализации отказоустойчивости и управления переключением баз данных. Логика аварийного переключения заключается в том, что когда мастер выходит из строя, ведомый автоматически повышается до главной библиотеки, а затемСообщите другим ведомым устройствам о новом ведущем устройстве и продолжите синхронизацию данных с нового ведущего устройства.Здесь мы будем использоватьmhaТеперь инструмент управления высокой доступностью mysql. mha может автоматически завершить операцию аварийного переключения базы данных в течение 0–30 секунд, а в процессе аварийного переключения он может в максимальной степени обеспечить согласованность данных, чтобы достичь высокой доступности в истинном смысле. Я не буду здесь вдаваться в подробности о различных деталях мха, они все есть в официальномwikeСредний (документ действительно очень подробный, автор рассматривает множество распространенных сценариев, и многие параметры можно настроить).
Ссылка на сайт:
мха установить
преимущество
мха архитектура
конфигурация мха
подожди подожди....
Здесь мы только разбираем архитектуру и принцип его реализации отказоустойчивости Структура следующая (картинка на официальном сайте, слегка размытая)
мха состоит из двух частей:
mha manager (узел управления): он развертывается на отдельной машине для управления несколькими кластерами master-slave (предпочтительно управляемыми серверами, связанными с mysql), или может быть развернут на подчиненном узле для обслуживания нескольких серверов mysql. , выбор мастера, проверка соединения, отработка отказа мастера и т. д.
узел mha (узел данных): работающий на каждом сервере mysql, функция состоит в том, чтобы скопировать главный двоичный журнал; затем сгенерировать дифференциальный журнал ретрансляции на подчиненном устройстве с последними данными и применить дифференциальный журнал; наконец, удалить его, не останавливая SQL поток Следующий журнал.
принцип:
(1) Сохранение событий бинарного журнала из разбившегося мастера;
(2) Определите ведомое устройство с последним обновлением;
(3) Применить журнал ретрансляции различий к другим ведомым устройствам;
(4) Применить события двоичного журнала (события бинлога), сохраненные от мастера;
(5) Заставьте другие ведомые устройства подключаться к новому ведущему для репликации;
(6) Заставьте другие ведомые устройства подключаться к новому ведущему для репликации;
Проблемы, которые решает mha:
Как определить нового мастера:
Поскольку mysql не имеет распределенных узлов принятия решений кластера, таких как elasticsearch и т. д., главным узлом выбора здесь является узел менеджера mha.mha в основном относится к нескольким факторам: 1 Параметр серверов-кандидатов, настроенный вручную в файле конфигурации **candidate_master=1** (Например: если вы хотите, чтобы такое же машинное помещение или машина в той же стойке предпочтительна в качестве ведущей), 2 В соответствии с последними двоичными файлами в каждом ведомом, последний ведомый узел может быть повышен до ведущего.
какГарантированная согласованность данных:
mha гарантирует, что данные не будут потеряны в наибольшей степени.Когда мастер mysql неисправен, но машина предоставляет услуги нормально, тогда mha сравнит разницу данных между главным узлом и подчиненным узлом, который станет главным узлом, а затем скопируйте разностные данные на новое ведомое устройство, а затем примените эту часть разностных данных для завершения данных.
Если мастер mysql неисправен и машина ненормальна, то двоичный файл binlog, сохраненный в системе, недоступен, поэтому его нельзя скопировать, тогда процесс копирования будет пропущен, а новый мастер будет выбран непосредственно из подчиненного кандидаты. Если вы используете полусинхронную репликацию mysql 5.5, вы можете значительно снизить риск потери данных.
Как копировать данные между узлами:
Поскольку в mysql нет внутренней функции копирования bin-log, у нас есть собственные требования для достижения репликации. Здесь mha нужно опираться на протокол ssh, то есть передавать файлы по протоколу scp (для сборки mha необходимо сделать так, чтобы каждый хост мог общаться по ssh).
Как другие ведомые узлы узнают о новом ведущем:
Когда мастер-кандидат становится мастером, менеджер mha будет использовать метод репликации изменений mysql, чтобы изменить источник синхронизации всех подчиненных устройств в текущем кластере.
Как узлы управления решают проблемы с сетевыми разделами:
В приведенной выше сетевой структуре мы можем догадаться, что может быть большая проблема с системой, т.е.сетевой раздел. Под сетевым разделом понимается разделение системы на два кластера за счет разделения сети, каждый из которых не доверяет друг другу. Что касается системы без сохранения состояния, она почти не влияет и нормально обрабатывает запросы, такие как nginx; когда в системе данных есть проблема с разделами, если дизайн или конфигурация системы неразумны, это приведет к несогласованности данных, и эта проблема будет быть очень сложной для восстановления, поэтому в elasticsearch, etcd, mongdb и других системах данных, которые естественным образом поддерживают распределенные, есть механизмы, позволяющие избежать несогласованности данных, вызванной сетевыми разделами.Большинство узлов в кластере, которые могут нормально обмениваться данными, находятся в нормальном режиме.Например, если в вашем кластере 5 нод, а в результате разбиения получается 2 ноды в одной партиции и 3 в одной партиции, то партиция из 2 нод будет считаться ненормальной и не сможет нормально предоставлять услуги, здесь тоже есть свои специфические алгоритмы. Подобные проблемы можно решить, как плот.
Например, на рисунке ниже 3 узла, тогда минимальное количество узлов в доверенном кластере должно быть 2, поэтому узел C будет помечен как ненормальный и не будет нормально предоставлять услуги
Сетевой раздел mha немного отличается от упомянутого выше, так как кластер имеет только одно управление mha (обратите внимание, здесь может быть развернуто только одно управление, а множественное развертывание не допускается, иначе возникнет исключение), поэтому здесь Это не проблема разделения мозга в управлении mha.Сетевой раздел относится к разделу между узлом управления mha и главным узлом mysql следующим образом:
Когда управление mha и мастер mysql появляются в двух разделах, mha думает, что мастер mysql ненормальный, но фактический мастер mysql и ведомый mysql работают нормально и предоставляют услуги, но в это время mha все равно переключит мастер, что может быть полезно для приложение (если на интерфейсе будет балансировщик нагрузки), будет 2 мастера, что приведет к несогласованности данных. Столкнувшись с этой ситуацией, mha предоставляет вторичный метод обнаружения, то есть обнаружение нескольких ссылок, 1 ссылка — это управление mha путем прямого обнаружения главного узла mysql, 2 другие ссылки — это управление mha через вход в систему по ssh. Другие подчиненные методы используются для определения того, мастер mysql нормальный, что может решить проблему сетевого раздела между менеджером mha и мастером mysql и предотвратить случайное переключение.
Автоматическое восстановление клиентского приложения
Вообще говоря, распределенные системы с аварийным переключением могут сами восстанавливать службы, такие как elasticsearch и т. д. Их клиенты и кластеры могут автоматически определять изменения в узлах кластера. Клиент подключается к набору адресов кластера. См. пример ниже. Например, адрес сервера Endpoints []string, подключенный через etcd, представляет собой массив, который гарантирует, что в случае сбоя IP-адреса узла, отсутствия доступа к машине, ненормальной работы машины или загрузки машины другие узлы будут ее обрабатывать. следующим образом:
cfg := client.Config {
Endpoints: []string{"http://127.0.0.1:2379"},
Transport: client.DefaultTransport, // set timeout per request to fail fast when the target endpoint is unavailable
HeaderTimeoutPerRequest: time.Second,
}
Однако, как и метод подключения по умолчанию для mysql, метод по умолчанию использования tomcat или других клиентов для подключения к базе данных — это драйвер mysql, который не может подключиться к массиву. Таким образом, наше решение состоит в том, чтобы уменьшить восприятие клиента и изменения логики, чтобы клиенту нужно было подключаться только к одному ip, как и раньше, ip здесь - прокси-ip, и здесь будет несколько способов (шардинг и шардинг здесь не рассматриваются. Для другая расширенная маршрутизация, учитывайте только подключение к приложению, высокую доступность прокси можно использовать для взаимного бекапа через keepalived)
Лучше всего работать с клиентом через метод прокси.В принципе, прокси-сервер анализирует протокол mysql, а затем направляет (разделение чтения-записи) на соответствующий сервер mysql на внутреннем сервере в соответствии с различными библиотеками, таблицами и типами запросов, но из-за таких 7 уровней прокси-анализа, поэтому производительность будет потеряна, как правило, около 20%, вышеупомянутые прокси будут иметь свои преимущества, функции и детали, вы можете посмотреть соответствующее сравнение, все, что нам нужно сделать заключается в настройке нашего прокси-сервера Группа приложений службы настроена с разделением чтения и записи.Когда мастер ненормальный, его можно переключить.
4-уровневый прокси не будет парсить 7-уровневый протокол mysql, а только 4 слоя, поэтому достаточно убедиться, что back-end порт mysql подключен, то есть когда он обнаружит, что back-end master недоступен , переключиться на резервный мастер, т.к. он 4-х уровневый Протокол не может настроить автоматическое разделение чтения-записи, только мастер порт и слейв порт можно настроить отдельно (если настроить keepalived, то можно настроить скрипт на переключение, и пользовательский скрипт может настроить задержку синхронизации master-slave)
- Используйте VIP напрямую
- Скрипт для настройки вип
- keepalived настроить vip
Окончательная логика такова:
Вручную настройте VIP: настройте виртуальный VIP на главном компьютере. Когда мастер mysql неисправен, управление mha передает настроенный сценарий master_ip_online_change_script. может это не влияет, проще настроить вип
О процессе настройки [процесс настройки](Блог Woohoo.cn на.com/go MySQL/afraid/3…), тут все предельно ясно, подробно разбирать не буду.
Наша производственная среда фактически использует maxscale, который используется для разделения чтения и записи.ДокументацияЭто особенно всеобъемлющее. Причина, по которой мы выбираем его, заключается в том, что он стабилен и эффективен и может беспрепятственно взаимодействовать с mha. Mha не нужно настраивать какую-либо логику, такую как переключение IP. Когда mha переключается, maxscale автоматически воспринимает роль серверов в системе, переключение мастеров может быть воспринято и не влияет на приложение, как показано ниже:
Суммировать:
Здесь решается проблема высокой доступности исходной официальной версии mysql от сообщества.Используя метод mha + maxscale, это решение может внести изменения в существующую систему с минимальными затратами и повысить доступность и стабильность системы. Как упоминалось ранее, mysql в предыдущих версиях (до 5.7) имеет относительно слабую поддержку кластеризации, но на самом деле mysql развивается, и сообщество также разработало множество решений, таких как PhxSQL, Percona XtraDB Cluster, MariaDB Galera Cluster и Должностные лица mysql также разработали для того, чтобы использовать GA репликации группы MySQL, распределенный протокол используется для решения проблемы согласованности данных.Я с нетерпением жду, когда в будущем будет предлагаться все больше и больше решений, чтобы лучше решить проблему высокой доступности MySQL.