Что произойдет, если ведущий узел упадет в PostgreSQL?

PostgreSQL: Failover при падении ведущего узла

Это критически важная тема для high availability систем. За 10+ лет работал с разными сценариями failover'а.

Архитектура PostgreSQL Replication

Базовая настройка

┌──────────────────────────────────────┐
│  WRITE REQUESTS                      │
└───────────┬──────────────────────────┘
            │
            ▼
┌──────────────────────────────────────┐
│  PRIMARY (Master)                    │
│  - Принимает WRITE                   │
│  - Логирует WAL (Write-Ahead Logs)   │
│  - Отправляет WAL на replicas        │
│  - IP: 10.0.1.10                     │
└───────────┬──────────────────────────┘
            │ WAL Stream
            │
    ┌───────┴──────────┐
    ▼                  ▼
┌────────────┐   ┌────────────┐
│ STANDBY 1  │   │ STANDBY 2  │
│ - Восстанавливает из WAL
│ - Готов к failover
│ - IP: 10.0.1.11    │ IP: 10.0.1.12
└────────────┘   └────────────┘
   READ-ONLY      READ-ONLY

Что произойдет: пошаговый процесс

Этап 1: Primary падает (0 сек)

# Primary не отвечает
timestamp = "10:00:00.000"
status = {
    "primary_status": "CRASHED/UNREACHABLE",
    "active_connections": "LOST",
    "pending_writes": "WAITING (timeout)",
    "wal_files": "Последние не реплицированы"
}

impact = {
    "applications": "Cannot write (получают CONNECTION REFUSED)",
    "read_replicas": "Все ещё work (читают из своего кэша)",
    "data_loss_risk": "Возможна потеря последних N сек данных"
}

Этап 2: Detection (3-30 сек в зависимости от конфигурации)

# Как обнаруживается падение?

detection_methods = {
    "heartbeat_timeout": {
        "mechanism": "Health check не получает ответ",
        "timeout": "tcp_keepalives_idle = 30 сек (по умолчанию)",
        "example": "10:00:30 - Discovery что Primary dead"
    },
    "application_error": {
        "mechanism": "Приложение получает CONNECTION TIMEOUT",
        "timeout": "Зависит от конфигурации connection pool",
        "example": "Django прилага: connection timeout = 5 сек"
    },
    "external_monitoring": {
        "mechanism": "Prometheus, Zabbix, custom script",
        "timeout": "Настраивается (обычно 10 сек)",
        "example": "pg_monitoring.py проверяет каждые 5 сек"
    }
}

print("10:00:30 - Обнаружено: Primary недоступен")

Этап 3: Failover Decision (30-60 сек)

# Какой standby станет новым primary?

# Автоматический failover требует:
requirements_for_auto_failover = {
    "synchronous_commit": "on",
    "reason": "Гарантия что все synced replicas имеют данные",
    
    "primary_conninfo": "Известна конфигурация primary",
    
    "synchronous_standby_names": "Определено кто может стать primary",
    "example": "FIRST 1 (standby1, standby2)  # Первый из двух"
}

# Выбор кандидата
candidate_selection = {
    "standby1": {
        "status": "In sync with primary (до последнего сек)",
        "decision": "PROMOTE (выигрывает)",
        "reason": "Свежие данные, минимум потери"
    },
    "standby2": {
        "status": "Slightly behind (на 100ms)",
        "decision": "Остаётся standby",
        "reason": "Менее свежие данные"
    }
}

print("10:00:45 - Решение: Promote standby1")

Этап 4: Promotion (60-120 сек)

# Что происходит в момент promotion

promotion_steps = {
    "step_1_stop_recovery": {
        "action": "Standby перестаёт читать WAL",
        "command": "pg_ctl promote -D /var/lib/postgresql/data",
        "time": "1-2 сек"
    },
    "step_2_consistency_check": {
        "action": "Проверить что recovery закончена",
        "query": "SELECT pg_is_in_recovery();  -- False = promoted",
        "time": "1-2 сек"
    },
    "step_3_wal_cleanup": {
        "action": "Очистить старые WAL files",
        "time": "5-30 сек (зависит от размера data)"
    },
    "step_4_accept_writes": {
        "action": "Начать принимать WRITE queries",
        "time": "1 сек"
    },
    "total_time": "10-40 сек"
}

