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

Понимание кластера MariaDB Galera

Что такое кластер MariaDB Galera?

MariaDB Galera Cluster — это решение для кластеризации баз данных с открытым исходным кодом, построенное на технологии репликации Galera. Он обеспечивает синхронную репликацию с несколькими мастерами для MariaDB, обеспечивая согласованность данных на всех узлах в кластере.

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

Кластеры бывают двух основных конфигураций: активный-пассивный и активный-активный. В активно-пассивных кластерах все операции записи выполняются на одном активном сервере, а затем копируются на один или несколько пассивных серверов, которые готовы вступить во владение только в случае сбоя активного сервера. Некоторые активно-пассивные кластеры также позволяют выполнять операции SELECT на пассивных узлах. В активно-активном кластере каждый узел доступен для чтения и записи, и изменение, внесенное в один, реплицируется на все.

MariaDB Galera Cluster — это виртуально синхронный многоосновной кластер для MariaDB.

Ключевые особенности и преимущества Galera Cluster

Функции

  • Практически синхронная репликация.
  • Активно-активная многоосновная топология.
  • Чтение и запись на любой узел кластера.
  • Автоматический контроль членства, отказавшие узлы удаляются из кластера.
  • Автоматическое присоединение узлов.
  • Настоящая параллельная репликация на уровне строк.
  • Прямые подключения к клиентам, собственный внешний вид MariaDB.

Преимущества

Вышеуказанные функции дают несколько преимуществ для кластерного решения СУБД, в том числе:

  • Нет задержки реплики.
  • Отсутствие потерянных транзакций.
  • Читайте масштабируемость.
  • Меньшие задержки клиента.

Архитектура кластера MariaDB Galera

  1. Роли узлов:
    В кластере Galera каждый узел может действовать как ведущий и подчиненный одновременно. Это позволяет распространять запросы на запись по всему кластеру, обеспечивая согласованность данных.
  2. Связь между узлами и синхронизация:
    Galera Cluster использует протокол репликации на основе многоадресной рассылки для эффективной связи и синхронизации между узлами. Узлы совместно используют наборы записей и применяют их для обеспечения согласованности данных.
  3. Кворум и репликация на основе сертификации.
    Кворум определяет минимальное количество узлов, необходимое для поддержания операционной доступности и согласованности. Репликация на основе сертификации присваивает каждой транзакции уникальный индекс сертификации, обеспечивая согласование порядка совершения транзакций.

В кластере MariaDB сервер реплицирует транзакцию во время фиксации, передавая набор записей, связанный с транзакцией, каждому узлу в кластере. Клиент подключается напрямую к СУБД и в большинстве случаев ведет себя так же, как и нативная версия MariaDB. API wsrep (API репликации набора записей) определяет интерфейс между репликацией Galera и MariaDB.

Преимущества кластера MariaDB Galera

Высокая доступность и отказоустойчивость:

  • Непрерывные операции с базой данных: Galera Cluster гарантирует, что даже в случае отказа одного или нескольких узлов кластер продолжит работу без простоев.
  • Автоматические механизмы аварийного переключения и восстановления: в случае сбоя узла Galera Cluster автоматически продвигает новый узел на роль главного, обеспечивая бесперебойное обслуживание базы данных.

Масштабируемость и балансировка нагрузки:

  • Гибкое масштабирование с дополнительными узлами: Galera Cluster позволяет легко добавлять узлы для обработки растущих рабочих нагрузок и роста данных.
  • Распределенная балансировка нагрузки и параллельная обработка. Кластер распределяет запросы на чтение и запись по нескольким узлам, обеспечивая горизонтальную масштабируемость и повышенную производительность.

Синхронная репликация:

  • Обеспечение строгой согласованности данных. При синхронной репликации все узлы в кластере одновременно имеют одни и те же данные, что обеспечивает надежную согласованность данных.
  • Репликация в реальном времени на всех узлах: изменения, внесенные в любой узел в кластере, немедленно реплицируются на все остальные узлы, обеспечивая синхронизацию данных в реальном времени.

Примеры технического использования Galera

Читать мастер

Традиционная топология «ведущий-ведомый» MariaDB, но с Galera все «ведомые» узлы всегда могут быть ведущими — это просто приложение, которое рассматривает их как ведомые. Репликация Galera может гарантировать нулевую задержку ведомых устройств для таких установок и, благодаря параллельному применению ведомых устройств, гораздо лучшую пропускную способность для кластера.

Кластеризация глобальной сети

Синхронная репликация отлично работает по сети WAN. Будет задержка, пропорциональная времени приема-передачи по сети (RTT), но она влияет только на операцию фиксации.

Аварийное восстановление

