Как настроить репликацию группы MySQL в Ubuntu 16.04

Вступление

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

Групповая репликация - это способ реализации более гибкого, отказоустойчивого механизма репликации. Этот процесс включает создание пула серверов, каждый из которых участвует в обеспечении правильного копирования данных. Если основной сервер испытывает проблемы, участники выборов могут выбрать новый основной из группы. Это позволяет оставшимся узлам продолжать работу даже перед лицом проблем. Согласование членства, обнаружение сбоев и доставка сообщений обеспечивается реализациейPaxos concensus algorithm.

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

Предпосылки

Для продолжения вам понадобится группа из трех серверов Ubuntu 16.04. На каждом из этих серверов вам нужно будет настроить пользователя без полномочий root с привилегиямиsudo и настроить базовый брандмауэр. Мы будем использоватьinitial server setup guide for Ubuntu 16.04, чтобы удовлетворить эти требования и привести каждый сервер в состояние готовности.

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

Генерация UUID для идентификации MySQL Group

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

Наmysqlmember1 используйте командуuuidgen, чтобы сгенерировать действительный UUID для группы:

uuidgen

Output959cf631-538c-415d-8164-ca00181be227

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

Настройте групповую репликацию в файле конфигурации MySQL

Теперь мы готовы изменить конфигурационный файл MySQL. Откройте основной файл конфигурации MySQL наeach MySQL server:

sudo nano /etc/mysql/my.cnf

По умолчанию этот файл используется только для получения дополнительных файлов из подкаталогов. Нам нужно будет добавить нашу собственную конфигурациюbeneath в строки!includedir. Это позволяет нам легко переопределить любые настройки из включенных файлов.

Для начала откройте раздел для компонентов сервера MySQL, включив заголовок[mysqld]. Ниже мы вставим настройки, необходимые для групповой репликации. Префиксloose- позволяет MySQL корректно без ошибок обрабатывать параметры, которые он не распознает. Нам нужно будет заполнить и настроить многие из этих настроек в ближайшее время:

/etc/mysql/my.cnf

. . .
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/

[mysqld]

# General replication settings
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1

# Shared replication group configuration
loose-group_replication_group_name = ""
loose-group_replication_ip_whitelist = ""
loose-group_replication_group_seeds = ""

# Single or Multi-primary mode? Uncomment these two lines
# for multi-primary mode, where any host can accept writes
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON

# Host specific replication configuration
server_id =
bind-address = ""
report_host = ""
loose-group_replication_local_address = ""

Мы разделили конфигурацию выше на четыре раздела. Давайте рассмотрим их сейчас.

Настройки репликации группы Boilerplate

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

/etc/mysql/my.cnf

. . .
# General replication settings
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1
. . .

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

Параметры репликации общей группы

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

Установитеloose-group_replication_group_name на UUID, который вы создали ранее с помощью командыuuidgen. Вставьте скопированный UUID в качестве значения для этой переменной.

Затем установитеloose-group_replication_ip_whitelist в список всех IP-адресов вашего сервера MySQL, разделенных запятыми. Параметрloose-group_replication_group_seeds должен быть почти таким же, как и белый список, но должен добавлять порт репликации группы, который мы будем использовать, в конец каждого члена. Для этого руководства мы будем использовать рекомендуемый порт 33061 для групповой репликации:

/etc/mysql/my.cnf

. . .
# Shared replication group configuration
loose-group_replication_group_name = "959cf631-538c-415d-8164-ca00181be227"
loose-group_replication_ip_whitelist = "203.0.113.1,203.0.113.2,203.0.113.3"
loose-group_replication_group_seeds = ""203.0.113.1:33061,203.0.113.2:33061,203.0.113.3:33061"
. . .

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

Выбор одного основного или нескольких основных

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

Если вы хотите настроить группу с несколькими основными источниками, раскомментируйте директивыloose-group_replication_single_primary_mode иloose-group_replication_enforce_update_everywhere_checks. Это создаст многоосновную группу. Для одной основной группы просто оставьте эти две строки с комментариями:

/etc/mysql/my.cnf

