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

Ну вот, сидим мы тут, с этими базами данных, как будто жизнь от них зависит. А потом раз — и пиздец, сервер лег. И все эти ваши «инновационные решения» летят в тартарары. Так что слушай сюда, как мы эту хрень настраивали, чтобы потом не орать «ой, всё пропало!».

В последнем проекте, на PostgreSQL, мы запилили асинхронную потоковую репликацию (Streaming Replication). Зачем? Ну, чтобы если мастер, сука, накроется медным тазом, у нас был запасной вариант. И чтобы читающие запросы не ебали мозг одному серверу, а распределялись.

Архитектура, проще некуда:

• Один мастер-сервер. Он тут главный по тарелкам, только на него пишем.
• Две реплики (standby) в режиме hot_standby. Это значит, что на них можно в любой момент навесить SELECT-запрос, и они тебе всё покажут, не перезагружаясь. Удобно, блядь.

А теперь, как мы это всё собирали, пока кофе не остыл:

1. Ковыряем конфиг мастера (postgresql.conf):

   wal_level = replica          # Говорим: «Записывай всё, что происходит, мы это будем реплицировать!»
   max_wal_senders = 3          # Сколько реплик можем кормить одновременно. Три — с запасом.
   wal_keep_size = 1GB          # Чтобы если реплика отстала на минутку, WAL-файлы не успели сдохнуть.

   Без этого — нихуя не заработает, запомни.

2. Кто имеет право подключаться? (pg_hba.conf):

   host replication replica_user 192.168.1.0/24 md5

   Тут мы говорим: «Ребята с этой подсети, если вы — replica_user и знаете пароль, можете тащить себе наши логи». Без этой строчки реплики будут как слепые котята — тыкаться носом в закрытую дверь.

3. Создание самой реплики: Берём pg_basebackup, делаем слепок с мастера, а потом в конфиге реплики (recovery.conf или postgresql.auto.conf в новых версиях) пишем «слушай вот того дядю и повторяй за ним». Всё, реплика оживает и начинает догонять.

А как понять, что всё работает, а не просто так мигает? Запускаешь запрос и смотришь:

-- Проверка состояния репликации
SELECT client_addr, application_name, state, sync_state, replay_lag 
FROM pg_stat_replication;

Если тут строки есть и state = streaming — значит, реплики на связи, данные текут. Если пусто — ебать, пора волноваться.

И самое вкусное — оркестрация. Потому что руками переключать мастер-реплику при падении — это как играть в русскую рулетку с полным барабаном. Мы поставили Patroni, а в качестве хранилища конфигов — etcd. Эта связка превращает кучку серверов в самоуправляемый кластер, который сам решает, кто тут главный, а кто — на подхвате. Патрони, ёпта, следит за здоровьем нод и если мастер сдыхает — он поднимает одну из реплик на его место, пока все спят. Красота, а не жизнь. Теперь можно спать спокойнее. Ну, почти.