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

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

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

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

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

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

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

    MySQL NDB Cluster

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

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

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

    Продолжение Sequoia

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

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

    федерация

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

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

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

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

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

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

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

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

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

    другие

    сфинкс

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

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

    Резюме

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

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

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

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

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

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

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

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

    • Блог пользователя Dries Buytaert
    • Блог WorkHabits

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

    Самое приятное в том, что делать репликацию – это просто. Просто настройте 2 ящика mysql, измените идентификатор сервера во втором поле, а затем укажите второе поле на первом, используя команду change 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 = ‘xxxx’; изменить мастер на MASTER_PASSWORD = “xxxxx”;

    и так далее.

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

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

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

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

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

    Получайте удовольствие от этого .. soooo easy …

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

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

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

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

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

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

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

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

    Благодарю.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Interesting Posts

    Поле Gson Serialize, если оно не пустое или не пустое

    Будет ли работать Trim, если вы создаете натянутый том из двух дисков (не AS RAID)

    Как удалить только пробелы строки в Java и сохранить ведущие пробелы?

    Почему шаблоны могут быть реализованы только в файле заголовка?

    В JQGrid, возможно ли использовать другой форматтер для группировки итоговой ячейки, отличной от форматирования столбцов?

    Создать сценарий в окне окна, который извлекает данные из окна Linux, выполняя cmds

    Как такие сервисы, как Google Latitude, геолокают мой ноутбук совершенно без GPS?

    Получение java.lang.ClassNotFoundException: исключение org.apache.commons.logging.LogFactory

    Загрузите загрузочный контент Bootstrap с помощью AJAX. Это возможно?

    здесь-документ дает ошибку «неожиданный конец файла»

    Рабочий пример углового материала 2.0 MdDialog с угловым 2,0

    Использование нескольких версий одной и той же библиотеки DLL

    Использование библиотеки FFMPEG с iPhone SDK для кодирования видео

    Установите системный часовой пояс из .NET.

    onInterceptTouchEvent получает только ACTION_DOWN

    Давайте будем гением компьютера.