. . .
# Single or Multi-primary mode? Uncomment these two lines
# for multi-primary mode, where any host can accept writes
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON
. . .

Эти настройки должны быть одинаковыми на всех ваших серверах MySQL.

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

Специфичные для хоста настройки конфигурации

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

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

Директиваserver_id должна иметь уникальный номер. Для первого члена просто установите для него значение «1» и увеличьте число на каждом дополнительном хосте. Установитеbind-address иreport_host на IP-адрес текущего сервера, чтобы экземпляр MySQL мог прослушивать внешние соединения и правильно сообщать свой адрес другим хостам. Вloose-group_replication_local_address также должен быть установлен IP-адрес текущего сервера с портом репликации группы (33061), добавленным к IP-адресу:

/etc/mysql/my.cnf

. . .
# Host specific replication configuration
server_id = 1
bind-address = "203.0.113.1"
report_host = "203.0.113.1"
loose-group_replication_local_address = "203.0.113.1:33061"

Завершите этот процесс на каждом из ваших серверов MySQL.

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

Перезапустите MySQL и включите удаленный доступ

Наш конфигурационный файл MySQL теперь содержит директивы, необходимые для начальной загрузки групповой репликации MySQL. Чтобы применить новые настройки к экземпляру MySQL, перезапустите службу наeach of your servers с помощью следующей команды:

sudo systemctl restart mysql

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

Нам нужно открыть доступ к этим двум портам в нашем брандмауэре, что мы можем сделать, набрав:

sudo ufw allow 33061
sudo ufw allow 3306

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

Настроить пользователя репликации и включить плагин репликации группы

Наeach of your MySQL servers войдите в свой экземпляр MySQL с администратором, чтобы начать интерактивный сеанс:

mysql -u root -p

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

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

Мы потребуем SSL для пользователей репликации, предоставим им привилегии репликации на сервере, а затем сбросим привилегии для реализации изменений. После этого мы снова включим двоичное ведение журнала, чтобы возобновить нормальную работу. Убедитесь, что используете безопасный пароль при создании пользователя репликации:

SET SQL_LOG_BIN=0;
CREATE USER 'repl'@'%' IDENTIFIED BY 'password' REQUIRE SSL;
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;

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

CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';

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

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

Убедитесь, что плагин активен, набрав:

SHOW PLUGINS;

Output+----------------------------+----------+--------------------+----------------------+---------+
| Name                       | Status   | Type               | Library              | License |
+----------------------------+----------+--------------------+----------------------+---------+
|                            |          |                    |                      |         |
| . . .                      | . . .    | . . .              | . . .                | . . .   |
|                            |          |                    |                      |         |
| group_replication          | ACTIVE   | GROUP REPLICATION  | group_replication.so | GPL     |
+----------------------------+----------+--------------------+----------------------+---------+
45 rows in set (0.00 sec)

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

Начать групповую репликацию

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

Начальная загрузка первого узла

Чтобы запустить группу, выполните следующие шаги наa single member of the group.

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

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

SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

Группа должна быть запущена с этим сервером в качестве единственного участника. Мы можем проверить это, проверив записи в таблицеreplication_group_members в базе данныхperformance_schema:

SELECT * FROM performance_schema.replication_group_members;

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

Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
1 row in set (0.00 sec)

ЗначениеONLINE дляMEMBER_STATE указывает, что этот узел полностью работает в группе.

Затем создайте тестовую базу данных и таблицу для проверки нашей репликации:

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

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

SELECT * FROM playground.equipment;

Output+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.00 sec)

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

Запустите оставшиеся узлы

Затем наsecond server запустите групповую репликацию. Поскольку у нас уже есть активный участник, нам не нужно загружать группу, и мы можем просто присоединиться к ней:

START GROUP_REPLICATION;

Наthird server запустите репликацию группы таким же образом:

START GROUP_REPLICATION;

Проверьте список участников еще раз. Теперь вы должны увидеть три сервера:

SELECT * FROM performance_schema.replication_group_members;

Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

