Повышенная доступность MySQL Cluster и алгоритм арбитража


Оглавление (нажмите, чтобы открыть):

Статья об отказоустойчивости MySQL Cluster

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

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

Re: Статья об отказоустойчивости MySQL Cluster

Я так понимаю, что арбитр — это Master.

Пересказ документации, только сумбурный и очень непоследовательный.

Гораздо лучше было воткнуть статью о построении отказоустойчивой (реально, а не как в статье) системы с двумя управляющими машинами (есть на opennet.ru).

Re: Статья об отказоустойчивости MySQL Cluster

Арбитр это Arbitrator. Существуют другие отказоустойчивые решения, но в статье речь идет именно о MySQL Cluster. Основное внимание уделяется алгоритмам арбитража, которые в документации MySQL в настоящее время не описаны. Другая информация о MySQL Cluster приведена в справочном виде без стремления охватить все, так как тема достаточно широкая.

Re: Статья об отказоустойчивости MySQL Cluster

ИМХО статья ни о чем. Никакой конкретики и очень сумбурно.

Re: Статья об отказоустойчивости MySQL Cluster

все признаки диалекта русского языка, использованного в статье, указывают на то, что её разработал высокоуровневый программист. начинающий — судя по сумбуру и недосказанностям. )

Re: Статья об отказоустойчивости MySQL Cluster

статья из 10 строчек? ага это даже на рассказ школьника о mysql не тянет

Re: Статья об отказоустойчивости MySQL Cluster

>Арбитр это Arbitrator. Существуют другие отказоустойчивые решения,

Когда на управляющей ноде смотришь в машины это скорее всего Master.

Других решений есть одна штука, если я все верно помню — реплика мастер-мастер + к ней slaves по принципу двойного дерева. Адрес навскидку не скажу, т.к. для моих целей не подходило и тестил кратко.

Re: Статья об отказоустойчивости MySQL Cluster

> Когда на управляющей ноде смотришь в машины это скорее всего Master.

Такова официальная терминология MySQL Cluster. Master в кластере — одна из дата-нод, которая выполняет некоторые дополнительные функции (координация транзакций и другие). На управляющей ноде действительно можно смотреть текущую конфигурацию, но арбитр не обязательно на управляющей ноде. Арбитр — роль, которую может играть управляющая или SQL-нода. Роль простая — решать, кто остается в работе в случае фрагментации.

На двух физических машинах MySQL Cluster отказоустойчивым быть не может — такой факт жизни (исключение — MySQL CLuster Carrier Grade Edition с отключенным арбитражом). Среди других решений можно привести Master-Master репликацию (так называемую круговую) с числом серверов от 2 и выше, решения с использованием DRBD и сторонние решения на MySQL, например Continuent uni/cluster.

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

а) кластер продолжит нормальную работу без потери данных

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

MySQL Cluster

Название базовой системы (платформы): MySQL
Разработчики: Oracle
Дата последнего релиза: 2020/02/06
Технологии: СУБД

Содержание

2020: MySQL Cluster 7.5.0

6 февраля 2020 года Oracle представила выпуск MySQL Cluster 7.5.0 [1] .

Пакет помогает организовать распределенные хранилища и высоконадежные конфигурации, которые обеспечат уровень доступности сервиса

99.999% при обеспечении требований ACID к выполнению транзакций (атомарность, согласованность, изолированность, долговечность).

Код проекта распространяется под лицензией GPL и доступен для свободной загрузки. Выпуск примечателен переходом на использование ветки MySQL 5.7 и обновлением движка NDB.

MySQL Cluster предоставляет средства для создания распределённой сети реплицированных в режиме multi-master серверов, гарантирующих отсутствие единой точки отказа. Система обеспечивает горизонтальное масштабирование — наращивание мощности кластера производится за счёт подключения новых узлов и использования техники автоматического шардинга (распределения набора данных по серверам на основе определенного ключа). Для решения задач режима реального времени предлагается хранилище для обработки данных в оперативной памяти (In-Memory).

Доступны SQL и NoSQL API, включая интерфейсы для C++, Java, http, Memcached и JavaScript/Node.js.

Вышел релиз MySQL Cluster 7.4.4

26 февраля 2015 года команда разработки MySQL в составе Oracle анонсировала готовность MySQL Cluster 7.4 к производственным нагрузкам [2] .

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

Скриншот графиков производительности (операций чтения/записи/с) различных версий MySQL Cluster, 2014

  • Максимальное число узлов кластера осталось без изменений, но в самых больших конфигурациях существенно (до 50%) увеличена производительность. К возможности выполнять сложные операции соединения (join) добавилась функция их распараллеливания между узлами кластера с последующей консолидацией результатов, что заметно улучшило масштабируемость. В подобных задачах особую важность приобретает скорость сканирования таблиц, которая в конкретной версии также повышена.
  • Улучшены средства управления и администрирования. Действующая ранее возможность прозрачного добавления нового узла в кластер потребовала функций контроля распределения данных между узлами (в MySQL Cluster принята модель без разделения системных ресурсов). Поскольку отдельные таблицы БД могут храниться в памяти (in-memory) и распределяться по оперативной памяти разных узлов кластера, операции удаления в них должны сопровождаться перераспределением данных по узлам и высвобождением ресурсов ОЗУ для последующего использования. Эти функции реализованы в версии 7.4.
  • MySQL Cluster спроектирована так, что в ней отсутствует возможность отказа при выходе из строя одного из узлов. В частности, с этой целью завершение транзакции фиксируется только после синхронной репликации всех изменений на разные узлы кластера. Вместе с тем поддерживается и асинхронная репликация, которая в MySQL Cluster называется географической и применяется для обеспечения катастрофоустойчивости путем резервирования кластеров в географически удаленных дата-центрах. В версии 7.4 подобная репликация получила дальнейшее развитие, что, по мнению создателей, позволило сузить временные окна для оперативной технической поддержки. Это важно для компаний с бизнесом, географически распределенным по множеству часовых поясов (телекоммуникационных операторов, онлайновых ритейлеров).

MySQL Cluster 7.4

6 ноября 2014 года компания Oracle объявила о выходе обновления — DMR-версии MySQL Cluster 7.4.

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


  • Репликация в режиме «активный-активный» (active-active replication), позволяющая реплицировать данные между распределенными кластерами с автоматическим обнаружением и разрешением конфликтных ситуаций.
  • Улучшения производительности – за счет возможности использования большего числа ядер в каждом узле для «крупномасштабного» горизонтального масштабирования пропускной способности.
  • Операционные усовершенствования, такие как улучшение отчетности и ускорение операций обслуживания. Ключевые функции, находящиеся в стадии разработки, «ранний доступ» к которым открыт для тестирования и обсуждения сообществом MySQL:
  • Multi-source Replication — консолидирует данные из нескольких master-серверов на одном или более slave-сервере.
  • MySQL Group Replication — упрощает обеспечение высокой доступности, позволяя любому серверу принимать записи (данные), и повышает прозрачность приложений за счет устранения необходимости координирования между приложением и серверами маршрутизации транзакций.

MySQL Cluster 7.3

19 июня 2013 года корпорация Oracle объявила о выпуске новой версии MySQL Cluster 7.3.

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

Программный пакет помогает создавать распределенные хранилища и высоконадежные конфигурации, которые способны обеспечивать доступность сервиса на уровне 99.999% при обеспечении требований AC >[3] к выполнению транзакций. Код распространяется под лицензией GPL и доступен для свободной загрузки.

Наличие библиотеки NoSQL JavaScript Connector для платформы node.js позволяет создавать сервисы, предназначенные для развертывания на кластерных конфигурациях, состоящих из стандартных аппаратных средств с минимальными усилиями на разработку и управление.

  • встроенная поддержка внешних ключей (Foreign Keys), для контроля связности и целостности данных в таблицах, распределённых по разным узлам кластера, в том числе находящихся в разных дата-центрах;
  • автоматический инсталлятор на основе браузера, при помощи которого возможно в считанные минуты запустить решение на основе MySQL Cluster и оптимально настроить конфигурацию, в зависимости от требуемого типа задач, решаемых кластером;
  • оптимизированная масштабируемость в потоках обработки соединений, которые дополнительно помогают обеспечивать для конечных пользователей соответствие требованиям к базе данных высокой доступности, предъявляемым новым поколением облачных, коммуникационных и веб-сервисов.

Слой SQL теперь базируется на новейшей версии MySQL 5.6, что позволяет разработчикам и системным администраторам использовать такие особенности версии, как повышенная пропускная способность и надежность репликации. Используя новую версию MySQL 5.6, разработчики могут комбинировать механизмы хранения данных InnoDB и MySQL Cluster в одном приложении.

