Как настроить репликацию в MySQL

Предыдущая версия этого руководства была написана Этель Свердлов.

Введение

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

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

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

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

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

Предпосылки

Для выполнения этого руководства вам потребуется:

Два сервера под управлением Ubuntu 20.04. Оба должны иметь администратора без полномочий root с привилегиями sudo и брандмауэр, настроенный с помощью UFW. Следуйте нашему руководству по первоначальной настройке сервера для Ubuntu 20.04, чтобы настроить оба сервера.
MySQL установлен на каждом сервере. В этом руководстве предполагается, что вы используете последнюю версию MySQL, доступную в репозиториях Ubuntu по умолчанию, которая на момент написания этой статьи имеет версию 8.0.25. Чтобы установить это на обоих серверах, следуйте нашему руководству «Как установить MySQL в Ubuntu 20.04».

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

Аналогично, любые команды, которые должны выполняться на сервере экземпляра реплики MySQL, будут иметь красный фон:

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

Понимание репликации в MySQL

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

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

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

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

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

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

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

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

Шаг 1 — Настройка брандмауэра исходного сервера

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

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

Эта конкретная команда разрешает любые соединения, которые исходят от IP-адреса сервера-реплики, представленного replica_server_ip, к номеру порта MySQL по умолчанию, 3306:

sudo ufw allow from replica_server_ip to any port 3306

Обязательно замените replica_server_ip фактическим IP-адресом вашего сервера-реплики. Если правило было успешно добавлено, вы увидите следующий вывод:

OutputRule added

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

Шаг 2 — Настройка исходной базы данных

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

В Ubuntu 20.04 файл конфигурации сервера MySQL по умолчанию называется mysqld.cnf и находится в каталоге /etc/mysql/mysql.conf.d/. Откройте этот файл на исходном сервере в предпочитаемом вами текстовом редакторе. Здесь мы будем использовать nano:

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

В файле найдите директиву bind-address. По умолчанию это будет выглядеть так:

. . .
bind-address            = 127.0.0.1
. . .

127.0.0.1 — это петлевой адрес IPv4, представляющий локальный хост, и установка его в качестве значения для директивы bind-address указывает MySQL прослушивать подключения только по адресу локального хоста. Другими словами, этот экземпляр MySQL сможет принимать соединения только с сервера, на котором он установлен.

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

Замените 127.0.0.1 IP-адресом исходного сервера. После этого директива bind-address будет выглядеть так, с IP-адресом вашего собственного сервера вместо source_server_ip:

. . .
bind-address            = source_server_ip
. . .

Затем найдите директиву server-id, которая определяет идентификатор, который MySQL использует внутри для различения серверов в настройке репликации. Каждый сервер в среде репликации, включая исходный и все его реплики, должен иметь собственное уникальное значение идентификатор_сервера. Эта директива по умолчанию будет закомментирована и будет выглядеть так:

. . .
# server-id             = 1
. . .

Раскомментируйте эту строку, удалив знак решетки (#). Вы можете выбрать любое число в качестве значения этой директивы, но помните, что число должно быть уникальным и не может совпадать ни с каким другим идентификатором_сервера в вашей группе репликации. Для простоты в следующем примере это значение оставлено по умолчанию, 1:

. . .
server-id               = 1
. . .

Под строкой идентификатор_сервера найдите директиву log_bin. Это определяет базовое имя и расположение двоичного файла журнала MySQL.

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

. . .
log_bin                       = /var/log/mysql/mysql-bin.log
. . .

Наконец, прокрутите файл вниз, чтобы найти закомментированную директиву binlog_do_db:

. . .
# binlog_do_db          = include_database_name

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

. . .
binlog_do_db          = db

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

. . .
binlog_do_db          = db
binlog_do_db          = db_1
binlog_do_db          = db_2

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

. . .
binlog_ignore_db          = db_to_ignore

После внесения этих изменений сохраните и закройте файл. Если вы использовали nano для редактирования файла, сделайте это, нажав CTRL + X, Y, а затем ENTER. .

Затем перезапустите службу MySQL, выполнив следующую команду:

sudo systemctl restart mysql

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

Шаг 3 — Создание пользователя репликации

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

Начните с открытия оболочки MySQL:

sudo mysql

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

mysql -u sammy -p

Замените sammy именем вашего выделенного пользователя и введите пароль этого пользователя при появлении запроса.

Имейте в виду, что некоторые операции в этом руководстве, в том числе те, которые должны выполняться на сервере-реплике, требуют расширенных прав. Из-за этого может быть удобнее подключиться в качестве пользователя с правами администратора, как это можно сделать с помощью предыдущей команды sudo mysql. Если вы хотите использовать менее привилегированного пользователя MySQL в этом руководстве, ему должны быть как минимум предоставлены права CREATE USER, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE и REPLICATION_SLAVE_ADMIN.

В командной строке создайте нового пользователя MySQL. В следующем примере будет создан пользователь с именем replica_user, но вы можете назвать его как хотите. Обязательно измените replica_server_ip на общедоступный IP-адрес вашего сервера-реплики и измените пароль на надежный пароль вашего выбор:

CREATE USER 'replica_user'@'replica_server_ip' IDENTIFIED WITH mysql_native_password BY 'password';

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

После создания нового пользователя предоставьте ему соответствующие привилегии. Как минимум, пользователь репликации MySQL должен иметь разрешения REPLICATION SLAVE:

GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'replica_server_ip';

После этого рекомендуется запустить команду FLUSH PRIVILEGES. Это освободит всю память, кэшированную сервером в результате выполнения предыдущих операторов CREATE USER и GRANT:

FLUSH PRIVILEGES;

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

Шаг 4 — Получение координат двоичного журнала из источника

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

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

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

FLUSH TABLES WITH READ LOCK;

Затем выполните следующую операцию, которая вернет текущую информацию о состоянии двоичных файлов журнала источника:

SHOW MASTER STATUS;

В выводе вы увидите таблицу, похожую на этот пример:

Output+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |      899 | db           |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

Это позиция, с которой реплика начнет копирование событий базы данных. Запишите имя File и значение Position, так как они понадобятся вам позже, когда вы начнете репликацию.

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

Если в вашем источнике нет данных для переноса

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

UNLOCK TABLES;

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

CREATE DATABASE db;

OutputQuery OK, 1 row affected (0.01 sec)

После этого закройте оболочку MySQL:

exit

После этого можно переходить к следующему шагу.

Если в вашем источнике есть данные для переноса

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

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

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

В новом окне или вкладке терминала откройте еще один сеанс SSH с сервером, на котором размещен исходный экземпляр MySQL:

ssh sammy@source_server_ip

Затем из новой вкладки или окна экспортируйте базу данных с помощью mysqldump. В следующем примере создается файл дампа с именем db.sql из базы данных с именем db, но убедитесь, что вместо этого вы указали имя своей собственной базы данных. Кроме того, обязательно запустите эту команду в оболочке bash, а не в оболочке MySQL:

sudo mysqldump -u root db > db.sql

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

UNLOCK TABLES;

Затем вы можете выйти из оболочки MySQL:

exit

Теперь вы можете отправить файл моментального снимка на сервер-реплику. Предполагая, что вы настроили ключи SSH на исходном сервере и добавили открытый ключ источника в файл authorized_keys вашей реплики, вы можете безопасно сделать это с помощью команды scp, например:

scp db.sql sammy@replica_server_ip:/tmp/

Обязательно замените sammy именем административного профиля пользователя Ubuntu, созданного на сервере-реплике, и замените replica_server_ip с IP-адресом сервера-реплики. Также обратите внимание, что эта команда помещает моментальный снимок в каталог /tmp/ сервера-реплики.

После отправки снапшота на сервер реплики подключитесь к нему по SSH:

ssh sammy@replica_server_ip

Затем откройте оболочку MySQL:

sudo mysql

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

CREATE DATABASE db;

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

exit

Затем импортируйте снимок базы данных:

sudo mysql db < /tmp/db.sql

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

Шаг 5 — Настройка базы данных реплики

Все, что осталось сделать, это изменить конфигурацию реплики аналогично тому, как вы изменили исходную. Откройте файл конфигурации MySQL, mysqld.cnf, на этот раз на вашем сервере-реплике:

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

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

server-id               = 2

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

. . .
log_bin                 = /var/log/mysql/mysql-bin.log
. . .
binlog_do_db            = db
. . .

Наконец, добавьте директиву relay-log, определяющую расположение файла журнала ретрансляции реплики. Включите следующую строку в конце файла конфигурации:

. . .
relay-log               = /var/log/mysql/mysql-relay-bin.log

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

sudo systemctl restart mysql

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

Шаг 6 — Запуск и тестирование репликации

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

sudo mysql

В командной строке выполните следующую операцию, которая одновременно настраивает несколько параметров репликации MySQL. После запуска этой команды, как только вы включите репликацию на этом экземпляре, он попытается подключиться к IP-адресу, следующему за SOURCE_HOST, используя имя пользователя и пароль, следующие за SOURCE_USER и SOURCE_PASSWORD соответственно. Он также будет искать двоичный файл журнала с именем, следующим за SOURCE_LOG_FILE, и начнет его чтение с позиции после SOURCE_LOG_POS.

Обязательно замените source_server_ip IP-адресом исходного сервера. Точно так же replica_user и пароль должны совпадать с пользователем репликации, созданным на шаге 2; а mysql-bin.000001 и 899 должны отражать координаты двоичного журнала, полученные на шаге 3.

Вы можете ввести эту команду в текстовом редакторе, прежде чем запускать ее на своем сервере-реплике, чтобы вам было проще заменить всю соответствующую информацию:

CHANGE REPLICATION SOURCE TO
SOURCE_HOST='source_server_ip',
SOURCE_USER='replica_user',
SOURCE_PASSWORD='password',
SOURCE_LOG_FILE='mysql-bin.000001',
SOURCE_LOG_POS=899;

После этого активируйте сервер-реплику:

START REPLICA;

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

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

SHOW REPLICA STATUS\G;

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

Output*************************** 1. row ***************************
             Replica_IO_State: Waiting for master to send event
                  Source_Host: 138.197.3.190
                  Source_User: replica_user
                  Source_Port: 3306
                Connect_Retry: 60
              Source_Log_File: mysql-bin.000001
          Read_Source_Log_Pos: 1273
               Relay_Log_File: mysql-relay-bin.000003
                Relay_Log_Pos: 729
        Relay_Source_Log_File: mysql-bin.000001
. . .

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

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

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

START REPLICA;

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

STOP REPLICA;

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

Начните с открытия оболочки MySQL на исходном компьютере:

sudo mysql

Выберите базу данных, которую вы выбрали для репликации:

USE db;

Затем создайте таблицу в этой базе данных. Следующая операция SQL создает таблицу с именем example_table с одним столбцом с именем example_column:

CREATE TABLE example_table (
example_column varchar(30)
);

OutputQuery OK, 0 rows affected (0.03 sec)

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

INSERT INTO example_table VALUES
('This is the first row'),
('This is the second row'),
('This is the third row');

OutputQuery OK, 3 rows affected (0.03 sec)
Records: 3  Duplicates: 0  Warnings: 0

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

USE db;

Затем запустите оператор SHOW TABLES, чтобы вывести список всех таблиц в выбранной базе данных:

SHOW TABLES;

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

Output+---------------+
| Tables_in_db  |
+---------------+
| example_table |
+---------------+
1 row in set (0.00 sec)

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

SELECT * FROM example_table;

В SQL звездочка (*) означает «все столбцы». Таким образом, этот запрос, по сути, говорит MySQL вернуть каждый столбец из example_table. Если репликация работает должным образом, эта операция вернет эти данные в своем выводе:

Output+------------------------+
| example_column         |
+------------------------+
| This is the first row  |
| This is the second row |
| This is the third row  |
+------------------------+
3 rows in set (0.00 sec)

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

Заключение

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

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