Центр Диагностики & База Системных Ошибок

Решения для Windows Server, Active Directory, 1С, СУБД, Linux, Cisco, MikroTik и IP-телефонии.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, баз данных и сетевого оборудования. Перед выполнением действий обязательно создайте резервную копию. При отсутствии необходимой квалификации обратитесь к ИТ-специалистам.
MYSQL_GTID_REPL_SETUP Linux / DevOps

Настройка классической репликации MySQL Master-Slave на основе GTID

Обновлено: 21.08.2026
  • Необходимость горизонтального масштабирования операций чтения (Read Replicas).
  • Сложности с переключением реплик и поиском позиций бинарных логов (binlog file/pos) при сбоях.
  • Риск рассинхронизации данных при традиционной репликации по именам файлов.

1. Настройка Master (Источник / Source)

Отредактируйте /etc/mysql/mysql.conf.d/mysqld.cnf:

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON
log_replica_updates = ON

Перезапустите Master и создайте пользователя репликации:

CREATE USER 'repl_user'@'%' IDENTIFIED WITH caching_sha2_password BY 'SecureReplPassword_2024';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
FLUSH PRIVILEGES;

2. Настройка Slave (Реплика / Replica)

Конфигурация реплики mysqld.cnf:

[mysqld]
server-id = 2
relay_log = /var/log/mysql/mysql-relay-bin.log
gtid_mode = ON
enforce_gtid_consistency = ON
log_replica_updates = ON
read_only = ON
super_read_only = ON

3. Создание исходного дампа базы с фиксацией GTID

# Создание консистентного дампа на Master
mysqldump -u root -p --all-databases --single-transaction --triggers --routines --set-gtid-purged=ON > /tmp/master_dump.sql

# Восстановление дампа на Slave
mysql -u root -p < /tmp/master_dump.sql

4. Запуск GTID-репликации на стороне Slave

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='192.168.1.100',
  SOURCE_PORT=3306,
  SOURCE_USER='repl_user',
  SOURCE_PASSWORD='SecureReplPassword_2024',
  SOURCE_AUTO_POSITION=1,
  SOURCE_SSL=1;

START REPLICA;

-- Проверка статуса репликации
SHOW REPLICA STATUS\G
Практический опыт инженера: Всегда включайте 'super_read_only = ON' на Slave-нодах. Обычный 'read_only' защищает только от непривилегированных пользователей, оставляя возможность для root случайно модифицировать данные и сломать консистентность.

Частые вопросы (FAQ)

В чем главное преимущество GTID над репликацией по File/Position?

С GTID (SOURCE_AUTO_POSITION=1) не требуется вручную искать имя бинарного лога и точное смещение байт. Реплика автоматически запрашивает у мастера все транзакции, отсутствующие в ее наборе gtid_executed.

Зачем включать опцию enforce_gtid_consistency = ON?

Она запрещает выполнение небезопасных с точки зрения GTID конструкций (например, CREATE TABLE ... SELECT или временные таблицы внутри транзакций), которые могут сломать репликацию.