В Ситимобил мы используем базу данных MySQL в качестве основного хранилища постоянных данных. У нас есть несколько кластеров баз данных под различные сервисы и цели.

Постоянная доступность мастера является критическим показателем работоспособности всей системы и ее отдельных частей. Автоматическое восстановление кластера в случае отказа мастера сильно снижает время реагирования на инцидент и время простоя системы. В этой статье я рассмотрю схему обеспечения высокой доступности (HA) кластера MySQL на основе MySQL Orchestrator 和虚拟 IP 地址 (VIP)。

基于VIP的HA解决方案

首先我简单介绍一下我们的数据存储系统是什么。

Мы используем классическую схему репликации с одним мастером, доступным на запись, и множеством реплик, которые используются только на чтение. Кластер может содержать промежуточный мастер — узел, который одновременно является и репликой, и мастером для других. Клиенты обращаются к репликам через HAProxy, что позволяет равномерно распределять нагрузку и легко масштабироваться. Использование HAProxy обусловлено историческими причинами, и сейчас мы в процессе миграции на ProxySQL.

Репликация выполняется в полусинхронном режиме на основе GTID. Это значит, что как минимум одна реплика должна записать транзакцию в журнал, прежде чем та будет признана успешной. Такой режим репликации обеспечивает оптимальный баланс между производительностью и сохранностью данных в случае выхода из строя главного узла. В основном все изменения передаются от мастера к репликам с помощью Row Based Replication (RBR), но часть узлов может иметь mixed binlog format.

编排器定期更新集群拓扑的状态，分析收到的信息，如果出现问题，它可以启动自动恢复程序。 开发人员对程序本身负责，因为它可以通过不同的方式实现：基于 VIP、DNS、使用服务发现服务或自编写的机制。

如果主节点发生故障，恢复主节点的一种简单方法是使用浮动 VIP 地址。

在继续操作之前，您需要了解有关此解决方案的信息：

• VIP 是不与特定物理网络接口关联的 IP 地址。 如果某个节点发生故障或在计划维护期间，我们可以将 VIP 切换到另一个资源，从而最大限度地减少停机时间。
• Освобождение и выдача виртуального IP-адреса — дешевые и быстрые операции.
• 要使用 VIP，您需要通过 SSH 访问服务器，或使用特殊实用程序，例如， keepalived.

让我们看看向导可能出现的问题，并想象一下自动恢复机制应该如何工作。

与主站的网络连接已消失，或者硬件级别出现问题，服务器不可用

1. Оркестратор обновляет топологию кластера, каждая реплика сообщает о недоступности мастера. Оркестратор запускает процесс выбора реплики, подходящей на роль нового мастера, и начинает восстановление.
2. 我们正在尝试从旧主人那里删除 VIP - 但没有成功。
3. Реплика переключается на роль мастера. Топология перестраивается.
4. Добавляем новый сетевой интерфейс с VIP. Поскольку снять VIP не удалось, в фоновом режиме запускаем периодическую отправку запроса gratuitous ARP. Этот вид запроса/ответа позволяет обновить на подключенных коммутаторах таблицу соответствия IP- и MAC-адресов, тем самым уведомляя о переезде нашего VIP. Это минимизирует вероятность split brain при возврате старого мастера.
5. Все новые соединения сразу же перенаправляются на новый мастер. Старые соединения завершаются неудачно, выполняются повторные обращения к БД на уровне приложения.

服务器以正常模式运行，DBMS 级别发生故障

该算法与前面的情况类似：更新拓扑并启动恢复过程。 由于服务器可用，我们成功释放了旧master上的VIP，将其转移到新master上，并发送了几个ARP请求。 旧master的可能回归不应影响重建的集群和应用程序的运行。

其他问题

Отказ реплик или промежуточных мастеров 不会导致 自动化操作，需要人工干预。

虚拟网络接口始终是临时添加的，即服务器重新启动后，不会自动分配 VIP。 每个数据库实例默认以只读模式启动，orchestrator自动将新的master切换为写入并尝试安装 read only на старом мастере. Эти действия направлены на уменьшение вероятности split brain.

В процессе восстановления могут возникнуть проблемы, о которых стоит также уведомлять через UI оркестратора помимо стандартных средств мониторинга. Мы расширили REST API, добавив такую возможность (PR сейчас находится на рассмотрении).

HA解决方案的总体框图如下所示。

选择新主人

编排者足够聪明并尝试选择 наиболее подходящую реплику 根据以下标准作为新主人：

• 副本落后于主服务器；
• MySQL版本的master和replica；
• 复制类型（RBR、SBR 或混合）；
• расположение в одном или разных дата-центрах;
• 可用性 errant GTID — 在副本上执行但不在主服务器上执行的事务；
• 还考虑了自定义选择规则。

