Установка и настройка кластера mysql ubuntu

Обновлено: 05.07.2024

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

Оба форка используют в качестве плагина InnoDB, движок Percona XtraDB Storage Engine.

Этот движок основан на коде InnoDB-plugin и полностью совместимый с ним, но отличается заметно более высокой производительностью, благодаря интеграции патчей от компаний Google и Percona.
В частности, в XtraDB улучшен механизм работы с памятью, улучшена работа подсистемы ввода/вывода InnoDB, добавлена поддержка нескольких потоков чтения и записи, поддержка управления пропускной способностью,
реализация упреждающей выборкой данных (read-ahead), адаптивная установка контрольных точек (adaptive checkpointing), расширены возможности по масштабированию для больших проектов, система организации блокировок адаптирована
для работы на системах с большим числом CPU, добавлены дополнительные возможности для накопления и анализа статистики.

При этом, MariaDB Galera отличается целым рядом других улучшений и возможностей.

Aria (ранее Maria) — основанное на MyISAM высоконадежное хранилище, отличающееся повышенной устойчивостью и сохранению целостности данных после краха, при полной совместимости с MyISAM. Благодаря ведению лога операций, в случае краха производится откат результатов выполнения текущей операции. Также поддерживается возможность восстановления состояния из любой точки в логе операций (включая поддержку CREATE/DROP/RENAME/TRUNCATE).
PBXT (PrimeBase XT) — хранилище, разработанное с нуля и поддерживающее мультиверсионный метод организации хранения данных MVCC (multi-version concurrency control), позволяющий избавиться от блокировок при выполнении операций чтения.
PBXT поддерживает ACID-совместимые транзакции, быстрый откат транзакций и восстановление после некорректного завершения работы сервера. Имеются средства для обеспечения ссылочной целостности данных, поддержка определения внешних ключей (foreign key), каскадных обновлений и удалений данных. Поддерживается возможность прямого потокового ввода и вывода бинарных данных (BLOB) в БД;
FederatedX — позиционируется в качестве замены разработанного в Sun Microsystems и уже не поддерживаемого хранилища Federated. FederatedX позволяет организовать обращение к удаленным таблицам как к локальным.
Имеется поддержка транзакций, одновременной установки нескольких соединений к удаленной СУБД, использования операций «LIMIT»;
OQGRAPH — хранилище для организации иерархических (древовидных) структур и сложных графов (узлов, имеющих множество связей);
Sphinx — хранилище для построения поисковых движков. Встроенный Sphinx-клиент позволяет MariaDB обмениваться данными с searchd, выполнять поисковые запросы и получать результаты поиска;

Кроме того, в MariaDB Galera 10 появился целый ряд улучшений по сравнению с версией 5.5:

Улучшения портированные из MySQL 5.6:

Обновлённый вариант хранилища InnoDB.
Поддержка движка PERFORMANCE_SCHEMA и связанной с ним базы performance_schema, предоставляющей низкоуровневые средства для мониторинга за выполнением запросов и различными событиями при работе СУБД;
Режим только для чтения для транзакций в InnoDB, поддержка выражения «TRANSACTION READ ONLY»;
Оптимизации скорости выполнения запросов вида «ORDER BY… LIMIT».
Поддержка "--plugin-load-add";
Возможность выполнения «ALTER TABLE» на лету;
Установка привилегий для временных таблиц;
Расширения, связанные с поддержкой кодировок;
Выражение «GET DIAGNOSTICS»;
Временные литералы (например, TIME'12:34:56').

Более подробное описание стабильного выпуска СУБД MariaDB 10.0, можно найти в источнике на opennet

Почему я выбрал MariaDB Galera 10?

MariaDB Galera 10 поддерживает MySQL Query Cache из коробки. Любая инструкция по установке любой из имплементаций MySQL Galera, явно указывает о необходимости отключения Query Cache. В итоге, при переходе с одиночного сервера баз данных на кластерный вариант, скорость чтения сложных запросов падает в разы. А нагрузка на сервер, соизмеримо возрастает.
Percona XtraDB Cluster в версии 5.6 так же приблизились к внедрению полноценного поддержки Query Cache, но тут требуется включать его на «живую», уже после запуска ноды при помощи запросов:

При включенном Query Cache, до 95% запросов возвращают результат из кеша вместо того что бы выполняются снова.

Хочу сразу дать пару своих замечаний.

