Базы данных на собственных серверах

Логический бэкап экспортирует данные в виде SQL-выражений или архива с помощью инструментов вроде pg_dump или mysqldump. Он переносим между версиями и позволяет восстановить одну таблицу, но для больших баз медленно создаётся и восстанавливается. Физический бэкап копирует файлы базы, например через pg_basebackup, pgBackRest или Percona XtraBackup. Для больших объёмов данных он гораздо быстрее, а в сочетании с непрерывным архивированием WAL или бинарного лога позволяет восстановиться на момент времени. Большинство серьёзных конфигураций использует физические бэкапы с архивированием логов для восстановления и периодические логические дампы для переносимости и восстановления отдельных таблиц.

Несколько слоёв. Во-первых, сервис привязан к 127.0.0.1 или интерфейсу частной сети, что я проверяю через ss -tlnp. Во-вторых, файрвол на хосте по умолчанию запрещает входящий трафик и пропускает только 22, 80 и 443; если доступ нужен серверам приложений, я разрешаю только частную подсеть. В-третьих, файрвол облачного провайдера дублирует эти правила. В-четвёртых, аутентификация всё равно строгая: никакого удалённого входа под root, scram-sha-256 в PostgreSQL, сильные пароли для каждого приложения. Для админского доступа с ноутбука я использую SSH-туннель, а не открываю порт. С Docker я привязываю опубликованные порты к 127.0.0.1, потому что Docker может обходить правила ufw.

Начинаю с памяти. Для MySQL innodb_buffer_pool_size на выделенном сервере занимает большую часть RAM, около 50–70 процентов, и меньше, если машину делит приложение. Для PostgreSQL shared_buffers около 25 процентов RAM, effective_cache_size около 50–75 процентов и скромный work_mem, потому что он умножается на каждую операцию и соединение. Держу max_connections разумным и добавляю PgBouncer при большом числе клиентов. Затем включаю лог медленных запросов, разбираю худшие запросы через EXPLAIN и добавляю индексы. Большинство реальных выигрышей в производительности приходит от запросов и индексов, а не от экзотических флагов конфигурации.

RPO (recovery point objective) — это сколько данных вы можете позволить себе потерять, измеренное во времени. RTO (recovery time objective) — сколько вы можете простаивать во время восстановления. Ночной дамп даёт RPO до 24 часов; если бизнес может потерять только минуты, нужно непрерывное архивирование WAL или binlog либо управляемая база с восстановлением на момент времени. RTO зависит от объёма данных и практики: логическое восстановление 200 GB может занять часы, а повышение реплики — минуты. Сначала я согласовываю эти цифры с бизнесом, затем выбираю инструменты и проверяю оба показателя учениями по восстановлению с замером времени.

Управляемая — более безопасный выбор по умолчанию, когда простой или потеря данных обходятся дорого, а специалиста по базам в команде нет: вы получаете автоматические бэкапы, восстановление на момент времени, патчи, реплики и failover. Компромиссы — стоимость, меньший контроль над версиями и расширениями и определённая привязка к вендору. Своя база дешевле и полностью гибкая и хорошо работает для небольших и средних проектов, когда бэкапы, мониторинг и обновления автоматизированы, а восстановление проверено. Я часто советую начинать MVP со своей базы на хорошо настроенном сервере и переходить на управляемую, когда выручка или требования к доступности это оправдают, ведь миграция — это запланированные дамп и восстановление.

Я создаю отдельную роль только для чтения с SELECT лишь на нужную схему или таблицы, плюс привилегии по умолчанию, чтобы покрывались и новые таблицы. Подключения идут через SSH-туннель или бастион, никогда через публичный порт. В идеале роль смотрит на реплику для чтения или недавно восстановленную копию, чтобы тяжёлые отчёты не тормозили продакшен. Если в данных есть персональная информация, я ограничиваю колонки через представления или даю анонимизированную копию. Доступ персональный, а не общий, поэтому его можно отозвать индивидуально, а логирование запросов или расширения аудита фиксируют, что выполнялось. Учётку удаляют, когда она человеку больше не нужна.

Failover — это повышение standby до primary, когда primary умирает, и перенаправление приложения на него. Опасный случай — split-brain: старый primary лишь недоступен, а не мёртв, и оба принимают записи, создавая расходящиеся данные, которые мучительно сливать. Для защиты нужен механизм консенсуса или fencing. Patroni с etcd для PostgreSQL или managed-сервис держит leader lock и понижает или изолирует старый primary до повышения нового. Приложения подключаются через стабильный endpoint — виртуальный IP, прокси или DNS под управлением кластера. Синхронная репликация может гарантировать нулевую потерю данных ценой задержки записи и доступности при отказе standby. Небольшим командам managed-база обычно выгоднее, чем строить всё это правильно самим.

Redis предлагает RDB-снимки — периодические дампы на момент времени, компактные и быстро загружаемые, но теряющие записи с последнего снимка, — и AOF, журнал каждой записи в режиме append-only. С appendfsync everysec, обычной настройкой, сбой теряет максимум около секунды. Для очередей и сессий я включаю AOF плюс RDB, ставлю maxmemory-policy noeviction, чтобы Redis возвращал ошибки, а не молча выбрасывал задачи, и ставлю алерт на память задолго до лимита. Ещё я разделяю ответственность: инстанс для кэша с allkeys-lru и без persistence и инстанс для очередей с надёжностью. Если даже секунда потерянных задач неприемлема, источником истины для задач должна быть SQL-база, а Redis — только транспортом.

Исходите из того, что атакующий с root на сервере базы попытается удалить и бэкапы. Поэтому сервер должен уметь записывать бэкапы, но не удалять и не перезаписывать их: используйте бакет в отдельном аккаунте с object lock или версионированием плюс политикой хранения и учётные данные, которые разрешают только загрузку. Шифруйте бэкапы на стороне клиента ключами, хранящимися вне сервера, чтобы утёкший бакет ничего не раскрыл. Держите хотя бы одну копию у другого провайдера. Мониторьте отсутствующие или подозрительно маленькие бэкапы, потому что тихий сбой выглядит так же, как атака. И наконец, проводите учения по восстановлению из удалённой копии без доступа к исходному серверу — это ровно та ситуация, что бывает после инцидента.

Обе отличные, и опыт команды часто важнее возможностей. PostgreSQL предлагает более богатый SQL, мощный JSONB с индексами, частичные индексы и индексы по выражениям, расширения вроде PostGIS и pgvector, транзакционный DDL и строгую корректность, поэтому для сложных доменов и приложений с большим количеством аналитики это мой выбор по умолчанию. MySQL с InnoDB прост в эксплуатации, имеет очень зрелую репликацию, огромную экосистему хостинга и мгновенное добавление колонок для многих изменений схемы, а фреймворки вроде Laravel работают на нём одинаково хорошо. Важны и эксплуатационные различия: PostgreSQL раньше требует пулинга соединений и понимания vacuum, MySQL требует осторожности с online DDL на больших таблицах. Я выбираю PostgreSQL, если только существующие системы, хостинг или навыки команды не говорят в пользу MySQL.