Какие знаешь способы обеспечения отказоустойчивости в БД?

Способы обеспечения отказоустойчивости БД

Отказоустойчивость — это способность системы продолжать работать при отказе одного или нескольких компонентов.

1. Репликация данных

Основной способ. Данные копируются на несколько серверов.

Синхронная репликация:

• Primary записывает данные
• Ждёт подтверждения от всех replicas
• Только потом отвечает клиенту
• Гарантирует никакие данные не потеряны
• Но медленнее

Асинхронная репликация:

• Primary записывает и сразу отвечает
• Данные отправляются replicas в фоне
• Быстрее, но может быть временная несогласованность
• Если primary упадёт до синхронизации — потеря данных

# PostgreSQL конфигурация
ALTER SYSTEM SET synchronous_commit = "remote_apply";
ALTER SYSTEM SET synchronous_standby_names = "standby1,standby2";

2. Failover (автоматическое переключение)

При отказе primary → автоматически переходим на replica.

Процесс:

1. Failover manager мониторит здоровье primary
2. Если primary не отвечает 30 секунд
3. Выбираем лучшую replica
4. Делаем её новым primary
5. Обновляем конфигурацию подключений

Инструменты:

• Patroni + etcd
• PgBouncer
• Kubernetes StatefulSet

3. Резервные копии (Backups)

Страховка от потери данных при серьёзных сбоях.

Полные копии:

pg_dump database > backup.sql

Дифференциальные копии:

• Копируются только изменения с момента последней копии
• Меньше места и времени
• Позволяет восстановить БД на любой момент (PITR)

archive_mode = on
archive_command = "cp %p /backup/wal/%f"

Правило 3-2-1:

• 3 копии данных
• На 2 разных носителях (HDD + облако)
• 1 копия в отдалённом месте (другой дата-центр)

4. Шардирование

Данные распределяются по нескольким БД.

def get_shard_number(user_id: int, num_shards: int) -> int:
    return user_id % num_shards

shard_id = get_shard_number(123, 4)  # shard 3
db = databases[f"shard_{shard_id}"]

Плюсы:

• Горизонтальная масштабируемость
• Если упадёт один shard — только часть данных потеряется

Минусы:

• Сложнее разработка
• Дорогие cross-shard запросы

5. Master-Slave кластеры

[Master] ← Все WRITE операции
  ↓
[Slave 1] ← READ
[Slave 2] ← READ

• Все изменения идут на Master
• Master отправляет репликацию на Slaves
• Reads балансируются между несколькими Slaves
• При отказе Master → promote одного Slave

6. Multi-Master кластеры

[Master 1] ←→ [Master 2]

• Оба master могут принимать writes
• Синхронизируют друг друга
• При отказе одного — система продолжает работу
• Но сложнее: нужна разрешение конфликтов

7. Load Balancing

Распределяем нагрузку между несколькими узлами.

import random

write_db = primary_connection
read_dbs = [replica1, replica2, replica3]
read_db = random.choice(read_dbs)

# Использование
session.execute(read_query, bind=read_db)
session.execute(write_query, bind=write_db)

8. Мониторинг и Health Checks

Отказоустойчивость бесполезна без мониторинга.

def check_db_health():
    try:
        conn = psycopg2.connect("postgresql://...")
        cursor = conn.cursor()
        cursor.execute("SELECT 1")
        cursor.close()
        conn.close()
        return True
    except Exception as e:
        return False

if not check_db_health():
    trigger_failover()

Что мониторить:

• Доступность primary и replicas
• Lag репликации
• Использование диска
• Количество подключений
• Slow queries
• CPU и Memory

Проверка репликации в PostgreSQL

-- На Master
SELECT client_addr, state, sync_state 
FROM pg_stat_replication;

-- На Slave
SELECT pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();

Практическая стратегия для production

1. Асинхронная репликация на несколько replicas (быстро)
2. Автоматический failover через Patroni + etcd
3. Daily incremental backups с 3-2-1 правилом
4. Мониторинг всех узлов с alerting
5. Load balancing reads на replicas
6. Регулярное тестирование восстановления из backup

Этот стек обеспечит высокую доступность и надёжность БД.