Кейс: PostgreSQL (репликация и базовые запросы)

Связь с легендой: ../../legend/LEGEND.md — раздел «Домашняя лаборатория / pet-проект». SQL как язык запросов уже вписан в легенду как сквозной инструмент (работа с данными сопровождаемых сервисов в АО ТНИИС), но отдельного опыта администрирования/репликации самой СУБД в рабочей практике не было — это тоже честный pet-кейс поверх рабочего опыта с запросами.

Что нужно реально сделать (домашний стенд)

Поднять master + одну streaming-реплику PostgreSQL в Docker Compose, попробовать синхронный и асинхронный режим репликации, прогнать pgbench для базовых цифр производительности и потренировать SQL-запросы на простой учебной схеме.

1. docker-compose.yml — master + replica

version: "3.8"

services:
  pg-master:
    image: postgres:16
    container_name: pg-master
    environment:
      POSTGRES_PASSWORD: labpass
      POSTGRES_USER: labuser
      POSTGRES_DB: labdb
    command: >
      postgres
      -c wal_level=replica
      -c max_wal_senders=5
      -c max_replication_slots=5
      -c synchronous_commit=on
      -c synchronous_standby_names='FIRST 1 (replica1)'
    volumes:
      - ./master-init.sql:/docker-entrypoint-initdb.d/init.sql
    ports:
      - "5432:5432"

  pg-replica:
    image: postgres:16
    container_name: pg-replica
    environment:
      POSTGRES_PASSWORD: labpass
      PGUSER: labuser
    depends_on:
      - pg-master
    ports:
      - "5433:5432"
    entrypoint: >
      bash -c "
      until pg_basebackup -h pg-master -D /var/lib/postgresql/data -U labuser -Fp -Xs -P -R --slot=replica1 --create-slot;
      do echo waiting for master; sleep 2; done;
      echo \"primary_conninfo = 'host=pg-master port=5432 user=labuser application_name=replica1'\" >> /var/lib/postgresql/data/postgresql.auto.conf;
      exec postgres"

2. master-init.sql — учебная схема

CREATE TABLE customers (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL
);

CREATE TABLE orders (
    id SERIAL PRIMARY KEY,
    customer_id INT REFERENCES customers(id),
    amount NUMERIC(10,2),
    status TEXT
);

INSERT INTO customers (name) VALUES ('Иванов'), ('Петров'), ('Сидоров');
INSERT INTO orders (customer_id, amount, status)
VALUES (1, 1500.00, 'paid'), (1, 300.00, 'pending'), (2, 4200.00, 'paid');

3. Шаги воспроизведения

docker compose up -d — поднять master, дождаться, пока replica пройдёт pg_basebackup и подключится (docker compose logs -f pg-replica).
Проверить репликацию: psql -h localhost -p 5432 -U labuser labdb -c "INSERT INTO customers (name) VALUES ('Новый клиент')", затем psql -h localhost -p 5433 -U labuser labdb -c "SELECT * FROM customers" — строка должна появиться на реплике.
Проверить статус на master: SELECT * FROM pg_stat_replication; — увидеть replica1, state = streaming, sync_state = sync (при заданном synchronous_standby_names).
Переключить на асинхронный режим: убрать synchronous_standby_names из command, перезапустить master, повторить pg_stat_replication — sync_state сменится на async. Разница на практике: при sync транзакция на master не считается закоммиченной, пока реплика не подтвердила запись (гарантия нуля потерянных данных при падении master ценой задержки commit); при async master коммитит сразу, не дожидаясь реплики (быстрее, но при падении master возможна потеря последних транзакций).
Погонять pgbench для базовых цифр: pgbench -h localhost -p 5432 -U labuser -i labdb (инициализация), pgbench -h localhost -p 5432 -U labuser -c 10 -j 2 -T 30 labdb (10 клиентов, 30 секунд) — записать TPS в ../../legend/CAPACITY.md.
Потренировать запросы на схеме customers/orders: JOIN, агрегации, WHERE id = N — см. QUESTIONS.md.

Что это даёт в разговоре с интервьюером

Практическое понимание разницы sync/async репликации не как определения, а как наблюдаемого поведения (pg_stat_replication, разная задержка commit).
Понимание streaming-репликации через WAL и pg_basebackup — как реплика вообще получает данные.
Базовые цифры TPS со своей лабы — честная отправная точка для разговора про производительность (см. ../../legend/CAPACITY.md).
Уверенное владение основными типами JOIN и агрегатными запросами на конкретной схеме.

Как это ложится в легенду

PostgreSQL как СУБД — pet-кейс, не приписанный к опыту в компаниях. SQL как язык запросов к данным сопровождаемых сервисов остаётся в легенде как рабочий навык (см. ../../legend/LEGEND.md); этот кейс добавляет к нему более глубокое, честно обозначенное pet-понимание того, как устроена сама СУБД под капотом.

6.2 KiB Raw Blame History Unescape Escape