Вопросы по эксплуатации баз данных на собеседовании

Инженера эксплуатации спрашивают про базы не как разработчика, а как дежурного: почему таблица распухает при работающей автоочистке, чем реплика отличается от резервной копии, что делать при отставании потребителя Kafka и что теряется при падении Redis.

Что спрашивают

• +PostgreSQL в проде: пулер соединений, autovacuum и долгие транзакции, блокировки при миграциях
• +Копии: логический дамп против физической копии, восстановление на точку, проверка времени восстановления
• +Репликация: синхронная и асинхронная, отставание и чтение с реплик, автопереключение и раздвоение лидера
• +Брокеры и кэши: журнал против очереди, партиции и лаг, ретенция, вытеснение и сохранность Redis

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, что просели.

• Репликация и failover7
• Kafka и RabbitMQ6
• PostgreSQL в проде6
• Redis и кэши6
• Бэкапы и восстановление6

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

• PostgreSQL в проде: пулер, очистка, блокировки6 вопросов
• Бэкапы базы и восстановление на точку6 вопросов
• Репликация базы и переключение лидера7 вопросов
• Kafka и RabbitMQ в эксплуатации6 вопросов
• Redis как кэш: память, прогрев, сохранность6 вопросов

Примеры вопросов с разбором

1. #dvo_broker_ops1 / 9
   Чем Kafka принципиально отличается от классической очереди вроде RabbitMQ?

   A)Kafka хранит журнал по сроку, и его читают повторно с любого места

   B)Kafka удаляет сообщение после подтверждения, очередь хранит его вечно

   C)Kafka работает только внутри кластера, очередь доступна снаружи

   D)Kafka теряет порядок сообщений, а очередь его держит

   показать ответ и разбор

   +A)Kafka хранит журнал по сроку, и его читают повторно с любого места

   // разбор: Очередь ориентирована на доставку задач: сообщение забрали, подтвердили — оно исчезло, маршрутизация гибкая. Kafka — журнал: записи лежат в партициях до истечения ретенции, каждая группа потребителей держит свою позицию и может перечитать историю с нужного места. Отсюда разные сценарии: очередь для задач и RPC-подобных потоков, журнал для событий, которые нужны нескольким потребителям и для перепроигрывания.

2. #dvo_cache_ops2 / 9
   Redis используют как кэш. Что настраивают, чтобы он не упёрся в память?

   A)Предел памяти и политику вытеснения плюс сроки жизни ключей

   B)Сохранение на диск: вытесненные ключи уедут в файл

   C)Ограничение числа клиентов и размера пакета

   D)Репликацию: реплика заберёт часть данных на себя

   показать ответ и разбор

   +A)Предел памяти и политику вытеснения плюс сроки жизни ключей

   // разбор: Без ограничения памяти кэш растёт до предела контейнера и получает убийство по нехватке памяти. Штатно задают maxmemory и политику вытеснения — обычно выбрасывать давно не используемые ключи среди тех, у кого задан срок жизни, — и следят, чтобы сроки действительно проставлялись. Иначе кэш незаметно превращается в хранилище: ключи копятся, вытеснять нечего, и всё кончается отказом.

3. #dvo_db_backup3 / 9
   Чем логический дамп отличается от физической копии базы?

   A)Логический снимается на живой базе, физический требует остановки

   B)Логический хранит только схему, физический — данные

   C)Логический — команды и данные, физический — файлы

   D)Логический подходит для восстановления на точку, физический — нет

   показать ответ и разбор

   +C)Логический — команды и данные, физический — файлы

   // разбор: Логический дамп описывает содержимое: его можно развернуть в другой версии базы, перенести отдельную таблицу, прочитать глазами. Расплата — медленное восстановление большой базы: данные заливаются как обычные вставки, индексы строятся заново. Физическая копия — снимок файлов кластера, восстановление быстрое и точное, но привязано к версии и архитектуре, зато с ним работает восстановление на момент времени.

4. #dvo_db_ops4 / 9
   Перед PostgreSQL ставят пулер соединений. Зачем, если пул есть и в приложении?

   A)Пулер кэширует результаты запросов и разгружает базу

   B)Соединение — это процесс с памятью, а сервисов много

   C)Пулер шифрует трафик до базы и снимает эту работу с неё

   D)Через пулер работают миграции схемы, напрямую они запрещены

   показать ответ и разбор

   +B)Соединение — это процесс с памятью, а сервисов много

   // разбор: PostgreSQL на каждое соединение поднимает процесс со своей памятью, поэтому сотни клиентских пулов от десятков подов упираются в предел раньше, чем в процессор. Внешний пулер держит небольшое число реальных соединений и мультиплексирует в них клиентов. Побочно он даёт единую точку ограничения нагрузки и переживания переключений — правда, в режиме транзакций часть возможностей сессии становится недоступной.

