TOC

Как настроить кластер Galera с MariaDB 10.1 на серверах Ubuntu 16.04

Вступление

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

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

В этом руководстве мы настроим активно-активный кластер MariaDB Galera. В демонстрационных целях мы настроим и протестируем три узла, самый маленький настраиваемый кластер.

Предпосылки

Чтобы следовать, вам понадобится:

  • Three Ubuntu 16.04 servers, каждый с пользователем без полномочий root с привилегиямиsudo и частной сетью, если вам это доступно.

Как только все эти предварительные условия будут готовы, мы готовы установить MariaDB.

[[шаг-1 -—- добавление-mariadb-10-1-repositories-to-all-servers]] == Шаг 1 - Добавление репозиториев MariaDB 10.1 на все серверы

MariaDB 10.1 не входит в стандартные репозитории Ubuntu, поэтому мы начнем с добавления внешнего репозитория Ubuntu, поддерживаемого проектом MariaDB, на все три наших сервера.

[.note] #Note: MariaDB - уважаемый провайдер, но не все внешние репозитории надежны. Обязательно устанавливайте только из проверенных источников.
#

Сначала мы добавим ключ репозитория MariaDB с помощью командыapt-key, которую apt будет использовать для проверки подлинности пакета. 

sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8

Получив доверенный ключ в базе данных, мы можем добавить репозиторий. После этого нам нужно будет запуститьapt-get update, чтобы включить манифесты пакетов из нового репозитория: 

sudo add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://nyc2.mirrors.digitalocean.com/mariadb/repo/10.1/ubuntu xenial main'
sudo apt-get update

[.note] #Note: Вы должны запустить `update` после добавления репозитория. В противном случае вы установите версию 10.0 из пакетов Ubuntu, которые не содержат пакет Galera.
#

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

[[step-2 -—- install-mariadb-on-all-servers]] == Шаг 2 - Установка MariaDB на всех серверах

Начиная с версии 10.1, пакеты MariaDB Server и MariaDB Galera Server объединены, поэтому установка `mariadb-server` автоматически установит Galera и несколько зависимостей: 

sudo apt-get install mariadb-server

Во время установки вам будет предложено установить пароль для пользователя-администратора MariaDB. Независимо от того, что вы выберете, этот корневой пароль будет перезаписан паролем от первого узла после начала репликации.

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

sudo apt-get install rsync

Это подтвердит, что новейшая версияrsync уже доступна, или предложит обновить или установить ее.

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

[[step-3 -—- configuring-the-first-node]] == Шаг 3 - Настройка первого узла

Каждый узел в кластере должен иметь почти идентичную конфигурацию. Из-за этого мы выполним всю конфигурацию на нашей первой машине, а затем скопируем ее на другие узлы.

По умолчанию MariaDB настроен на проверку каталога/etc/mysql/conf.d, чтобы получить дополнительные параметры конфигурации, начиная с.cnf. Мы создадим файл в этом каталоге со всеми нашими специфичными для кластера директивами: 

sudo nano /etc/mysql/conf.d/galera.cnf

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

/etc/mysql/conf.d/galera.cnf

[mysqld]
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so

# Galera Cluster Configuration
wsrep_cluster_name="test_cluster"
wsrep_cluster_address="gcomm://first_ip,second_ip,third_ip"

# Galera Synchronization Configuration
wsrep_sst_method=rsync

# Galera Node Configuration
wsrep_node_address="this_node_ip"
wsrep_node_name="this_node_name"

  • The first section изменяет или повторно утверждает настройки MariaDB / MySQL, которые позволят кластеру работать правильно. Например, Galera Cluster не будет работать с MyISAM или аналогичными нетранзакционными механизмами хранения, аmysqld не должен быть привязан к IP-адресу для localhost. Вы можете узнать о настройках более подробно на Galera Clustersystem configuration page.

  • The “Galera Provider Configuration” section настраивает компоненты MariaDB, которые предоставляют API репликации WriteSet. В нашем случае это означает Galera, поскольку Galera является поставщиком wsrep (WriteSet Replication). Мы задаем общие параметры для настройки начальной среды репликации. Это не требует настройки, но вы можете узнать больше оGalera configuration options.

  • The “Galera Cluster Configuration” section определяет кластер, идентифицируя членов кластера по IP-адресу или разрешаемому имени домена и создавая имя для кластера, чтобы гарантировать, что члены присоединятся к правильной группе. Вы можете изменитьwsrep_cluster_name на что-то более значимое, чемtest_cluster, или оставить как есть, но выmust обновитеwsrep_cluster_address с адресами ваших трех серверов. Если ваши серверы имеют частные IP-адреса, используйте их здесь.

  • The “Galera Synchronization Configuration” section определяет, как кластер будет обмениваться данными и синхронизировать данные между участниками. Это используется только для передачи состояния, которая происходит, когда узел подключается к сети. Для нашей начальной настройки мы используемrsync, потому что он широко доступен и делает то, что нам нужно сейчас.

  • The “Galera Node Configuration” section уточняет IP-адрес и имя текущего сервера. Это полезно при попытке диагностировать проблемы в журналах и для ссылки на каждый сервер несколькими способами. wsrep_node_address должен соответствовать адресу компьютера, на котором вы находитесь, но вы можете выбрать любое имя, которое поможет вам идентифицировать узел в файлах журнала.

