Масштабируемые решения для MySQL (Репликация, Кластеризация)
https://stackoverflow.com/questions/189903
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
В самом запуск Я работаю в компании, сейчас мы рассматриваем решения по масштабированию нашей базы данных.Ситуация становится несколько запутанной (по крайней мере, для меня) с MySQL, который имеет Кластер MySQL, репликация и Репликация кластера MySQL (из вер.5.1.6), который является асинхронной версией кластера MySQL.Руководство по MySQL объясняет некоторые различия в его часто задаваемые вопросы по кластерам, но по нему трудно определить, когда использовать то или иное.
Я был бы признателен за любые советы от людей, которые знакомы с различиями между этими решениями и с тем, каковы их плюсы и минусы, и когда вы рекомендуете использовать каждое из них.
Решение
Я много читал о доступных опциях. Я также получил в руки High Performance MySQL 2nd edition, которую я настоятельно рекомендую.
Вот что мне удалось собрать вместе:
Кластеризация
<р>Кластеризация в общем смысле - это распределение нагрузки по многим серверам, которые представляются внешнему приложению как один сервер.
MySQL NDB Cluster
MySQL NDB Cluster - это распределенный механизм хранения в памяти, не имеющий общего доступа, с синхронной репликацией и автоматическим разделением данных (извините, я заимствовал это буквально из книги «Высокая производительность», но они очень хорошо это описали). Это может быть высокопроизводительное решение для некоторых приложений, но веб-приложения обычно не работают на нем.
Основная проблема заключается в том, что помимо очень простых запросов (которые касаются только одной таблицы), кластеру, как правило, приходится искать данные на нескольких узлах, позволяя задержке в сети закрадываться и значительно замедлять время выполнения запросов. Поскольку приложение обрабатывает кластер как один компьютер, оно не может сказать ему, с какого узла получать данные.
Кроме того, требование в оперативной памяти не работает для многих больших баз данных.
Continuent Sequoia
Это еще одно кластерное решение для MySQL, которое выступает в качестве промежуточного программного обеспечения поверх сервера MySQL. Он предлагает синхронную репликацию, балансировку нагрузки и аварийное переключение. Это также гарантирует, что запросы всегда получают данные из последней копии, автоматически выбирая узел, который имеет свежие данные.
Я прочитал хорошие вещи , и в целом это звучит довольно многообещающе.
Федерация
Федерация похожа на кластеризацию, поэтому я тоже ее подтолкнул. MySQL предлагает объединение через объединенный механизм хранения. Подобно кластерному решению NDB, оно хорошо работает только с простыми запросами, но еще хуже, чем кластер для сложных запросов (поскольку задержка в сети намного выше).
Репликация и балансировка нагрузки
MySQL обладает встроенной способностью создавать репликации базы данных на разных серверах. Это может быть использовано для многих целей - распределение нагрузки между серверами, горячее резервное копирование, создание тестовых серверов и отработка отказа.
Базовая настройка репликации включает один главный сервер, обрабатывающий в основном записи, и один или несколько подчиненных, обрабатывающих только чтение. Более сложный вариант - это вариант master-master , который позволяет масштабировать записи как хорошо, имея несколько серверов, пишущих одновременно.
Каждая конфигурация имеет свои плюсы и минусы, но одной проблемой, с которой они все сталкиваются, является задержка репликации - поскольку репликация MySQL асинхронна, не все узлы имеют самые свежие данные за все время. Это требует, чтобы приложение было осведомлено о репликации и включало запросы, поддерживающие репликацию, чтобы работать как положено. Для некоторых приложений это может не быть проблемой, но если вам всегда нужны самые свежие данные, все усложняется.
Репликация требует некоторой балансировки нагрузки для разделения нагрузки между узлами. Это может быть так просто, как некоторые изменения в коде приложения, или использование специальных программных и аппаратных решений.
Разделение и разделение
Sharding - это широко используемый подход к масштабированию решений для баз данных. Вы разделяете данные на более мелкие фрагменты и распределяете их по разным узлам сервера. Это требует, чтобы приложение знало о модификации хранилища данных для эффективной работы, поскольку оно должно знать, где найти нужную информацию.
Существуют структуры абстракции, которые помогают справиться с разделением данных, такие как Осколки гибернации , расширение Hibernate ORM
Другие советы
Отказ от ответственности: я не использовал MySQL Cluster, поэтому я исхожу только из того, что слышал.
MySQL Cluster - это решение высокой доступности (HA). Это быстро, потому что все в памяти, но реальная точка продажи - доступность. Там нет единой точки отказа. С другой стороны, при репликации, если мастер выйдет из строя, вам придется переключиться на реплику, и может быть небольшое время простоя. (хотя решение 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)
установите имя пользователя и пароль, к которым может подключиться подчиненное устройство, Тогда беги изменить мастер на MASTER_HOST = 'x.x.x.x'; изменить мастер на MASTER_PASSWORD = " xxxxx " ;;
и так далее.
наконец, запустите " запустите ведомый; "
Up приходит ваш раб и начинает воспроизводить. милая да!
Предполагается, что вы начинаете с 2 пустых серверов. Затем вы можете сбросить вашу базу данных на главный сервер, и при загрузке он также будет загружаться на подчиненный.
Вы можете проверить статус ведомого, выполнив:
показать статус ведомого \ G
Удачи с этим .. тааак легко ...
Проводя исследование высокой доступности, я наткнулся на множество решений, и, вероятно, в нашем случае, когда система была более интенсивной при записи, я обнаружил, что кластер DRBD лучше, чем кластер NDB, поскольку он обеспечивает большее количество транзакций в секунду.
Репликация Mysql может предоставить вам резервную машину, которая может использоваться либо как подчиненное устройство для чтения, либо в случае аварийного восстановления.
С помощью различных режимов управления транзакциями, предоставляемых DRBD, вы можете несколько снизить производительность, снижаемую репликацией данных по сети на уровне устройства.Для надежной системы, которая не должна потерять ни одной транзакции в случае сбоя, используйте режим C, в противном случае перейдите на B.
Я попытался перечислить некоторые уроки, которые я усвоил во время настройки кластера DRBD по адресу http://www.techiegyan.com/?p=132
Это действительно хорошо работает при выделенном соединении для репликации, т.е.зарезервируйте отдельные высокоскоростные интерфейсы на обеих машинах только для репликации drbd.Heartbeat может прекрасно управлять кластером со всеми сервисами один за другим, т.е.IP-адреса, разделы, drbd и mysql.
Мне еще предстоит открыть для себя конфигурацию Master-Master в DRBD.Буду обновлять по мере того, как добьюсь успеха в этом.
Спасибо.
На мой взгляд, путаница здесь просто возвращает меня во Мнезию. Благодаря фрагментации, декларативному и прагматичному способу обработки индексов прозрачность расположения реплик базы данных 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 может не обрабатывать столько записей, сколько возможно из-за ограничения размера таблицы. Но мы нашли это утверждение неверным. При хорошей настройке (фрагментации) наши базы данных mnesia хранят в среднем около 250 миллионов записей в год.
Мы получили выгоду от сложной структуры данных Эрланга и того факта, что Mnesia может поглотить ее без изменений. Приложения Erlang / OTP являются наиболее эффективными из всех других приложений на устаревших языках, и с нашей системой мы планируем перевести все это на технологию Erlang / OTP. Из Erlang мы, по-видимому, без особых усилий получаем доступ к данным из MySQL Cluster и выполняем запросы на его серверах. Фактически, мы пришли к выводу, что его Erlang / OTP может полностью использовать ресурсы сервера MySQL из-за его (Erlang) большого параллелизма.
Mnesia сработала для нас очень хорошо. Mnesia полностью изменила наш взгляд на базы данных благодаря своей потрясающей производительности. Наши ядра ЦП сервера Solaris работают в среднем около 48% в часы пик.
Я советую вам проверить mnesia, и, кто знает, может ответить на ряд ваших потребностей в распространении или репликации.
Я не использовал их, но из документации я бы сказал, что репликация является предпочтительным решением, если наибольшая нагрузка заключается в чтении из базы данных.
" в памяти " ограничение не позволяет нам использовать кластер MySQL для наших почти 50 ГБ данных, поэтому мы используем DRBD плюс linux Heartbeat .
Это похоже на массив raid между двумя (или более) блоками, который синхронизирует базы данных / журналы / конфигурации (но только один сервер может быть «живым» одновременно). Аварийное переключение происходит автоматически, использует тот же IP-адрес и выполняется быстро, как перезапуск MySQL, поэтому это было для нас хорошим решением.
Кластер MySQL - странная вещь, и каждый раз, когда мы оценивали, он либо работал очень плохо, либо был ненадежным.
Это ужасно сложно настроить (вам нужно как минимум три узла, возможно, больше). Также не предусмотрено, что клиенты могут переключаться при сбое, поэтому вы должны сделать это самостоятельно (или использовать что-то еще, чтобы действовать как прокси и т. Д.).
Это очень умно, потому что он выполняет автоматическое разбиение хеша по первичному ключу, что позволяет масштабировать записи, а также потому, что у него нет единой точки отказа.
Но я действительно думаю, что он лучше подходит для особых случаев, для которых он был разработан. В большинстве случаев он не может заменить другой механизм базы данных (например, InnoDB) ни по производительности, ни по функциям.
