Управление реляционными СУБД — итоги
Кратко — что стоит унести из раздела "Управление реляционными СУБД". Если пункт кажется туманным — откройте указанную главу или оглавление.
FAQ — Часто задаваемые вопросы
Типичные инциденты и ошибки при установке, настройке и эксплуатации РСУБД. Здесь — что проверить первым делом; пункты для самопроверки — в чек-листе.
Вопрос. PostgreSQL установлен, но psql -U postgres выдаёт "connection refused" на localhost.
Ответ. Проверьте, запущена ли служба (postgresql), слушает ли порт в postgresql.conf (listen_addresses, port) и не блокирует ли firewall. На Linux часто нужен systemctl start postgresql. Подробнее здесь — PostgreSQL — установка, Первые шаги SQL.
Вопрос. Забыли пароль суперпользователя PostgreSQL на своём стенде — как войти без переустановки?
Ответ. На учебном сервере временно разрешите local trust в pg_hba.conf для сокета, перезагрузите конфиг, смените пароль через ALTER USER, верните строгие правила. В production так не делают без процедуры и аудита. Подробнее здесь — справочник PostgreSQL, Справочник по MySQL.
Вопрос. Диск с данными PostgreSQL заполнился на 100% за ночь — сервис лёг.
Ответ. Ищите рост WAL, логов, временных файлов, неудачный импорт или bloat таблиц. Освободите место (архив WAL, ротация логов, VACUUM), затем мониторьте тренд. Заранее задайте алерты на 80–85%. Подробнее здесь — обзор администрирования, справочник § PITR.
Вопрос. После запуска полного бэкапа production "тормозит" — это нормально?
Ответ. Тяжёлый pg_dump/mysqldump на primary конкурирует за I/O и блокировки. Снимайте с реплики или hidden secondary, планируйте окно, используйте физический бэкап (basebackup, XtraBackup). Подробнее здесь — справочник PostgreSQL, резервное копирование SQL.
Вопрос. Файл .backup / .sql есть, а pg_restore падает на полпути.
Ответ. Проверьте версию формата, целостность файла (обрыв копирования), права на создание объектов и конфликты имён. Бэкап без регулярного тестового restore — иллюзия безопасности. Подробнее здесь — Резервное копирование и восстановление PostgreSQL, восстановление после сбоя.
Вопрос. replication lag на read-replica растёт — отчёты показывают вчерашние данные.
Ответ. Реплика отстаёт из-за тяжёлой записи на primary, медленного диска на replica, длинных транзакций или сети. Смотрите lag-метрики, нагрузку на WAL apply, при необходимости упрочняйте replica или переносите отчёты на materialized view. Подробнее здесь — масштабирование, практикум PostgreSQL 8.11.
Вопрос. Primary упал — команда в панике "не знает, кого сделать новым master".
Ответ. Failover должен быть задокументирован и отрепетирован: кто promote replica, как переключить DNS/connection string, как проверить split-brain. Автоматика (Patroni, Orchestrator) снижает хаос. Подробнее здесь — обзор, восстановление.
Вопрос. В коде приложения прописан postgres / sa / SYS — "так проще на dev".
Ответ. Суперпользователь в приложении — полный компромисс БД при утечке конфига или SQL-инъекции. Создайте роль только с SELECT/INSERT/UPDATE/DELETE на нужные таблицы; секреты — в vault, не в git. Подробнее здесь — Справочник по MySQL, обзор § безопасность.
Вопрос. MySQL: ERROR 1130 (HY000): Host is not allowed to connect с IP приложения.
Ответ. Пользователь MySQL привязан к user@host — 'app'@'10.0.1.5' и 'app'@'%' разные записи. Создайте grant для фактического IP/подсети и проверьте bind-address в my.cnf. Подробнее здесь — 211 MySQL, MySQL API.
Вопрос. Клиент БД ругается на SSL: certificate verify failed после обновления сервера.
Ответ. Сверьте CA, срок сертификата, hostname в SAN и режим verify-full vs require. После ротации cert обновите trust store в приложении и JDBC/ODBC строках. Подробнее здесь — справочник PostgreSQL, облако § shared responsibility.
Вопрос. Таблицы раздулись, простые SELECT стали медленными — autovacuum "не справляется".
Ответ. Длинные транзакции блокируют vacuum; растёт dead tuple bloat. Найдите idle in transaction, настройте autovacuum агрессивнее для hot-таблиц, при необходимости VACUUM (FULL) в окне. Подробнее здесь — справочник, производительность.
Вопрос. Oracle: табличное пространство USERS offline, приложение не стартует.
Ответ. Проверьте место на диске, повреждение datafile, статус в DBA_DATA_FILES, alert.log. Восстановление из RMAN или перевод tablespace online после устранения причины — по runbook. Подробнее здесь — Oracle, восстановление.
Вопрос. SQL Server: файл LDF разросся до сотен гигабайт.
Ответ. При модели FULL log растёт, пока не сделан backup log. Проверьте recovery model, регулярность log backup и длинные незавершённые транзакции. Не удаляйте LDF вручную без процедуры shrink после backup. Подробнее здесь — 212 SQL Server, Резервное копирование и восстановление PostgreSQL.
Вопрос. Увеличили shared_buffers / innodb_buffer_pool_size "на весь RAM" — PostgreSQL не стартует.
Ответ. СУБД и ОС нужна память под соединения, sort, кэш FS. Правило — оставить 20–30% RAM системе и другим процессам; смотрите документацию по tuning. Откатите параметр через конфиг и перезапуск. Подробнее здесь — девять рычагов, справочник.
Вопрос. Антивирус сканирует каталог PGDATA — случайные фризы на секунды.
Ответ. Real-time scan на data/WAL каталогах даёт латентные spikes. Исключите пути данных и логов СУБД из on-access scanning (с согласования ИБ). Подробнее здесь — обзор, Справочник по MySQL.
Вопрос. На production обнаружили trust для всех в pg_hba.conf — "так поставили по умолчанию".
Ответ. trust пропускает без пароля — критическая дыра при доступе к порту. Замените на scram-sha-256, ограничьте IP, перезагрузите конфиг, проверьте приложения. Подробнее здесь — Справочник по MySQL, справочник.
Вопрос. Бэкапы "есть три года", restore никто ни разу не пробовал — можно ли спать спокойно?
Ответ. Нет: без тестового восстановления неизвестны битые архивы, неверные права и время RTO. Раз в квартал — restore на стенд и smoke-test приложения. Подробнее здесь — Резервное копирование и восстановление PostgreSQL, восстановление.
Вопрос. Нужно откатить БД "на вчера 14:37" — есть только nightly dump.
Ответ. Точечный момент требует PITR — непрерывное архивирование WAL/binlog/redo между полными бэкапами. Настройте archive_mode, хранение WAL и процедуру до инцидента. Подробнее здесь — справочник § PITR, Резервное копирование и восстановление PostgreSQL.
Вопрос. Приложение: FATAL: too many connections for role "app" в пик нагрузки.
Ответ. Каждый инстанс приложения открывает пул; сумма превышает max_connections. Введите PgBouncer/ProxySQL, уменьшите pool size, закройте idle connections. Подробнее здесь — масштабирование, справочник.
Вопрос. Миграция ALTER TABLE висит час — в pg_stat_activity "waiting for AccessExclusiveLock".
Ответ. Долгий SELECT или idle transaction держит lock. Найдите блокирующий pid, согласуйте kill или окно; для индексов используйте CREATE INDEX CONCURRENTLY. Подробнее здесь — блокировки SQL, справочник.
Вопрос. REINDEX / rebuild индекса запустили днём — пользователи жалуются на зависания.
Ответ. Полный rebuild блокирует запись или чтение в зависимости от СУБД. Планируйте CONCURRENTLY или окно обслуживания; сначала измерьте bloat — может хватить vacuum. Подробнее здесь — 884 индексы, производительность.
Вопрос. Managed RDS/Cloud SQL или своя VM — команда спорит без критериев.
Ответ. Сравните RPO/RTO, компетенции команды, стоимость скрытого администрирования, требования регулятора и shared responsibility (бэкапы "в облаке" тоже нужно проверять). Подробнее здесь — БД в облаке, выбор СУБД.
Вопрос. Major upgrade PostgreSQL 14 → 16 — "просто apt upgrade" или есть подводные камни?
Ответ. Нужен план: pg_upgrade или dump/restore, проверка extensions, collation, downtime, rollback. Прогоните на копии, зафиксируйте время простоя. Подробнее здесь — новинки PG16, Справочник по MySQL.
Вопрос. Два приложения в одной БД — один с DROP TABLE, второй "случайно" потерял таблицу.
Ответ. Изоляция через отдельные БД или схемы + роли без DDL-прав у app-пользователя. REVOKE CREATE ON SCHEMA и отдельные credentials. Подробнее здесь — Справочник по MySQL, обзор.
Вопрос. Мониторинг: диск 95%, что делать в первые 15 минут?
Ответ. Определите, data, WAL или log растёт; остановите незапланированный dump, архивируйте старые WAL после backup, очистите temp. Долгосрочно — retention, отдельный том для WAL, алерт на 80%. Подробнее здесь — Zabbix, Prometheus.
Вопрос. MySQL replication: Slave_SQL_Running: No, ошибка duplicate entry.
Ответ. Реплика сошлась из-за ручной правки на replica или неконсистентного snapshot. Не "skip one" вслепую в production — найдите рассинхрон, пересоздайте replica с свежего backup. Подробнее здесь — Справочник по MySQL, восстановление.
Вопрос. Сменили пароль БД в vault — половина микросервисов всё ещё с старым.
Ответ. Rolling restart без координации даёт auth storm. План: dual-password window (где поддерживается), поэтапный rollout, healthcheck. Документируйте владельца credential rotation. Подробнее здесь — обзор § безопасность, облако.
Вопрос. RPO "0" и RTO "5 минут" озвучили на встрече, но бэкап раз в неделю.
Ответ. Требования и реализация не сходятся. Сначала зафиксируйте допустимую потерю данных и время простоя, затем подберите full/incr backup, WAL archiving и failover. Подробнее здесь — Резервное копирование и восстановление PostgreSQL, обзор.
Вопрос. Журналы транзакций на том же HDD, что и данные — "админ сказал, так проще".
Ответ. WAL/redo и data на одном медленном диске — узкое место при commit storm. Вынесите журналы на отдельный быстрый том (желательно NVMe). Подробнее здесь — девять рычагов, Справочник по MySQL.
Вопрос. После mysql_secure_installation root без пароля всё ещё заходит локально — это ок?
Ответ. На стенде — временно; в production root только break-glass, приложения на отдельных users, удалите anonymous users и test DB, как предписывает hardening. Подробнее здесь — Справочник по MySQL, MySQL.
Вопрос. Я только учу SQL — этот раздел про DBA нужен уже сейчас?
Ответ. Для первых SELECT достаточно 101 → 888. Сюда возвращайтесь перед деploy на сервер, стажировкой в эксплуатации или когда поднимаете PostgreSQL дома и нужны бэкап и pg_hba. Подробнее здесь — о разделе.
Вопрос. Кто такой DBA и чем занимается администратор баз данных?
Ответ. DBA (Database Administrator) — установка, настройка, бэкапы, безопасность, мониторинг, репликация и восстановление РСУБД. SQL пишут разработчики; DBA держит сервер живым. Подробнее здесь — обзор администрирования.
Вопрос. Как установить PostgreSQL на Ubuntu или Debian — пошагово?
Ответ. Пакет postgresql → initdb (если нужно) → служба → пользователь ОС postgres → createuser/createdb → правка pg_hba.conf. Подробнее здесь — 211 PostgreSQL, 101 SQL.
Вопрос. pg_dump — как сделать бэкап базы PostgreSQL?
Ответ. pg_dump -U postgres -Fc -f backup.dump dbname — сжатый custom-формат; список БД — pg_dumpall для ролей. Проверяйте restore на стенде. Подробнее здесь — справочник § pg_dump, 106 SQL.
Вопрос. pg_hba.conf — что это и как настроить доступ к PostgreSQL?
Ответ. Файл правил кто, откуда, как аутентифицируется: local, host, scram-sha-256, конкретные IP. После правки — pg_ctl reload. Подробнее здесь — Справочник по MySQL, справочник.
Вопрос. Репликация PostgreSQL — streaming replication как настроить?
Ответ. На primary: wal_level = replica, слот репликации, пользователь replication. На standby: pg_basebackup → standby.signal → primary_conninfo. Подробнее здесь — справочник, масштабирование, практикум 8.11.
Вопрос. Point-in-Time Recovery (PITR) PostgreSQL — как восстановить на момент времени?
Ответ. Нужны base backup + непрерывный архив WAL; восстановление через recovery_target_time. Без archive_mode PITR невозможен. Подробнее здесь — справочник § PITR, восстановление после сбоя.
Вопрос. Что такое WAL в PostgreSQL простыми словами?
Ответ. Write-Ahead Log — журнал изменений до записи на data pages; обеспечивает durability и основу для репликации и PITR. Аналог — redo log в Oracle, transaction log в SQL Server. Подробнее здесь — обзор, основы БД.
Вопрос. shared_buffers PostgreSQL — сколько выставлять?
Ответ. Ориентир — 25% RAM сервера (не 100%): остальное — OS cache, work_mem, соединения. Тюнинг под нагрузку и мониторинг hit ratio. Подробнее здесь — девять рычагов, справочник.
Вопрос. Autovacuum PostgreSQL — что делает и почему таблица "раздувается"?
Ответ. Autovacuum убирает dead tuples после UPDATE/DELETE и обновляет статистику. Bloat растёт при долгих транзакциях и отключённом vacuum. Подробнее здесь — справочник, Справочник по MySQL.
Вопрос. PgBouncer — зачем нужен и чем отличается от PostgreSQL?
Ответ. PgBouncer — пулer соединений: тысячи клиентов → десятки реальных подключений к Postgres. Снижает too many connections и overhead на backend. Подробнее здесь — масштабирование, обзор.
Вопрос. Как создать пользователя и базу данных в PostgreSQL?
Ответ. CREATE USER app WITH PASSWORD '…'; → CREATE DATABASE myapp OWNER app; → GRANT на схему/таблицы. Приложению — минимальные права. Подробнее здесь — Справочник по MySQL, 888 SQL.
Вопрос. MySQL mysqldump — как сделать бэкап и восстановить?
Ответ. mysqldump -u root -p --single-transaction db > dump.sql; restore — mysql db < dump.sql. Для PITR включите log_bin. Подробнее здесь — 211 MySQL, Резервное копирование и восстановление PostgreSQL.
Вопрос. Oracle RMAN backup — краткий обзор для начинающего DBA?
Ответ. RMAN — штатный инструмент физического бэкапа Oracle: full/incremental, восстановление datafile, PITR при ARCHIVELOG. Подробнее здесь — Oracle, восстановление.
Вопрос. SQL Server backup — FULL, DIFF, LOG — как выбрать модель?
Ответ. FULL recovery + регулярный log backup → PITR. SIMPLE — без log chain. DIFF уменьшает объём между full. Подробнее здесь — 212 SQL Server, Резервное копирование и восстановление PostgreSQL.
Вопрос. Managed database (RDS, Cloud SQL) или свой сервер — что выгоднее?
Ответ. Managed — патчи, бэкапы, SLA, меньше ops; self-hosted — контроль, стоимость на масштабе, свои расширения. Shared responsibility: бэкапы в облаке тоже проверяйте. Подробнее здесь — БД в облаке, выбор СУБД.
Вопрос. Replication lag — что делать, если реплика отстаёт на часы?
Ответ. Проверьте нагрузку на primary, скорость диска replica, сеть, long transactions. Временно снимите тяжёлые отчёты с replica; при необходимости пересоздайте standby. Подробнее здесь — масштабирование, восстановление.
Вопрос. RPO и RTO — что это и как связано с бэкапами?
Ответ. RPO — сколько данных можно потерять (интервал бэкапа/WAL). RTO — за сколько поднять сервис после сбоя. От этого зависит стратегия full/incr и failover. Подробнее здесь — Резервное копирование и восстановление PostgreSQL, обзор.
Вопрос. Как открыть порт PostgreSQL 5432 только для приложения?
Ответ. Firewall: allow 5432/tcp с IP app-серверов; в pg_hba.conf — те же подсети; listen_addresses — конкретный интерфейс, не * без нужды. Подробнее здесь — Справочник по MySQL, обзор § сеть.
Вопрос. initdb PostgreSQL — что делает и когда запускать?
Ответ. initdb создаёт новый кластер: каталог PGDATA, системные таблицы, postgresql.conf, pg_hba.conf. Один раз на новый инстанс; кодировка и locale задаются здесь. Подробнее здесь — Справочник по MySQL, справочник.
Вопрос. Мониторинг PostgreSQL — какие метрики смотреть в первую очередь?
Ответ. Connections, replication lag, disk usage, cache hit ratio, deadlocks, long queries в pg_stat_activity, autovacuum. Инструменты — Zabbix, Prometheus/Grafana. Подробнее здесь — Zabbix, Prometheus, практикум PG 8.11.
Вопрос. PostgreSQL vs Oracle — когда нужен Oracle в enterprise?
Ответ. Oracle — RAC, legacy ERP, жёсткие enterprise-контракты и экосистема. PostgreSQL закрывает большинство новых проектов; Oracle — там, где уже развёрнут стек или нужны специфичные опции. Подробнее здесь — Oracle, выбор СУБД.
Вопрос. Как стать DBA — с чего начать учиться администрированию БД?
Ответ. Сначала SQL (101–888), затем установка PostgreSQL, бэкап/restore, pg_hba, мониторинг, репликация на стенде. Подробнее здесь — о разделе, обзор, практикум 8.11.
Вопрос. Patroni и HA PostgreSQL — что это для high availability?
Ответ. Patroni — оркестратор failover: следит за primary, promote replica при сбое, интеграция с etcd/Consul. Кластеризация без ручного switchover. Подробнее здесь — масштабирование, практикум 8.11.
Что запомнить
Управление реляционными системами управления базами данных — это комплексная дисциплина, объединяющая архитектурное проектирование, эксплуатацию, безопасность, отказоустойчивость и производительность. Современная РСУБД — высоконагруженная, распределённая, критически важная система, требующая глубокого понимания как программных, так и аппаратных аспектов.
Подготовка к развёртыванию начинается задолго до установки — выбор платформы определяется лицензированием, экосистемой, требованиями к ресурсам и поддержке. Планирование ресурсов включает выделение изолированного окружения, расчёт дискового пространства с учётом роста и служебных файлов, настройку файловой системы и создание непривилегированных пользователей ОС. Безопасность закладывается на этапе проектирования — ограничение сетевого доступа, сегментация трафика, стратегия управления учётными данными.
Процесс установки у каждой СУБД уникален — PostgreSQL требует явной инициализации кластера, Oracle разделяет установку ПО и создание экземпляра, SQL Server предлагает гибкие режимы аутентификации, а MySQL после первого запуска требует обязательного выполнения mysql_secure_installation.
Конфигурация — это баланс между производительностью, надёжностью и безопасностью. Ключевые параметры — слушающие адреса, объёмы памяти, настройки журналирования и автоматического обслуживания. Неправильные значения могут привести к утечкам данных, падению производительности или невозможности восстановления после сбоя.
Терминальные клиенты (psql, sqlplus, sqlcmd, mysql) остаются основным инструментом администратора благодаря точности, автоматизируемости и независимости от графических интерфейсов. Настройка доступа следует принципу минимальных привилегий: локальные методы аутентификации заменяются контролируемыми, удалённый доступ ограничивается по IP и типу соединения.
Создание баз данных и пользователей выполняется с учётом ролевой модели: приложение получает только те права, которые необходимы для его функционирования. Использование суперпользовательских учётных записей в коде приложения недопустимо.
Администрирование — это цикл мониторинга, диагностики и коррекции. Аутентификация и авторизация чётко разделяются: первая подтверждает личность, вторая — права. Поддерживаются разнообразные методы — парольные, сертификатные, ОС-аутентификация, LDAP/Kerberos. Мониторинг активных сеансов, блокировок и журналов ошибок позволяет выявлять проблемы до их критического развития. Регулярное обслуживание (статистика, дефрагментация, перестроение индексов) предотвращает деградацию производительности.
Резервное копирование — обязательная практика. Логические бэкапы (pg_dump, mysqldump, expdp) обеспечивают переносимость, физические (pg_basebackup, RMAN, BACKUP DATABASE, XtraBackup) — скорость и точность. Стратегия выбирается по RPO и RTO — полные, инкрементальные, дифференциальные, горячие и холодные копии. Автоматизация через планировщики или встроенные средства гарантирует регулярность и проверяемость.
Восстановление — зеркало стратегии бэкапа. Логическое восстановление подходит для частичных исправлений, физическое — для аварийного возврата всей системы. Point-in-Time Recovery (PITR) минимизирует потерю данных, но требует непрерывного архивирования журналов транзакций.
Репликация решает задачи отказоустойчивости и масштабирования. Физическая репликация (Streaming Replication, Data Guard, Always On, Standard Replication) обеспечивает низкую задержку и высокую надёжность. Логическая (Logical Replication, GoldenGate, Transactional Replication, Group Replication) даёт гибкость — фильтрация, частичная репликация, интеграция с другими системами. Масштабирование чтения достигается через реплики, записи — через шардинг. Кластеризация (Patroni, RAC, Always On AG, InnoDB Cluster) обеспечивает автоматический failover и балансировку нагрузки.
Производительность оптимизируется итеративно: измерение → анализ → изменение → повторное измерение. Ключевые области — память (буферные пулы, временные операции), дисковая подсистема (SSD, RAID, раздельное хранение данных и журналов), параллелизм, актуальность статистики для планировщика запросов. Инструменты анализа (EXPLAIN, AWR, DMVs, Performance Schema) предоставляют детальную телеметрию для принятия обоснованных решений.
Эффективное управление РСУБД невозможно без системного подхода, документирования решений, автоматизации рутинных операций и постоянного обучения. Это непрерывный процесс поддержания системы в состоянии, соответствующем бизнес-требованиям.
Куда идти дальше
Полный маршрут — на странице о разделе.
Проверьте себя: Чек-лист самопроверки.