print("10:00:50 - Starting promotion of standby1")
print("10:01:20 - Promotion complete")
print("10:01:20 - Accepting writes on new primary")

Этап 5: Recovery на других standbys (120-300 сек)

# Что происходит со standby2 и другими?

recovery_process = {
    "standby2_status_before": {
        "role": "Streaming replication from primary",
        "problem": "Primary это уже не primary, а promoted standby1"
    },
    
    "what_happens": {
        "automatic": "Standby2 может автоматически перейти на standby1",
        "requires": "Правильная конфигурация pg_standby или patroni",
        "time": "30-120 сек"
    },
    
    "standby2_status_after": {
        "role": "Streaming replication from NEW primary (standby1)",
        "lag": "Может быть 10-100ms пока ловит"
    }
}

print("10:01:30 - Standby2 detected primary changed")
print("10:01:35 - Standby2 reconnected to standby1 (new primary)")
print("10:02:00 - Standby2 fully in sync")

Сценарии: что теряется?

Сценарий A: Synchronous Replication (Safe)

# Конфигурация PRIMARY
config_safe = {
    "synchronous_commit": "on",
    "what_means": "Primary не коммитит WRITE пока standby не подтвердит",
    
    "failure_scenario": {
        "timestamp_1": "10:00:00 - Write X committed (synced to standby)",
        "timestamp_2": "10:00:30 - Primary crashes",
        "timestamp_3": "10:01:00 - Standby promoted",
        
        "data_loss": "NONE - Standby имеет всё (был in sync)",
        "trade_off": "Более медленная WRITE (wait for replication)"
    }
}

print("Configuration: Synchronous")
print("Data loss: ZERO")
print("Write latency: 2-5ms extra (replication RTT)")

Сценарий B: Asynchronous Replication (Fast but Risky)

# Конфигурация PRIMARY
config_fast = {
    "synchronous_commit": "off",  # default
    "what_means": "Primary коммитит сразу, потом отправляет на standby",
    
    "failure_scenario": {
        "timestamp_1": "10:00:00 - Write X committed on primary",
        "timestamp_2": "10:00:00 - WAL отправляется на standby (async)",
        "timestamp_3": "10:00:00.5 - Primary crashes",
        "timestamp_4": "10:00:0.3 - WAL НЕ достиг standby",
        
        "data_loss": "Write X теряется (был на primary, не на standby)",
        "quantity": "~500ms-2сек последних writes",
        "trade_off": "Очень быстрые WRITE (не ждём replication)"
    }
}

print("Configuration: Asynchronous")
print("Data loss: POSSIBLE (last N seconds)")
print("Write latency: MINIMAL (immediate commit)")

Код: мониторинг реплики

import psycopg2
from datetime import datetime

def check_replication_lag():
    """Проверить отставание replication"""
    conn = psycopg2.connect(
        "host=primary.db.local user=postgres dbname=myapp"
    )
    cur = conn.cursor()
    
    # На primary
    cur.execute("""
        SELECT 
            client_addr,
            state,
            replay_lag,
            write_lag,
            flush_lag
        FROM pg_stat_replication
    """)
    
    for row in cur.fetchall():
        client_addr, state, replay_lag, write_lag, flush_lag = row
        print(f"Replica {client_addr}:")
        print(f"  State: {state}")
        print(f"  Replay lag: {replay_lag}")
        print(f"  Write lag: {write_lag}")
        print(f"  Flush lag: {flush_lag}")
        
        # Alert если lag > 1 сек
        if replay_lag and replay_lag.total_seconds() > 1:
            print(f"  WARNING: High lag!")
    
    conn.close()

# На standby
def check_standby_status():
    """Проверить статус standby"""
    conn = psycopg2.connect(
        "host=standby.db.local user=postgres dbname=myapp"
    )
    cur = conn.cursor()
    
    # Проверить что мы в recovery mode
    cur.execute("SELECT pg_is_in_recovery()")
    is_standby = cur.fetchone()[0]
    
    if is_standby:
        print("✓ In standby mode (safe to read)")
    else:
        print("✗ ERROR: Not in recovery (primary?)")
    
    # Проверить последний восстановленный LSN
    cur.execute("""
        SELECT 
            pg_last_wal_receive_lsn() as receive_lsn,
            pg_last_wal_replay_lsn() as replay_lsn
    """)
    
    receive_lsn, replay_lsn = cur.fetchone()
    print(f"Receive LSN: {receive_lsn}")
    print(f"Replay LSN: {replay_lsn}")
    
    conn.close()

