Репликация MySQL надежно отражает данные и операции из одной базы данных в другую. Обычные репликации включают в себя первичный сервер, выполненный с возможностью принимать операции записи в базе данных с вторичными серверами, которые копируют и применяют действия из журнала первичного сервера для своих собственных наборов данных. Эти вторичные серверы могут быть использованы для чтения, но, как правило, не в состоянии выполнить запись данных.
Репликация группы является более гибким способом реализации отказоустойчивого механизма репликации. Этот процесс включает в себя создание пула серверов, каждый из которых, участвует в обеспечении правильного копирования данных. Если первичный сервер испытывает проблемы, могут выбрать новый первичный из группы. Это позволяет остальным узлам продолжать работать, даже перед лицом проблем. Переговоры, обнаружение сбоев и доставка сообщений обеспечиваются через реализацию алгоритма Paxos.
В этой статье мы создадим группу репликации MySQL с помощью набора из трех Ubuntu 16,04 серверов. Конфигурация будет охватывать работу одного первичного или несколько первичных групп репликации.
Для того, чтобы следовать этой статьи, вы будете нуждаться в группе из трех серверов на Ubuntu 16,04. На каждом из этих серверов, вам нужно будет создать не суперпользователя с правами sudo и настроить основной брандмауэр. Мы будем использовать начальное руководство по настройке сервера для Ubuntu 16.04, чтобы удовлетворить эти требования и получить каждый сервер в состояние готовности.
Версия MySQL в репозиториях Ubuntu по умолчанию не включает плагин группы репликации, который нам нужен. К счастью, проект MySQL поддерживает свои собственные репозитории для последней версии MySQL, которая включает в себя этот компонент. Следуйте нашему руководство по установке MySQL на Ubuntu 16.04 для установки репликации, версии рупповой MySQL на каждом сервере.
Перед тем как открыть файл конфигурации MySQL для настройки параметров для репликации группы, мы должны сгенерировать UUID, который можно использовать для идентификации группы MySQL, которую мы будем создавать.
На mysqlmember1 , используйте команду uuidgen, чтобы создать действительный UUID для группы:
959cf631-538c-415d-8164-ca00181be227
Скопируйте значение, которое вы получите. Мы будем ссылаться на его в тот момент, при настройки имени группы для нашего пула серверов.
Теперь мы готовы изменить файл конфигурации для MySQL. Откройте конфигурационный файл MySQL на каждом сервере MySQL:
sudo nano /etc/mysql/my.cnf
По умолчанию этот файл используется только для источника дополнительных файлов из подкаталогов. Мы должны добавить нашу собственную конфигурацию под линиями!includedir. Это позволяет легко изменить все настройки из включенных файлов.
Для начала, откройте раздел для серверных компонентов MySQL, включив заголовок [mysqld]. Под ним мы вставим настройки, которые нужны для группы репликации. Префикс loose-позволяет MySQL корректно обрабатывать параметры без сбоев. Нам нужно будет заполнить и настроить многие из этих параметров в данный момент:
/etc/mysql/my.cnf
. . . !includedir /etc/mysql/conf.d/ !includedir /etc/mysql/mysql.conf.d/ [mysqld] # Главные настройки репликации 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 # Общая конфигурация группы репликации loose-group_replication_group_name = "" loose-group_replication_ip_whitelist = "" loose-group_replication_group_seeds = "" # Один или несколько в первичными режиме? Раскомментируйте следующие две строки # для мульти-основной режима, в котором любой узел может вести запись #loose-group_replication_single_primary_mode = OFF #loose-group_replication_enforce_update_everywhere_checks = ON # Конкретные репликации группы хоста server_id = bind-address = "" report_host = "" loose-group_replication_local_address = ""
Мы разделили конфигурацию выше на четыре секции. Давайте рассмотрим их сейчас.
В первом разделе содержится общие параметры, необходимые для группы репликации, которые не требуют изменений:
. . . # Главные настройки репликации 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 в список всех ваших MySQL IP — адресов серверов, разделенных запятыми. Настройка loose-group_replication_group_seeds должна быть почти такой же, как белый список, но следует добавить порт группы репликации, который мы будем использовать в конце каждого элемента. В этом руководстве мы будем использовать рекомендуемый порт 33061 для репликации группы:
. . . # Общая конфигурация группы репликации loose-group_replication_group_name = "959cf631-538c-415d-8164-ca00181be227" loose-group_replication_ip_whitelist = "114.0.50.1,114.0.50.2,114.0.50.3" loose-group_replication_group_seeds = ""114.0.50.1:33061,114.0.50.2:33061,114.0.50.3:33061" . . .
Этот раздел должен быть одинаковым на каждом из серверов MySQL, поэтому убедитесь, что тщательно скопировали его.
Далее, вы должны решить, следует ли настроить группы single-primary или multi-primary. В некоторых частях официальной документации MySQL, это различие также упоминается как репликации «single» против «multi-master». В одной первичной конфигурации, MySQL обозначает один первичный сервер (почти всегда первый участник группы) для обработки операций записи. Мульти-основная группа позволяет писать любого из участников группы.
Если вы хотите настроить несколько первичных групп, раскомментируйте директивы loose-group_replication_single_primary_mode и loose-group_replication_enforce_update_everywhere_checks. Это позволит создать несколько основных групп. Для одной основной группы просто оставьте эти две строки закомментироваными:
. . . # Один или несколько в первичными режиме? Раскомментируйте следующие две строки # для мульти-основной режима, в котором любой узел может вести запись #loose-group_replication_single_primary_mode = OFF #loose-group_replication_enforce_update_everywhere_checks = ON . . .
Эти параметры должны быть одинаковыми на каждом из серверов MySQL.
Вы можете изменить эту настройку в более позднее время, но не без перезагрузки группы MySQL. Для перехода к новой конфигурации, вы должны остановить каждый из экземпляров MySQL в группе, начните каждый элемент с новыми параметрами, а затем повторно сделайте перезагрузку репликации группы. Это не повлияет на ваши данные, но требует небольшого окна простоя.
Четвертый раздел содержит параметры, которые будут отличаться на каждом из серверов, в том числе:
Директива server_id должна быть установлена на уникальный номер. Для первого элемента, просто установите «1» и увеличиваем количество на каждом дополнительном узле. Установите bind-address и report_host на IP — адрес текущего сервера, так чтобы экземпляр MySQL слушал внешние подключения и правильно сообщал свой адрес другим хостам. loose-group_replication_local_address также должен быть установлен IP — адрес текущего сервера с портом группы репликации (33061), приложенном к IP — адресу:
. . . # Host specific replication configuration server_id = 1 bind-address = "114.0.50.1" report_host = "114.0.50.1" loose-group_replication_local_address = "114.0.50.1:33061"
Завершите этот процесс на каждом из серверов MySQL.
Когда вы закончите, дважды проверьте, что общие настройки репликаций одинаковы на каждом хосте, и что настройки хоста-специфичный настроены для каждого хоста. Сохраните и закройте файл на каждом хосте, когда вы закончите.
Наш файл конфигурации MySQL теперь содержит директивы, необходимые для начальной загрузки группы репликации MySQL. Для того, чтобы применить новые параметры к экземпляру MySQL, перезапустите службу на каждом из серверов с помощью следующей команды:
sudo systemctl restart mysql
В файле конфигурации MySQL, мы настроили службу для прослушивания внешних соединений на порту 3306 по умолчанию. Мы также определили порт 33061 в качестве порта, который участники должны использовать для координации репликации.
Нам нужно открыть доступ к этим двум портам в нашем брандмауэре, выполнив:
sudo ufw allow 33061 sudo ufw allow 3306
Имея доступ к открытым портам MySQL, мы можем создать пользователя репликации и включить плагин группы репликации.
На каждом из серверов MySQL, необходимо войти в экземпляр 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;
+----------------------------+----------+--------------------+----------------------+---------+ | Name | Status | Type | Library | License | +----------------------------+----------+--------------------+----------------------+---------+ | | | | | | | . . . | . . . | . . . | . . . | . . . | | | | | | | | group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | GPL | +----------------------------+----------+--------------------+----------------------+---------+ 45 rows in set (0.00 sec)
Строка group_replication подтверждает, что плагин был загружен и в данный момент активен.
Теперь, когда у каждого сервера MySQL настроен пользователь репликации и включена репликация группы, мы можем начать привлекать участников в нашу группу.
Для того, чтобы запустить группу, выполните следующие шаги по каждому участнику группы.
Участники групп полагаются на существующих участниках для передачи данных репликации, уточненных списков участников, а также другой информации, когда первоначально соединяется с группой. Из-за этого нам нужно использовать несколько иную процедуру для запуска начального участника группы, так что он знает, что не следует ожидать эту информацию от других участников в своем списке.
Если установлено, что переменная 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;
Вы должны увидеть одну строку, представляющую текущий хост:
+---------------------------+--------------------------------------+--------------+-------------+--------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | +---------------------------+--------------------------------------+--------------+-------------+--------------+ | group_replication_applier | 13324ab7-2s23-5s3-675s3-67d1-22b78adaa992 | 114.0.50.5 | 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");
Проверьте содержимое, чтобы убедиться, что оно был введено правильно:
+----+-------+-------+-------+ | id | type | quant | color | +----+-------+-------+-------+ | 1 | slide | 2 | blue | +----+-------+-------+-------+ 1 row in set (0.00 sec)
Теперь мы убедились, что этот сервер является участником группы, и что у него есть возможность писать. Теперь другие серверы могут присоединиться к группе.
Далее, на втором сервере, запустим репликацию группы. Так как у нас уже есть активный элемент, мы не должны грузить группу и можем просто присоединиться к ней:
START GROUP_REPLICATION;
На третьем сервере, запустите группу репликации таким же образом:
START GROUP_REPLICATION;
Проверьте список участников вновь. Вы должны увидеть три сервера в настоящее время:
SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+--------------+-------------+--------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | +---------------------------+--------------------------------------+--------------+-------------+--------------+ | group_replication_applier | 13324ab7-13da-5s3-675s3-67d1-22b78adaa992 | 114.0.50.5 | 3306 | ONLINE | | group_replication_applier | 1ae4b211-13da-5s3-675s3-6789-ceb93e1d5494 | 114.0.50.2 | 3306 | ONLINE | | group_replication_applier | 157b597a-13da-5s3-675s3-6783-566a6de6dfef | 114.0.50.3 | 3306 | ONLINE | +---------------------------+--------------------------------------+--------------+-------------+--------------+ 3 rows in set (0.01 sec)
Все участники должны иметь MEMBER_STATE значение ONLINE. Для свежей группы, если какой — либо из узлов, перечисленный как RECOVERING в течение более чем одной или двух секунд, это обычно признак того, что произошла ошибка или что — то было неправильно настроено. Проверьте журнал в /var/log/mysql/error.log чтобы получить дополнительную информацию о том, что пошло не так.
Проверьте, была ли репликация информации тестовой базы данных на новых участниках:
SELECT * FROM playground.equipment;
+----+-------+-------+-------+ | id | type | quant | color | +----+-------+-------+-------+ | 1 | slide | 2 | blue | +----+-------+-------+-------+ 1 row in set (0.01 sec)
Если имеются данные о новых участниках, то это означает, что группа репликация работает правильно.
Далее, мы можем попытаться написать к базе данных из наших новых участников. Если это удастся, выбрали ли вы настроить один первичный или несколько основной группы.
В одной основной группе, следует ожидать какие-либо операции записи от неосновного сервера должны быть отклонены по соображениям совместимости. Вы можете открыть текущий первичный в любое время с помощью следующего запроса:
SHOW STATUS LIKE '%primary%';
+----------------------------------+--------------------------------------+ | Variable_name | Value | +----------------------------------+--------------------------------------+ | group_replication_primary_member | 13324ab7-2s23-5s3-675s3-67d1-22b78adaa992 | +----------------------------------+--------------------------------------+ 1 row in set (0.01 sec)
Значение запроса будет, MEMBER_ID что вы можете сопоставить с хостом, запрашивая список участников группы, как мы делали раньше:
SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+--------------+-------------+--------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | +---------------------------+--------------------------------------+--------------+-------------+--------------+ | group_replication_applier | 13324ab7-2s23-5s3-675s3-67d1-22b78adaa992 | 114.0.50.5 | 3306 | ONLINE | | group_replication_applier | 1ae4b211-2s23-5s3-675s3-6789-ceb93e1d5494 | 114.0.50.2 | 3306 | ONLINE | | group_replication_applier | 157b597a-2s23-5s3-675s3-6783-566a6de6dfef | 114.0.50.3 | 3306 | ONLINE | +---------------------------+--------------------------------------+--------------+-------------+--------------+ 3 rows in set (0.01 sec)
В этом примере мы можем видеть , что хозяин в 114.0.50.5настоящее время является основным сервером. Если попытаться записать в базу данных из другого участника, следует ожидать , что к сбою операции:
INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");
ERROR 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%';
+----------------------------------+-------+ | Variable_name | Value | +----------------------------------+-------+ | group_replication_primary_member | | +----------------------------------+-------+ 1 row in set (0.02 sec)
Если переменная пуста, это означает, что там не обозначен основной узел и что любой участник должен быть в состоянии принять записи.
Проверьте это на втором сервере , введите команду:
INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");
Query OK, 1 row affected (0.00 sec)
Второй сервер совершил операцию записи без каких-либо ошибок.
На третьем сервере , запрос , чтобы увидеть , что новый элемент был добавлен:
SELECT * FROM playground.equipment;
+----+-------+-------+--------+ | 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");
Query OK, 1 row affected (0.02 sec)
Назад на первый сервер, проверьте, что операции записи из обоих новых участников были скопированы обратно:
SELECT * FROM playground.equipment;
+----+--------+-------+--------+ | id | type | quant | color | +----+--------+-------+--------+ | 1 | slide | 2 | blue | | 2 | swing | 10 | yellow | | 3 | seesaw | 3 | green | +----+--------+-------+--------+ 3 rows in set (0.01 sec)
Это подтверждает, что репликация работает в каждом направлении, и что каждый элемент способен выполнять операции записи.
После того, как группа загрузилась, отдельные участники могут присоединиться и оставить без влияния на доступность, до тех пор, пока имеется достаточно участников, чтобы избрать первичные сервера. Однако, если некоторые изменения конфигурации сделаны (например, переключение между одним и несколькими первичными серверами), или все участникы группы уходят, возможно, потребуется повторная начальная загрузка группы. Вы можете сделать это точно так же, как вы делали изначально.
На вашем первом сервере, установите переменную group_replciation_bootstrap_group, а затем начните инициализацию группы:
После того, как первый участник вступил в группу, другие участники могут присоединиться:
Выполните этот процесс для дополнительных участников:
Теперь группа должна быть доступной в Интернете со всеми участниками:
SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+--------------+-------------+--------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | +---------------------------+--------------------------------------+--------------+-------------+--------------+ | group_replication_applier | 13324ab7-2s23-5s3-675s3-67d1-22b78adaa992 | 114.0.50.5 | 3306 | ONLINE | | group_replication_applier | 1ae4b211-2s23-5s3-675s3-6789-ceb93e1d5494 | 114.0.50.2 | 3306 | ONLINE | | group_replication_applier | 157b597a-2s23-5s3-675s3-6783-566a6de6dfef | 114.0.50.3 | 3306 | ONLINE | +---------------------------+--------------------------------------+--------------+-------------+--------------+ 3 rows in set (0.01 sec)
Этот процесс может быть использован для запуска группы снова по мере необходимости.
С текущими настройками, если сервер перезагружает участника, он не будет автоматически повторно присоединиться к группе при запуске. Если вы хотите, чтобы участникы автоматически присоединялись к группе, вы должны внести изменения в файл конфигурации.
Настройте, если вы хотите, чтобы участники автоматически присоединиться при загрузке. Тем не менее, есть некоторые вещи, которые вы должны знать:
С учетом указанных выше предостережений, если вы хотите настроить узлы автоматически присоединять к группе при запуске MySQL, откройте основной файл конфигурации MySQL:
Внутри, найдите переменную loose-group_replication_start_on_boot, и установите ее в положение «ON»:
[mysqld] . . . loose-group_replication_start_on_boot = ON . . .
Сохраните и закройте файл, когда вы закончите. Участник должен автоматически пытаться присоединиться к группе в следующий раз при запуске его экземпляра в MySQL.
В этой статье мы рассмотрели, как настроить репликацию группы MySQL между тремя серверами на Ubuntu 16,04. Для отдельных первичных установок, участники автоматически избирают первичный для записи, когда это необходимо. Для многих первичных групп, любой участник может выполнять операции записи и обновления.
Репликация групп обеспечивает гибкую топологию репликации, которая позволяет участникам присоединиться или оставаться по желанию, одновременно обеспечивая гарантии в целостности данных и упорядочения сообщений. Репликация группы MySQL может быть немного сложнее в настройке, но она предоставляет возможности, недоступные в традиционной репликации.
(Пока оценок нет)
Загрузка...
Заполните форму и наш менеджер перезвонит Вам в самое ближайшее время!
Спасибо! Ваша заявка принята
Спасибо! Ваша заявка принята