Не каждая реплика является идеальным кандидатом на роль мастера. Например, реплика может использоваться для резервного копирования данных, либо сервер имеет более слабую конфигурацию «железа». Оркестратор 支持 ручные правила, с помощью которых можно настроить свои предпочтения по выбору кандидата от наиболее предпочтительных до игнорируемых.

响应和恢复时间

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

• slave_net_timeout — количество секунд, в течение которых реплика ожидает поступления новых данных или heartbeat-сигнала от мастера, прежде чем соединение признается потерянным и выполняется переподключение. Чем меньше значение, тем быстрее реплика сможет определить, что связь с мастером нарушена. Мы устанавливаем это значение равным 5 секундам.
• MASTER_CONNECT_RETRY — количество секунд между попытками переподключения. В случае сетевых проблем низкое значение этого параметра позволит быстро переподключиться и предотвратить запуск процесса восстановления кластера. Рекомендуемое значение — 1 секунда.
• MASTER_RETRY_COUNT — 重新连接尝试的最大次数。
• MASTER_HEARTBEAT_PERIOD — интервал в секундах, после которого мастер отправляет heartbeat-сигнал. По умолчанию равен половине значения slave_net_timeout.

编排器参数：

• DelayMasterPromotionIfSQLThreadNotUpToDate - 如果相等 true, то роль мастера не будет применена на реплике-кандидате до тех пор, пока SQL-поток реплики не выполнит все непримененные транзакции из Relay Log. Мы используем эту опцию, чтобы не терять транзакции в условиях отставания всех реплик-кандидатов.
• InstancePollSeconds — 构建和更新拓扑的频率。
• RecoveryPollSeconds — 拓扑分析的频率。 如果检测到问题，则会启动拓扑恢复。 这 常数，等于 1 秒。

每个集群节点由协调器每隔一次轮询一次 InstancePollSeconds секунд. При обнаружении проблемы состояние кластера принудительно 更新，然后最终决定进行恢复。 通过尝试不同的数据库和协调器参数，我们能够将响应和恢复时间缩短至 30 秒。

测试台

我们开始测试 HA 计划并开发本地 试验台 и дальнейшего внедрения в тестовое и боевое окружения. Локальный стенд полностью автоматизирован на основе Docker и позволяет экспериментировать с конфигурацией оркестратора и сети, масштабировать кластер от 2-3 серверов до нескольких десятков и проводить учения в безопасной среде.

在练习过程中，我们选择一种问题模拟方法：使用立即射击大师 kill -9, мягко завершить процесс и остановить сервер (docker-compose stop），使用模拟网络问题 iptables -j REJECT или iptables -j DROP. Мы ожидаем такие результаты:

• оркестратор обнаружит проблемы с мастером и обновит топологию не более чем за 10 секунд;
• автоматически запустится процедура восстановления: изменится сетевая конфигурация, роль мастера перейдёт к реплике, топология перестроится;
• 新的主服务器将变得可写，实时副本在重建过程中不会丢失；
• данные начнут записываться в новый мастер и реплицироваться;
• 总恢复时间不会超过30秒。

Как вы знаете, система может вести себя по-разному в тестовом и production-окружениях из-за разной конфигурации «железа» и сети, различий в синтетической и реальной нагрузке и т.д. Поэтому периодически мы проводим учения в реальных условиях, проверяя, как ведет себя система при потере сетевой связности или деградации ее отдельных частей. В будущем хотим построить полностью идентичную инфраструктуру для обеих сред и автоматизировать ее тестирование.

发现

主存储系统节点的健康状况是SRE和运营团队的主要任务之一。 基于VIP的编排器和HA解决方案的实施使我们取得了以下成果：

• надежное обнаружение проблем с топологией кластера БД;
• 自动快速响应主站相关事件，减少系统停机时间。

然而，该解决方案有其局限性和缺点：

• 将 HA 方案扩展到多个数据中心将需要在它们之间使用单个 L2 网络；
• 在为新master分配VIP之前，我们需要在旧master上释放它。 该过程是连续的，这会增加恢复时间；
• 释放 VIP 需要通过 SSH 访问服务器，或者调用远程过程的任何其他方法。 由于服务器或数据库遇到导致恢复过程的问题，我们无法确定 VIP 删除是否会成功完成。 这可能会导致两台服务器出现具有相同虚拟IP地址的问题 split brain.

避免 split brain，你可以使用该方法 斯托尼斯 （“Shoot The Other Node In The Head”），这可以完全隔离或禁用问题节点。 还有其他方法可以实现集群高可用：VIP和DNS的组合、服务发现和代理服务、同步复制等方法，这些方法各有缺点和优点。

我谈到了我们创建 MySQL 故障转移集群的方法。 它易于实施，并在当前条件下提供可接受的可靠性水平。 随着整个系统、特别是基础设施的发展，这种方法无疑将会发展。

来源： habr.com