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