Решения по масштабированию для MySQL (репликация, кластеризация)

Question

При запуске Я работаю над тем, что мы сейчас рассматриваем решения по масштабированию для нашей базы данных. Ситуация несколько смущает (по крайней мере, для меня) с MySQL, который имеет кластер MySQL , репликация и репликация кластера MySQL (из версии 5.1.6) , которая является асинхронной версией кластера MySQL. Руководство по MySQL объясняет некоторые различия в его FAQ по кластеру , но из него трудно определить, когда использовать тот или иной.

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

Answer 1

Я много читал о доступных опциях. Я также получил в руки High Performance MySQL 2nd edition, которую я настоятельно рекомендую.

Вот что мне удалось собрать воедино:

Кластеризация

Кластеризация в общем смысле - это распределение нагрузки по многим серверам, которые представляются внешнему приложению как один сервер.

MySQL NDB Cluster

MySQL NDB Cluster - это распределенный механизм хранения в памяти, не имеющий общего доступа, с синхронной репликацией и автоматическим разделением данных (извините, я заимствовал буквально из книги «Высокая производительность», но они очень хорошо ее описали). Это может быть высокопроизводительное решение для некоторых приложений, но веб-приложения обычно не работают на нем.

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

Кроме того, требование в оперативной памяти не работает для многих больших баз данных.

Континуент Секвойя

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

Я прочитал хорошие вещи , и в целом это звучит довольно многообещающе.

Федерация

Федерация похожа на кластеризацию, поэтому я тоже ее подтолкнул. MySQL предлагает объединение через объединенный механизм хранения. Подобно кластерному решению NDB, оно хорошо работает только с простыми запросами, но еще хуже, чем кластер для сложных запросов (поскольку задержка в сети намного выше).

Репликация и балансировка нагрузки

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

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

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

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

Sharding и partioning

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

Существуют структуры абстракции, которые помогают справиться с разбиением данных, такие как Осколки гибернации , расширение Hibernate ORM (которое, к сожалению, находится на Java. Я использую PHP). HiveDB - еще одно такое решение, которое также поддерживает ребалансировку осколков.

Другие

Sphinx

Sphinx - это механизм полнотекстового поиска, который можно использовать не только для тестового поиска. Для многих запросов это намного быстрее, чем MySQL (особенно для группировки и сортировки), и может выполнять параллельные запросы к удаленным системам и объединять результаты, что делает его очень полезным при использовании с шардингом.

Обычно sphinx следует использовать с другими решениями для масштабирования, чтобы получить больше доступного оборудования и инфраструктуры. Недостатком является то, что вам снова нужен код приложения, чтобы быть в курсе сфинкса, чтобы использовать его с умом.

Краткое описание

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

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

Answer 2

Отказ от ответственности: я не использовал MySQL Cluster, поэтому я исхожу только из того, что слышал.

MySQL Cluster - решение высокой доступности. Это быстро, потому что все в памяти, но реальная точка продажи - доступность. Там нет единой точки отказа. С другой стороны, при репликации, если мастер выйдет из строя, вам придется переключиться на реплику, и может быть небольшое время простоя. (хотя решение DRBD является еще одной альтернативой, которая имеет высокую доступность)

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

Я думаю, что если HA не очень важен (читай: вероятно, нет), это больше хлопот (и денег), чем стоит. Репликация чаще - лучший путь.

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

Answer 3

Есть несколько хороших дискуссий о том, как люди, которые поддерживают drupal.org, структурировали свои серверы баз данных:

• Сушит блог Байтаерта
• Блог WorkHabits

Оба с 2007 года, поэтому поддержка кластеризации может быть сильнее, но в то время, когда они выбрали репликацию.

Answer 4

Самое классное в репликации то, что это легко. Просто установите 2 блока mysql, измените serverID во втором блоке, а затем укажите второй блок на первый, используя команду master для изменения.

Вот соответствующий пример конфигурации slave my.cnf

#
#       Log names
#

log-bin=binlog
relay-log=relaylog
log-error=errors.log

#
#       Log tuning
#

sync_binlog = 1
binlog_cache_size = 1M

#
#       Replication rules (what are we interested in listening for...)
#
#       In our replicants, we are interested in ANYTHING that isn't a permission table thing
#

replicate-ignore-db =      mysql
replicate-wild-ignore-table=mysql.%

#
#       Replication server ID
#

server-id      =        2

Поэтому убедитесь, что каждый ведомый получает идентификатор сервера, увеличенный на 1 (так, чтобы следующий ведомый был сервером 3)

установить имя пользователя и пароль, к которым может подключиться подчиненное устройство, Тогда беги изменить мастер на MASTER_HOST = 'x.x.x.x'; смените мастер на MASTER_PASSWORD = "xxxxx";

и так далее.

наконец, запустите «запуск ведомого»;

Поднимается ваш раб и начинает копировать. милая да!

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

Вы можете проверить статус ведомого, выполнив:

показать статус ведомого \ G

Веселитесь с этим .. оооочень легко ...

Answer 5

на мой взгляд, путаница здесь просто возвращает меня во Мнезию. Благодаря фрагментации, декларативному и прагматичному способу обработки индексов прозрачность расположения реплик базы данных e.t.c

В нашей настройке мы запускаем MySQL Cluster и Mnesia. Наши данные являются сезонными. Так что через некоторое время мы избавляемся от мнезийных данных, которые больше не используются, и выбрасываем их в кластер MYSQL. Это делает нашу мнезию эффективной. Также у нас есть приложения, реализованные на языках основного потока (Python, Clojure e.t.c), которые используют данные непосредственно из MySQL.

В двух словах, мы запускаем mnesia поверх MySQL Cluster. MySQL Cluster может обрабатывать большие наборы данных, база данных может увеличиться до 50 ГБ плюс. У нас есть mnesia для приложений Erlang / OTP . Java и PHP получают доступ к данным из mnesia через специализированные REST (недавно Thrift ) API, использующие JSON и XML в качестве форматов обмена.

Уровень доступа к данным имеет абстрагированный доступ к данным в Mnesia и старым поставляемым данным в MySQL Cluster, если это необходимо. Mnesia здесь, по сути, для поддержки приложений Erlang / OTP. Как только они перегружены данными, мы добавляем их в MYSQL Cluster. Уровень доступа к данным может обращаться как к данным в mnesia, так и к MySQL в абстрактном API от имени всех приложений.

Что я могу здесь сказать, так это то, что Мнезия была для нас лучшим вариантом. Таблицы сильно фрагментированы и проиндексированы, запросы выполняются очень хорошо, а база данных реплицируется в двух местах, соединенных через туннель.

Ранее мы опасались, что mnesia может не обрабатывать столько записей, сколько возможно из-за ограничения размера таблицы. Но мы нашли это утверждение неверным. При хорошей настройке (фрагментации) наши базы данных mnesia хранят в среднем около 250 миллионов записей в год.

Мы извлекли выгоду из сложной структуры данных Эрланга и того факта, что Mnesia может поглотить ее без изменений. Приложения Erlang / OTP являются наиболее эффективными из всех других приложений на устаревших языках, и с нашей системой мы планируем перевести все это на технологию Erlang / OTP. Из Erlang мы, по-видимому, без особых усилий получаем доступ к данным из MySQL Cluster и выполняем запросы на его серверах. На самом деле, мы пришли к выводу, что его Erlang / OTP может полностью использовать ресурсы сервера MySQL из-за его (Erlang) большого параллелизма.

Mnesia сработала для нас очень хорошо. Mnesia полностью изменила наш взгляд на базы данных благодаря своей потрясающей производительности. Наши ядра ЦП сервера Solaris работают в среднем около 48% в часы пик.

Я советую вам проверить mnesia, и кто знает, это может удовлетворить ряд ваших потребностей в распространении или репликации.

Answer 6

Во время исследования высокой доступности я столкнулся со многими решениями, и, вероятно, в нашем случае, когда система была более интенсивной, я обнаружил, что кластер DRBD лучше, чем кластер NDB, поскольку он обеспечивает большее количество транзакций в секунду.

Mysql Replication может предоставить вам машину для резервного копирования, которую можно использовать в качестве ведомого для чтения или в случае аварийного восстановления.

С помощью различных режимов управления транзакциями, предоставляемых DRBD, вы можете несколько снизить производительность, которая снижается при репликации данных по сети на уровне устройства. Для надежной системы, которая не потеряет ни одной транзакции в случае сбоя, используйте режим C, иначе перейдите к B.

Я попытался перечислить некоторые уроки, которые я получил во время настройки кластера DRBD на http://www.techiegyan.com/?p=132

Он действительно хорошо работает на выделенном соединении для репликации, т.е. резервирует отдельные высокоскоростные интерфейсы на обеих машинах только для репликации drbd. Heartbeat может прекрасно управлять кластером со всеми сервисами, то есть IP-адресами, разделами, drbd и mysql.

Мне еще предстоит открыть конфигурацию Мастер-Мастер на DRBD. Буду обновлять, как и когда я добьюсь успеха в этом.

Спасибо.

Answer 7

Ограничение «в памяти» не позволяет нам использовать кластер MySQL для наших почти 50 ГБ данных, поэтому мы используем DRBD плюс linux Heartbeat .

Это похоже на массив raid между двумя (или более) блоками, который синхронизирует базы данных / журналы / конфигурации (но только один сервер может быть «живым» одновременно). Аварийное переключение происходит автоматически, использует тот же IP-адрес и быстро, как перезапуск mysql, так что это было для нас хорошим решением.

Answer 8

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

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

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

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

Answer 9

Я не использовал их, но из документации я бы сказал, что репликация является предпочтительным решением, если наибольшая нагрузка - чтение из базы данных.