8.3 KiB
Вопросы: PostgreSQL / базы данных
Опираются на кейс: CASE.md. Источники реальных вопросов — Реалист банк.md, Alfa-Bank.md, VK Cloud.md.
Расскажи про синхронный и асинхронный режим работы PostgreSQL — в чём разница?
При синхронной репликации (synchronous_commit=on + synchronous_standby_names) master не подтверждает клиенту commit транзакции, пока хотя бы одна указанная реплика не подтвердила запись WAL — это гарантирует нулевую потерю данных при падении master ценой более медленного commit. При асинхронной репликации master коммитит сразу и отправляет WAL реплике фоном — быстрее, но при падении master прямо перед репликацией последние транзакции можно потерять. У себя в стенде я явно переключал этот параметр и видел разницу в pg_stat_replication.sync_state (sync → async), а не просто читал про это.
Как будешь разворачивать PostgreSQL на две ноды?
Классическая схема — master + streaming replica: реплика инициализируется через pg_basebackup с master и дальше получает изменения через WAL-стриминг по replication slot. Дальше поверх этого нужен failover-механизм (например, Patroni + etcd/Consul для автоматического переключения при падении master) — сам failover-контроллер я не поднимал, но принцип базовой репликации прогнал в Docker Compose на две ноды (master + replica) и вижу, из каких частей состоит более сложная HA-схема поверх этого.
Какие виды JOIN существуют и как они работают?
INNER JOIN — только строки, где есть совпадение в обеих таблицах. LEFT JOIN — все строки левой таблицы + совпадения справа (NULL, если совпадения нет). RIGHT JOIN — зеркально, все строки правой таблицы. FULL OUTER JOIN — все строки из обеих таблиц, с NULL там, где нет совпадения. На своей учебной схеме customers/orders: SELECT c.name, o.amount FROM customers c LEFT JOIN orders o ON o.customer_id = c.id покажет всех клиентов, включая тех, у кого нет заказов (у меня в примере таких не было, но проверял именно так, добавляя клиента без заказов).
Что такое кластер (в контексте баз данных)?
В контексте PostgreSQL термин многозначный: (1) «кластер БД» на уровне процесса — это весь набор баз данных, которыми управляет один экземпляр postgres (директория данных, initdb); (2) в контексте отказоустойчивости — группа из нескольких инстансов (master + реплики), обеспечивающая доступность и/или масштабирование чтения. У себя в лабе я поднял именно второй случай — master + reплика как единый логический кластер с общими данными.
Как происходит репликация базы данных?
Master пишет все изменения в WAL (write-ahead log) до применения к данным. Реплика подключается к master через replication slot, получает поток WAL-записей (streaming replication) и применяет их у себя, воспроизводя то же состояние с небольшой задержкой (или без задержки — при sync-режиме). Начальное состояние реплика получает через pg_basebackup — полную копию данных на момент старта, дальше — только дельты через WAL.
Что такое quorum в конфигурации master-master (или в отказоустойчивом кластере вообще)?
Кворум — минимальное количество узлов, которое должно быть согласно/доступно, чтобы кластер считал своё решение валидным (обычно больше половины от общего числа узлов). Нужен, чтобы избежать одновременного принятия противоречащих решений разными частями кластера при разрыве сети — при потере кворума меньшая часть кластера не имеет права принимать решения (например, выбирать нового master), что и предотвращает split brain.
Расскажи про split brain и почему кворум помогает?
Split brain — ситуация, когда из-за разрыва сети кластер разделяется на две части, и обе считают себя главными/рабочими одновременно (например, две ноды одновременно думают, что они master и принимают записи) — это ведёт к расхождению данных. Кворум решает эту проблему: только та часть кластера, где узлов больше половины от общего числа, имеет право принимать решения (выбирать нового лидера, подтверждать транзакции); меньшая часть автоматически переходит в read-only или отказывает в обслуживании, не считая себя валидным большинством.
Есть таблица orders — какая команда выведет количество записей, где id = 15?
SELECT COUNT(*) FROM orders WHERE id = 15;
Так как id — первичный ключ, результат либо 0, либо 1; если бы вопрос был про количество заказов конкретного клиента, это было бы SELECT COUNT(*) FROM orders WHERE customer_id = 15;.
Что такое скоринг и кредитный конвейер? (контекст банковских вакансий)
Скоринг — процесс автоматической оценки кредитоспособности клиента по набору параметров (доход, кредитная история и т.д.), результат — числовой балл или решение одобрить/отклонить. Кредитный конвейер — сквозной автоматизированный процесс обработки заявки на кредит от подачи до решения: сбор данных → проверки (антифрод, скоринг, внешние бюро) → решение → оформление. Для инженера сопровождения/DevOps практический смысл в том, что это высоконагруженный и критичный по SLA процесс — отсюда повышенные требования к мониторингу и отказоустойчивости систем, которые его обслуживают.