Кеша не должно быть много. Самый большой размер, который вообще стоит устанавливать, это не более 512МБ. Даже 512МБ — это очень много, реально нужно меньше. И вот почему:

Если в любой из таблиц, выборка из которой есть в кеше, проиcходят изменения (вставка или изменение строк), то MySQL удаляет из кеша такие выборки. Такой подход ускоряет работу MySQL, но может быть неэффективным для систем с большим количеством запросов на изменение таблиц. Это приводит к тому, что таблицы просто блокируются в режиме Waiting for query cache lock.

Кеш запросов можно представлять себе как хеш, ключами которого являются запросы, а значениями — результаты запросов.
Если использование кеша запросов включено, то при получении запроса MySQL определяет, равны ли первые три символа запроса «SEL». Если да, то MySQL смотрит, есть ли в кеше запросов запись с ключом, равным запросу.

Отсюда следуют два важных правила:

MySQL выполняет побайтовое сравнение, поэтому запросы, имеющие отличие хотя бы в одном символе (например, SELECT * FROM table и select * from table) будут рассматриваться как два разных запроса. Поэтому необходимо писать запросы в едином стиле;
В MySQL до версии 5.0 запросы, в начале которых есть пробел или написан комментарий никогда не будут браться из кеша.

Кроме результатов, MySQL хранит в кеше список таблиц, выборка из которых закеширована.

Подробнее о кеше запросов, можно прочитать в источнике на habrahabr

От слов к делу

Думаю, что Вам использовать, Вы уже разобрались. Дальше по тексту я описываю работу с MariaDB Galera 10, но практически все описанное, справедливо и для Percona XtraDB Cluster 5.6.

Если мы переводим одиночную инсталяцию MySQL в кластерное исполнение:

Убедимся что все наши базы данных не содержат таблиц с движком MyISAM
Убедимся что у всех таблиц в наших базах данных есть первичные ключи:

Для решения первой проблемы есть 2 пути:

Для небольших таблиц первый вариант срабатывает довольно-таки быстро. А вот с большими таблицами возникают проблемы. Так как конвертация будет выполняться долго, таблица будет заблокирована и все операции с ней станут невозможными, что непременно скажется на оказании услуг/сервисов. Для решения этой проблемы нам поможет утилита pt-online-schema-change из комплекта percona-toolkit.

Ставится эта утилита из репозитария для CentOS:

Важно Необходимо, чтобы у конвертируемой таблицы был или первичный (PRIMARY), или уникальный (UNIQUE) ключ, иначе выдаст ошибку, например такую:

Cannot chunk the original table `database`.`NAMETABLE01_NOKEY`: There is no good index and the table is oversized. at /usr/bin/pt-online-schema-change line 5442.

Для решения второй проблемы, увы, путь только один — добавить PRIMARY или UNIQUE ключ через ALTER.

All tables should have a primary key (multi-column primary keys are supported). DELETE operations are unsupported on tables without a primary key. Also, rows in tables without a primary key may appear in a different order on different nodes.

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

Если эти проблемы мы оставили позади, то перейдем к установке и настройке самого сервера БД.

Для настройки серверов MariaDB и кластеров Galera, я написал скрипт, он создает заготовку конфигурационного файла, индивидуально для каждого сервера.

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

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

Пояснения к конфигу и скрипту генерации

wsrep_sst_method=xtrabackup

Если использовать режим rsync, то в момент синхронизации ноды с донора, донор будет полностью блокирован на запись. В режиме xtrabackup же, блокировка будет длиться лишь несколько секунд, пока xtrabackup «прицепится» к базе.
Если вы используете HAProxy как это описано тут HAPRoxy для Percona или Galera на CentOS. Его настройка и мониторинг в Zabbix то что бы работать с сервером, пока тот находится в режиме донора, нам нужно отредактировать скрипт clustercheck на нодах.

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

