Контекст: Мы используем кластер MariaDB Gallera с (всего) 2 главными узлами для веб-приложения. Вчера вечером у нас отключилось электричество, и теперь мы не можем восстановить данные и обнаружили, что база данных повреждена на обоих узлах. Наше первое впечатление об этой настройке было таким: если один узел выйдет из строя, другой быстро станет основным узлом.
Мои вопросы:
Есть ли способ настроить кластер, чтобы всегда был резервный узел, который будет автоматически реплицироваться, если один из узлов выйдет из строя? Особенно при отключении электричества.
Какая будет правильная реализация галерейного кластера?
Ответ на первый вопрос, как и на большинство компьютерных проблем: да, если у вас достаточно ресурсов и времени. Если кластер находится в какой-то среде центра обработки данных, можно надеяться, что у него будет какой-то интерфейс внеполосного управления, такой как выделенные сетевые адаптеры управления и / или система KVM.
Современные решения для управления центрами обработки данных, такие как Менеджер центра обработки данных Intel или Системы управления Raritan Datacenter предлагают пользователям возможность настраивать политики для автоматической перезагрузки систем после сбоя питания, отправки уведомлений и, возможно, даже начала развертывания удаленных или облачных узлов аварийного переключения. Однако для установки и настройки всех аспектов такого рода сети безопасности потенциально требуются большие затраты и высокий уровень знаний, для этого требуется много оборудования, а тщательное тестирование и подготовка затруднены без некоторого простоя.
Другой распространенный инструмент управления узлами - это Nagios что позволяет удаленно управлять и контролировать питание.
В дополнение к параметрам внутриполосного и внеполосного управления настройка сервера управления конфигурацией с помощью инструмента CM, например Поваренная соль или Повар поможет обеспечить правильную настройку узлов и значительно упростит задачу подготовки новых узлов даже в странных или удаленных средах. Требования к хранилищу и базе данных, а также сетевая среда помогут определить подходящую архитектуру кластера, особенно в отношении хранения, питания и резервного копирования. В некоторых случаях может быть полезно сгенерировать клоны кикстарта или какое-то подобное средство установки, такое как AutoYaST, в системах SUSE. Это позволит вам быстро создавать чистые узлы и импортировать необходимые данные из моментальных снимков или резервных копий в случае отказа оборудования.
Сохранение пользовательских образов системы, созданных с помощью Система сборки KIWI другой вариант - импорт, монтирование или копирование необходимых данных. Использование KIWI позволит вам создавать образы, которые можно развертывать в различных сценариях, в том числе в виде виртуальных машин, через PXE, загрузочный DVD / USB и т. Д. Создание идеального пользовательского образа для ваших нужд с помощью KIWI или другого инструмента сборки операционной системы может быть весьма полезным по ряду причин.
Трудно дать более конкретный ответ на второй вопрос, не зная, какую длину вы сочтете приемлемой. Настройка и ресурсы, необходимые для многосайтового кластера высокой доступности с дополнительными удаленными резервными копиями, автоматическим переключением при отказе и восстановлением, кардинально отличаются от тех, которые потребуются для кластера, где "высокая доступность" означает, что здание, в котором находится кластер, имеет питание и интернет нужны для работы. Надеюсь, часть информации будет полезной.
Мы используем кластер Galera с 5 узлами, перед которыми находится балансировщик нагрузки, который постоянно проверяет все узлы. Наша конфигурация такова, что у нас есть только один из узлов, обслуживающих цель записи и чтения для соединений от балансировщика нагрузки, а другие узлы находятся в горячем резерве. Но, конечно, Galera также поддерживает чтение и запись с несколькими мастерами, так что вы можете настроить это по своему вкусу.
Минимальный размер кластера должен быть равен трем, так как он должен быть нечетным, чтобы избежать ситуации разделения мозга, когда соединение между узлами по какой-либо причине прерывается. (Вы также можете использовать арбитр, но более простая настройка - это просто использовать как минимум 3 правильных узла кластера.) Мы используем 5 узлов, чтобы упростить обновление кластера и повысить устойчивость.
Galera также поддерживает кластер через WAN, но это требует дополнительной настройки в настройках сервера, чтобы не снижать производительность сервера. Обычно для приложений подойдет кластер с 3+ узлами, имеющими резервную сеть и питание.
Кое-что вы не сказали в своем вопросе, так это тип движка базы данных, который вы используете в своем кластере Galera. Видя, что у вас коррупция, я бы подумал, что это, вероятно, MyISAM? Если это так, вам необходимо перейти на использование InnoDB, поскольку MyISAM фактически не поддерживается Galera. У него также есть и другие преимущества, такие как более гибкая запись, позволяющая избежать повреждения данных даже в том маловероятном случае, когда кластер действительно развалится, и вам потребуется восстановить базу данных.