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