стоит попробовать поменять на transaction-isolation = READ-COMMITTED т.е. переход на снимочное выполнение транзакций. Каждая транзакция становится своего рода независимой песочницей. Снимком данных.
Это нечто похожее на уровень изоляции Oracle. Все выражения SELECT… FOR UPDATE и SELECT… LOCK IN SHARE MODE блокируют только индексные записи и не блокируют интервал перед ними. Поэтому они позволяют свободно добавлять новые записи после заблокированных. UPDATE и DELETE, которые используют уникальный индекс и уникальные условия поиска, блокируют только найденную индексную запись, и не блокируют интервал перед ней. Но в UPDATE и DELETE диапазонного типа в InnoDB должны установить блокировку следующего ключа или интервальную блокировку и блокировать добавления другими пользователями в интервал, покрытый диапазоном. Это необходимо, т.к. «фантомные строки» должны быть блокированы для успешной работы репликации и восстановления в MySQL. Согласованное чтение работает как и в Oracle: каждое согласованное чтение, даже внутри одной транзакции, устанавливает и читает свой собственный снимок.
В большинстве случаев, переход дает прирост в скорости на конкурентной записи, но так же возможен эффект фантомного чтения. На своей практике я встречал лишь одно приложение, которое болело фантомностью. Т.е. это приложения использующие СУБД, нужно проверить на возможность работы в этом режиме.

innodb_flush_log_at_trx_commit = 2

Значение «1» означает, что любая завершенная транзакция будет синхронно сбрасывать лог на диск. Это вариант по умолчанию, он является самым надежным с точки зрения сохранности данных, но самым медленным по скорости работы.
Значение «2» делает то же самое, только сбрасывает лог не на диск, а в кеш операционной системы (т.е. не происходит flush после каждой операции). Это значение подойдет в большинстве случаев, т.к. не выполняет дорогой операции записи после каждой транзакции. При этом лог пишется на диск с задержкой в несколько секунд, что весьма безопасно с точки зрения сохранности данных.
Но у нас кластер и в случае краха, данные все равно будут переданы с донора. Главное что бы транзакция закомитилась на других нодах. Тогда данные мы получим при SST

innodb_buffer_pool_instances = 2

По умолчанию InnoDB использует для Buffer Pool один инстанс.
При этом есть возможность выделить несколько блоков — и работает с ними MySQL в InnoDB в ряде случаев гораздо эффективнее. Это связанно с меньшими блокировками кеша при записи данных.

innodb_file_format = barracuda

Этот формат самый «новый» и поддерживает компрессию. Это позволяет снизить нагрузку на IO (диски) путём использования сжатия. Так же как рекомендация можно использовать размер блока записи 16КБ.

Вот пример alter’a:

Вот результаты тестирования скорости и размера данных при сжатии.
Но есть минусы сжатия. На сжатых таблицах ALTER-ы будут происходить значительно дольше, как известно ALTER, как и любой DDL, блокирует таблицу и вместе с ней весь кластер. ALTER — это не транзакционная инструкция, а значит не реплицируются ROW-бинарными diff-ами а передаются в виде запосов. И пока этот запрос не исполнится на всех нодах кластера, все коммиты будут заморожены.
Т.е. сжатие имеет смысл делать либо на больших таблицах, где не планируются DDL в принципе, либо на одиночных инстансах mysql.

innodb_flush_method = O_DIRECT

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

Стоит добавить важный с точки зрения производительности параметр skip-innodb_doublewrite

Even though double write requires each page written twice its overhead is far less than double. Write to double write buffer is sequential so it is pretty cheap. It also allows Innodb to save on fsync()s – instead of calling fsync() for each page write Innodb submits multiple page writes and calls fsync() which allows Operating System to optimize in which order writes are executed and use multiple devices in parallel. This optimization could be used without doublewrite though, it was just implemented at the same time. So in general I would expect no more than 5-10% performance loss due to use of doublewrite.

tmp_table_size = 2048M
max_heap_table_size = 2048M

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

optimizer_switch='derived_merge=off,derived_with_keys=off'

Бывают проблемы с совместимостью приложения с базой, после перехода на percona 5.6 и galera 10. Наиболее значительные из них стоит сразу предупредить параметром

thread_handling = pool-of-threads
thread_pool_size = количество_ядер

wsrep_retry_autocommit = 3

Важно! Если в базе дедлок, коммиты будут ретраиться, т.е. нода не будет выпадать из кластера при первом же чихе, а будет дальше работать и мы не теряем коммит.

Вот подробное описание, эти параметры я обычно ставлю по умолчанию всегда.

Параметр wsrep_replicate_myisam=1 это почти 100% гарантия смерти кластера если там появится хоть одна боевая myisam таблица.

