Я не беспокоюсь о разделении мозга, поскольку соединение между двумя серверами надежное (и поскольку у меня нет третьей машины)
Я хочу иметь репликацию MariaDB с автоматическим отказоустойчивым режимом, чтобы даже если одна база данных умрет, она продолжала работать. Я видел MaxScale, но поскольку у меня всего две машины, он должен работать на той же машине, что и один из серверов, и если этот сервер умрет, то ничего не будет работать. AFAIK, кластеры MariaDB Galera не позволят мне работать только на двух и иметь автоматический отказоустойчивый режим (потребуется кворум). Однако я мог бы запустить арбитратор на другой машине или даже запустить на ней другую базу данных, но это будет медленно.
Кроме того, бэкэнд — это PHP — я готов изменить настройки MySQLi и т. п., но не знаю, придется ли мне что-то там менять и что именно.
EDIT: Я готов отказаться от автоматического переключения при сбое, но тогда поведение, которое я хотел бы получить, было бы следующим:
Если я подключаюсь к серверу A, он подключается к базе данных A (главной) и нормально считывает/записывает данные.
Если я подключаюсь к Serer B, он подключается к базе данных B (только для чтения) и читает нормально. Если ему нужно записать, он сможет, но он передаст их в базу данных A.
Возможно ли это с использованием MaxScale на обоих серверах или чего-то подобного?
решение1
У вас два узла. Не используйте master-master любого вида, это невероятно склонно к split-brain на двух узлах (это почти гарантированно произойдет в конечном итоге).
Нельзя ожидать, что подобное приложение с отслеживанием состояния сможет самостоятельно хорошо справиться с развертыванием кластера из двух узлов — для того, чтобы кластер стал хоть немного устойчивым в случае сбоя, потребуется либо вмешательство оператора, либо CRM — именно поэтому оно изначально и кластеризовано.
У вас есть кластер из двух узлов. Вам определенно следует беспокоиться о split-brain, потому что эта архитектура очень склонна к split-brain условиям. То, что межузловая сетевая связь сегодня прочная, не означает, что так будет всегда, и это один из самых больших компонентов риска в кластере из двух узлов. Потеря этой связи мгновенно split-brain кластера, если толькоОХВАТЫВАНИЕилиКВОРУМустанавливается между узлами. Это одно из самых важных соображений в кластере из двух узлов, поскольку ограждение снижает вероятность состояний расщепленного мозга с высокой до почти нулевой.
Я бы рекомендовал справиться с этим с помощью Pacemaker/Corosync. Это сложный стек, но он обеспечивает механизмы, необходимые для создания кластера производственного уровня из двух узлов. Я бы также рекомендовал использовать только один главный экземпляр за раз, а не несколько главных, даже под принуждением такого менеджера кластера.
Есть хорошее руководство по HA MariaDB, которое может послужить отправной точкой. Оно НЕ охватывает использование ограждения. Если вы не можете выполнить ограждение, Corosync также может использовать небольшой узел-арбитр, на котором запущен голосующий демон, чтобы обеспечить общую реализацию с кворумом без накладных расходов на приложения (см. информацию о Corosync qdevice).
Он находится за стеной подписки, но этоПолное руководство по настройке кластера MySQL «активный-пассивный», работающего на одном узле за раз и реплицирующего блочное хранилище между узлами
Расширенные типы ресурсов Pacemaker охватывают большинство ваших вопросов относительно того, как изящно организовать отказоустойчивость, с возможностью группировать ресурсы в линейные цепочки зависимостей, а также выражать семантику выбора лидера с несколькими состояниями для запуска более одного экземпляра приложения на узлах.Это можно найти здесь.
Пакеты — это способ достижения изоляции приложений в Pacemaker с помощью контейнерных сред выполнения, таких как Docker и RKT. Это открывает еще один путь ограждения, поскольку эти пакеты появляются в кластере как сами узлы Pacemaker — поэтому они могут быть «ограждены» кластером независимо от других приложений.Это можно найти здесь.
решение2
Я запускал различные базы данных (Mongo, Elasticsearch, SQL Server и другие) с одной и той же философией: «Меня не волнуют проблемы, я могу запустить только два узла».
Это был МИР боли.
Если вы работаете по принципу «хозяин-раб», то хорошо. Но будут головные боли.
После многих лет попыток обойти эту проблему и решения различных проблем DevOps, возникших из-за моего настойчивого желания использовать только два узла (на чем я настаивал, поскольку наши базы данных были очень большими, а стоимость третьего узла была существенной), я наконец начал использовать три узла.
И потом все стало лучше.
Урок, который я усвоил за годы занятий танцами, таков: есть два варианта:
- Один узел с теплым резервом (например, ведущий-ведомый)
- Три узла
Исходя из моего опыта, я бы никогда больше не стал запускать два узла в режиме «активный-активный» (если только не найдется волшебная штука, которая полностью предотвращает разделение мозга, что я видел и что безумно уродливо).
Пять лет работы с несколькими базами данных объемом 0,5–1,5 ТБ на различных стеках.
решение3
Одним из вариантов было бы запустить асинхронную репликацию master-master с keepalived для отказа через плавающий IP. Это не очень хорошо, но это покрыло бы сценарий полного отказа сервера.
Есть ли у вас ILO или какой-либо другой способ заставить одну машину принудительно выключить другую (STONITH)? Это действительно необходимо для предотвращения частичного отказа, например, машина выходит из строя, но не полностью, поэтому она все еще достаточно жива, чтобы отвечать на пакеты heartbeat, но в остальном не работает. Это может привести к тому, что отказ не произойдет, когда это должно произойти.