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

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

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

9 79
mysql scaling replication cluster-computing database-cluster

9 ответов:

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

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

кластеризации

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

MySQL NDB Cluster

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

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

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

Continuent Секвойя

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

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

Федерации

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

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

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

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

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

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

осколки и разделение

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

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

другие

Сфинкс

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

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

резюме

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

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

101

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

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

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

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

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

12

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

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

4

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

вот соответствующий образец 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

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

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

и так далее.

наконец, запустите " start slave;"

появляется ваш раб и начинает размножаться. Мило Ха!

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

вы можете проверить состояние ведомого устройства, запустив:

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

весело с ним.. оооочень легко...

2

ограничение "в памяти" не позволяет нам использовать MySQL cluster для наших почти 50 Гб данных, поэтому мы используем DRBD plus linux Heartbeat.

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

1

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

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

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

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

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

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

спасибо.

1

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

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

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

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

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

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

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

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

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

1

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

0

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

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

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

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

0