Данная фича до сих пор экспериментальная и ее включение добавляет к ROW (на базе бинарных diff снимков) репликации еще и statement, те как и при репликации DDL команд. Это значит постоянные конфликты, блокировки и развал кластера после любого дедока myisam таблицы.

Если у вас возникнут вопросы, трудности или потребуется совет:
Мои контакты в профиле

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

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

В самом простом случае вес каждого узла является равным 1, соответственно, если для наблюдаемой части кластера сумма весов узлов > N/2, эта часть кластера считается работоспособной. Например, для 3х узлов:

В общем случае, для безотказной работы кластера Galera вам необходимо обеспечить надежность:

избыточность сетевой инфраструктуры (стеки, MLAG, OSPF);
качественное энергоснабжение и разделение на независимые домены отказа, например, 3 VM в одном сервере не могут считаться надежным решением для формирования кластера Galera.

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

Подробнее за деталями обратитесь к оригинальной статье о Galera.

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

Конечно, помимо достоинств у кластера Galera есть и ограничения (перевод фрагмента с официального сайта MariaDB):

Не поддерживается репликация явных блокировок, включая LOCK TABLES , FLUSH TABLES WITH READ LOCK , ( GET_LOCK () , RELEASE_LOCK () ,…); Правильное использование транзакций позволяет преодолеть эти ограничения, однако, если движок использует вышеприведенные операции, они должны выполняться но одном и том же узле. Операции глобальной блокировки, такие как FLUSH TABLES WITH READ LOCK поддерживаются.
Все таблицы должны иметь первичный ключ (поддерживаются первичные ключи на нескольких столбцах). Операции DELETE не поддерживаются в таблицах без первичного ключа. Кроме того, строки в таблицах без первичного ключа могут извлекаться на разных узлах в разном порядке.
Общий журнал запросов и журнал медленных запросов не могут быть перенаправлены в таблицу. Если вы включите эти журналы, то вы должны отправлять вывод записей журналов в файл, установив log_output = FILE .
Транзакции XA не поддерживаются.
Хотя Galera явно не ограничивает размер транзакции, набор записей обрабатывается как один резидентный буфер памяти, и в результате очень большие транзакции (например, LOAD DATA ) могут отрицательно повлиять на производительность узла. Чтобы избежать этого, системные переменные wsrep_max_ws_rows и wsrep_max_ws_size ограничивают размер строки в транзакции 128 КБ, а максимальный размер транзакции составляет 1 ГБ. При необходимости пользователи могут увеличить эти ограничения. В будущих версиях будет добавлена поддержка фрагментации транзакций.

Мы рассмотрим самую простую настройку кластера Galera с тремя узлами, как изображено на следующей картинке:

Для дальнейшей работы рассмотрим как установить MariaDB для различных операционных систем. В этом руководстве мы будем использовать текущую стабильную версию MariaDB версии 10.3.

Установка MariaDB

Установка в Debian 9

Произведем базовую установку MariaDB 10.3, рекомендованную поставщиком для Debian 9 Stretch:

Проверьте корректность установки, соединившись с MariaDB с помощью клиента командной строки:

Соединение работает, если вы получили вывод похожий на приведенный выше. Теперь, когда установка MariaDB завершена, можно перейти к настройке кластера.

Установка в Ubuntu 18.04

Произведем базовую установку MariaDB 10.3, рекомендованную поставщиком для Ubuntu Linux 18.04:

Проверьте корректность установки, соединившись с MariaDB с помощью клиента командной строки:

Установка в Ubuntu 16.04

Произведем базовую установку MariaDB 10.3, рекомендованную поставщиком для Ubuntu Linux 16.04:

Проверьте корректность установки, соединившись с MariaDB с помощью клиента командной строки:

Установка в CentOS 7

Произведем базовую установку MariaDB 10.3, рекомендованную поставщиком для CentOS 7. Сначала необходимо добавить репозиторий пакетов MariaDB 10.3 в Yum:

со следующим содержимым:

Теперь можно выполнить установку пакетов:

Проверьте корректность установки, соединившись с MariaDB с помощью клиента командной строки:

Подготовка к настройке кластера

Настройка кластера Galera довольно проста, однако требует выполнения ряда подготовительных действий.

Конфигурация сетевых параметров

Для корректной работы кластера необходим доступ к следующим портам:

Мы считаем, что узлы соединены приватной доверенной сетью, не требующей брэндмауэра. Если у вас используется брэндмауэр, вам необходимо открыть вышеуказанные порты для обеспечения пропуска трафика. Если вы планируете использовать multicast , порт 4567 должен быть открыт как для пропуска трафика UDP, так и для TCP.

Примечание для пользователей Cloud2 NetPoint: В облаке Cloud 2 NetPoint для каждого аккаунта или проекта помимо публичной сети предоставляется еще и приватная сеть, в которую входят только виртуальные машины этого аккаунта. Эта сеть безопасна, работает на скорости 10 Gbit/s, и именно она должна использоваться для настройки кластерных решений вместо публичной сети.

Шифрование трафика кластера

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

Дополнительные параметры конфигурации MySQL

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

Параметр wsrep_sst_method

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

Мы будем использовать способ rsync, который является рекомендуемым способом по умолчанию.

Общий вид конфигурационного файла galera.cnf

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

Настройка с использованием multicast

При использовании многоадресной доставки в файл настроек необходимо внести некоторые изменения:

Другие параметры wsrep_*

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

На каждом узле остановите MariaDB, в каталоге /etc/mysql/conf.d создайте файл galera.cnf с указанными выше настройками для Galera:

Не забудьте установить корректные значения параметров wsrep_cluster_address , wsrep_provider_options (multicast группа или другие опции, если используются), wsrep_node_address , wsrep_node_name , wsrep_cluster_name .

Инициализация кластера

Запуск первого узла Galera. Выберите любой из узлов и инициализируйте кластер. Операция не деструктивная, никакие данные не удаляются и не повреждаются:

Запуск оставшихся узлов. Каждый из оставшихся узлов запускается как обычно:

Проверьте состояние кластера с помощью значения переменных wsrep_*:

Если теперь на одном из узлов выполнить команду sudo systemctl stop mariadb , то вы немедленно увидите как изменится вывод вышеприведенных команд:

Важно. Когда вы отключаете узлы штатным способом, как сделали выше, кластер понимает, что общий вес кластера надо уменьшить (был 3/3, стал 2/2), поэтому состояние кластера считается целостным, а не деградированным. Если же узлы отключаются аварийно, то вес кластера не уменьшается (был 3/3, стал 2/3).

Проверка репликации данных

На одном из узлов создадим базу данных, таблицу и вставим данные в нее:

Убедимся, что репликация произошла на оставшиеся узлы, выполнив на каждом из них команду запроса данных:

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

Перезапуск кластера

Если каким-то образом все узлы кластера оказались выключены, вы должны повторить процедуру инициализации. Если серверы MariaDB будут запущены обычным образом, то сборка кластера не произойдет. Первый сервер вы должны запустить с помощью команды sudo galera_new_cluster .

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

Использование ClusterControl для развертывания и управления кластером Galera

Мы рассмотрели настройку кластера Galera в ручном режиме. Кроме этого подхода кластер Galera можно легко развернуть и обслуживать с помощью ClusterControl.

Если вы хотите развернуть кластер Galera с помощью ClusterControl, обратитесь к нашей статье на эту тему.

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

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

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

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

Требования

Для работы вам понадобится 3 сервера: два будут нодами MySQL (ndbd), а оставшийся будет менеджером кластера (ndb_mgmd) и сервером/клиентом MySQL (mysqld and mysql).

Примечание: Серверы должны находиться в одном датацентре и иметь доступ к частной сети.

Требования к серверам:

Система Ubuntu 18.04.
Пользователь с доступом к sudo.

Настроить серверы вам поможет этот мануал.

Не забудьте записать внутренние IP-адреса серверов. В данном мануале мы используем такие адреса:

198.51.100.0 – первая нода MySQL Cluster.
198.51.100.1 – вторая нода.
198.51.100.2 – менеджер кластера и серверная нода MySQL.

Замените условные IP-адреса адресами своих серверов.

1: Установка и настройка менеджера MySQL Cluster

Для начала загрузите и установите ndb_mgmd, менеджер MySQL Cluster.

Для этого нужно получить соответствующий инсталлятор .deb с официального сайта MySQL Cluster.

Откройте страницу загрузок и в Select Operating System выберите Ubuntu Linux. Затем в Select OS Version выберите Ubuntu Linux 18.04 (x86, 64-bit).