Аварийное восстановление — это подкласс репликации WAN. Здесь один центр обработки данных является пассивным и только получает события репликации, но не обрабатывает никакие клиентские транзакции. Такой удаленный центр обработки данных будет постоянно обновляться, и потери данных не произойдет. Во время восстановления резервный сайт просто назначается основным, и приложение может продолжать работу в обычном режиме с минимальной задержкой отработки отказа.

Ластик задержки

Благодаря топологии репликации WAN узлы кластера могут располагаться близко к клиентам. Поэтому все операции чтения и записи будут очень быстрыми при подключении к локальному узлу. Задержка, связанная с RTT, будет ощущаться только во время фиксации, и даже тогда она может быть в целом принята конечным пользователем. Обычно конечным пользователям доставляет удовольствие медленное время отклика при просмотре, а операции чтения выполняются настолько быстро, насколько это возможно.

Лучшие практики для кластера MariaDB Galera:

Сетевые соображения:

  • Оптимизация задержки и пропускной способности: минимизация задержки в сети и обеспечение достаточной пропускной способности для обеспечения быстрой и надежной связи между узлами.
  • Предотвращение и восстановление из сетевых разделов: реализация стратегий для обнаружения и устранения проблем с сетевыми разделами для поддержания стабильности кластера.

Балансировка нагрузки и распределение нагрузки:

  • Эффективные стратегии балансировки нагрузки: внедрение методов балансировки нагрузки для равномерного распределения запросов на чтение и запись по узлам, оптимизации использования ресурсов.
  • Эффективное управление трафиком чтения и записи: маршрутизация запросов на чтение к определенным узлам для разгрузки основного мастера и балансировки рабочей нагрузки.

Безопасность и аутентификация:

  • Защита связи кластера: шифрование связи между узлами для защиты конфиденциальности и целостности данных.
  • Управление пользователями и контроль доступа: внедрение надлежащих механизмов управления пользователями и контроля доступа для обеспечения авторизованного доступа к кластеру.

Настройка и оптимизация производительности:

  • Настройка системных переменных и параметров кэша: тонкая настройка различных системных переменных и параметров кэша для оптимизации производительности кластера в зависимости от характеристик рабочей нагрузки.
  • Методы индексирования и оптимизации запросов: анализ планов выполнения запросов, оптимизация запросов и использование соответствующих стратегий индексирования для повышения производительности базы данных.

Реальные примеры использования кластера Galera

Электронная коммерция и онлайн-приложения

  • Обеспечение бесперебойной работы при пиковых нагрузках
  • Управление большими объемами транзакций

Большие данные и аналитика

  • Обработка сложных запросов и агрегаций
  • Масштабирование кластера с учетом роста данных

Развертывание в нескольких центрах обработки данных

  • Географически распределенные кластеры для аварийного восстановления
  • Достижение доступа с низкой задержкой для глобальных баз пользователей

Что на самом деле происходит при запуске сервера MariaDB?

  • Каждый Сервер пытается установить сетевое соединение с другими Серверами в кластере.
  • Группы подключенных серверовобразуют компонент
  • Когда сервер устанавливает сетевое соединение с основным компонентом, он синхронизирует свою локальную базу данных с базой данных кластера.
  • Как член Первичного компонента, Сервер становится работоспособным — он может принимать чтение и запись запросов от клиентов.
  • Во время запуска основным компонентом является сервер, загружаемый для работы в качестве основного компонента. Когда кластер подключен к сети, Первичным компонентом становится любая комбинация Серверов, включающая как минимум более половины общего количества Серверов.

Сервер или группа Серверов, которые теряют сетевое соединение с большей частью кластера, становятся неработоспособными.

