Какую роль выполняет Master-сервер (или Primary) в репликации баз данных?

Ответ

В репликации баз данных Master (также известный как Primary или ведущий) — это главный узел, который является единственным источником истины для всех операций записи (INSERT, UPDATE, DELETE).

Основной принцип работы:

Master-сервер принимает все запросы на изменение данных.
Он записывает эти изменения в специальный лог транзакций (например, binlog в MySQL).
Подчинённые серверы (Replicas или Slaves) подключаются к мастеру, считывают этот лог и последовательно применяют изменения к своей копии данных.

Репликация может быть:

Асинхронной (по умолчанию): Мастер не ждёт подтверждения от реплик. Это обеспечивает высокую производительность, но создаёт риск потери данных при сбое мастера и задержку репликации (replication lag).
Синхронной: Мастер ждёт подтверждения от одной или нескольких реплик перед тем, как ответить клиенту. Это гарантирует консистентность, но снижает производительность.

Пример настройки репликации в MySQL:

-- На Master-сервере
CREATE USER 'replica_user'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'%';
FLUSH PRIVILEGES;
SHOW MASTER STATUS; -- Запомнить File и Position

-- На Replica-сервере
CHANGE MASTER TO
  MASTER_HOST='master_ip_address',
  MASTER_USER='replica_user',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.000001', -- Имя файла из SHOW MASTER STATUS
  MASTER_LOG_POS=154;               -- Позиция из SHOW MASTER STATUS

START SLAVE;

Ключевые проблемы и их решения:

Единая точка отказа (SPOF): Если мастер выходит из строя, запись в БД останавливается. Решается с помощью автоматического переключения на реплику (failover) или использования кластерных решений (например, Galera Cluster, Percona XtraDB Cluster).
Задержка репликации: Чтение данных с реплики может вернуть устаревшие данные. Это нужно учитывать при проектировании архитектуры приложения.