Почему можно писать только в Master реплику?

Основные причины ограничения на запись только в Master реплику

В классической архитектуре Master-Slave репликации (также называемой источник-реплика) в системах управления базами данных, включая PostgreSQL, MySQL и другие, запись разрешена только на мастер-узле по нескольким фундаментальным причинам, связанным с консистентностью данных, производительностью и архитектурой распределенных систем.

1. Гарантия консистентности и линейного порядка операций

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

-- Пример: если две реплики независимо принимают запись
-- Реплика 1: INSERT INTO users (id, name) VALUES (1, 'Alice');
-- Реплика 2: INSERT INTO users (id, name) VALUES (1, 'Bob');
-- Возникает конфликт по первичному ключу id=1 при синхронизации

Механизм репликации обычно работает так:

1. Все операции записи (INSERT, UPDATE, DELETE) выполняются на мастере.
2. Мастер записывает изменения в бинарный лог (WAL, binlog).
3. Реплики асинхронно или синхронно получают и применяют эти изменения в том же порядке.

2. Избежание конфликтов при распределенных транзакциях

Разрешение записи в несколько узлов приводит к распределенным транзакциям, требующим сложных протоколов координации (например, 2PC — Two-Phase Commit), что значительно снижает производительность и увеличивает задержки.

// Псевдокод, иллюстрирующий сложность распределенной записи
func distributedWrite(data Data, replicas []Replica) error {
    // Фаза 1: Подготовка всех реплик
    for _, r := range replicas {
        if err := r.prepare(data); err != nil {
            return err
        }
    }
    // Фаза 2: Фиксация на всех репликах
    for _, r := range replicas {
        if err := r.commit(data); err != nil {
            // Теперь нужен механизм отката!
        }
    }
    return nil
}

3. Производительность и простота архитектуры

• Мастер оптимизирован для записи (индексы, кэши).
• Реплики оптимизированы для чтения, могут иметь свои индексы для специфичных запросов без нагрузки на мастер.
• Асинхронная репликация позволяет масштабировать чтение горизонтально, добавляя реплики без ущерба для производительности записи.

4. Механизмы обеспечения отказоустойчивости

При отказе мастера одна из реплик повышается до мастера через процесс failover. До этого момента реплики остаются доступны только для чтения, что предотвращает разделение данных (split-brain).

// Пример логики выбора нового мастера
func promoteNewMaster(replicas []Replica) *Replica {
    // Выбираем реплику с наибольшим LSN (позицией в логе)
    var newMaster *Replica
    for i := range replicas {
        if replicas[i].lsn > newMaster.lsn {
            newMaster = &replicas[i]
        }
    }
    newMaster.setWritable(true)
    return newMaster
}

5. Специфика реализации репликации

Большинство СУБД используют физическую репликацию на уровне бинарного лога. Реплика буквально повторяет байты с мастера, что технически не позволяет локальные изменения на реплике без остановки репликации.

Современные альтернативы и расширения

Стоит отметить, что в современных системах это ограничение смягчается:

1. Multi-Master репликация (Galera Cluster для MySQL, BDR для PostgreSQL) — позволяет запись в несколько узлов, но требует разрешения конфликтов и имеет overhead.
2. Шардирование (сегментирование) — данные распределяются по разным мастерам на основе ключа шардирования.
3. Citus, Vitess, CockroachDB — распределенные СУБД, которые абстрагируют сложность распределенных записей.

Вывод

Ограничение записи только в мастер — это архитектурный компромисс, обеспечивающий простоту, консистентность и производительность в подавляющем большинстве сценариев OLTP-нагрузок. Для распределенных записей требуются более сложные системы, которые жертвуют либо производительностью (за счет координации), либо консистентностью (в пользу eventual consistency). Выбор подхода зависит от конкретных требований приложения к согласованности, доступности и устойчивости к разделению сети (CAP-теорема).