Масштабируемость для потоков обработки соединений (Connection Thread Scalability) обеспечивает повышение пропускной способности в 1,5 — 7,5 раза, в расчете на одно соединение с узлами данных кластера MySQL Custer, увеличивая общую емкость и масштабируемость кластера. Улучшение достигается за счет разбиения внутренних блокировок и уменьшения размера критических секций в коде обработки соединений.

MySQL Cluster 7.2

Корпорация Oracle объявила в начале 2012 года о выходе новой версии реляционной базы данных MySQL Cluster 7.2, предназначенной для обеспечения 99,999% доступности, высокой масштабируемости записи и сверхмалого времени отклика. Новая версия MySQL Cluster поддерживает как язык запросов SQL, так и модель доступа NoSQL через новый интерфейс Memcached API, при этом обеспечивает повышение производительности при выполнении сложных запросов и масштабируемости для ЦОДов с несколькими источниками (multi-data centers).

По словам разработчиков, MySQL Cluster 7.2 позволяет развертывать распределенные, высокомасштабируемые базы данных с обоими интерфейсами — SQL и NoSQL, с возможностью выполнения сложных запросов или многотабличных транзакций в соответствии с требованиями стандарта ACID. Пользователи могут выполнять как сложные, так и простые запросы — типа «ключ/значение» (key-value) — для одних и тех же наборов данных в одной и той же базе данных.

«Повышение производительности и гибкости, обеспечиваемое MySQL Cluster 7.2, предоставляет пользователям надежную платформу для критически важных веб-приложений, объединяющую передовые технологии SQL и NoSQL для снижения рисков, затрат и упрощения системы», — заявил Томас Улин (Tomas Ulin), вице-президент Oracle по разработке MySQL.

По информации Oracle, адаптивная локализация запроса обеспечивает рост производительности при обработке сложных запросов в 70 раз. В результате, преимуществами MySQL Cluster могут воспользоваться еще больше приложений, таких как аналитические приложения реального времени, работающие с оперативными данными.

Среди других усовершенствований MySQL Cluster 7.2 можно отметить расширенную масштабируемость. Многосайтовые кластеры (multi-site clusters) позволяют размещать отдельные узлы с данными в разных центрах обработки данных; при этом базы данных автоматически распределяются между этими узлами. Синхронная репликация поддерживает целостность и непротиворечивость данных между «сайтами», вместе с возможностями быстрого автоматизированного обхода отказов и восстановления. Расширенная репликация в режиме «активный-активный» (active/active replication) упрощает обнаружение и разрешение конфликтов между несколькими активными кластерами, освобождая разработчиков от необходимости поддерживать колонку временных меток в приложениях, пояснили в Oracle.

Другой особенностью MySQL Cluster версии 7.2 является упрощение использования и администрирования. Совместно используемые таблицы прав пользователей консолидируют предыдущие распределенные таблицы в кластерных узлах с данными, делая их доступными со всех серверов MySQL. Благодаря новой функции администраторам теперь не нужно устанавливать и управлять пользовательскими правами на каждом SQL-узле кластера.

MySQL Cluster 7.2 также сертифицирована для работы со средой виртуализации Oracle VM. Возможности гибкого масштабирования по запросу и самовосстановления в сочетании с поддержкой Oracle VM делают MySQL Cluster оптимальным выбором для решений, развертываемых в средах облачных вычислений, утверждают в Oracle. Наряду с Oracle VM, СУБД MySQL Cluster также сертифицирована для работы с операционными системами Oracle Linux и Oracle Solaris.

MySQL Cluster — MySQL Cluster

MySQL Cluster

Разработчики) оракул
Первый выпуск ноябрь 2004
Стабильная версия
Операционная система Кросс-платформенная
Доступно в английский
Тип RDBMS
Лицензия GNU General Public License (версия 2, с связывая исключение ) или коммерческое EULA
Веб-сайт

MySQL Cluster это технология , обеспечивающая разделяемого ничего кластеризацию и авто-шардинг для MySQL системы управления базами данных . Он предназначен для обеспечения высокой доступности и высокой пропускной способности с низкой задержкой, допуская при этом вблизи линейной масштабируемостью. MySQL Cluster осуществляется через ОПРС механизм хранения или для MySQL NDB кластера ( «ОПРС» обозначает N etwork Д ата б ASE).

содержание

Архитектура

MySQL Cluster разработана вокруг распределенной, мульти-мастер ACID совместимой архитектуры, без единой точки отказа . MySQL Cluster использует автоматическую шардинга (секционирования) масштабировать операции чтения и записи на аппаратном обеспечении и могут быть доступны через SQL и Non-SQL (NoSQL) API ,

копирование

Внутренне MySQL Cluster использует синхронную репликацию через двухфазной фиксации механизма для того , чтобы гарантировать , что данные записаны на нескольких узлах при совершении данных. (Это в отличие от того , что обычно называют «репликации MySQL», который является асинхронным .) Две копии (известные как реплики ) данных необходимы , чтобы гарантировать доступность. MySQL Cluster автоматически создает «группы узлов» из числа реплик и узлов данных , указанных пользователем. Обновления синхронно реплицируются между членами группы узла для защиты от потери данных и поддерживают быстрый переход на другой ресурс между узлами.

Кроме того , можно повторить асинхронно между кластерами; это иногда называют «MySQL репликации кластера» или «географической репликации». Это , как правило , используется для репликации кластеров между центрами обработки данных для аварийного восстановления или для уменьшения эффектов задержки в сети за счет размещения данных физически ближе к набору пользователей. В отличии от стандартной репликации MySQL, географическая репликация MySQL Cluster использует оптимистическое управление параллелизмом и концепцию Эпохи , чтобы обеспечить механизм для обнаружения и разрешения конфликтов, что позволяет активный / активный кластер между центрами обработки данных.

Начиная с MySQL Cluster 7.2, поддержка синхронной репликации между центрами обработки данных была поддержана с функцией Multi-Site кластера.

Горизонтальное разделение данных (авто-Sharding)

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

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

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

Гибридное хранение

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

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


MySQL Cluster пишет Повторить регулярно журналы на диск для всех изменений данных, а также данные проверок , указывая на диск. Это позволяет кластер последовательно восстановить с диска после полного кластера отключения электроэнергии. В логах написано асинхронно по отношению к транзакции, некоторые небольшое количество сделок , могут быть потеряны , если полный кластер не удается, однако это может быть устранена с помощью географической репликации или кластера на нескольких площадках рассмотренную выше. Тока по умолчанию задержка асинхронной записи составляет 2 секунды, и конфигурируется. Нормальная одна точка сценариев отказа не приводит к потере данных из — за синхронную репликацию данных в кластере.

Когда таблица кластера MySQL поддерживаются в памяти, кластер будет иметь доступ только дисковое хранилище для записи Повторить записи и контрольные точки. Поскольку эти записи являются последовательными и ограниченные модели произвольного доступа участвует, MySQL Cluster может достичь более высоких темпов производительности записи с ограниченным аппаратным диском по сравнению с традиционным дисковомом кэширования РСУБДА. Это чекпойнтинг на диск данных таблицы в памяти может быть отключен (на основе каждой таблицы), если сохранение на диск на основе не требуется.

не Shared ничего

MySQL Cluster предназначен не иметь единую точку отказа . При условии , что кластер правильно настроен, любой отдельный узел, система, или часть оборудования может выйти из строя без всего кластера не удается. Общий диск ( SAN ) не требуется. Межсоединений между узлами может быть стандартным Ethernet , Gigabit Ethernet , InfiniBand или SCI межсоединения.

SQL и NoSQL API,

Как MySQL хранит кластер таблицы в узлах данных, а не в сервере MySQL, есть несколько интерфейсов, доступные для доступа к базе данных:

  • SQL доступа через сервер MySQL
  • NoSQL API, где библиотеки кластера MySQL могут быть встроены в приложение, чтобы обеспечить прямой доступ к узлам данных без прохождения через SQL слоя. Они включают:
    • Memcached
    • Node.js / JavaScript
    • Java и JPA
    • HTTP / REST
    • ОПРС ​​API (C ++)

MySQL Cluster Manager

Часть коммерческих MySQL Cluster КГЭ, MySQL Cluster Manager представляет собой инструмент, предназначенный для упрощения создания и администрирования базы данных MySQL Cluster КГЭ за счет автоматизации общих задач управления, в том числе по линии масштабирования, обновления, резервного копирования / восстановления и реконфигурации. MySQL Cluster Manager также отслеживает и автоматически восстанавливает MySQL узлов сервера приложений и узлов управления, а также узлы кластера данных MySQL.

