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

Ответ 1

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

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

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

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

MySQL NDB Cluster

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

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

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

Continuent Sequoia

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

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

Федерация

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

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

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

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

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

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

Облицовка и разделение

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

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

Другие

Sphinx

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

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

Резюме

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

• Блог Dries Buytaert
• Блог WorkHabits

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

Ответ 4

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

Вот соответствующий пример slave my.cnf config

#
#       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";

и т.д.

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

Вверх приходит ваш раб и начинает реплицировать. сладкий ха!

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

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

показать статус подчиненного \G

Удачи с ним.. soooo easy...

Ответ 5

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

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

Ответ 6

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

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

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

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

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

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

Спасибо.

Ответ 7

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

В нашей настройке мы запускаем MySQL Cluster и Mnesia. Наши данные являются сезонными. Итак, что происходит, когда-то, мы избавляемся от 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. Уровень доступа к данным может обращаться к данным в mnesia и MySQL в абстрактном API от имени всех приложений.

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

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

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

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

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

Ответ 8

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

Ответ 9

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

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

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

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