Сравнение различных реализаций кластера для MySQL?

Question

[Евгений]

Всем привет!

Надеюсь, что мой вопрос не выходит за рамки данного ресурса и найдёт ответ.

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

В глаза сразу бросается использование какой-либо реализации кластера MySQL, и рассматриваю несколько решений:

• MySQL Cluster
• Percona XtraDB Cluster
• MariaDB Galera Cluster

К сожалению, ранее с ними не работал и моих практических/теоретических знаний по ним немного(поднял Percona XtraDB Cluster на виртуалках - с виду работает). Русской информации так же гуглится немного. Надеюсь, многоуважаемое сообщество, поможет мне с выбором технологии.

Из исходных данных:

• Проект работает с одним MySQL 5.5 сервером. Таблицы innodb
• Операции чтения превалируют над операциями записи
• Серьёзных переработок кода проекта хотелось бы избежать
• Для реализации решения можно(и планируется) использовать 3+ сервера. Они могут быть разнесены по разным ДЦ

По большей части интересует следующее:

1. Есть ли где-нибудь внятные материалы по сравнению всех трёх решений?
2. Насколько стабильны кластерные решения?(вылеты нод из работы, ситуации при пропадании связи)
3. Сильные/слабые стороны определённых решений, какие они?
4. Обслуживание каждого из решений на уровне администратора(сложно, легко, восстановление после сбоя)?
5. Есть ли какие-либо альтернативы?

Буду рад Вашим ответам :)

PS Так как в данной теме ещё "плаваю", мог упустить какие-либо важные детали или вопросы, которые могут возникнуть по ходу изучения/внедрения технологии. Если Вы подскажете их - это будет очень круто!

Answer 1

[Евгений]

Всем спасибо за помощь!

В конечном итоге была выбрана кластеризация с использованием Percona Cluster, как наиболее стабильное решение с наименьшими затратами на внедрение.

В работу внедрили уже несколько кластеров на Percona(пока что из 3х серверов). Падение одной ноды переживает нормально. Проблем с какой-либо потерей данных не наблюдается.

Да, при географическом распределении, при записи данных, задержки есть. Но между Селектел и Hetzner - вполне терпимы.
Между Питером и Москвой тоже не очень большие(всё зависит от способа работы сайта с БД).

Как итог - можно использовать Percona Cluster и не бояться :) Всё зависит от допустимой "деградации" Вашей системы. В данном случае это некоторая задержка при записи данных(но ведь запросов на запись обычно меньше, чем на чтение ;))

Comments

[Алексей]

Евгений, а спустя 2 года и выходом новых версий продуктов, всё также используете Percona Cluster? Стоим сейчас перед аналогичным выбором, интересует географическое распределение, изменилось ли что за два года? Много ли проблем при использовании в production?

[Евгений]

Алексей:
Алексей, добрый вечер!

Боюсь, что полноценно не смогу помочь вам с ответом, т.к. полтора года назад я сменил место работы и более с распределёнными кластерами Percona Cluster не работал.
На текущем месте видел у соседней команды Galera Cluster в рамках одного ДЦ - работает нормально, но внутренностями не интересовался.

В своих текущих реалиях могу сказать, что между ДЦ мы используем асинхронную репликацию между несколькими PostgreSQL серверами. Т.к. сервера в Новосибирске, Москве и Европе, а объёмы данных велики(>30-100 Гб на некоторые БД) - синхронная репликация для нас не позволительна. Восстановление слейвов - редко, но бывает и мы считаем это нормальной ситуацией, которая просто должна хорошо мониториться.

[Алексей]

Евгений:
Всё равно спасибо за ответ. Последние 3 года так же используем асинхронную репликацию, правда на Mysql 5.5 ещё, объём бд 25 Гб. И тут возникает пауза по времени переключения slave в master с рестартом Mysql и дальнейший прогрев бд. Одним из вариантов решения подумали о Percona Xtradb Cluster.

Answer 2

[Пума Тайланд]

Перкона использует галера кластер решение
В стандартном мускуле все на NDB таблицах
Кластер и разнесение по датацентрам маловероятное решение , тут либо синхронная работа либо дикие задержки если сервера далеко.

Comments

[Евгений]

Спасибо за Ваш ответ!
Сталкивались ли Вы с NDB таблицами? Чем они так плохи?

Сервера - Hetzner и Селектел. Да, канал между ними не сильно широкий, но пинг порядка 44 мс..

[Пума Тайланд]

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

Answer 3

[Сергей Петриков]

Percona XtraDB Cluster и MariaDB Galera Cluster у меня на тесте работали одинаково в пределах погрешности, стандартный мускуль сильно хуже.
1. Самые внятные материалы - официальная дока проектов, все ховту что я находил (года 2 назад было) не соответствовали реальности
2. Стабильность очень средняя, вылет одной ноды переживает нормально, вылет 2х и более одновременно на галера и клонах (мускуль даже не тестировал из за поганой производительности) с непредсказуемым результатом от нормально до полной рассинхронизации с необходимостью ручного вмешательства, от чего зависит не понял, похоже фаза луны.
3. Сильные - таки удобно, слабые - было нестабильно, сейчас не знаю, ну и при разных географически площадках сильные тормоза, очень требовательно к среде передачи данных.
4. От пары минут, до восстановления с последнего бэкапа.
5. Кластер на уровне ФС, а не мускулей, Оракл.

Comments

[Евгений]

@RicoX , спасибо за ответ!
Можете ли Вы рассказать - были ли Ваши тесты на каком-либо боевом проекте, либо это было "ручное" тестирование?
Требовалось ли как-либо подстраивать БД для их размещения в кластерах(особенно интересуют различия между Percona и MySQL-Cluster)?

[Сергей Петриков]

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

[Евгений]

На виртуалках уже развернул кластер на Percona - при простых запросах отрабатывает на "ура!", попробую более нагруженные тесты прогнать на днях.
Скажите, пожалуйста, на скольких машинах у Вас был развёрнут кластер? Ноды выходили из него без каких-либо предупреждений? Выходил из строя именно сервис Percona, или весь сервер целиком? После выхода из строя - требовалось восстанавливать данные с ноды донора?

[Сергей Петриков]

Было развернуто на 5 нодах, ноды выходили без предупреждений, т.к. разнос был на 3 техплощадки, то-есть теряем канал с техплощадкой где 2 ноды, сразу подымаем примерно раз из 5 теряем синхронизацию, сам сервер понятно работает, но синхронизация не идет полный лог ошибок, ок исключаем отпавшие 2 ноды из кластера, делаем ресинк, включаем - все пошло. Пробовали эмулировать падение более половины нод одновременно - из 3 раз 1 раз получили полную кашу в данных. Может готовили не правильно, конфигурация была базовая без доработки, но решили отказаться. У провайдера было 3 ноды на одной техплощадке, там проблем небыло никаких.

Answer 4

[andreylartsev]

1. MariaDB Gallera Cluster и Percona Cluster это по сути одно и то же решение, так как базируется на одной технологии - Gallera library (https://github.com/codership/galera)
https://mariadb.com/kb/en/mariadb/what-is-mariadb-...
www.percona.com/doc/percona-xtradb-cluster/5.6/int...

2. Oracle MySQL Cluster это sharded In memory DB. Это решение скорее для low latency а не для High availability.
Главный недостаток это коммерческая лицензия которая будет стоить в зависимости от размера БД и может стоить десятки и сотни тысяч зеленых денег.
И часть SQL кода скорее всего придется переписать.