Какой у вас опыт настройки репликации баз данных?

«Какой у вас опыт настройки репликации баз данных?» — вопрос из категории Базы данных, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Мой опыт в DevOps включает настройку и поддержку репликации для обеспечения отказоустойчивости и распределения нагрузки. Работал преимущественно с PostgreSQL и MySQL в production-средах.

PostgreSQL (Streaming Replication & Logical Replication):

  • Настраивал physical streaming replication на основе WAL (Write-Ahead Logging) для создания hot/warm standby реплик.
  • Конфигурация primary-сервера (postgresql.conf, pg_hba.conf):
    wal_level = replica
    max_wal_senders = 5
    wal_keep_size = 1GB
  • Настройка standby-сервера (standby.signal или recovery.conf в старых версиях):
    primary_conninfo = 'host=primary-db-host user=replicator password=... application_name=replica1'
  • Использовал Patroni для управления кластером и автоматического failover.
  • Настраивал логическую репликацию для выборочного копирования таблиц между разными мажорными версиями.

MySQL (GTID-based Replication):

  • Настраивал асинхронную репликацию master-slave с использованием GTID (Global Transaction Identifier) для упрощения позиционирования и failover.
  • Конфигурация master:
    [mysqld]
    server-id=1
    log-bin=mysql-bin
    gtid-mode=ON
    enforce-gtid-consistency=ON
  • Настройка slave:
    CHANGE MASTER TO
      MASTER_HOST='master-host',
      MASTER_USER='repl',
      MASTER_PASSWORD='...',
      MASTER_AUTO_POSITION=1;
    START SLAVE;

Общие практики:

  • Мониторинг: отслеживание лага репликации (pg_stat_replication, SHOW SLAVE STATUS), использование Prometheus exporters.
  • Бэкапы: организация бэкапов со standby-реплик для снижения нагрузки на primary.
  • Тестирование отработки отказа: регулярные drills по ручному и автоматическому переключению (switchover/failover).