Реализация

MySQL Cluster использует три различных типа узлов (процессов):

  • Узел данных (NDBD / ndbmtd процесс) : Эти узлы хранения данных. Таблицы автоматически sharded по узлам данных , которые также прозрачно обрабатывать балансировки нагрузки, репликации, восстановления после сбоя и самовосстановления.
  • Узел управления (NDB_MGMD процесс) : Используется для конфигурирования и мониторинга кластера. Они необходимы только для запуска или перезапуска узла кластера. Они также могут быть настроены в качестве арбитров, но это не является обязательным (MySQL сервер может быть настроен в качестве арбитров , а).
  • Узел приложения или SQL — узел (процесс туздЫ) : Сервер MySQL (туздЫ) , который подключается ко всем узлам данных для выполнения хранения и извлечения данных. Этот тип узла не является обязательным; можно запросить узлы данных непосредственно через API ОПРС, либо изначально с использованием API C ++ или один из дополнительных интерфейсов NoSQL , описанных выше.

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

Версии

не MySQL версии кластера номера больше не привязана к серверу MySQL — например, самая последняя версия MySQL Cluster 7.5, даже если она основана на / содержит серверный компонент с MySQL 5.7.

Более высокие версии MySQL Cluster включают все функции нижних версий, а также некоторые новые функции.

Более старые версии (уже не в разработке):

  • Ndb включены в MySQL 5.1.x исходного дерева
  • MySQL Cluster 6.2 на основе MySQL 5.1.A

Во-первых «телекоммуникационной» или «операторского класса издание» релиз. Поддержка 255 узлов, онлайн таблицы изменяющих, задержка репликации и улучшения пропускной способности и т.д.

  • MySQL Cluster 6.3 на основе MySQL 5.1

Включает в себя сжатую резервную копию + LCP, поддержка репликации круговое обнаружение конфликтов / разрешение, оптимизация таблицы и т.д.

  • MySQL Cluster 7.0 на основе MySQL 5.1.C

Включает в себя многопоточные узлах данных (ndbmtd), транзакционный DDL, поддержка Windows.

  • MySQL Cluster 7.1 на основе MySQL 5.1.D

Включает ClusterJ и ClusterJPA разъемы

В настоящее время доступны версии:

  • MySQL Cluster 7.2 на основе MySQL 5.5

Включает в себя адаптивный запросе Локализация (толчки РЕГИСТРИРУЙТЕСЬ операции вниз к узлам данных), Memcached API, упрощена активные / активные Географические репликации, мульти-сайт кластеризации, улучшение масштабируемости узла данных, консолидированные привилегии пользователя.

  • MySQL Cluster 7.3 на основе MySQL 5.6

Включает поддержку внешних ключей ограничений, Node.js / JavaScript API и авто-инсталлятора.

  • MySQL Cluster 7.4 на основе MySQL 5.6

Включает в себя усиленное Обнаружение и разрешение конфликтов, улучшение времени перезапуска узла, новый API событий.

  • MySQL Cluster 7.5 на основе MySQL 5.7

Включает поддержку для больших наборов данных (более чем 128TB на узел), улучшенная масштабируемость чтения через прочитанных оптимизированные таблицы, улучшена поддержка SQL.

  • MySQL Cluster 8.0 на основе MySQL 8.0

Требования

Для целей оценки, можно запустить MySQL Cluster на одном физическом сервере. Для развертывания производства, минимальные системные требования относятся к 3-х инстанций / хостов:

  • 2 × Узлы данных
  • 1 × Применение / Узел управления
  • 2 × Узел данных + Программное обеспечение
  • 1 × Узел управления

Конфигурации следующим образом:

  • ОС: Linux , Solaris , Windows , . MacOs (для развития только)
  • Процессор: Intel / AMD x86 / x86-64, UltraSPARC
  • Память: 1 Гб
  • HDD: 3GB
  • Сеть: 1+ узлы (Стандарт Ethernet — TCP / IP)

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

история

MySQL AB приобрела технологию за MySQL Cluster от Alzato , небольшой венчурной компании начатой Ericsson . ОПРС был первоначально разработан для телекоммуникационного рынка , с высокой доступностью и высокими требованиями к производительности.

MySQL Cluster на основе движка хранения NDB с тех пор была интегрирована в MySQL продукт, с его первым выпуском релиза в MySQL 4.1.

Служба поддержки

MySQL Cluster лицензирован под GPLv лицензии 2. Коммерческая поддержка доступна как часть MySQL Cluster КГЭ, которая также включает в себя аддоны , не с открытым исходным кодом , такие как MySQL Cluster Manager, MySQL Enterprise Monitor, в дополнение к MySQL Enterprise Security и MySQL Enterprise аудита.

Сравнение различных реализаций кластера для MySQL?


Надеюсь, что мой вопрос не выходит за рамки данного ресурса и найдёт ответ.

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

В глаза сразу бросается использование какой-либо реализации кластера MySQL, и рассматриваю несколько решений:

  • MySQL Cluster
  • Percona XtraDB Cluster
  • MariaDB Galera Cluster

К сожалению, ранее с ними не работал и моих практических/теоретических знаний по ним немного(поднял Percona XtraDB Cluster на виртуалках — с виду работает). Русской информации так же гуглится немного. Надеюсь, многоуважаемое сообщество, поможет мне с выбором технологии.

Из исходных данных:

  • Проект работает с одним MySQL 5.5 сервером. Таблицы innodb
  • Операции чтения превалируют над операциями записи
  • Серьёзных переработок кода проекта хотелось бы избежать
  • Для реализации решения можно(и планируется) использовать 3+ сервера. Они могут быть разнесены по разным ДЦ

По большей части интересует следующее:

  1. Есть ли где-нибудь внятные материалы по сравнению всех трёх решений?
  2. Насколько стабильны кластерные решения?(вылеты нод из работы, ситуации при пропадании связи)
  3. Сильные/слабые стороны определённых решений, какие они?
  4. Обслуживание каждого из решений на уровне администратора(сложно, легко, восстановление после сбоя)?
  5. Есть ли какие-либо альтернативы?

Буду рад Вашим ответам 🙂

PS Так как в данной теме ещё «плаваю», мог упустить какие-либо важные детали или вопросы, которые могут возникнуть по ходу изучения/внедрения технологии. Если Вы подскажете их — это будет очень круто!

  • Вопрос задан более трёх лет назад
  • 13788 просмотров

Всем спасибо за помощь!

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

В работу внедрили уже несколько кластеров на Percona(пока что из 3х серверов). Падение одной ноды переживает нормально. Проблем с какой-либо потерей данных не наблюдается.

Да, при географическом распределении, при записи данных, задержки есть. Но между Селектел и Hetzner — вполне терпимы.
Между Питером и Москвой тоже не очень большие(всё зависит от способа работы сайта с БД).

Как итог — можно использовать Percona Cluster и не бояться 🙂 Всё зависит от допустимой «деградации» Вашей системы. В данном случае это некоторая задержка при записи данных(но ведь запросов на запись обычно меньше, чем на чтение ;))

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

MySQL Cluster CGE

MySQL Cluster CGE

Разработчики: Oracle
Состояние разработки: Активно
Платформа: Кроссплатформенная
Тип ПО: Кластер (группа компьютеров)
Лицензия: GNU GPL (General Public License) [1]
Веб-сайт www .mysql .com

MySQL Cluster CGE — Это технология, позволяющая объединять данные в единый кластер. Данная система поддерживает автоматический шардинг и предоставляет удобный интерфейс для управления всеми связанными данными. Она была разработана в целях упрощения создания высоконагруженных и отказоустойчивых систем. [2]

Содержание

Общие сведения

