Кластер баз данных — группа серверов СУБД, работающих совместно для обеспечения отказоустойчивости и/или масштабирования. При падении одного узла другие принимают нагрузку. Чтение распределяется между репликами. Кластеризация применяется, когда одиночный сервер не справляется с нагрузкой или когда недопустим простой при отказе оборудования.
Основные топологии кластеров
- Master-Slave / Primary-Replica: запись только на master, чтение со slave. Репликация асинхронная (задержка 0–100 мс) или полусинхронная. При падении master — ручной или автоматический failover. Используют: MySQL Replication, PostgreSQL Streaming Replication.
- Multi-Primary (Galera Cluster): запись принимают несколько узлов одновременно. Galera для MySQL/MariaDB — синхронная репликация через wsrep API; RPO = 0. Минимум 3 узла (кворум).
- Patroni: фреймворк высокой доступности для PostgreSQL на базе etcd/Consul/ZooKeeper. Автоматический failover за ~30 секунд, leader election через Raft. Используется в Zalando, GitLab, Avito.
- Шардирование: горизонтальное разделение данных по ключу между несколькими серверами. PostgreSQL Citus, MongoDB Sharding, MySQL partitioning.
История
Oracle RAC (Real Application Clusters) — первый широко известный коммерческий кластер СУБД, представлен в 2001 году. MySQL Replication появилась в MySQL 3.23 (2000). Galera Cluster для MySQL разработан финской компанией Codership, первый стабильный релиз — 2007 год. Patroni создан командой Zalando в 2015 году и опубликован под MIT-лицензией. PostgreSQL Citus (горизонтальное шардирование) приобретён Microsoft в 2019 году и включён в Azure Database for PostgreSQL.
Метрики надёжности
RTO (Recovery Time Objective) — максимально допустимое время восстановления. RPO (Recovery Point Objective) — максимально допустимая потеря данных. Galera Cluster: RPO = 0 (синхронная репликация), RTO < 1 мин. Patroni со synchronous_standby: RPO = 0, RTO ~ 30 с. Асинхронный master-slave: RPO = секунды (данные записанные, но не реплицированные могут потеряться при краше master).
Инструменты для управления кластером БД
ProxySQL — умный прокси для MySQL-кластеров: автоматически направляет write-запросы на master, read — на реплики; перехватывает failover прозрачно для приложения. PgBouncer — connection pooler для PostgreSQL: снижает нагрузку при большом числе соединений.
На что обращать внимание
На виртуальном хостинге кластер БД недоступен. На VPS от 3 узлов — настраивается вручную (Galera, Patroni) или через managed-решения. AWS RDS Multi-AZ, Yandex Managed PostgreSQL, Selectel Managed Databases предоставляют кластер как управляемую службу. Перед созданием кластера оцени: нужна ли HA (High Availability) или масштабирование нагрузки — это разные архитектуры с разными компромиссами.
Репликация vs шардирование vs кластеризация
- Репликация
- Копирование данных на несколько серверов. Цель — отказоустойчивость и масштабирование чтения. Запись — только на один (primary).
- Шардирование
- Горизонтальное разделение данных по ключу между серверами. Каждый шард хранит часть данных. Цель — масштабирование записи и ёмкости. Сложнее в управлении.
- Кластер с shared storage
- Все узлы обращаются к общему хранилищу (SAN, NFS). Oracle RAC, Microsoft SQL Always On с SMB. Устраняет необходимость репликации данных, но создаёт зависимость от хранилища.
Инструменты управления кластером
Galera Cluster для MySQL/MariaDB: синхронная multi-primary репликация, минимальный кворум — 3 узла. Patroni + etcd для PostgreSQL: автоматический failover через leader election. Vitess (разработан YouTube) — горизонтальное шардирование MySQL с поддержкой Kubernetes. PgBouncer и ProxySQL — connection poolers, снижающие нагрузку на кластер от большого числа кратковременных соединений.