5. #dvo_db_replication5 / 9
   Чем синхронная репликация отличается от асинхронной на практике?

   A)Синхронная ждёт реплику: медленнее, но без потерь

   B)Синхронная копирует файлы, асинхронная передаёт запросы

   C)Синхронная работает внутри зоны, асинхронная — только между регионами

   D)Синхронная требует одинаковых версий базы, асинхронная — нет

   показать ответ и разбор

   +A)Синхронная ждёт реплику: медленнее, но без потерь

   // разбор: При синхронной схеме транзакция считается зафиксированной, когда реплика подтвердила получение: при падении лидера ничего не теряется, но каждая запись оплачивается задержкой сети и зависит от живости реплики. Асинхронная быстрее и устойчивее к тормозам реплики, зато при аварии теряется хвост транзакций, который не успел уехать. Выбор делают по требованию к допустимой потере данных.

6. #dvo_broker_ops6 / 9
   Потребители не успевают за потоком. Добавили ещё пять экземпляров — скорость не выросла. Почему?

   A)Группа потребителей не масштабируется больше трёх экземпляров

   B)Новые экземпляры читают с начала журнала и мешают остальным

   C)Параллелизм ограничен числом партиций

   D)Брокер распределяет нагрузку раз в сутки при перебалансировке

   показать ответ и разбор

   +C)Параллелизм ограничен числом партиций

   // разбор: Партиция обрабатывается одним потребителем в группе — это и даёт порядок внутри неё. Если партиций восемь, девятый экземпляр останется без работы. Расширяют число партиций (заранее, с запасом: уменьшать их нельзя, а добавление меняет распределение ключей) либо ускоряют самого потребителя — пачками, параллельной обработкой внутри, выносом тяжёлых операций.

7. #dvo_cache_ops7 / 9
   После перезапуска кэша база легла под шквалом запросов. Как этого избежать в следующий раз?

   A)Поднять таймауты в приложении, чтобы запросы дождались базы

   B)Прогревать кэш и не давать всем промахам идти в базу разом

   C)Отключить кэш на время нагрузки и включить после стабилизации

   D)Уменьшить срок жизни ключей, чтобы данные обновлялись чаще

   показать ответ и разбор

   +B)Прогревать кэш и не давать всем промахам идти в базу разом

   // разбор: Пустой кэш означает, что каждый запрос идёт в базу, и она получает нагрузку, на которую не рассчитана. Помогают три вещи: прогрев горячих ключей до включения трафика, блокировка на пересчёт (первый промах считает, остальные ждут результат) и разброс сроков жизни, чтобы ключи не протухали одновременно. Отдельно проверяют, что база переживёт полный отказ кэша хотя бы в деградации.

8. #dvo_db_backup8 / 9
   Что нужно, чтобы восстановить базу на состояние за минуту до ошибочного удаления?

   A)Ежечасные логические дампы и выбор ближайшего по времени

   B)Базовая копия плюс непрерывный архив журнала предзаписи

   C)Реплика с задержкой применения изменений на сутки

   D)Снимок диска, снятый в момент инцидента

   показать ответ и разбор

   +B)Базовая копия плюс непрерывный архив журнала предзаписи

   // разбор: Восстановление на точку складывается из двух частей: физическая базовая копия и все журналы предзаписи после неё, уезжающие в архив непрерывно. При восстановлении база разворачивается из копии и проигрывает журнал до указанного момента — вплоть до секунды перед ошибкой. Отсюда требования: архив на отдельном хранилище, контроль непрерывности сегментов и регулярная проверка, что развернуть это реально получается.

9. #dvo_db_ops9 / 9
   Таблица распухла, место кончается, автоочистка работает, но не помогает. Что смотреть?

   A)Индексы: их надо перестроить, чтобы вернуть место

   B)Настройки контрольных точек: они удерживают старые страницы

   C)Кэш страниц: он не отдаёт устаревшие версии строк

   D)Долгие открытые транзакции держат старые версии

   показать ответ и разбор

   +D)Долгие открытые транзакции держат старые версии

   // разбор: База хранит старые версии строк, пока их может увидеть хоть одна открытая транзакция. Забытая сессия в состоянии idle in transaction, зависший отчёт или репликация с задержкой держат горизонт видимости, и очистка не имеет права освободить место — таблица растёт, а очистка каждый раз отчитывается «нечего убирать». Смотрят самые старые транзакции, ставят таймауты на простой в транзакции и следят за отставанием реплик.

Частые вопросы

• Почему репликация не заменяет резервные копии?

  Репликация защищает от отказа узла, но не от ошибки: удаление таблицы доедет до реплик за секунды. Нужен независимый по времени слепок и архив журнала, чтобы восстановиться на момент до ошибочной команды.

• Что спрашивают про Kafka у эксплуатации?

  Чем журнал отличается от очереди, почему добавление потребителей сверх числа партиций не ускоряет обработку, как связаны отставание потребителя, срок хранения и место на диске брокеров.