Назад | Перейти на главную страницу

Высокая доступность MariaDB только два сервера

Меня не беспокоит разделение мозга, поскольку соединение между двумя серверами прочное (и потому что у меня нет третьей машины)

Я хочу иметь репликацию MariaDB с автоматическим аварийным переключением, чтобы даже если одна база данных умирает, она продолжала работать. Я видел MaxScale, но поскольку у меня всего две машины, он должен работать на той же машине, что и один из серверов, и если этот сервер умирает, то ничего не работает. AFAIK, кластеры MariaDB Galera не позволят мне работать только на двух и иметь автоматическое переключение при отказе (потребуется кворум). Однако я мог бы запустить арбитра на другом компьютере или даже запустить на нем другую базу данных, но это было бы медленно.

Кроме того, бэкэнд - это PHP - я готов изменить настройку mysqli и тому подобное, но я не знаю, нужно ли или что мне там менять.


РЕДАКТИРОВАТЬ: я готов отказаться от автоматического переключения при отказе, но поведение, которое я тогда хотел бы, будет следующим:

Если я подключаюсь к серверу A, он подключается к базе данных A (главной) и читает / записывает нормально.

Если я подключаюсь к Serer B, он подключается к базе данных B (подчиненное устройство только для чтения) и читает нормально. Если ему нужно писать, он сможет, но отправит их в базу данных A.

Возможно ли это, используя MaxScale на обоих серверах или что-то в этом роде?

У вас есть два узла. Не используйте мастер-мастер любого типа, это невероятно склонно к разделению мозга на два узла (в конечном итоге это почти гарантировано).

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

У вас есть двухузловой кластер. Вам абсолютно необходимо беспокоиться о разделенном мозге, потому что эта архитектура очень склонна к условиям разделения мозга. Тот факт, что сегодня межузловая сетевая связь надежна, не означает, что так будет всегда, и это один из самых больших компонентов риска в двухузловом кластере. Потеря этой связи мгновенно разделит мозг кластера, если только Фехтование или КВОРУМ устанавливается между узлами. Это одно из важнейших соображений в двухузловом кластере, поскольку ограждение снижает вероятность состояний разделенного мозга с высокой до почти нулевой.

Я бы рекомендовал справиться с этим с помощью Pacemaker / Corosync. Это сложный стек, но он предоставляет механизмы, необходимые для создания кластера производственного уровня из двух узлов. Я бы также рекомендовал использовать только один главный экземпляр за раз, а не несколько, даже если под контролем такого диспетчера кластера.

Есть хорошее руководство для HA MariaDB, которое может служить отправной точкой. Он НЕ распространяется на использование ограждений. Если вы не можете выполнить ограждение, Corosync также может использовать небольшой узел арбитра, на котором запущен демон голосования, чтобы обеспечить общую реализацию с кворумом без дополнительных затрат на приложение (см. Информацию о Corosync qdevice).

Он находится за стеной подписки, но это полное руководство по настройке активно-пассивного кластера MySQL, работающего на одном узле за раз и репликации блочного хранилища между узлами

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

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

Один из вариантов - запустить асинхронную репликацию мастер-мастер с keepalived для отказа через плавающий IP-адрес. Это не очень хорошо, но это касается сценария полного отказа сервера.

Есть ли у вас МОТ или какой-то другой способ заставить одну машину принудительно отключить другую (STONITH)? Это действительно необходимо для предотвращения частичного отказа, например. машина выходит из строя, но не полностью, поэтому она все еще достаточно жива, чтобы отвечать на пакеты подтверждения, но в остальном не работает. Это может привести к тому, что аварийное переключение не произойдет, когда это необходимо.