При масштабуванні веб-додатків із високою інтенсивністю записів (
$$High-Load$$
) стандартна вертикальна архітектура баз даних швидко впирається в ліміти дискової підсистеми (
$$I/O Operations Per Second$$
) та пропускну здатність шини пам’яті. Для забезпечення аптайму рівня
$$99.99\%$$
виникає необхідність розгортання розподіленої топології баз даних із чітким розділенням потоків читання/запису.
1. Конфігурація пулу з’єднань через PgBouncer
Прямі підключення до СКБД PostgreSQL створюють окремий процес backend для кожної сесії, що приводить к надмірній утилізації операційної пам’яті (
$$RSS$$
). Для мінімізації накладних витрат на рівні ядра Linux впроваджується проксі-шар PgBouncer у режимі Transaction Pooling.
Ini, TOML
[databases]
production_db = host=10.0.0.10 port=5432 dbname=core pool_size=50
[pgbouncer]
listen_port = 6432
auth_type = scram-sha-256
pool_mode = transaction
max_client_conn = 10000
default_pool_size = 20
Ця конфігурація дозволяє утримувати до 10 000 клієнтських сокетів, утилізуючи всього 50 реальних потоків до бінарного дерева PostgreSQL.
2. Асинхронна vs Синхронна реплікація та ліміти CAP-теореми
Згідно з CAP-теоремою, в умовах мережевого розщеплення (
$$Network Partition$$
) розподілена система може забезпечити лише дві з трьох властивостей: узгодженість (
$$Consistency$$
), доступність (
$$Availability$$
) або стійкість до розпаду (
$$Partition Tolerance$$
).
- Асинхронна реплікація (Streaming Replication): Майстер-нода записує дані в лог передзапису ($$WAL – Write-Ahead Log$$) і миттєво повертає клієнту статус
COMMIT. Репліки вичитують WAL-потоки асинхронно. Пропускна здатність максимальна, але є ризик втрати даних при аварійному вимкненні майстра ($$Failover$$). - Синхронна реплікація: Транзакція вважається завершеною лише тоді, коли WAL-фрейм підтверджено щонайменше однією реплікою:$$\text{synchronous\_commit} = \text{on}$$Це гарантує абсолютну консистентність, але збільшує затримку ($$Latency$$) на величину мережевого пингу ($$RTT$$) між нодами кластера.
3. Автоматичний Failover за допомогою Patroni та Consul
Для реалізації автоматичного перемикання ролей без участі чергового інженера використовується керуючий демон Patroni, який використовує розподілене сховище конфігурацій (DCS) Consul або Etcd на базі алгоритму консенсусу Raft.
Кожні
$$X$$
секунд Patroni на майстер-ноді оновлює TTL-ключ у Consul:
$$\Delta t_{\text{heartbeat}} < \text{TTL}$$
Якщо майстер перестає відповідати через апаратний збій, лідерська сесія в Consul експірується. Решта нод кластера ініціюють голосування. Нода з найбільш актуальною позицією логу (
$$LSN – Log Sequence Number$$
) обирається новим майстром, а PgBouncer автоматично перенаправляє трафік запису (Read-Write) на новий IP-інтерфейс.