check_replication_lag()
check_standby_status()

Решения для автоматического failover

1. Patroni (рекомендуется)

# /etc/patroni/patroni.yml
scope: postgres-cluster
namespace: /patroni
name: postgres-01

restapi:
  listen: 0.0.0.0:8008
  connect_address: primary.db.local:8008

ctl:
  insecure: false

etcd:
  host: etcd.local:2379

postgresql:
  data_dir: /var/lib/postgresql/data
  pgpass: /var/lib/postgresql/.pgpass
  parameters:
    shared_buffers: 256MB
    max_wal_senders: 10
    max_replication_slots: 10
    wal_keep_size: 1GB
    max_parallel_workers_per_gather: 2

bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    maximum_lag_on_failover: 1048576
    postgresql:
      use_pg_rewind: true
      use_slots: true
      parameters:
        synchronous_commit: "on"
        synchronous_standby_names: "*"

2. pg_basebackup + monitoring script

#!/bin/bash
# failover.sh

PRIMARY_IP="10.0.1.10"
STANDBY_IP="10.0.1.11"
VIP="10.0.1.100"  # Virtual IP

# 1. Проверить primary
if ! ping -c 1 $PRIMARY_IP > /dev/null; then
    echo "[$(date)] PRIMARY DEAD - starting failover"
    
    # 2. Promote standby
    ssh postgres@$STANDBY_IP "/usr/lib/postgresql/promote.sh"
    
    # 3. Переместить VIP на новый primary
    arping -U -I eth0 -c 5 $VIP
    
    echo "[$(date)] FAILOVER COMPLETE - standby is now primary"
fi

Как приложение это переживает

Драйвер: psycopg2 (python)

from psycopg2 import pool
import psycopg2

# Connection pool с автоматическим reconnect
connection_pool = pool.SimpleConnectionPool(
    1, 20,
    host="postgres.db.local",  # DNS round-robin
    user="app",
    password="secret",
    dbname="myapp",
    # Автоматический reconnect
    keepalives=1,
    keepalives_idle=30,
    keepalives_interval=10,
    keepalives_count=5
)

def safe_query(query, params=None):
    """Query с автоматическим retry при failover"""
    max_retries = 3
    for attempt in range(max_retries):
        try:
            conn = connection_pool.getconn()
            cur = conn.cursor()
            cur.execute(query, params)
            result = cur.fetchall()
            conn.commit()
            return result
        except psycopg2.OperationalError as e:
            # Failover happening - retry
            print(f"Attempt {attempt+1}: {e}")
            if attempt < max_retries - 1:
                time.sleep(2 ** attempt)  # Exponential backoff
            else:
                raise
        finally:
            conn.close()

try:
    result = safe_query("SELECT * FROM users")
except Exception as e:
    print(f"Failed after {max_retries} retries: {e}")

Чеклист: что произойдет

failover_checklist = {
    "↓ Primary crashes": "Immediate - connection refused",
    "↓ Detection": "3-30 сек (зависит от monitoring)",
    "↓ Failover decision": "5-30 сек (выбираем кандидата)",
    "↓ Promotion": "10-40 сек (standby становится primary)",
    "↓ Application reconnect": "1-5 сек (retry logic)",
    "↓ Service restored": "Total: 20-100 сек (1-2 мин)",
    
    "Data loss": "0 сек (sync) или до 2 сек (async)",
    "Read availability": "Read replicas work immediately",
    "Write availability": "Restored after promotion + app reconnect"
}

Итог

При падении primary в PostgreSQL:

1. Сразу: Приложение получает ошибку при WRITE
2. За 10-30 сек: Обнаруживается падение
3. За 10-40 сек: Standby promoted
4. За 1-5 сек: Приложение переподключается
5. Всего: 20-100 сек downtime

Минимизировать:

• Synchronous replication → Zero data loss
• Patroni or similar → Automatic failover
• Connection pooling + retry logic → Fast app recovery
• Monitoring + alerting → Know immediately