Когда вы будете удовлетворены файлом конфигурации кластера, скопируйте его содержимое в буфер обмена, сохраните и закройте файл.

[[шаг-4 -—- настройка-оставшихся-узлов]] == Шаг 4 - Настройка оставшихся узлов

На каждом из оставшихся узлов откройте файл конфигурации: 

sudo nano /etc/mysql/conf.d/galera.cnf

Вставьте конфигурацию, скопированную с первого узла, затем обновите «Конфигурацию узла Galera», чтобы использовать IP-адрес или разрешаемое имя домена для конкретного настраиваемого узла. Наконец, обновите его имя, которое вы можете установить на любое, что поможет вам идентифицировать узел в ваших файлах журнала:

/etc/mysql/conf.d/galera.cnf

. . .
# Galera Node Configuration
wsrep_node_address="this_node_ip"
wsrep_node_name="this_node_name"
. . .

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

[[шаг-5 -—- открытие-брандмауэр-на-каждом-сервере]] == Шаг 5 - Открытие брандмауэра на каждом сервере

На каждом сервере давайте проверим состояние брандмауэра: 

sudo ufw status

В этом случае только SSH разрешен через: 

OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

Поскольку в этом случае разрешен только трафик ssh, нам нужно добавить правила для трафика MySQL и Galera. Если мы попытаемся запустить кластер, мы потерпим неудачу из-за правил брандмауэра.

Galera может использовать четыре порта:

  • 3306 Для клиентских подключений MySQL и State Snapshot Transfer, которые используют метод mysqldump.

  • 4567 Для трафика репликации Galera Cluster многоадресная репликация использует как транспорт UDP, так и TCP на этом порту.

  • 4568 для дополнительной передачи государства.

  • 4444 Для всех других состояний передачи снимков.

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

Откройте порты с помощью следующей команды: 

sudo ufw allow 3306,4567,4568,4444/tcp
sudo ufw allow 4567/udp

[.note] #Note: В зависимости от того, что еще работает на ваших серверах, вы можете сразу же ограничить доступ. В этом может помочь руководствоUFW Essentials: Common Firewall Rules and Commands.
#

[[step-6 -—- start-the-cluster]] == Шаг 6. Запуск кластера

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

Остановите MariaDB на всех трех серверах:

Используйте команду ниже на всех трех серверах, чтобы остановить mysql, чтобы мы могли восстановить их в кластере: 

sudo systemctl stop mysql

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

sudo systemctl status mysql

Если последняя строка выглядит примерно так, команда прошла успешно. 

Output . . .
Aug 19 02:55:15 galera-01 systemd[1]: Stopped MariaDB database server.

После того, как мы отключимmysql на всех серверах, мы будем готовы продолжить.

Подними первый узел:

Чтобы вызвать первый узел, нам нужно использовать специальный скрипт запуска. Как мы настроили наш кластер, каждый узел, который подключается к сети, пытается подключиться хотя бы к одному другому узлу, указанному в его файлеgalera.cnf, чтобы получить свое начальное состояние. Без использования сценарияgalera_new_cluster, который позволяет systemd передавать параметр--wsrep-new-cluster, обычныйsystemctl start mysql завершится ошибкой, потому что нет запущенных узлов, с которыми можно было бы соединиться с первым узлом. 

sudo galera_new_cluster

Когда этот скрипт завершается успешно, узел регистрируется как часть кластера, и мы можем увидеть его с помощью следующей команды: 

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"
Output+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 1     |
+--------------------+-------+

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

Подними Второй Узел:

Началоmysql: 

sudo systemctl start mysql

Мы должны увидеть увеличение размера нашего кластера при подключении каждого узла: 

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"
Output+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 2     |
+--------------------+-------+

Подними Третий Узел:

Началоmysql: 