Прокрутите вниз до «DEB Package, NDB Management Server» и нажмите Download для пакета без dbgsym (если только вам не нужны символы отладки). Вы попадете на страницу Begin Your Download. Здесь кликните правой кнопкой на No thanks, just start my download. Скопируйте ссылку на файл .deb.

Войдите на сервер Cluster Manager (198.51.100.2), загрузите файл:

Установите ndb_mgmd с помощью dpkg:

sudo dpkg -i mysql-cluster-community-management-server_7.6.6-1ubuntu18.04_amd64.deb

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

Менеджер кластера должен быть первым компонентом, запускаемым в любом кластере MySQL. Для этого требуется передать файл конфигурации в качестве аргумента его исполняемому файлу. Создайте файл конфигурации /var/lib/mysql-cluster/config.ini и используйте его для этой цели.

На менеджере создайте каталог /var/lib/mysql-cluster, в котором будет находиться этот файл:

sudo mkdir /var/lib/mysql-cluster

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

sudo nano /var/lib/mysql-cluster/config.ini

Вставьте следующий текст в редактор:

После этого не забудьте заменить указанные выше условные значения правильными IP-адресами серверов. Установка параметра hostname является важной мерой безопасности – это препятствует подключению других серверов к Cluster Manager.

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

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

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

Теперь можно запустить менеджер, выполнив бинарный файл ndb_mgmd и указав его конфигурационный файл с помощью флага -f:

Это означает, что сервер-менеджер кластера MySQL успешно установлен и теперь запущен на вашем сервере.

В идеале менеджер кластера должен запускаться автоматически при загрузке сервера. Для этого создайте сервис systemd и добавьте его в автозагрузку.

Но сначала нужно остановить работающий сервер:

sudo pkill -f ndb_mgmd

Теперь откройте и отредактируйте следующий юнит-файл systemd:

sudo nano /etc/systemd/system/ndb_mgmd.service

Вставьте в него:

[Unit] Description=MySQL NDB Cluster Management Server
After=network.target auditd.service
[Service] Type=forking
ExecStart=/usr/sbin/ndb_mgmd -f /var/lib/mysql-cluster/config.ini
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
[Install] WantedBy=multi-user.target

Файл содержит минимальный набор параметров, которые сообщают systemd о том, как запустить, остановить и перезапустить процесс ndb_mgmd. Чтобы узнать больше о параметрах, используемых в такой конфигурации, обратитесь к руководству по systemd.

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

Теперь перезагрузите конфигурацию systemd менеджера с помощью daemon-reload:

sudo systemctl daemon-reload

Включите сервис, который вы только что создали, чтобы добавить его в автозагрузку:

sudo systemctl enable ndb_mgmd

Теперь запустите сервис:

sudo systemctl start ndb_mgmd

Убедитесь, что сервис NDB Cluster Management запущен успешно:

Такой вывод указывает, что менеджер кластера MySQL ndb_mgmd теперь работает как сервис systemd.

Последним шагом в настройке менеджера будет поддержка входящих соединений от других нод MySQL Cluster в этой частной сети.

Примечание: Если при настройке этого сервера вы не настроили брандмауэр ufw, вы можете просто перейти к следующему разделу.

Добавьте правила, пропускающие локальные входящие соединения с обоих нод данных:

sudo ufw allow from 198.51.100.0
sudo ufw allow from 198.51.100.1

Вы получите такой вывод:

Менеджер кластера настроен и запущен, а также поддерживает соединения с нодами по частной сети.

2: Установка и настойка нод данных

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

Теперь пора установить демон нод данных ndbd и настроить ноды для взаимодействия с менеджером.

Для этого нужно получить соответствующий инсталлятор .deb с официального сайта MySQL Cluster.

Откройте страницу загрузок и в Select Operating System выберите Ubuntu Linux. Затем в Select OS Version выберите Ubuntu Linux 18.04 (x86, 64-bit).

Прокрутите вниз до «DEB Package, NDB Data Node Binaries» и нажмите Download для пакета без dbgsym (если только вам не нужны символы отладки). Вы попадете на страницу Begin Your Download. Здесь кликните правой кнопкой на No thanks, just start my download. Скопируйте ссылку на файл .deb.

Войдите на сервер первой ноды (198.51.100.0), загрузите файл:

Затем нужно установить зависимость:

sudo apt update
sudo apt install libclass-methodmaker-perl

Теперь можно установить пакет:

sudo dpkg -i mysql-cluster-community-data-node_7.6.6-1ubuntu18.04_amd64.deb

Ноды данных берут свои конфигурации из стандартного файла MySQL /etc/my.cnf. Создайте его и откройте в редакторе:

sudo nano /etc/my.cnf

Добавьте в файл такой параметр:

Расположение менеджера кластера является единственной конфигурацией, необходимой для запуска ndbd. Остальная конфигурация будет загружена непосредственно с менеджера.

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

В данном примере нода данных узнает, что ее каталог данных находится в /usr/local/mysql/data, в конфигурации менеджера. Перед запуском демона создайте этот каталогг:

sudo mkdir -p /usr/local/mysql/data

Запустите ноду данных:

Демон ноды данных NDB был успешно установлен и теперь запущен на вашем сервере.

Также необходимо разрешить входящие соединения от других нод MySQL Cluster в частной сети.

Примечание: Если при настройке этого сервера вы не включили брандмауэр ufw, вы можете просто перейти к следующему разделу.

Добавьте правила, которые пропустят входящие соединения от менеджера кластера и других нод данных:

sudo ufw allow from 198.51.100.0
sudo ufw allow from 198.51.100.2

После ввода команд вы увидите:

Теперь нода данных MySQL может взаимодействовать с менеджером и второй нодой данных по частной сети.

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

Сначала остановите процесс ndbd:

sudo pkill -f ndbd

Откройте и отредактируйте юнит-файл:

sudo nano /etc/systemd/system/ndbd.service

Вставьте такой код:

[Unit] Description=MySQL NDB Data Node Daemon
After=network.target auditd.service
[Service] Type=forking
ExecStart=/usr/sbin/ndbd
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
[Install] WantedBy=multi-user.target

Файл содержит минимальный набор параметров, которые сообщают systemd о том, как запустить, остановить и перезапустить процесс ndbd. Чтобы узнать больше о параметрах, используемых в такой конфигурации, обратитесь к руководству по systemd.

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

Теперь перезагрузите конфигурацию systemd менеджера с помощью daemon-reload:

sudo systemctl daemon-reload

Включите сервис, который вы только что создали, чтобы добавить его в автозагрузку:

sudo systemctl enable ndbd

Теперь запустите сервис:

sudo systemctl start ndbd

Убедитесь, что сервис ndbd запущен успешно:

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

Закончив настройку первой ноды, повторите шаги этого раздела на второй ноде данных (198.51.100.1).

3: Настройка и запуск сервера и клиента MySQL

Стандартный сервер MySQL, который доступен в репозитории APT Ubuntu, не поддерживает механизм NDB MySQL Cluster. Это означает, что вам нужно установить SQL-сервер, упакованный вместе с другим программным обеспечением MySQL Cluster, которое вы установили ранее.

Загрузите двоичный код MySQL Cluster Server с официальной страницы MySQL Cluster.

Откройте страницу загрузок и в Select Operating System выберите Ubuntu Linux. Затем в Select OS Version выберите Ubuntu Linux 18.04 (x86, 64-bit).

Прокрутите вниз до DEB Bundle и нажмите Download (пакет будет первым в списке). Вы попадете на страницу Begin Your Download. Здесь кликните правой кнопкой на No thanks, just start my download. Скопируйте ссылку на tar архив.

Войдите на сервер менеджера кластера(198.51.100.2), загрузите этот архив (напоминаем, что в среде производства совмещать сервер MySQL и менеджер кластера на одной ноде не рекомендуется, лучше использовать для этого отдельные машины).

Теперь распакуйте архив в каталог install. Создайте его:

Извлеките архив в этот каталог:

tar -xvf mysql-cluster_7.6.6-1ubuntu18.04_amd64.deb-bundle.tar -C install/

Перейдите в него:

Прежде чем установить сервер MySQL, установите его зависимости:

sudo apt update

sudo apt install libaio1 libmecab2

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

sudo dpkg -i mysql-common_7.6.6-1ubuntu18.04_amd64.deb
sudo dpkg -i mysql-cluster-community-client_7.6.6-1ubuntu18.04_amd64.deb
sudo dpkg -i mysql-client_7.6.6-1ubuntu18.04_amd64.deb
sudo dpkg -i mysql-cluster-community-server_7.6.6-1ubuntu18.04_amd64.deb

Теперь можно установить сервер MySQL с помощью dpkg:

После этого нужно настроить установку сервера.

Конфигурационный файл MySQL Server хранится в /etc/mysql/my.cnf.

Откройте его в редакторе:

sudo nano /etc/mysql/my.cnf

Вставьте в файл такие строки:

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

Перезапустите сервер MySQL:

sudo systemctl restart mysql

MySQL по умолчанию запускается автоматически после перезагрузки сервера. Если этого не случилось, введите:

sudo systemctl enable mysql

Теперь сервер SQL запущен на сервере Cluster Manager / MySQL Server.

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

4: Тестирование установки MySQL Cluster

Чтобы протестировать работу установки, войдите на сервер Cluster Manager / SQL Server.

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

По запросу введите свой пароль и нажмите Enter. Появится такой вывод:

Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.7.22-ndb-7.6.6 MySQL Cluster Community Server (GPL)
Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>

В оболочке клиента MySQL введите команду:

SHOW ENGINE NDB STATUS \G

Вы должны увидеть информацию о кластере NDB, начиная с параметров подключения:

*************************** 1. row ***************************
Type: ndbcluster
Name: connection
Status: cluster_node_id=4, connected_host=198.51.100.2, connected_port=1186, number_of_data_nodes=2, number_of_ready_data_nodes=2, connect_count=0
. . .

Это означает, что вы успешно подключились к вашему кластеру MySQL.

Наиболее важной строкой является number_of_ready_data_nodes. Как видите, в кластере запущено две ноды. Такая избыточность обеспечивает работу кластера MySQL даже в случае сбоя одной из нод. Кроме того, запросы SQL будут распределяться между двумя нодами.

Попробуйте отключить одну ноду, чтобы протестировать надёжность кластера. Проще всего перезапустить сервер, чтобы выполнить полную проверку процесса восстановления. Вы увидите, что значение number_of_ready_data_nodes изменится: сначала появится 1, а после перезагрузки ноды снова станет 2.

Чтобы выйти из командной строки MySQL, просто введите quit или нажмите CTRL-D.

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

Откройте консоль управления кластером, ndb_mgm:

-- NDB Cluster -- Management Client --
ndb_mgm>

Нажмите Enter. Вы должны получить такой вывод:

Connected to Management Server at: 198.51.100.2:1186
Cluster Configuration
---------------------
[ndbd(NDB)] 2 node(s)
id=2 @198.51.100.0 (mysql-5.7.22 ndb-7.6.6, Nodegroup: 0, *)
id=3 @198.51.100.1 (mysql-5.7.22 ndb-7.6.6, Nodegroup: 0)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @198.51.100.2 (mysql-5.7.22 ndb-7.6.6)
[mysqld(API)] 1 node(s)
id=4 @198.51.100.2 (mysql-5.7.22 ndb-7.6.6)

Этот вывод показывает, что в кластере есть две ноды данных, связанные с node-ids 2 и 3. Существует также одна нода-менеджер с id 1 и один сервер MySQL с node-id 4. Вы можете получить больше информации о каждом id, введя его номер вместе с командой STATUS:

Эта команда выведет состояние ноды 2, версию MySQL и NDB:

Node 2: started (mysql-5.7.22 ndb-7.6.6)

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

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

5: Добавление данных в кластер

Чтобы продемонстрировать работу кластера. Попробуйте создать новую таблицу NDB и вставить в неё какие-нибудь данные.

Примечание: В кластере необходимо использовать именно NDB (не InnoDB и другие предлагаемые варианты). В противном случае кластер не будет работать должным образом.

Создайте БД clustertest:

CREATE DATABASE clustertest;

Откройте новую БД:

Создайте простую таблицу test_table:

CREATE TABLE test_table (name VARCHAR(20), value VARCHAR(20)) ENGINE=ndbcluster;

Чтобы использовать кластер, нужно явно указать ndbcluster. Вставьте данные в таблицу:

INSERT INTO test_table (name,value) VALUES('some_name','some_value');

Чтобы убедиться, что данные были помещены в БД, запросите их:

SELECT * FROM test_table;

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

Вы также можете сделать ndbcluster механизмом хранения по умолчанию – это делается в файле my.cnf, который вы редактировали ранее. Если вы это сделаете, вам не нужно будет указывать параметр ENGINE при создании таблиц. Чтобы узнать больше, обратитесь к руководству по MySQL.

Заключение

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

Читайте также: