На стартапе, над которым я работаю, мы сейчас рассматриваем решения для масштабирования нашей базы данных. Ситуация несколько сбивает (по крайней мере для меня) с MySQL, который имеет кластер MySQL , репликацию и репликацию кластера MySQL (начиная с версии 5.1.6), который является асинхронной версией кластера MySQL. Руководство MySQL объясняет некоторые различия в его часто задаваемых вопросах о кластерах , но из него трудно определить, когда использовать тот или другой.
Я был бы признателен за любой совет от людей, которые знакомы с различиями между этими решениями, а также с их плюсами и минусами и когда вы рекомендуете использовать каждое из них.
mysql
replication
scaling
cluster-computing
database-cluster
Эран Гальперин
источник
источник
Ответы:
Я много читал о доступных вариантах. Я также получил в свои руки 2-е издание High Performance MySQL, которое очень рекомендую.
Вот что мне удалось собрать воедино:
Кластеризация
Кластеризация в общем смысле - это распределение нагрузки по множеству серверов, которые внешнему приложению кажутся одним сервером.
Кластер MySQL NDB
MySQL NDB Cluster - это распределенный механизм хранения в памяти без совместного использования ресурсов с синхронной репликацией и автоматическим разделением данных (извините, я буквально заимствую из книги High Performance, но они там очень хорошо изложили это). Это может быть высокопроизводительное решение для некоторых приложений, но обычно веб-приложения с ним плохо работают.
Основная проблема заключается в том, что помимо очень простых запросов (которые касаются только одной таблицы), кластеру, как правило, придется искать данные на нескольких узлах, что приводит к появлению задержки в сети и значительному замедлению времени выполнения запросов. Поскольку приложение рассматривает кластер как один компьютер, оно не может сказать ему, с какого узла получить данные.
Кроме того, требование оперативной памяти не выполняется для многих больших баз данных.
Континент Секвойя
Это еще одно решение кластеризации для MySQL, которое действует как промежуточное ПО поверх сервера MySQL. Он предлагает синхронную репликацию, балансировку нагрузки и аварийное переключение. Это также гарантирует, что запросы всегда получают данные из последней копии, автоматически выбирая узел, на котором есть свежие данные.
Я прочитал о нем несколько хороших отзывов , и в целом он звучит многообещающе.
Федерация
Федерация похожа на кластеризацию, поэтому я ее тоже потянул. MySQL предлагает объединение через механизм объединенного хранилища. Подобно кластерному решению NDB, оно хорошо работает только с простыми запросами - но еще хуже кластер для сложных (поскольку сетевая задержка намного выше).
Репликация и балансировка нагрузки
MySQL имеет встроенную способность создавать репликации базы данных на разных серверах. Это можно использовать для многих вещей - разделения нагрузки между серверами, горячего резервного копирования, создания тестовых серверов и аварийного переключения.
Базовая настройка репликации включает в себя один главный сервер, обрабатывающий в основном записи, и один или несколько подчиненных серверов, обрабатывающих только чтение. Более продвинутый вариант - это конфигурация мастер-мастер , которая также позволяет масштабировать операции записи за счет одновременной записи нескольких серверов.
У каждой конфигурации есть свои плюсы и минусы, но одна проблема, которую они все разделяют, - это задержка репликации: поскольку репликация MySQL является асинхронной, не все узлы имеют самые свежие данные за все время. Это требует, чтобы приложение знало о репликации и включало запросы с поддержкой репликации, чтобы работать должным образом. Для некоторых приложений это может не быть проблемой, но если вам всегда нужны самые свежие данные, все становится несколько сложнее.
Репликация требует некоторой балансировки нагрузки для разделения нагрузки между узлами. Это может быть простое изменение кода приложения или использование специальных программных и аппаратных решений.
Шардинг и разделение
Шардинг - это обычно используемый подход для масштабирования решений для баз данных. Вы разделяете данные на более мелкие сегменты и распределяете их по разным узлам сервера. Это требует, чтобы приложение было осведомлено об изменениях в хранилище данных, чтобы работать эффективно, поскольку ему необходимо знать, где найти необходимую информацию.
Существуют инфраструктуры абстракции, которые помогают справиться с сегментированием данных, такие как Hibernate Shards , расширение ORM Hibernate (которое, к сожалению, находится в Java. Я использую PHP). HiveDB - еще одно такое решение, которое также поддерживает ребалансировку сегментов .
Другие
Сфинкс
Sphinx - это система полнотекстового поиска, которую можно использовать не только для тестового поиска. Для многих запросов он намного быстрее, чем MySQL (особенно для группировки и сортировки), и может запрашивать удаленные системы параллельно и агрегировать результаты, что делает его очень полезным при использовании с сегментированием.
В общем, sphinx следует использовать с другими решениями для масштабирования, чтобы получить больше доступного оборудования и инфраструктуры. Обратной стороной является то, что вам снова нужен код приложения, чтобы знать о sphinx, чтобы использовать его с умом.
Резюме
Решения для масштабирования различаются в зависимости от потребностей приложения, которому это необходимо. Для нас и для большинства веб-приложений я считаю, что репликация (возможно, с несколькими мастерами) - это способ балансировки нагрузки, распределяющей нагрузку. Разделение конкретных проблемных областей (огромные таблицы) также необходимо для возможности масштабирования по горизонтали.
Я также собираюсь попробовать Continuent Sequoia и посмотреть, действительно ли он может делать то, что обещает, поскольку это потребует наименьшего количества изменений в коде приложения.
источник
Отказ от ответственности: я не использовал MySQL Cluster, поэтому я исхожу только из того, что слышал.
MySQL Cluster - это решение высокой доступности (HA). Это быстро, потому что все в памяти, но главное преимущество - доступность. Нет единой точки отказа. С другой стороны, при репликации, если мастер выходит из строя, вам придется фактически переключиться на реплику, и это может привести к небольшому времени простоя. (хотя решение DRBD - еще одна альтернатива с высокой доступностью)
Кластер требует, чтобы вся ваша база данных умещалась в памяти. Это означает, что на каждой машине в кластере должно быть достаточно памяти для хранения всей базы данных. Так что это невыполнимое решение для очень больших баз данных (или, по крайней мере, это очень дорогое решение).
Я думаю, что если HA не очень важна (читай: вероятно, нет), это больше хлопот (и денег), чем того стоит. Чаще всего лучше использовать репликацию.
Изменить: я забыл упомянуть также, что кластер не позволяет использовать внешние ключи, а сканирование диапазона выполняется медленнее, чем на других движках. Вот ссылка, в которой говорится о известных ограничениях кластера MySQL
источник
Есть несколько хороших дискуссий о том, как люди, поддерживающие drupal.org, структурировали свои серверы баз данных:
Оба относятся к 2007 году, поэтому поддержка кластеризации сейчас может быть сильнее, но в то время они выбрали репликацию.
источник
В репликации замечательно то, что это легко. Просто настройте 2 ящика mysql, измените serverID во втором поле, а затем укажите второй ящик на первом, используя команду change master to.
Вот соответствующий пример конфигурации my.cnf slave
# # 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)
установите имя пользователя и пароль, к которым ведомое устройство может подключиться. Затем запустите команду change master на MASTER_HOST = 'xxxx'; изменить мастер на MASTER_PASSWORD = "xxxxx";
и так далее.
наконец, запустите "start slave;"
Подходит ваш раб и начинает репликацию. милая да!
Предполагается, что вы начинаете с 2 пустых серверов. Затем вы можете выгрузить свою базу данных на главный сервер, и по мере ее загрузки она также загрузится на подчиненный сервер.
Вы можете проверить статус ведомого, запустив:
показать статус ведомого \ G
Получайте удовольствие .. так просто ...
источник
Во время исследования высокой доступности я столкнулся со многими решениями и, вероятно, в нашем случае, который был более интенсивной системой записи, я обнаружил, что кластер DRBD лучше, чем кластер NDB, поскольку он обеспечивает большее количество транзакций в секунду.
Mysql Replication может предоставить вам резервную машину, которая может использоваться как ведомое устройство чтения или может использоваться в случае аварийного восстановления.
Благодаря различным режимам управления транзакциями, предоставляемым DRBD, вы можете несколько снизить производительность, связанную с репликацией данных на уровне устройства по сети. Для надежной системы, которая не должна терять транзакции в случае сбоя, используйте режим C, иначе выберите B.
Я попытался перечислить некоторые из уроков, которые я сделал во время настройки кластера DRBD, на http://www.techiegyan.com/?p=132
Он действительно хорошо работает на выделенном соединении для репликации, т.е. резервирует отдельные высокоскоростные интерфейсы на обеих машинах только для репликации drbd. Heartbeat может хорошо управлять кластером со всеми службами по очереди, т.е. IP-адресами, разделами, drbd и mysql.
Мне еще предстоит открыть для себя конфигурацию Master-Master на DRBD. Буду обновлять по мере того, как я добьюсь успеха в этом.
Благодарю.
источник
на мой взгляд, путаница здесь просто возвращает меня во Мнесию. С фрагментацией, декларативным и прагматическим способом обработки индексов, прозрачностью расположения реплик базы данных и т. Д.
В нашей настройке мы запускаем MySQL Cluster и Mnesia. Наши данные носят сезонный характер. Итак, через какое-то время мы освобождаем память от данных, которые больше не используются, и бросаем их в кластер MYSQL. Благодаря этому наша память остается эффективной. Также у нас есть приложения, реализованные на основных языках потока (Python, Clojure и т. Д.), Которые используют данные непосредственно из MySQL.
Короче говоря, мы запускаем mnesia поверх MySQL Cluster. Кластер MySQL может обрабатывать большие наборы данных, база данных может увеличиваться до 50 ГБ. У нас есть mnesia, поддерживающая приложения Erlang / OTP . Данные доступа Java и PHP из mnesia через настроенный REST (недавно Thrift ) с использованием JSON и XML в качестве форматов обмена.
Уровень доступа к данным имеет абстрагированный доступ к данным в Mnesia и старым отправленным данным в MySQL Cluster, если это необходимо. Mnesia здесь, по сути, для поддержки приложений Erlang / OTP. Как только они загружаются данными, мы бросаем их в кластер MYSQL. Уровень доступа к данным может обращаться как к данным в mnesia, так и к MySQL в абстрактном API от имени всех приложений.
Что я могу сказать здесь, так это то, что Mnesia был для нас лучшим вариантом. Таблицы сильно фрагментированы и индексированы, запросы выполняются очень хорошо, а база данных реплицируется в 2 местах, связанных через туннель.
Ранее мы опасались, что mnesia может не обработать как можно больше записей из-за ограничения размера таблицы. Но мы нашли это утверждение неверным. При хорошей настройке (фрагментации) наши базы данных мнезии содержат в среднем около 250 миллионов записей в год.
Мы извлекли выгоду из сложной структуры данных Erlang и того факта, что Mnesia может поглотить ее без изменений. Приложения Erlang / OTP являются наиболее эффективными из всех других приложений на устаревших языках, и с нашей системой мы планируем перенести все это на технологию Erlang / OTP. Из Erlang нам кажется, что мы получаем доступ к данным из MySQL Cluster и очень чудесно выполняем запросы на его серверах. Фактически, мы пришли к выводу, что его Erlang / OTP может полностью использовать ресурсы сервера MySQL из-за его (Erlang) массивного параллелизма.
Mnesia сработала для нас очень хорошо. Mnesia полностью изменила наш взгляд на базы данных из-за своей потрясающей производительности. Ядра ЦП наших серверов Solaris загружены в среднем на 48% в часы пик.
Я советую вам проверить mnesia, и кто знает, он может удовлетворить ряд ваших потребностей в распространении или репликации.
источник
Я не использовал их, но из документации я бы сказал, что репликация является предпочтительным решением, если самая большая нагрузка - это чтение из базы данных.
источник
Ограничение «в памяти» не позволяет нам использовать кластер MySQL для наших почти 50 ГБ данных, поэтому мы используем DRBD плюс linux Heartbeat .
Это что-то вроде массива рейдов между двумя (или более) ящиками, который поддерживает синхронизацию баз данных / журналов / конфигураций (но только один сервер может быть "активным" одновременно). Отработка отказа выполняется автоматически, использует тот же IP-адрес и выполняется быстро, как перезапуск mysql, так что это было для нас хорошим решением.
источник
Кластер MySQL - странное чудовище, и каждый раз, когда мы оценивали его работу, он либо работал очень плохо, либо был ненадежным.
Его ужасно сложно настроить (вам нужно как минимум три узла, а может и больше). Также нет условий для переключения клиентов при отказе, поэтому вы должны сделать это самостоятельно (или использовать что-то еще в качестве прокси и т. Д.).
Это очень умно, потому что оно выполняет автоматическое разбиение хэша по первичному ключу, что позволяет масштабировать записи, а также потому, что у него нет единой точки отказа.
Но я действительно думаю, что он лучше подходит для особых случаев, для которых он был разработан. В большинстве случаев он не может заменить другой механизм базы данных (например, InnoDB) ни по производительности, ни по функциям.
источник