Галера прекрасна, кроме:

  • Galera не является решением для масштабирования записи. Нужно писать быстрее? Тогда Galera — это не то, что вам нужно, потому что вы ограничены скоростью записи на одном узле. Кроме того, обычный рекомендуемый вариант использования — направлять записи на один узел, а затем разделять чтение. Это помогает при тупиковых ситуациях, связанных со сбоем сертификации записи.
  • Задержка записи фактически становится скоростью времени пинга между узлами. Задержка записи одной строки — это самое большое время прохождения туда и обратно в вашем кластере. Да, вы можете запускать Galera по всему континенту, но будьте готовы к более медленным коммитам. Однако ваш вариант использования может быть в порядке.
  • Если узел будет удален или выйдет из строя, вам придется дождаться полного восстановления, прежде чем он снова станет доступен, пока работает архив, перетаскивая узел в вашем кластере, который только что стал на один узел меньше. Большая база данных означает большее восстановление.
  • Помните тот коммит, который должен был ждать задержки узла? Расскажу о триггерах. Посмотрите на синтаксис триггера… «Для каждой строки». Да, они имеют это в виду. Для каждой чертовой строки вы получаете время прохождения туда и обратно.
  • Используете планировщик событий? Не с Галерой. Да, он действительно будет работать, но вам придется управлять тем, на каком отдельном узле запущен планировщик. Кластер не допустит более одного и отключит остальные. Это здорово. Да, за исключением тех пор, пока запланированные действия не начнут стоять в очереди, блокируя wsrep, а затем вызывая сбои, требующие SST. Видите ли, запланированные события как бы игнорируют все эти повторные попытки тупиковой ситуации с ошибкой сертификации записи, а затем все очень быстро идет наперекосяк. Каждое событие — это новое соединение, которое не будет завершено из-за сбоя фиксации, но сеанс все еще остается открытым. Затем они создают еще больше вещей в подвешенном состоянии, и в конечном итоге весь кластер выходит из строя. Да, другие узлы будут удалены из-за истечения времени ожидания, и вы останетесь только с планировщиком. Конечно, он станет одиноким, и кворум не сработает, пока вы его тоже не снимете. Он также не выключится корректно, и вам придется убить -9 этот узел, а затем запустить его вручную. Когда вы выполняете обычный запуск, произойдет сбой, потому что нет других узлов, поэтому вам нужно будет выполнить запуск начальной загрузки кластера. И обязательно выберите узел с самым продвинутым журналом транзакций, потому что иначе это не сработает. Затем запустите другие узлы вручную, и они обязательно захотят создать SST-архив. И часто после неприятного сбоя с uuid хоста происходит что-то странное, и SST не может присоединиться, что требует второго запуска. Тем временем твой менеджер трется о твою ногу, желая получить статус каждые 6 минут.
  • Что делает ваш код, когда видит взаимоблокировку? С Galera вы должны повторить попытку, потому что ошибка взаимоблокировки указывает на сбой сертификации записи, но, возможно, временно.
  • Изменения схемы теперь являются абсолютным кошмаром. Вы, наверное, избалованы алгоритмом = общий доступ, блокировка = нет. Да, это все еще будет работать с параллельной активностью, но только для вашего локального узла. Что происходит, когда это действие завершается, а затем реплицируется на другие узлы, так это то, что, пока оно выполняется на других узлах, весь чертов кластер блокируется. В вашем случае большое изменение в одном приложении теперь блокирует запись из других 10. Ваши альтернативы — использовать что-то вроде pt-online-schema-change для всего или извлекать узлы по одному из потока репликации, изменять схему, вводить их обратно, и это работает только в том случае, если ваши изменения схемы закодированы правильным образом, чтобы быть устойчивыми, иметь новые столбцы в конце таблицы и всегда указывать значения по умолчанию. Это очень быстро становится неинтересным даже с автоматизацией, поскольку всплывают небольшие пограничные случаи и узлы удаляются, потому что что-то пошло не так, и сертификация записи обнаружила разницу в дате.

Замечания о кластере Galera:

  1. Galera может обеспечить настоящий мультимастер с = 3 узлами, что означает, что его можно довольно легко бросить за балансировщиком нагрузки, все еще используя innodb.
  2. Запись на несколько узлов — большая проблема, нужно учитывать, как будет вести себя автоинкремент, и лучше всего писать на виртуальный IP на одном узле. Кроме того, параллельная запись на несколько узлов не дает никаких преимуществ, поскольку это N-сторонняя синхронная репликация, а это означает, что каждая запись должна быть подтверждена на всех N узлах, что фактически делает время прохождения по сети в обоих направлениях дополнительным фактором производительности записи.
  3. Затем, когда узел выходит из строя, для восстановления требуется загрузить полную копию с другого узла, что также является процессом, эффективно замедляющим работу всего кластера. Когда вы делаете синхронный, нет возможности просмотреть журнал повторов.
  4. В общем, Galera — действительно отличное решение, если у вас быстрое оборудование и нагрузка, ориентированная на чтение. В других случаях не так много, если только у вас нет особой потребности в синхронной репликации. Пока вы не наберете несколько тысяч запросов в секунду, все будет замечательно, по крайней мере, на бумаге.

Заключение

MariaDB Galera Cluster позволяет компаниям создавать высокодоступные, масштабируемые и отказоустойчивые инфраструктуры баз данных. Механизмы синхронной репликации и автоматического аварийного переключения обеспечивают непрерывную работу, а архитектура обеспечивает легкое масштабирование и балансировку нагрузки. Следуя передовым методам и учитывая конкретные требования своей среды, организации могут использовать возможности MariaDB Galera Cluster для поддержки критически важных приложений, обработки больших наборов данных и обеспечения непрерывности бизнеса в случае сбоев.