MySQL— свободная реляционная система управления базами данных. Разработку и поддержку MySQL осуществляет корпорация Oracle, получившая права на торговую марку вместе с поглощённой Sun Microsystems, которая ранее приобрела шведскую компанию MySQL AB. Продукт распространяется как под GNU General Public License, так и под собственной коммерческой лицензией. Помимо этого, разработчики создают функциональность по заказу лицензионных пользователей. Именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации. MySQL является решением для малых и средних приложений. Входит в состав серверов WAMP, AppServ, LAMP и в портативные сборки серверов Денвер, XAMPP, VertrigoServ. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы. Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц. 26 февраля 2008 года Sun Microsystems приобрела MySQL AB за 1 млрд долларов, 27 января 2010 года [[Oracle[[ приобрела Sun Microsystems за 7,4 млрд долларов и включила MySQL в свою линейку СУБД. Сообществом разработчиков MySQL созданы различные ответвления кода, такие как Drizzle (англ.), OurDelta, Percona Server и MariaDB. Все эти ответвления уже существовали на момент поглощения компании Sun корпорацией Oracle. Сервер MySQL, который является частью кластера, отличается от обычного только одним: он использует тип хранения NDBCLUSTER. Этот тип хранения также упоминается просто как NDB, и эти две формы имени являются синонимами. NDB доступен в двоичных дистрибутивах, начиная с MySQL-Max 4.1.3 для Linux, Mac OS X и Solaris, недавно также была добавлена поддержка операционных систем windows.

История

В основе MySQL Cluster CGE лежат технологии Alzato, небольшой венчурной компании, открытой компанией Ericsson. NDB первоначально был сконструирован для рынка телекоммуникаций, где были заявлены требования высокой эффективности. Кластер MySQL на основе механизма хранения NDB был интегрирован в продукт MySQL, первыЙ релиз заявлен в версии MySQL 4.1. [3]

Архитектура

MySQL Cluster использует новый способ хранения NDB Cluster, чтобы сделать возможным выполнение нескольких серверов MySQL в кластере. MySQL Cluster использует автоматическое сегментирование (секционирование) для масштабирования операций чтения и записи на аппаратном уровне и может быть доступен через SQL и не-SQL (NoSQL) программные интерфейсы.

Архитектура MySQL Cluster CGE приведена на изображении ниже

Вся система состоит из трёх различных типов узлов. В них входят:

  • Узел для исполнения SQL-команд
  • Узел для хранения файлов
  • Узел управления

Все узлы выполняют различные функции. Первый тип узлов нужен для того, чтобы выполнять команды, которые поступают на кластер (такие как SELECT, UPDATE и т. п.). Второй — для хранения информации. Третий тип узлов используется для манипуляций над первыми двумя (такими как включение/выключение, решение Split-brain)

Репликация

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

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

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

Горизонтальное секционирование данных (автоматическое сегментирование)

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

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

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

Гибридное хранилище

Если объем данных больше, чем может быть записано на одной машине, MySQL Cluster может позволить хранить такие данные и получать доступ к ним на нескольких машинах.

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

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

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


SQL и NoSQL API

Кластер MySQL хранит таблицы в данных узлов, а не на сервере MySQL. Существует несколько интерфейсов для доступа к базе данных:

  • SQL доступ с помощью MySQL Server
  • [[NoSQL[[ API, где MySQL Cluster библиотеки могут быть встроены в приложение, чтобы обеспечить прямой доступ к узлам данных, не проходя через уровень SQL. Такие API включают:
    • Memcached
    • Node.js / JavaScript
    • Java and JPA
    • HTTP / REST
    • NDB API (C++)

Версии

Номера версий MySQL Cluster больше не привязаны к версиям MySQL Server. Например, самая последняя версия MySQL Cluster 7.5, даже если она основана или содержит серверный компонент от MySQL 5.7. Более высокие версии MySQL Cluster включают все особенности более низких версий и некоторые новые функции.

Старые версии (больше не в разработке):

  • Ndb, включенный в MySQL 5.1.Х
  • MySQL Cluster 6.2 на основе MySQL 5.1.А

Первый релиз поддерживал 255 узлов, онлайн-таблицу изменений, задержку репликации и расширения пропускной способности и т.д.

Включает сжатую резервную копию + LCP, поддержку круговой репликации, обнаружение/разрешение конфликтов, оптимизацию таблиц и т.д.

Включает многопоточные узлы данных (ndbmtd), Библиотеки транзакций, поддержку Windows.

  • MySQL Cluster 7.1 на основе MySQL 5.1.D

Соединяет в себе ClusterJ и ClusterJPA.

Доступные на данный момент версии:

Включает в себя адаптивную локализацию запросов, Memcached API, упрощенную активную географическую репликацию, многостраничную кластеризацию, улучшения масштабируемости узлов данных, консолидированные права пользователя.

Поддерживает ограничения внешнего ключа, узлы в JS / JavaScript и API и авто-установщик.

Включает в себя улучшенное обнаружение и разрешение конфликтов, улучшенное время перезапуска узла, новый API событий.

Включает в себя поддержку больших наборов данных (более 128 ТБ на узел), улучшенную масштабируемость чтения с помощью чтения оптимизированных таблиц, улучшенную поддержку SQL.

Требования

Для оценки технологии можно выполнить MySQL Cluster на одиночном физическом сервере. Для производственных развертываний Минимальные системные требования для 3-x экземпляров/узлов:

  • 2 × Data Nodes
  • 1 × Application / Management Node
  • 2 × Data Node + Application
  • 1 × Management Node
  • ОС: Linux, Solaris, Windows. macOS (только для разработки)
  • Процессор: Intel/AMD с архитектурой x86/х86-64, систем
  • Память: 1GB
  • Жесткий диск: 3ГБ
  • Сеть: 1 + узлов (Стандартный Ethernet-TCP / IP)

Советы и рекомендации по развертыванию высокопроизводительных кластеров производственного класса можно найти в Руководстве по оценке MySQL Cluster и Руководстве по оптимизации производительности базы данных MySQL Cluster.

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

Создание кластера

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

Создание кластеров доступно для СУБД MySQL, начиная с версии 5.0. Чтобы создать кластер, необходимо выделить три группы узлов: для хранения, для обработки запросов и для управления. Для обеспечения максимальной доступности кластера, в каждую группу должно входить не менее 3 узлов.

Каждый узел имеет тип. В минимальной конфигурации кластера MySQL будут по крайней мере три узла:

  • Управляющий (MGM). Роль этого типа узла: управлять другими узлами внутри MySQL Cluster, таких как обеспечение данных конфигурации, старта и остановки узлов, выполнение резервного копирования и т.д. Поскольку этот тип узла управляет конфигурацией других узлов, узел этого типа должен быть запущен перед любым другим узлом. При работе кластера узел MGM не обязательно должен выполняться все время. MGM-узел запускается командой ndb_mgmd, по этой причине NDB_MGMD обеспечивается как псевдоним для MGM при конфигурировании кластера.
  • Память или узел базы данных (DB). Это тип узла, который управляет и сохраняет базу данных непосредственно. Имеется столько DB-узлов, сколько имеется фрагментов для репликаций. Например, с двумя репликациями по два фрагмента каждая, надо четыре DB-узла. Вполне достаточно одной репликации, стало быть минимальный кластер может содержать только один DB-узел. DB-узел запускается командой ndbd и NDBD обеспечивается как псевдоним для DB при конфигурировании кластера.
  • Клиентский (API) узел. Это узел пользователя, который обратится к кластеру. В случае кластера MySQL, узел пользователя традиционный сервер MySQL, который использует тип хранения NDB Cluster, допуская доступ к кластеризуемым таблицам. В основном, сервер MySQL действует как пользователь кластера NDB. Прикладные программы, использующие NDB API непосредственно, также рассматриваются как узлы API. Так как сервер MySQL обычно запускается командами mysqld или mysqld_safe, MYSQLD обеспечивается как псевдоним для API при конфигурировании кластера.

Резервное копирование

Кластерирование БД MySQL не устраняет нужды в бэкапе (резервном копировании) БД MySQL. Кластеры хороши для повышения доступности и производительности, но не способны напрямую противостоять таким угрозам, как человеческие ошибки, вирусы или проблемы MySQL. Если приложение включает оператор DROP DATABASE, не существует пути для восстановления удалённого содержимого БД – неважно, сколько узлов хранения имеет при этом кластер.

Установка

Debian / Ubuntu

Для установки mysql cluster сначала необходимо установить его зависимости.
Если узлы кластера находятся на разных серверах, то для каждого сервера это необходимо будет повторить отдельно.

Установка клиента клиента и сервера MySQL:

Установка пакета libaio1

Затем необходимо установить сам кластер. Его можно скачать с официального сайта: https://dev.mysql.com/downloads/cluster/
При выборе версии рекомендуется выбирать пакет linux-generic
После этого необходимо распаковать установленный пакет:

Далее необходимо настроить конфигурацию для каждого из трёх типов узлов. Узлов может быть сколь угодно много. В этом примере будет рассмотрена базовая конфигурация из одного SQL и Management узла и двух узлов для хранения данных.

Настройка узла управления (Management узла)

Создание директории для конфигурационного файла


Затем необходимо создать файл config.ini и в нём указать следующие данные:

Затем необходимо запустить узел управления

Настройка узла данных

Необходимо создать конфигурационный файл

И записать в него адрес узла управления

При хранении файлов необходимо также убедиться в существовании каталога под них, указанных в конфигурации узла управления
После этого узел можно запускать

Конфигурация SQL-узла

Конфигурация также записывается в /etc/my.cnf

Хорошим подходом является создание собственного пользователя для MySQL, но этот шаг опущен. Запуск узла управления:

После выполнения всех перечисленных шагов кластер будет запущен

Ниже приведена демонстрация работы кластера

Highload. Архитектура MySQL Cluster. (Видео)

Аренда сервера. Выделенные серверы в Украине и Нидерландах
Аренда сервера

VPS, VDS, Windows VPS — от $10
VPS

Видео доклад с конференции Highload 2008.

Название: Архитектура MySQL Cluster
Год: 2008
Докладчик: Григорий Рубцов
Компания: SQLInfo
Язык доклада: Русский
Описание: ель доклада – рассказать слушателям об архитектуре MySQL Cluster и возможностях его использования для построения отказоустойчивых нагруженных приложений.
MySQL Cluster – система распределенного хранения данных в рамках СУБД MySQL. Общая архитектура кластера будет рассмотрена с позиций производительности и отказоустойчивости, будут описаны алгоритмы арбитража, срабатывающие при отказе одной или нескольких нод кластера. В качестве примеров будут приведены отказоустойчивые (и не очень) конфигурации MySQL Cluster.
В докладе будут рассмотрены принципы работы механизма хранения NDB, используемого в кластере. Функциональные возможности различных версий NDB будут рассмотрены с точки зрения производительности и ресурсоемкости. В качестве примеров будут рассмотрены конфигурации, включающие репликацию с кластера на кластер и репликацию с кластера на одиночный сервер MySQL.
Прослушав доклад, слушатель сможет ответить на вопрос о применимости MySQL Cluster для стоящих перед ним задач.

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

MySQL Cluster — MySQL Cluster

MySQL Cluster

Разработчики) оракул
Первый выпуск ноябрь 2004
Стабильная версия
Операционная система Кросс-платформенная
Доступно в английский
Тип RDBMS
Лицензия GNU General Public License (версия 2, с связывая исключение ) или коммерческое EULA
Веб-сайт

MySQL Cluster это технология , обеспечивающая разделяемого ничего кластеризацию и авто-шардинг для MySQL системы управления базами данных . Он предназначен для обеспечения высокой доступности и высокой пропускной способности с низкой задержкой, допуская при этом вблизи линейной масштабируемостью. MySQL Cluster осуществляется через ОПРС механизм хранения или для MySQL NDB кластера ( «ОПРС» обозначает N etwork Д ата б ASE).

содержание

Архитектура

MySQL Cluster разработана вокруг распределенной, мульти-мастер ACID совместимой архитектуры, без единой точки отказа . MySQL Cluster использует автоматическую шардинга (секционирования) масштабировать операции чтения и записи на аппаратном обеспечении и могут быть доступны через SQL и Non-SQL (NoSQL) API ,

копирование

Внутренне MySQL Cluster использует синхронную репликацию через двухфазной фиксации механизма для того , чтобы гарантировать , что данные записаны на нескольких узлах при совершении данных. (Это в отличие от того , что обычно называют «репликации MySQL», который является асинхронным .) Две копии (известные как реплики ) данных необходимы , чтобы гарантировать доступность. MySQL Cluster автоматически создает «группы узлов» из числа реплик и узлов данных , указанных пользователем. Обновления синхронно реплицируются между членами группы узла для защиты от потери данных и поддерживают быстрый переход на другой ресурс между узлами.

Кроме того , можно повторить асинхронно между кластерами; это иногда называют «MySQL репликации кластера» или «географической репликации». Это , как правило , используется для репликации кластеров между центрами обработки данных для аварийного восстановления или для уменьшения эффектов задержки в сети за счет размещения данных физически ближе к набору пользователей. В отличии от стандартной репликации MySQL, географическая репликация MySQL Cluster использует оптимистическое управление параллелизмом и концепцию Эпохи , чтобы обеспечить механизм для обнаружения и разрешения конфликтов, что позволяет активный / активный кластер между центрами обработки данных.

Начиная с MySQL Cluster 7.2, поддержка синхронной репликации между центрами обработки данных была поддержана с функцией Multi-Site кластера.

Горизонтальное разделение данных (авто-Sharding)

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

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

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

Гибридное хранение

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

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

MySQL Cluster пишет Повторить регулярно журналы на диск для всех изменений данных, а также данные проверок , указывая на диск. Это позволяет кластер последовательно восстановить с диска после полного кластера отключения электроэнергии. В логах написано асинхронно по отношению к транзакции, некоторые небольшое количество сделок , могут быть потеряны , если полный кластер не удается, однако это может быть устранена с помощью географической репликации или кластера на нескольких площадках рассмотренную выше. Тока по умолчанию задержка асинхронной записи составляет 2 секунды, и конфигурируется. Нормальная одна точка сценариев отказа не приводит к потере данных из — за синхронную репликацию данных в кластере.

Когда таблица кластера MySQL поддерживаются в памяти, кластер будет иметь доступ только дисковое хранилище для записи Повторить записи и контрольные точки. Поскольку эти записи являются последовательными и ограниченные модели произвольного доступа участвует, MySQL Cluster может достичь более высоких темпов производительности записи с ограниченным аппаратным диском по сравнению с традиционным дисковомом кэширования РСУБДА. Это чекпойнтинг на диск данных таблицы в памяти может быть отключен (на основе каждой таблицы), если сохранение на диск на основе не требуется.

не Shared ничего

MySQL Cluster предназначен не иметь единую точку отказа . При условии , что кластер правильно настроен, любой отдельный узел, система, или часть оборудования может выйти из строя без всего кластера не удается. Общий диск ( SAN ) не требуется. Межсоединений между узлами может быть стандартным Ethernet , Gigabit Ethernet , InfiniBand или SCI межсоединения.

SQL и NoSQL API,

Как MySQL хранит кластер таблицы в узлах данных, а не в сервере MySQL, есть несколько интерфейсов, доступные для доступа к базе данных:

  • SQL доступа через сервер MySQL
  • NoSQL API, где библиотеки кластера MySQL могут быть встроены в приложение, чтобы обеспечить прямой доступ к узлам данных без прохождения через SQL слоя. Они включают:
    • Memcached
    • Node.js / JavaScript
    • Java и JPA
    • HTTP / REST
    • ОПРС ​​API (C ++)

MySQL Cluster Manager

Часть коммерческих MySQL Cluster КГЭ, MySQL Cluster Manager представляет собой инструмент, предназначенный для упрощения создания и администрирования базы данных MySQL Cluster КГЭ за счет автоматизации общих задач управления, в том числе по линии масштабирования, обновления, резервного копирования / восстановления и реконфигурации. MySQL Cluster Manager также отслеживает и автоматически восстанавливает MySQL узлов сервера приложений и узлов управления, а также узлы кластера данных MySQL.

Реализация

MySQL Cluster использует три различных типа узлов (процессов):


  • Узел данных (NDBD / ndbmtd процесс) : Эти узлы хранения данных. Таблицы автоматически sharded по узлам данных , которые также прозрачно обрабатывать балансировки нагрузки, репликации, восстановления после сбоя и самовосстановления.
  • Узел управления (NDB_MGMD процесс) : Используется для конфигурирования и мониторинга кластера. Они необходимы только для запуска или перезапуска узла кластера. Они также могут быть настроены в качестве арбитров, но это не является обязательным (MySQL сервер может быть настроен в качестве арбитров , а).
  • Узел приложения или SQL — узел (процесс туздЫ) : Сервер MySQL (туздЫ) , который подключается ко всем узлам данных для выполнения хранения и извлечения данных. Этот тип узла не является обязательным; можно запросить узлы данных непосредственно через API ОПРС, либо изначально с использованием API C ++ или один из дополнительных интерфейсов NoSQL , описанных выше.

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

Версии

не MySQL версии кластера номера больше не привязана к серверу MySQL — например, самая последняя версия MySQL Cluster 7.5, даже если она основана на / содержит серверный компонент с MySQL 5.7.

Более высокие версии MySQL Cluster включают все функции нижних версий, а также некоторые новые функции.

Более старые версии (уже не в разработке):

  • Ndb включены в MySQL 5.1.x исходного дерева
  • MySQL Cluster 6.2 на основе MySQL 5.1.A

Во-первых «телекоммуникационной» или «операторского класса издание» релиз. Поддержка 255 узлов, онлайн таблицы изменяющих, задержка репликации и улучшения пропускной способности и т.д.

  • MySQL Cluster 6.3 на основе MySQL 5.1

Включает в себя сжатую резервную копию + LCP, поддержка репликации круговое обнаружение конфликтов / разрешение, оптимизация таблицы и т.д.

  • MySQL Cluster 7.0 на основе MySQL 5.1.C

Включает в себя многопоточные узлах данных (ndbmtd), транзакционный DDL, поддержка Windows.

  • MySQL Cluster 7.1 на основе MySQL 5.1.D

Включает ClusterJ и ClusterJPA разъемы

В настоящее время доступны версии:

  • MySQL Cluster 7.2 на основе MySQL 5.5

Включает в себя адаптивный запросе Локализация (толчки РЕГИСТРИРУЙТЕСЬ операции вниз к узлам данных), Memcached API, упрощена активные / активные Географические репликации, мульти-сайт кластеризации, улучшение масштабируемости узла данных, консолидированные привилегии пользователя.

  • MySQL Cluster 7.3 на основе MySQL 5.6

Включает поддержку внешних ключей ограничений, Node.js / JavaScript API и авто-инсталлятора.

  • MySQL Cluster 7.4 на основе MySQL 5.6

Включает в себя усиленное Обнаружение и разрешение конфликтов, улучшение времени перезапуска узла, новый API событий.

  • MySQL Cluster 7.5 на основе MySQL 5.7

Включает поддержку для больших наборов данных (более чем 128TB на узел), улучшенная масштабируемость чтения через прочитанных оптимизированные таблицы, улучшена поддержка SQL.

  • MySQL Cluster 8.0 на основе MySQL 8.0

Требования

Для целей оценки, можно запустить MySQL Cluster на одном физическом сервере. Для развертывания производства, минимальные системные требования относятся к 3-х инстанций / хостов:

  • 2 × Узлы данных
  • 1 × Применение / Узел управления
  • 2 × Узел данных + Программное обеспечение
  • 1 × Узел управления

Конфигурации следующим образом:

  • ОС: Linux , Solaris , Windows , . MacOs (для развития только)
  • Процессор: Intel / AMD x86 / x86-64, UltraSPARC
  • Память: 1 Гб
  • HDD: 3GB
  • Сеть: 1+ узлы (Стандарт Ethernet — TCP / IP)

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

история

MySQL AB приобрела технологию за MySQL Cluster от Alzato , небольшой венчурной компании начатой Ericsson . ОПРС был первоначально разработан для телекоммуникационного рынка , с высокой доступностью и высокими требованиями к производительности.

MySQL Cluster на основе движка хранения NDB с тех пор была интегрирована в MySQL продукт, с его первым выпуском релиза в MySQL 4.1.

Служба поддержки

MySQL Cluster лицензирован под GPLv лицензии 2. Коммерческая поддержка доступна как часть MySQL Cluster КГЭ, которая также включает в себя аддоны , не с открытым исходным кодом , такие как MySQL Cluster Manager, MySQL Enterprise Monitor, в дополнение к MySQL Enterprise Security и MySQL Enterprise аудита.

Быстрая миграция MySQL на failover cluster

MySQL — одна из самых ходовых, распространенных и простых во внедрении СУБД. Этот СУБД использует, наверное, половина всех проектов веба. Исключительная простота установки и внедрения, распространенность, поддержка “из коробки” во всех ходовых языках программирования для веб (perl, PHP, ruby, python, JS/node). Из-за мнимой простоты внедрения на потенциальные проблемы внедрения внимания просто не обращают — 90% проектов не доживут до того момента, когда заботливо разложенные авторами MySQL грабли больно ударят по лбу.

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

В данном примере участвуют три сервера:

  • db1 (IP 10.10.171.2)
  • db2 (IP 10.10.171.3)
  • db3 (IP 10.10.171.4)

DB1 — “старый” сервер с обычным MySQL, данные с которого мигрируют в кластер. DB2 и DB3, соответственно — свежие сервера. В принципе, установка свежего кластера “с нуля” (без данных) — не будет отличаться практически ничем. Изначально статья ориентирована на Debian, но для CentOS сделаны необходимые отступления, благо отличий немного.

Немного истории

Percona XtraDB — это ответвление (fork) изначального MySQL, созданного Монти Видениусом. В какой-то момент Видениус продал свой проект, и это сильно затормозило развитие проекта. Так, как проект обладал спорным качеством когда и был (с другой стороны) очень популярен — появилось огромное количество патчей, которые расширяли, углубляли и ускоряли кодовую базу. Самыми известным были набор патчей от google и набор патчей от Петра Зайцева. Последний создал компанию Percona, в рамках которой оптимизирует MySQL и консультирует пользователей этой системы. Он же выпускает свой форк MySQL, в котором собирает удачно работающие патчи. Как следствие — percona sql server с одной стороны надежнее, с другой — функциональнее, да и просто быстрее. В определенный момент был выпущен специальный дистрибутив XtraDB Cluster с набором библиотек Gallera Cluster — очень удачного и производительного решения для кластеризации MySQL

Подготовка

XtraDB cluster не входит в стандартные дистрибутивы ОС (ни для Debian, ни для CentOS), по этому, нужно добавить дистрибутивы

Для Debian (все операции проводим от root):

теперь установим xtradb.

В момент установки MySQL server будет удален из системы. Вы НЕ потеряете базы и данные в них, но сервис не будет работать до тех пор, пока вы не закончите настройку

Чтобы члены кластера могли общаться друг с другом, на каждом сервере нужно разрешить доступ со всех членов кластера по портам 4444 и 4567. Кроме того, со всех серверов, которые будут использовать кластер БД нужно разрешить доступ на порт 3306 (штатный порт mysq) и 9199 (об этом — далее).


Настройка кластера

Добавим в /etc/my.cnf (в debian он может называться /etc/mysql/my.cnf — если он уже есть — правим его!) следующие строки:

запустим первый узел в кластере. Если вы мигрируете кластер с существующего MySQL на percona — это надо делать на старом сервере, где данные. Этот узел в кластере будет образцом — остальные заберут с него данные

создадим пользователя для синхронизации:

скопируем конфигурацию на DB2, и внесем необходимые изменения:

Теперь подключим новый узел в кластер:

Запускаться он будет долго, так как ему надо снять копию с работающего уже члена кластера. К слову — в этот момент кластер уже работает и ваши пользователи могут использовать базу.

Как только mysql на втором сервере стартует успешно — можно проверить состояние кластера. Для этого в mysql консоли любого сервера пишем:

как видно — status — synced, размер кластера — 2 (узла). Все работает, по аналогии добавляем третий узел (не забудьте поменять wsrep_node_address в настройках!)

failover-доступ

Большая часть современного ПО, работающая с MySQL, не может нормально обрабатывать несколько серверов. По этому мы будем использовать haproxy для распределения нагрузки. В этом примере haproxy ставится на каждый сервер, который использует mysql. HAProxy есть в базовом репозитории любого современного дистрибутива, так что просто ставим пакет:

Теперь настраиваем его. Пишем в конфигурацию /etc/haproxy/haproxy.cfg:

Порт 9199 haproxy будет использовать, чтобы убедится, что член кластера работоспособен и функционирует, как нужно. Сам XtraDB кластер не ждет соединений на 9199 порту. Нам потребуется специальный сервис, который будет локально проверять работу xtradb-cluster сервера для HAProxy. Сервис проверки очень прост, это не демон, так что его будет запускать супердемон xinetd. Вернемся на db1. Для начала — установим xinetd:

Создадим там файл /etc/xinetd.d/mysqlchk со следующим содержимым:

Немного подробностей о том, что тут написано. Главные настройки — это server_args. Они позиционные, так что очередность путать нельзя:

  • имя пользователя для проверки. Нужны права CONNECT и REPLICATION CLIENT
  • пароль
  • отвечать, что сервер доступен, если он — донор (то есть остальные сервера в данный момент синхронизируются с него)
  • путь к файлу журнала
  • отвечать, что сервер не доступен, если он сейчас readonly (синхронизируется или заблокирован). Если поставить 1 — haproxy будет считать сервер в статусе readonly доступным
  • путь к my.cnf. В некоторых версиях debian он находится в /etc/mysql/my.cnf

пользователь и пароль в директиве server_args — из конфигурации mysql (выше). Обратите внимание на путь к my.cnf, в некоторых версиях debian он находится в /etc/mysql/my.cnf

Так же нужно добавить следующую строку в /etc/services:

После этого можно перезапустить xinetd. Проверим, что сервис проверки работает, как задумано:

Эту последовательность действий надо повторить на всех машинах — членах кластера.

Теперь можно спокойно перезапустить haproxy, зайти на страницу статистики (в данном примере — https://[SERVER_IP]:8086/) и убедится, что haproxy видит все сервера кластера. После этого можно спокойно прописывать на сервере-пользователе БД локальный адрес 127.0.0.1, порт и все остальные настройки — без изменений — и теперь у вас есть отказоустойчивый кластер баз mysql

послесловие

Не смотря на то, что данное решение кажется “идеальным решением”, у него есть и слабые стороны. На всякий случай, опишу их:

  • Ведение кластеризации требует накладных расходов. Они очень незначительны (по моим замерам не получалось более 2% от базовой производительности сервера). Частично это нивелируется тем, что Percona быстрее, чем штатный MySQL, частично — тем, что мы используем балансировку нагрузки. Однако не упомянуть об этом было бы нечестно. Накладные расходы растут с увеличением количества узлов в кластере.
  • Percona Xtradb cluster крайне плохо поддерживает таблицы типа MyISAM. Об этом даже пишут в официальной документации. Если вам нужен MyISAM — я очень не рекомендую использовать xtradb cluster
  • Данная конфигурация отвечает исключительно за репликацию, шардирование (разделение данных между серверами в зависимости от содержимого, например — пользователи с четным ID — на правый сервер, с нечетным — на левый) — тут отсутствует.

в случае аварии

Если что-то из описанного в статье работает не так, как описано (или не работает вовсе) — попробуйте проверить ваши последние шаги. Самые частые проблемы, с которыми сталкивался я, это:

Как установить и настроить сервер кластер MySQL на CentOS 7

Главное меню » Операционная система CentOS » Как установить и настроить сервер кластер MySQL на CentOS 7

Заглавие

  1. Предпосылки
  2. Шаг 1 – Настройка узла управления
    1. A. Загрузка программного обеспечение кластера MySQL
    2. B. Установка и удаление пакетов
    3. C. Установка кластера MySQL
    4. D. Настройка кластера MySQL
    5. E. Старт узла управления
  3. Шаг 2 – Настройка в MySQL Cluster Data Nodes
    1. A. Войти как root пользователь и загрузить программное обеспечение кластера MySQL
    2. B. Установка и удаление пакетов
    3. C. Установить кластер MySQL
    4. D. Настройка узла данных
    5. E. Повторить шаг 2.А – 2.D на db3 сервере.
  4. Шаг 3 – Настройка SQL Node
    1. A. Вход в систему и загрузка кластера MySQL
    2. B. Установка и удаление пакетов
    3. C. Установка кластера MySQL
    4. D. Настройка SQL Node
    5. E. Повторить шаг 3.A – 3.D на DB5 сервере.
  5. Шаг 4 – Монитор кластера
  6. Шаг 5 – Тестирование кластера
  7. Вывод

M ySQL Cluster предназначен для обеспечения совместимой базы данных MySQL с высокой доступностью и низкой задержкой. Технология кластера MySQL реализуется через механизмы хранения NDB (Network DataBase) и NDB кластер и обеспечивает неразделяемую кластеризацию и авто-шардинга для систем баз данных MySQL. В неразделяемой архитектуре, каждый из узлов имеет свою собственную память и диск, использование общего хранилища, такие как NFS, SANs не рекомендуется и поддерживается.

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

1. Узел управления – NDB_MGMD/MGM
Сервер управления кластера используется для управления другого узла кластера. Мы можем создавать и настраивать новые узлы, перезагрузки, удаление или резервирование узлов в кластере из узла управления.

2. Узлы данных – NDBD / NDB
Это слой, где происходит процесс синхронизации и репликации данных между узлами.

3. SQL Узлы – MYSQLD / API
Серверы интерфейса, которые используются приложениями для подключения к кластеру базы данных.

На этом уроке, я проведу вас через установку и конфигурацию кластера MySQL с CentOS 7. Мы настроим узел управления, два узла передачи данных и два узла SQL.


Предпосылки

  • ОС CentOS 7 – 64-битная.
  • 5 CentOS серверов или виртуальных машин. Я буду использовать имена хостов и IP-адреса, как показано ниже:
    • Узел управления
      DB1 = 192.168.1.220
    • Данные узлы
      db2 = 192.168.1.221
      db3 = 192.168.1.222
    • SQL узлы
      db4 = 192.168.1.223
      DB5 = 192.168.1.224

Шаг 1 – Настройка узла управления

Первый шаг заключается в создании “Узел управления” с CentOS 7 DB1 и IP 192.168.1.220 . Убедитесь , что вы вошли в сервер db1 в качестве пользователя root.

A. Загрузите программное обеспечение кластера MySQL

Я буду загружать его с сайта MySQL с помощью wget. Я использую здесь “Red Hat Enterprise Linux 7 / Oracle Linux 7 (x86, 64-разрядная версия), RPM Bundle”, который совместим с CentOS 7. Затем извлекаем архивный файл.

B. Установка и удаление пакетов

Перед тем как установить пакет MySQL Cluster, вам нужно установить Perl-Data-Dumper, который требуется серверу MySQL-кластера. И вам нужно удалить MariaDB-LIBS прежде чем мы сможем установить MySQL Cluster.

C. Установить MySQL Cluster

Установить пакет MySQL Cluster с командой rpm :

Убедитесь, что нет никакой ошибки.

D. Настройка MySQL Cluster

Создайте новый каталог для файлов конфигурации. Я буду использовать каталог “/var/lib/mysql-cluster“.

Затем создайте новый файл конфигурации для управления кластерами под названием “config.ini ” в каталоге MySQL-кластера.

Вставьте следующую конфигурацию:

Сохраните файл и выйдите.

E. Запустите узел управления

Далее запустите узел управления с командой ниже:

Результат должен быть похож на этот:

MySQL Cluster Management Server mysql-5.6.28 ndb-7.4.10
2020-10-08 18:26:05 [MgmtSrvr] INFO — The default config directory ‘/usr/mysql-cluster’ does not exist. Trying to create it…
2020-10-08 18:26:05 [MgmtSrvr] INFO — Successfully created config directory

Узел управления запускается, теперь вы можете использовать команду “ndb_mgm” для мониторинга узла:

Вы можете увидеть, что узел управления был запущен с: MySQL-6.6 и ndb-7.4.

Шаг 2 – Настройка в MySQL Cluster Data Nodes

Мы будем использовать 2 сервера CentOS для узлов данных.

A. Войдите как пользователь root и загрузите программное обеспечение кластера MySQL

Вход на сервер DB2 с помощью SSH:

Затем загрузите пакет MySQL Cluster и извлеките его:

B. Установка и удаление пакетов

Установка Perl-Data-Dumper и удаление MariaDB-LIBS:

C. Установите MySQL Cluster

Теперь мы можем установить пакеты кластера MySQL для узлов данных с помощью этих команд rpm:

Убедитесь, что нет никакой ошибки.

D. Настройка узла данных

Создайте новый файл конфигурации в директории /etc с помощью редактора vi:

Вставьте следующую конфигурацию:

Сохраните файл и выйдите.

Затем создайте новый каталог для данных базы данных, которое мы определили в файле конфигурации узла управления “config.ini”.

Теперь запустите узел данных / NDBD:


2020-10-08 19:35:56 [ndbd] INFO — Angel connected to ‘192.168.1.220:1186’
2020-10-08 19:35:56 [ndbd] INFO — Angel allocated nodeid: 2

Узел данных DB2 подключен к узлу управления интеллектуальной собственностью 192.168.1.220.

E. Повторить шаг 2.А – 2.D на db3 сервере.

Так как мы имеем 2 узла данных, пожалуйста, повторить шаги 2.А – 2.d на нашем втором узле данных.

Шаг 3 – Настройка SQL Node

Это шаг содержит настройки для SQL Node, который предоставляет приложению доступ к базе данных. Мы используем 2 сервера CentOS для SQL узлов:

A. Войдите в систему и загрузите MySQL Cluster

Войдите на сервер db4 в качестве пользователя root:

И загрузите пакет MySQL Cluster:

B. Установка и удаление пакетов

Установите perl-Data-Dumper и удалите mariadb-libs, чтобы не было конфликта с MySQL Cluster.

C. Установите MySQL Cluster

Установите сервер MySQL Cluster, клиента и пакет с помощью команды rpm ниже:

D. Настройка SQL Node

Создайте новый файл my.cnf в каталоге /etc:

Скопируйте конфигурацию ниже:

Сохраните файл и выйдите из редактора.

Запустите SQL Node, запустив сервер MySQL:

E. Повторить шаг 3.A – 3.D на DB5 сервере.

Пожалуйста, повторите шаги 3.А – 3.D на втором сервере SQL (DB5).

Шаг 4 – Мониторинг кластера

Чтобы увидеть состояние кластера, мы должны войти в DB1 узел управления.

Мы можем использовать команду ndb_mgm, чтобы увидеть состояние кластера:

Еще одна полезная команда:

Шаг 5 – Тестирование кластера

Для того, чтобы выполнить тест на нашем новом MySQL Cluster, мы должны войти в db4 или db5 узлов серверов SQL.

Вход на сервер db4:

Измените в MySQL пароль по умолчанию, сохраненный в файле “.mysql_secret” в корневом каталоге:

# The random password set for the root user at Tue Mar 21 19:44:07 2020 (local time): qna4AwbJOuOnw13T

Теперь измените пароль с помощью команды ниже:

Введите старый пароль MySQL, а затем введите новый, нажмите клавишу ВВОД, чтобы подтвердить.

Если все будет сделано, вы можете войти в оболочку MySQL с паролем:

После того, как вы вошли в систему, создайте нового пользователя root для хоста ” @ “, так что мы сможем получить доступ к MySQL извне.

Заменить andreyex123 на ваш собственный надежный пароль! Теперь вы можете увидеть нового пользователя root “@” в списке пользователей MySQL:

И предоставьте новому пользователю root привилегии: читать и написать доступ с удаленного узла:

Теперь попробуйте создать новую базу данных с сервера db4 и вы увидите базу данных на DB5 тоже.

Это просто результат выборки для тестирования репликации данных кластера.

MySQL Cluster успешно был установлен на CentOS 7 с 5 серверными узлами

Вывод

MySQL Cluster представляет собой технологию, которая обеспечивает высокую доступность и избыточность для баз данных MySQL. Он использует NDB или NDBCLUSTER в качестве механизма хранения и обеспечивает неразделяемую кластеризацию и авто-шардинг для баз данных MySQL. Для реализации кластера, нам нужно 3 компонента: Узел управления (MGM), Узлы данных (NDB) и SQL-узлы (API). Каждый из узлов должен иметь свою собственную память и диск. Не рекомендуется использовать сетевое хранилище, такие как NFS. Чтобы установить MySQL Cluster на минимальной системе CentOS 7, мы должны удалить пакет MariaDB-LIBS, MariaDB-LIBS конфликтует с MySQL кластер-сервером, и вы должны установить пакет Perl-Data-Dumper, это необходимо для MySQL-кластера-сервера. Кластер MySQL легко установить и настроить на нескольких серверах CentOS.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Как ускорить работу MySQL и снять нагрузку с дисковой подсистемы

Любой успешный проект рано или поздно сталкивается с проблемой роста. Число посетителей веб-сайта увеличивается, веб-сервер обрабатывает бóльшее количество соединений, растёт поток запросов к базе данных. В определённый момент времени отзывчивость сайта снижается: страницы загружаются медленнее, что, согласно многочисленным исследованиям, влияет на конверсию (пример подобного исследования — https://www.webperformancetoday.com/2014/04/09/web-page-speed-affect-conversions-infographic/).

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

В первую очередь следует выяснить характер нагрузки на диски. В этом поможет утилита iostat. В Ubuntu она устанавливается с пакетом sysstat:

iostat — очень мощный и удобный инструмент для просмотра статистики ввода/вывода и показателей загрузки блочных устройств. Его использование — тема для отдельной статьи. В нашей ситуации с его помощью следует определить соотношение чтения/записи, чтобы выяснить дальнейшее направление работы.

Как ускорить чтение

Допустим, диски загружены запросами на чтение. Что можно сделать, чтобы ускорить отдачу данных? Закэшировать данные в памяти. MySQL предоставляет возможность использования разных хранилищ, или движков (storage engines), для доступа к данным, поэтому подход к кэшированию разный. Рассмотрим два наиболее популярных движка: MyISAM и InnoDB.

Движок InnoDB имеет встроенный кэш для данных и индексов — так называемый Buffer Pool. Его размер регулируется переменной innodb_buffer_pool_size. В идеале размер Buffer Pool должен быть как минимум такого объёма, чтобы в нём полностью можно было разместить все данные и индексы плюс 30%-60% от их размера. Дополнительная память используется для служебных нужд и Insert Buffer, а также для обеспечения запаса памяти на будущее. Переменная innodb_buffer_pool_size — не динамическая, поэтому после её изменения в конфигурационном файле потребуется перезапуск MySQL.

Движок MyISAM не имеет кэша для данных. Но мы по-прежнему можем ускорить чтения из таблиц MyISAM. Дело в том, что ядро Linux кэширует все прочитанные файлы в области оперативной памяти, которая называется pagecache. Разумеется, файлы с таблицами MyISAM также попадают в этот кэш. Объём pagecache можно узнать из вывода команды free:

Максимальной производительности чтения можно добиться, если объём pagecache равен объёму данных MyISAM.

По умолчанию под pagecache выделяется почти вся незанятая процессами память, поэтому увеличить его объём можно лишь установкой дополнительных планок RAM. Однако память — недорогой по сравнению с ЦПУ и дисками ресурс, при этом эффект от увеличения кэша может привести к значительному увеличению производительности. Ниже представлен график %iowait — доли времени, в течение которого ЦПУ ожидает ввода/вывода. График снят с рабочего нагруженного сервера. Думаю, комментарии здесь излишни.

Как ускорить запись

Увеличить производительность MySQL при большом объёме записи можно с помощью тонкой настройки параметров сервера.

По умолчанию InnoDB сбрасывает изменённые данные на диск с помощью системного вызова fsync(). При этом операционная система не гарантирует, что данные попадут в хранилища сию секунду, т.к. данные сперва проходят через буфер, поддерживаемый ядром. Буферизация необходима для ускорения ввода/вывода.

Однако если datadir MySQL расположен на аппаратном RAID-массиве, то есть возможность задействовать для такой буферизации NVRAM-кэш RAID-контроллера, что намного эффективнее. Следует только убедиться, что контроллер оснащён BBU (Battery Backup Unit) — отдельным источником питания для кэша. При внезапном отключении электропитания у контроллера должно быть время, чтобы сбросить содержимое кэша на диски, иначе данные в массиве останутся в неконсистентном состоянии.

При задействовании кэша RAID-контроллера повысить производительность операций записи в БД можно, отключив ненужную буферизацию на уровне операционной системы. Для этого требуется выставить переменную MySQL innodb_flush_method в значение O_DIRECT, после чего перезагрузить систему управления базы данных. Снизить нагрузку на диски также может изменение переменной innodb_flush_log_at_trx_commit. Для соответствия требованиям ACID движок InnoDB хранит логи транзакций, или redo-логи, в которые записываются все запросы на изменение данных. Эти логи используются в процессе восстановления после аварийного останова системы управления базами данных.

Значение по умолчанию (1) предполагает, что буфер redo-логов, расположенный в памяти InnoDB, записывается на диск после каждого коммита транзакции. Это наиболее безопасный режим работы, обеспечивающий сохранность каждой транзакции даже в случае “падения” сервера. Можно выставить innodb_flush_log_at_trx_commit в значение 2, тогда логи будут записываться также после каждого коммита, но fsync() — сброс данных на диск — будет выполняться лишь раз в секунду (начиная с версии MySQL 5.6.6 этот интервал определяется переменной innodb_flush_log_at_timeout). Аварийное завершение работы СУБД не приведёт к потере транзакций, однако отключение самого сервера может привести к потере последней секунды транзакций. Значение 0 подразумевает ещё более быстрый режим записи — данные и записываются, и синхронизируются раз в секунду, безотносительно коммитов транзакций. Однако innodb_flush_log_at_trx_commit=0 может привести к потере транзакций даже при падении процесса. Администратору базы данных нужно сделать выбор исходя из текущей нагрузки и бизнес-требований.

Оптимизировать дисковые операции записи помогает правильный выбор размера redo-логов. Для этого есть несложное правило. Достаточно замерить объём данных, который записан в лог за одну минуту. Эту операцию нужно выполнять в момент дневной пиковой нагрузки:

Из примера видно, что за минуту в лог InnoDB записывается 2,44 Мб данных. Объём лога следует подбирать таким образом, чтобы в него умещался объём данных за час. В таком случае у InnoDB будет достаточно времени, чтобы изменить порядок запросов на ввод/вывод для достижения последовательной записи. В нашем примере за один час через redo-логи проходит 150 Мб данных, поэтому переменную innodb_log_file_size следует выставить в значение не менее 75M. Если объём лога выбрать слишком большим, то увеличится время InnoDB Crash Recovery, что увеличит даунтайм при аварийном перезапуске (стоит отметить, что в MySQL 5.5 время Crash Recovery зависит от размера InnoDB-лога в меньшей степени).

Вывод

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

Мастер Йода рекомендует:  Создаем favicon для сайта
Добавить комментарий