sudo systemctl start mysql

Если все работает хорошо, размер кластера должен быть равен трем: 

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"
Output+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

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

[[step-7 -—- configuring-the-debian-maintenance-user]] == Шаг 7 - Настройка пользователя обслуживания Debian

В настоящее время серверы Ubuntu и MariaDB Debian выполняют обычное обслуживание, такое как ротация журналов, в качестве специального пользователя обслуживания. Когда мы установили MariaDB, учетные данные для этого пользователя были сгенерированы случайным образом, сохранены в/etc/mysql/debian.cnf и вставлены в базу данныхmysql MariaDB.

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

Чтобы исправить это, мы скопируемdebian.cnf нашего первого узла в остальные узлы.

Скопируйте с первого узла:

Откройте файлdebian.cnf в текстовом редакторе: 

sudo nano /etc/mysql/debian.cnf

Файл должен выглядеть примерно так: 

[client]
host     = localhost
user     = debian-sys-maint
password = 03P8rdlknkXr1upf
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = debian-sys-maint
password = 03P8rdlknkXr1upf
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

Скопируйте информацию в буфер обмена.

Обновите второй узел:

На втором узле откройте тот же файл: 

sudo nano /etc/mysql/debian.cnf

Несмотря на предупреждение в верхней части файла с надписью «НЕ ПРИКАСАЙТЕСЬ!», Нам нужно внести изменения, чтобы кластер работал. Вы можете уверенно удалить текущую информацию и вставить содержимое из конфигурации первого узла. Теперь они должны быть точно такими же. Сохраните и закройте файл.

Обновите третий узел:

На третьем узле откройте тот же файл: 

sudo nano /etc/mysql/debian.cnf

Удалите текущую информацию и вставьте содержимое из конфигурации первого узла. Сохраните и закройте файл.

Несоответствие не повлияло бы на нашу способность тестировать репликацию, но лучше позаботиться заранее, чтобы избежать сбоев позже.

[.Примечание]##

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

sudo cat /etc/mysql/debian.cnf

Скопируйте пароль с выхода. Затем подключитесь кmysql: 

mysql -u debian-sys-maint -p

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

Если нет, убедитесь, что пароль в файле совпадает с первым узлом, а затем замените его ниже: 

update mysql.user set password=PASSWORD('password_from_debian.cnf') where User='debian-sys-maint';

Повторите, чтобы проверить оставшиеся узлы.

[[step-8 -—- testing-replication]] == Шаг 8 - Тестирование репликации

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

Напишите первому узлу:

Начнем с внесения изменений в базу данных на нашем первом узле. Следующие команды создадут базу данных с именемplayground и таблицу внутри нее с именемequipment. 

mysql -u root -p -e 'CREATE DATABASE playground;
CREATE TABLE playground.equipment ( id INT NOT NULL AUTO_INCREMENT, type VARCHAR(50), quant INT, color VARCHAR(25), PRIMARY KEY(id));
INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");'

Теперь у нас есть одно значение в нашей таблице.

Читать и писать на втором узле:

Далее мы рассмотрим второй узел, чтобы убедиться, что репликация работает: 

mysql -u root -p -e 'SELECT * FROM playground.equipment;'

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

Output+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+

С этого же узла мы можем записать данные в кластер: 

mysql -u root -p -e 'INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");'

Читать и писать на третьем узле:

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

mysql -u root -p -e 'SELECT * FROM playground.equipment;'
Output   +----+-------+-------+--------+
   | id | type  | quant | color  |
   +----+-------+-------+--------+
   |  1 | slide |     2 | blue   |
   |  2 | swing |    10 | yellow |
   +----+-------+-------+--------+

Опять же, мы можем добавить еще одно значение из этого узла: 

mysql -u root -p -e 'INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");'

Читайте на первом узле:

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

mysql -u root -p -e 'SELECT * FROM playground.equipment;'
Output   +----+--------+-------+--------+
   | id | type   | quant | color  |
   +----+--------+-------+--------+
   |  1 | slide  |     2 | blue   |
   |  2 | swing  |    10 | yellow |
   |  3 | seesaw |     3 | green  |
   +----+--------+-------+--------+

Мы проверили, можем ли записывать все узлы, и что репликация выполняется правильно.

Заключение

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

Перед производственным использованием вы можете взглянуть на некоторые изother state snapshot transfer (sst) agents, такие как «xtrabackup», который позволяет вам очень быстро и без больших перерывов в работе ваших активных узлов настраивать новые узлы. Это не влияет на фактическую репликацию, но является проблемой при инициализации узлов.

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

Related