Какие есть виды репликаций?

Виды репликаций в системах хранения данных

Репликация — это процесс копирования данных с одного сервера (master) на другой или несколько (slaves/replicas). Это критично для обеспечения отказоустойчивости, масштабируемости и производительности.

1. Master-Slave (Master-Replica) репликация

Самый распространённый тип. Данные писаются только на master, а slaves получают копию для чтения.

Архитектура:

Master (write) -> Binary Log -> Slave1 (read-only)
                              -> Slave2 (read-only)
                              -> Slave3 (read-only)

Преимущества:

• Простая архитектура
• Хорошая масштабируемость для чтения
• Асинхронная репликация (быстро пишет)

Недостатки:

• Master — single point of failure
• Потеря данных при сбое master
• Задержка репликации (replication lag)

Пример конфигурации PostgreSQL:

# На сервере master в postgresql.conf:
# wal_level = replica
# max_wal_senders = 10
# hot_standby = on

# На сервере replica:
from psycopg2 import connect
conn = connect("dbname=mydb user=replica host=replica_host")
# Replica автоматически получает WAL (Write-Ahead Logs) от master

2. Master-Master (Multi-Master) репликация

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

Архитектура:

Master1 (read/write) <-> Replication <-> Master2 (read/write)
         |
         v
   Applications

Преимущества:

• Высокая доступность
• Нет single point of failure
• Можно писать на несколько серверов

Недостатки:

• Сложнее с конфликтами данных
• Требует разрешения конфликтов
• Задержки синхронизации

Пример с MySQL:

# Конфликты при одновременной записи одного поля
# Server 1: UPDATE users SET balance = 100 WHERE id = 1
# Server 2: UPDATE users SET balance = 200 WHERE id = 1
# Одно значение перезапишет другое -> потеря данных!

# Решение: UUID для первичных ключей
import uuid
user_id = uuid.uuid4()
# Каждый server генерирует уникальные ID

3. Synchronous (синхронная) репликация

Мaster ждёт подтверждения от slaves перед тем как подтвердить commit клиенту.

Характеристики:

• Гарантирует что данные достигли replicas
• Медленнее асинхронной
• Нет потери данных

Пример с PostgreSQL Streaming Replication:

# В postgresql.conf на master:
# synchronous_commit = on
# synchronous_standby_names = 'standby_1'

# Master ждёт ответа от standby перед commit
conn = psycopg2.connect("dbname=mydb")
cur = conn.cursor()
cur.execute("INSERT INTO users (name) VALUES (%s)", ("John",))
conn.commit()  # Блокирует пока standby не подтвердит

4. Asynchronous (асинхронная) репликация

Master не ждёт подтверждения от slaves. Данные копируются в фоне.

Характеристики:

• Быстро пишет
• Может быть задержка (lag)
• Возможна потеря данных при crash

Пример с Redis:

import redis

# Master Redis
master = redis.Redis(host='master', port=6379)
master.set('key', 'value')  # Немедленно возвращает управление

# Slave получит данные асинхронно позже
# Может быть задержка в миллисекундах или больше

5. Replication Log Types

Statement-based репликация

Репликируются SQL-команды (запросы).

# Master выполняет:
# UPDATE users SET last_login = NOW() WHERE id = 1

# Slave получает эту команду
# Но NOW() будет разным временем!
# Это может привести к расхождениям

Проблемы:

• Недетерминированные функции (NOW(), RAND())
• Порядок выполнения может отличаться

Row-based репликация

Репликируются изменения строк (BSON формат).

# Master: UPDATE users SET balance = 100 WHERE id = 1
# 
# Slave получает: "В таблице users изменилась строка с id=1: balance=100"
# Точное значение, без функций

Преимущества:

• Детерминировано
• Работает с любыми функциями
• Более точно

Mixed репликация

Комбинация statement и row-based.

6. Circular репликация

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

Master1 -> Master2 -> Master3 -> Master1

Используется редко из-за рисков циклических обновлений.

7. Peer-to-Peer репликация

Все узлы равноправны, данные синхронизируются между всеми.

Примеры:

• CouchDB — peer-to-peer синхронизация
• Riak — distributed key-value store

from couchdb import Server

server = Server('http://localhost:5984')
db1 = server['mydb1']
db2 = server['mydb2']

# Двусторонняя репликация
server.replicate('mydb1', 'mydb2', continuous=True)

8. Comparison Matrix

Практический пример: PostgreSQL со streaming replication

# master.conf
wal_level = replica
max_wal_senders = 10
wal_keep_segments = 64
synchronous_commit = on
synchronous_standby_names = 'standby_1'

# Приложение
import psycopg2
from psycopg2 import sql

conn = psycopg2.connect(
    host='master',
    database='mydb',
    user='postgres',
    password='password'
)

cur = conn.cursor()

# Синхронная репликация - ждёт standby
cur.execute('INSERT INTO users (name, email) VALUES (%s, %s)',
            ('John', 'john@example.com'))
conn.commit()  # Гарантировано на обоих серверах

# Чтение с replica для балансировки нагрузки
replica_conn = psycopg2.connect(
    host='replica',
    database='mydb',
    user='replica_user',
    password='password'
)

replica_cur = replica_conn.cursor()
replica_cur.execute('SELECT * FROM users')
rows = replica_cur.fetchall()

Failover и Recovery

Автоматический failover в PostgreSQL:

# Использовать pg_basebackup для инициализации replica
# Если master падает, promote standby:
# SELECT pg_promote();

# Или через Patroni (рекомендуется для production):
# Patroni автоматически управляет failover

Выводы

Выбор типа репликации зависит от:

• Master-Slave — простые приложения с Read-Heavy нагрузкой
• Master-Master — высокая доступность, но сложнее
• Synchronous — критичные данные, нет потерь
• Asynchronous — высокая производительность, допустима задержка

В production используют мониторинг, автоматический failover и multiple replicas для надёжности.