Все члены должны иметь значениеMEMBER_STATE равноеONLINE. Для новой группы, если какой-либо из узлов отображается какRECOVERING более секунды или двух, это обычно указывает на то, что произошла ошибка или что-то было неправильно сконфигурировано. Проверьте журналы на/var/log/mysql/error.log, чтобы получить дополнительную информацию о том, что пошло не так.

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

SELECT * FROM playground.equipment;

Output+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.01 sec)

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

Тестирование возможностей записи новых членов группы

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

Тестирование пишет в одной основной среде

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

SHOW STATUS LIKE '%primary%';

Output+----------------------------------+--------------------------------------+
| Variable_name                    | Value                                |
+----------------------------------+--------------------------------------+
| group_replication_primary_member | 13324ab7-1b01-11e7-9dd1-22b78adaa992 |
+----------------------------------+--------------------------------------+
1 row in set (0.01 sec)

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

SELECT * FROM performance_schema.replication_group_members;

Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

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

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");

OutputERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

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

Тестирование пишет в многоосновной среде

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

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

SHOW STATUS LIKE '%primary%';

Output+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| group_replication_primary_member |       |
+----------------------------------+-------+
1 row in set (0.02 sec)

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

Проверьте это на своемsecond server, набрав:

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");

OutputQuery OK, 1 row affected (0.00 sec)

Второй сервер совершил операцию записи без ошибок.

Вthird server запросите, чтобы увидеть, что новый элемент был добавлен:

SELECT * FROM playground.equipment;

Output+----+-------+-------+--------+
| id | type  | quant | color  |
+----+-------+-------+--------+
|  1 | slide |     2 | blue   |
|  2 | swing |    10 | yellow |
+----+-------+-------+--------+
2 rows in set (0.00 sec)

Это подтверждает, что запись второго сервера была успешно реплицирована.

Теперь проверьте возможности записи на третьем сервере, набрав:

INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");

OutputQuery OK, 1 row affected (0.02 sec)

Вернувшись кfirst server, протестируйте, чтобы убедиться, что операции записи от обоих новых участников были реплицированы обратно:

SELECT * FROM playground.equipment;

Output+----+--------+-------+--------+
| id | type   | quant | color  |
+----+--------+-------+--------+
|  1 | slide  |     2 | blue   |
|  2 | swing  |    10 | yellow |
|  3 | seesaw |     3 | green  |
+----+--------+-------+--------+
3 rows in set (0.01 sec)

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

Восстановление группы

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

На вашемfirst server установите переменнуюgroup_replciation_bootstrap_group, а затем начните инициализировать группу:

SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=ON;
START GROUP_REPLICATION;
SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=OFF;

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

START GROUP_REPLICATION;

Выполните этот процесс для дополнительных членов:

START GROUP_REPLICATION;

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

SELECT * FROM performance_schema.replication_group_members;

Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

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

Автоматическое присоединение к группе при запуске MySQL

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

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

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

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

Имея в виду вышеупомянутые предостережения, если вы хотите настроить узлы для автоматического присоединения к группе при запуске MySQL, откройте основной файл конфигурации MySQL:

sudo nano /etc/mysql/my.cnf

Внутри найдите переменнуюloose-group_replication_start_on_boot и установите для нее значение «ON»:

/etc/mysql/my.cnf

[mysqld]
. . .
loose-group_replication_start_on_boot = ON
. . .

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

Заключение

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

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

TOC

Как настроить репликацию группы MySQL в Ubuntu 16.04

Вступление

Предпосылки

Генерация UUID для идентификации MySQL Group

Настройте групповую репликацию в файле конфигурации MySQL

Настройки репликации группы Boilerplate

Параметры репликации общей группы

Выбор одного основного или нескольких основных

Специфичные для хоста настройки конфигурации

Перезапустите MySQL и включите удаленный доступ

Настроить пользователя репликации и включить плагин репликации группы

Начать групповую репликацию

Начальная загрузка первого узла

Запустите оставшиеся узлы

Тестирование возможностей записи новых членов группы

Тестирование пишет в одной основной среде

Тестирование пишет в многоосновной среде

Восстановление группы

Автоматическое присоединение к группе при запуске MySQL

Заключение

Related