Спроектируйте топологию PostgreSQL для базы заказов размером 12 ТБ с нагрузкой 6 000 записей и 35 000 чтений в секунду, ростом 400 ГБ в месяц, где checkout требует консистентности read-after-write, а отчетность допускает отставание на 30 секунд.

Я оставлю один лидер для записи, направлю на него чтения checkout, а followers использую для отчетности и изоляции нагрузки. - Я размещу один синхронный follower в другой зоне доступности относительно лидера и два асинхронных follower для отчетности, задав `synchronous_standby_names = 'FIRST 1 (ha1)'`. - Checkout будет работать с endpoint лидера через PgBouncer, а отчетность получит отдельный пул, маршрутизатор которого исключает follower при lag воспроизведения больше 30 секунд. - При 6 000 записей в секунду я измерю генерацию WAL и выделю хранилище как минимум на тройную пиковую пропускную способность WAL, а не буду считать, что followers увеличивают емкость записи. - Рост на 400 ГБ в месяц дает около 20 месяцев до достижения 20 ТБ, поэтому я назначу пересмотр архитектуры при 70% заполнения хранилища или 70% устойчивой загрузки I/O лидера.

Платежный ledger в PostgreSQL записывает 2 500 транзакций в секунду в двух зонах доступности с RTT 2 мс, а третий регион находится в 75 мс; выберите политику синхронной и асинхронной репликации с нулевым RPO внутри региона и целевым удаленным lag 10 секунд.

Я буду подтверждать commit после надежного сброса WAL на диск одной локальной standby и оставлю удаленную standby асинхронной. - Я задам `synchronous_commit = on` и `synchronous_standby_names = 'ANY 1 (az2a, az2b)'`, затем под нагрузкой проверю, укладывается ли commit p99 с дополнительным локальным RTT в бюджет приложения. - Я не включу удаленную standby с задержкой 75 мс в commit quorum, потому что это добавит как минимум один межрегиональный RTT и привяжет доступность записи к состоянию межрегиональной сети. - Я настрою alert при 5 секундах lag воспроизведения в удаленном регионе и сниму нагрузку от deployment или batch-задач до нарушения целевого RPO в 10 секунд. - Если обе локальные синхронные standby недоступны, я остановлю запись, а не стану незаметно переходить на асинхронные commits, потому что заявленный RPO внутри региона равен нулю.

Настройте Patroni для трехузлового кластера PostgreSQL 16 с 4 000 записей в секунду в трех зонах доступности, автоматическим failover только при отставании кандидата менее чем на 64 МБ и недопустимостью split-brain записи.

Я использую quorum из трех участников etcd для выбора лидера и настрою Patroni так, чтобы он не продвигал отставшую реплику. - Я размещу по одному voter etcd и одному узлу PostgreSQL в каждой зоне доступности, потому что три voter сохраняют quorum после потери одной зоны, а два не сохраняют. - Я задам в Patroni `maximum_lag_on_failover: 67108864`, `synchronous_mode: true` и `synchronous_mode_strict: true`, чтобы запись останавливалась, если ни одна синхронная standby не может ее защитить. - Я установлю `ttl: 30`, `loop_wait: 10` и `retry_timeout: 10`, затем проверю, что p99 хранилища и сети с большим запасом укладываются в эти интервалы lease. - HAProxy будет направлять запись только на primary health endpoint Patroni, а fencing отзовет у старого лидера доступ клиентов и хранилища до того, как новый начнет принимать запись.

Primary PostgreSQL генерирует 180 МБ WAL в секунду и уже обслуживает четыре локальные реплики; нужно добавить шесть реплик отчетности в регионе с RTT 90 мс и удерживать отставание отчетов от primary в пределах 45 секунд. Как вы спроектируете каскадную репликацию?

Я подключу к primary две региональные relay standby и от каждой каскадно запитаю по три реплики отчетности. - Два независимых relay-потока ограничат число прямых sender на primary шестью вместо десяти и не сделают один удаленный relay единственным источником всей мощности отчетности. - Я выделю каждому relay более 180 МБ/с входящей и 540 МБ/с суммарной исходящей пропускной способности, плюс I/O replay и запас 30%, потому что он должен воспроизводить WAL и одновременно обслуживать три downstream-потока. - Мониторинг будет измерять задержку воспроизведения от primary до реплики отчетности целиком, подавать alert на 30 секундах и исключать реплику из маршрутизации отчетов на пределе свежести 45 секунд. - Я применю physical replication slots с `max_slot_wal_keep_size`, рассчитанным на окно переподключения, и отработаю переключение downstream-реплик после смены timeline у relay.

Выберите схему hash sharding для event store PostgreSQL размером 60 ТБ, принимающего 120 000 вставок в секунду от 40 миллионов устройств, где типовой запрос получает события одного устройства за последние 24 часа, а удвоение мощности не должно перемещать все данные.

Я хеширую стабильный device ID в большое число логических buckets и распределю эти buckets по физическим shards. - Я начну с 4 096 логических buckets на 16 shards, чтобы при добавлении еще 16 shards переместить примерно половину buckets, а не перераспределять все 60 ТБ. - Составной ключ `(device_bucket, device_id, event_time)` сохранит запрос одного устройства за 24 часа на одном shard и равномерно распределит разные устройства. - При 120 000 вставок в секунду начальное среднее составит 7 500 вставок на shard, но я рассчитаю каждый shard как минимум на двойную нагрузку и буду отслеживать p99 по buckets, а не только среднее. - Хеширование ухудшает общие временные range scans по всем устройствам, поэтому такие агрегаты будут поступать через CDC в аналитическое хранилище без fan-out по всем OLTP shards.

Спроектируйте range sharding для мультитенантной billing-базы размером 25 ТБ с ростом 1 ТБ в месяц, 18 000 записей в секунду, транзакциями внутри tenant и пятью tenants, каждый из которых занимает более 8% данных.

Я использую явные диапазоны tenant ID, но заранее выделю крупным tenants отдельные диапазоны, прежде чем они перегрузят общий shard. - Сервис shard map будет маршрутизировать диапазоны tenants, а каждый из пяти tenants с долей больше 8% получит собственный shard с независимым пределом роста и записи. - Общие диапазоны будут рассчитаны на 1 ТБ или 2 000 записей в секунду с триггером разделения при 70% заполнения хранилища или 70% устойчивой мощности записи. - Счета и платежи одного tenant останутся транзакциями одного shard, потому что tenant ID входит во все primary и foreign keys. - Размещение диапазонов упрощает экспорт tenant и соблюдение residency, но последовательный глобальный tenant ID создает горячий растущий край, поэтому новых tenants я буду распределять по заранее созданным диапазонам, а не добавлять в один shard.

Спроектируйте топологию Vitess для каталога MySQL 8 размером 90 ТБ с 70 000 чтений и 15 000 записей в секунду, где 80% запросов ограничены merchant ID, а shards нужно добавлять онлайн.

Я разделю keyspace Vitess по хешированному merchant ID и сделаю запросы в пределах merchant быстрым путем одного shard. - Я начну с 32 shards, каждый с одним primary и двумя replica tablets, что до учета перекоса merchants дает в среднем около 470 записей в секунду на shard. - VTGate будет маршрутизировать запросы через VSchema с консистентным vindex по merchant ID, а поиск по всему каталогу пойдет в отдельный поисковый индекс вместо scatter по 32 shards. - Чтения, допускающие 5 секунд устаревания, будут использовать тип tablet `replica`, а проверка корзины и запись будут идти на `primary` для сохранения read-after-write. - Online resharding будет использовать VReplication для копирования и потока изменений, `SwitchReads` перед `SwitchWrites` и обратную репликацию на время окна rollback.

Разместите 30 ТБ данных CockroachDB для клиентов во Франкфурте и Сингапуре с 8 000 записей и 45 000 чтений в секунду, где данные клиентов ЕС должны оставаться в ЕС, локальные чтения должны укладываться в p99 менее 20 мс, а транзакции каждого клиента требуют serializable consistency.

Я использую отдельные кластеры CockroachDB для ЕС и Сингапура, потому что строгая резидентность важнее удобства одного глобального кластера. - Кластер ЕС разместит минимум три voters в одобренных зонах доступности ЕС, а кластер Сингапура использует три локальные зоны, поэтому каждый переживет потерю одной зоны без вывоза replicas. - Региональный каталог tenants хранит идентификационные metadata рядом с клиентом, а глобальный router видит только opaque route token и регион назначения; внутри выбранного кластера каждый primary key начинается с tenant ID. - CockroachDB сохраняет serializable transactions и локальные leaseholders внутри каждого кластера, а цель p99 20 мс я проверю отдельно во Франкфурте и Сингапуре при заданных 8 000 записей в секунду. - Межрегиональные SQL-транзакции намеренно недоступны; в глобальную аналитику попадают только одобренные агрегированные или токенизированные данные через CDC, что меняет простоту compliance на эксплуатацию двух кластеров.

Перенесите 14 ТБ и 20 000 записей в секунду с восьми перегруженных shards на шестнадцать без downtime, допуская не более 60 секунд риска rollback и требуя проверки количества строк и checksums.

Я проведу resharding как онлайн-передачу владения с bulk copy, упорядоченным change capture, валидацией и версионированной маршрутизацией. - Я скопирую snapshots диапазонов с ограничением 400 МБ/с на исходный shard и буду передавать последующие изменения от надежно сохраненной позиции WAL или binlog, не останавливая production-запись. - Перед cutover каждый приемник должен достичь apply lag менее 2 секунд и пройти проверку количества строк по диапазонам, checksums по chunks и выборочные запросы бизнес-инвариантов. - Версионированная shard map сначала атомарно переключит чтения, затем записи; устаревшие клиенты будут отклонены или перенаправлены, а не продолжат писать старому владельцу. - Я сохраню обратный change capture на 60 секунд, ограничу I/O миграции уровнем 25% мощности shard и удалю старые диапазоны только после окна rollback и финальной валидации.

Размещение заказа затрагивает данные inventory и payment на разных shards при 3 000 заказов в секунду; overselling запрещен, подтверждение платежа может занять 30 секунд, а держать распределенные locks во время внешних вызовов нельзя. Как вы реализуете cross-shard transaction?

Я использую локальные транзакции резервирования и надежную saga, а не буду держать двухфазный commit открытым во время платежного вызова. - Inventory shard атомарно уменьшит доступный остаток и создаст резервирование с TTL 2 минуты, используя order ID как idempotency key. - Та же локальная транзакция запишет outbox event; relay доставит его как минимум один раз, а payment shard выполнит дедупликацию по order ID перед созданием единственной попытки списания. - Успешный платеж в течение 30 секунд подтвердит резервирование, а отказ или истечение срока запустит идемпотентную компенсацию, которая вернет товар в остаток. - Я применю database 2PC только для коротких операций исключительно между базами с поддержкой durable prepare, если измеренное время locks остается ниже строгого порога, например 200 мс.

Таблица аудита PostgreSQL занимает 18 ТБ, принимает 12 000 вставок в секунду, растёт на 1,4 ТБ в месяц и хранит данные 13 месяцев; как вы спроектируете партиционирование по времени?

Я выберу партиционирование RANGE по event_time с месячными партициями, а затем проверю, остаётся ли месяц удобной единицей для запросов и хранения. - Declarative partitioning PostgreSQL даст 13 активных месячных дочерних таблиц и одну будущую, поэтому очистка превратится в DETACH PARTITION с последующим архивированием и DROP вместо огромного DELETE. - Я заранее создам партиции с точными полуоткрытыми границами, направлю некорректные timestamps в контролируемую DEFAULT-партицию и вынесу поздние данные в отдельное задание исправления. - В каждой дочерней таблице будет локальный B-tree по (tenant_id, event_time) для временных выборок арендатора и BRIN по event_time, только если физический порядок данных оправдывает его низкую стоимость хранения. - Дневные партиции уменьшат одну единицу обслуживания, но увеличат накладные расходы на relations, indexes, statistics и planning примерно с 14 активных партиций до 400.

PostgreSQL-база SaaS занимает 6 ТБ, обслуживает 8 000 QPS для 40 000 арендаторов, растёт на 500 ГБ в квартал и хранит данные семь лет; как применить list partitioning без ослабления изоляции арендаторов?

Я применю LIST partitioning только для небольшого числа классов размещения, а не создам отдельную партицию для каждого арендатора. - Таблица tenant_directory будет сопоставлять арендатора со стабильным классом shared_eu, shared_us, regulated или dedicated, а LIST-партиции закрепят известные границы размещения. - Каждый primary key и локальный index будет начинаться с tenant_id, а политики PostgreSQL RLS с доверенной настройкой арендатора на время транзакции защитят строки внутри общих партиций. - Крупных арендаторов я перенесу контролируемым копированием и переключением маршрута в выделенные партиции или базы; 40 000 дочерних таблиц сделают DDL, autovacuum, statistics и planning неуправляемыми. - Контролируемая DEFAULT-партиция поймает неописанные варианты размещения, но трафик приложения будет отклонён, если tenant_directory не содержит разрешённого маршрута.

Таблица приёма данных PostgreSQL занимает 4 ТБ, обрабатывает 30 000 записей в секунду, растёт на 220 ГБ в неделю и хранит данные 26 недель; решит ли hash partitioning одновременно распределение записи и очистку?

Hash partitioning распределит записи арендаторов, но усложнит недельную очистку, поэтому я сделаю верхний уровень RANGE по неделям и добавлю hash-подпартиции только при измеренном hotspot текущей недели. - Верхний уровень будет использовать RANGE по ingested_at, чтобы при достижении 26 недель отсоединять и удалять одну недельную партицию размером 220 ГБ. - Восемь HASH-остатков по tenant_id внутри недели распределят работу indexes и vacuum, но создадут около 216 активных конечных партиций и умножат обслуживание схемы. - Запросы должны содержать ingested_at для range pruning и tenant_id для hash pruning; запрос истории только по арендатору всё равно затронет все 26 недель. - Сначала я протестирую одну недельную партицию, поскольку PostgreSQL по-прежнему пишет через один основной storage stack, а hash-партиции сами не добавляют диски и не масштабируют насыщенный WAL path.

Таблица метрик PostgreSQL занимает 9 ТБ, содержит 36 месячных партиций, обслуживает 18 000 QPS, растёт на 300 ГБ в месяц и хранит данные три года, но запросы за семь дней сканируют все партиции; как восстановить pruning?

Я сделаю предикат непосредственно сопоставимым с ключом партиционирования и докажу pruning во время планирования и выполнения. - EXPLAIN (ANALYZE, BUFFERS) должен показать только одну или две текущие дочерние таблицы; Subplans Removed и узлы never executed отличат pruning во время выполнения от полного сканирования. - Выражения вроде date_trunc('day', recorded_at) = $1 или recorded_at::date = $1 я заменю полуоткрытыми границами recorded_at >= $1 AND recorded_at < $2 с совпадающими типами timestamptz. - PostgreSQL умеет отсекать параметризованные партиции при выполнении, но скрытый cast, volatile function, выражение вокруг partition key или отсутствие предиката по нему могут помешать ожидаемому исключению. - Pruning только выбирает дочерние таблицы, поэтому каждой оставшейся партиции всё равно нужны актуальная статистика и index под остальные фильтры, например (metric_id, recorded_at).

Историческая таблица PostgreSQL занимает 24 ТБ, обслуживает 3 500 QPS, прибавляет 4 ТБ в год и хранит данные пять лет; выбрать дневные, месячные или годовые партиции?

Я начну с месячных партиций, потому что примерно 60 активных дочерних таблиц соответствуют сроку хранения и не превращают каждую операцию обслуживания в многотерабайтное действие. - Дневное разбиение создаст около 1 825 дочерних таблиц ещё до indexes, увеличив catalog, память relcache, очередь объектов autovacuum, backup manifests и fan-out DDL. - Годовые партиции приблизятся к 4 или 5 ТБ каждая, поэтому validation при detach, перестроение indexes, восстановление vacuum и повтор архивации получат слишком большой blast radius. - Я воспроизведу реальную смесь запросов и сравню planning time, число затронутых партиций, locks и сквозной p95 для месячных и многолетних выборок до фиксации интервала. - Если один месяц не помещается в окно backup или обслуживания, я сокращу только эту границу и автоматизирую создание будущих таблиц, attachment indexes, ANALYZE и проверки retention.

Таблица заказов PostgreSQL занимает 7 ТБ, работает при 14 000 QPS, растёт на 180 ГБ в месяц, хранит данные шесть лет и разбита RANGE по created_at; как сохранить уникальность номера заказа и эффективность индексов?

Я не стану утверждать, что локальные indexes обеспечат глобальную уникальность order_number без ключа партиционирования. - PostgreSQL требует включать все столбцы ключа партиционирования в ограничение UNIQUE или PRIMARY KEY партиционированной таблицы, поэтому UNIQUE (order_number, created_at) не запрещает одинаковый номер в двух месяцах. - Если order_number обязан быть глобально уникальным, я зарезервирую его в небольшой непартиционированной таблице order_identity с UNIQUE (order_number), а строку заказа создам в той же транзакции. - Каждая дочерняя таблица получит только подтверждённые нагрузкой indexes, например (tenant_id, created_at DESC) INCLUDE (status, total) и partial index для открытых заказов, потому что каждый дополнительный B-tree нагружает 14 000 QPS и storage. - Новые партиции будут создаваться с совпадающими CHECK-границами и indexes до ATTACH PARTITION, а автоматизация проверит их через pg_indexes и реестр constraints.

Коммерческая база PostgreSQL занимает 12 ТБ, обрабатывает 22 000 OLTP QPS, растёт на 700 ГБ в квартал, хранит данные четыре года, а шестичасовой отчёт насыщает read replica; как изолировать reporting?

Я отделю резерв мощности для failover от reporting и перенесу шестичасовое сканирование в выделенную аналитическую копию. - Одна слабо нагруженная physical standby останется кандидатом на promotion, а reporting получит отдельный logical subscriber, warehouse или columnar store, рассчитанный на сканирования. - Добавление physical replicas не масштабирует writes, и каждая replica обязана воспроизводить тот же WAL; долгие standby-запросы могут отменяться из-за recovery conflicts либо при hot_standby_feedback удерживать мёртвые строки и увеличивать bloat на primary. - Logical replication или CDC опубликует нужные таблицы в reporting schema с индексами под отчёты и materialized aggregates, принимая измеримую свежесть, например пять минут. - Resource groups, statement_timeout, лимиты connections и запланированные refresh ограничат reporting, чтобы шквал повторов не занял storage bandwidth OLTP или резерв для failover.

Primary PostgreSQL на 10 ТБ выдерживает 16 000 QPS, создаёт 18 МБ WAL в секунду на пике, растёт на 250 ГБ в месяц и хранит данные пять лет; как рассчитать WAL, checkpoints и запас storage?

Я рассчитаю ёмкость по измеренным пиковым скоростям WAL и dirty pages, а затем зарезервирую место под вариативность checkpoints, replication retention и recovery operations. - При 18 МБ/с кластер создаёт около 16 ГБ WAL за 15 минут и 1,6 ТБ в сутки, поэтому pg_stat_wal, pg_stat_bgwriter и checkpoint logs должны подтвердить постоянную скорость и множитель всплеска. - Я начну тестирование с checkpoint_timeout 15 минут, checkpoint_completion_target около 0.9 и max_wal_size около 64 ГБ, затем настрою их по частоте checkpoints, fsync latency, recovery time и усилению full-page writes. - WAL storage получит низкую fsync latency и свободное место на несколько checkpoint cycles, а replication slots и archive backlog получат alerts по удержанным байтам, поскольку max_wal_size не является жёстким пределом диска. - Ёмкость данных учтёт рост таблиц, долю indexes, temporary files, пространство для vacuum rewrite, replicas, backups и запас при потере одного узла, а не только текущий heap на 10 ТБ.

Управляемый PostgreSQL хранит 32 ТБ, достигает 45 000 QPS, растёт на 55 процентов в год и обязан хранить данные семь лет; постройте трёхлетний capacity plan до достижения текущего предела 64 ТБ.

Я спрогнозирую каждый ресурс из драйверов нагрузки и задам migration triggers достаточно рано, чтобы начать работу до насыщения storage или throughput. - При сложном годовом росте 55 процентов объём 32 ТБ станет примерно 77 ТБ через два года и 119 ТБ через три ещё до indexes, temporary space, WAL, backups и копий replicas, поэтому предел 64 ТБ будет достигнут во втором году. - Я отдельно смоделирую reads, writes, rows, WAL bytes, working set, CPU, IOPS, throughput, connections и p99, потому что одни 45 000 QPS не показывают ограничивающий ресурс. - Ежеквартальные load tests с формой production-нагрузки включат пик трафика, обслуживание, догоняющую replica и потерю одного узла с целью ниже примерно 70 процентов устойчивого насыщения bottleneck. - Decision gate на 45 ТБ или при 12 месяцах прогнозного запаса запустит vertical migration, tiering хранения или sharding; read replicas появятся только если предел создают допускающие устаревание reads, а не writes или storage.

Платформа заказов Oracle хранит 30 ТБ, обслуживает 25 000 QPS, растёт на 3 ТБ в год и хранит данные десять лет; потратить бюджет на второй узел RAC или построить Data Guard в другом регионе?

Я выберу по целевому классу отказа: RAC добавляет локальную мощность и доступность instances, а Data Guard создаёт отдельную копию базы для отказа site и storage. - Два узла RAC могут сохранить services после отказа одного instance, но Cache Fusion и private interconnect не устраняют общие failure domains storage, cluster и региона. - Active Data Guard может разгрузить допустимые reads и поддерживать physical standby; synchronous Maximum Availability добавляет commit latency на расстоянии, а asynchronous transport оставляет измеримый RPO по redo lag. - Capacity tests должны доказать, что один оставшийся узел RAC выдержит критическую часть 25 000 QPS, а standby сможет принимать и применять пиковый redo при хранении прогнозных 60 ТБ за десять лет плюс indexes и recovery headroom. - Если нужны и локальная непрерывность, и региональное восстановление, RAC и Data Guard дополняют друг друга, поэтому я сравню их общие licenses и operations с более простой архитектурой single-instance primary и standby.

Вопросы на собеседовании: Администратор БД

100 реальных вопросов с образцовыми ответами и пояснениями для уровня Senior.

Смотреть пример резюме: Администратор БД →

Тренировка флешкарточками

Интервальное повторение · Hunter Pass

Вопросы

databasepostgresdesign

Я оставлю один лидер для записи, направлю на него чтения checkout, а followers использую для отчетности и изоляции нагрузки.

Я размещу один синхронный follower в другой зоне доступности относительно лидера и два асинхронных follower для отчетности, задав `synchronous_standby_names = 'FIRST 1 (ha1)'`.
Checkout будет работать с endpoint лидера через PgBouncer, а отчетность получит отдельный пул, маршрутизатор которого исключает follower при lag воспроизведения больше 30 секунд.
При 6 000 записей в секунду я измерю генерацию WAL и выделю хранилище как минимум на тройную пиковую пропускную способность WAL, а не буду считать, что followers увеличивают емкость записи.
Рост на 400 ГБ в месяц дает около 20 месяцев до достижения 20 ТБ, поэтому я назначу пересмотр архитектуры при 70% заполнения хранилища или 70% устойчивой загрузки I/O лидера.

Зачем это спрашивают: Интервьюер проверяет, разделяет ли кандидат полномочия записи, консистентность чтения, назначение реплик и измеримые пределы емкости.

transactionspostgresreplication

Я буду подтверждать commit после надежного сброса WAL на диск одной локальной standby и оставлю удаленную standby асинхронной.

Я задам `synchronous_commit = on` и `synchronous_standby_names = 'ANY 1 (az2a, az2b)'`, затем под нагрузкой проверю, укладывается ли commit p99 с дополнительным локальным RTT в бюджет приложения.
Я не включу удаленную standby с задержкой 75 мс в commit quorum, потому что это добавит как минимум один межрегиональный RTT и привяжет доступность записи к состоянию межрегиональной сети.
Я настрою alert при 5 секундах lag воспроизведения в удаленном регионе и сниму нагрузку от deployment или batch-задач до нарушения целевого RPO в 10 секунд.
Если обе локальные синхронные standby недоступны, я остановлю запись, а не стану незаметно переходить на асинхронные commits, потому что заявленный RPO внутри региона равен нулю.

Зачем это спрашивают: Сильный ответ превращает требования к надежности и задержке в явные настройки commit PostgreSQL и поведение в деградированном режиме.

postgresconfigavailability

Я использую quorum из трех участников etcd для выбора лидера и настрою Patroni так, чтобы он не продвигал отставшую реплику.

Я размещу по одному voter etcd и одному узлу PostgreSQL в каждой зоне доступности, потому что три voter сохраняют quorum после потери одной зоны, а два не сохраняют.
Я задам в Patroni `maximum_lag_on_failover: 67108864`, `synchronous_mode: true` и `synchronous_mode_strict: true`, чтобы запись останавливалась, если ни одна синхронная standby не может ее защитить.
Я установлю `ttl: 30`, `loop_wait: 10` и `retry_timeout: 10`, затем проверю, что p99 хранилища и сети с большим запасом укладываются в эти интервалы lease.
HAProxy будет направлять запись только на primary health endpoint Patroni, а fencing отзовет у старого лидера доступ клиентов и хранилища до того, как новый начнет принимать запись.

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

postgresreplicationdesign

Я подключу к primary две региональные relay standby и от каждой каскадно запитаю по три реплики отчетности.

Два независимых relay-потока ограничат число прямых sender на primary шестью вместо десяти и не сделают один удаленный relay единственным источником всей мощности отчетности.
Я выделю каждому relay более 180 МБ/с входящей и 540 МБ/с суммарной исходящей пропускной способности, плюс I/O replay и запас 30%, потому что он должен воспроизводить WAL и одновременно обслуживать три downstream-потока.
Мониторинг будет измерять задержку воспроизведения от primary до реплики отчетности целиком, подавать alert на 30 секундах и исключать реплику из маршрутизации отчетов на пределе свежести 45 секунд.
Я применю physical replication slots с `max_slot_wal_keep_size`, рассчитанным на окно переподключения, и отработаю переключение downstream-реплик после смены timeline у relay.

Зачем это спрашивают: Интервьюер проверяет, снижает ли каскадная репликация fan-out источника без сокрытия накопленного lag и требований к мощности relay.

queriespostgressharding

Я хеширую стабильный device ID в большое число логических buckets и распределю эти buckets по физическим shards.

Я начну с 4 096 логических buckets на 16 shards, чтобы при добавлении еще 16 shards переместить примерно половину buckets, а не перераспределять все 60 ТБ.
Составной ключ `(device_bucket, device_id, event_time)` сохранит запрос одного устройства за 24 часа на одном shard и равномерно распределит разные устройства.
При 120 000 вставок в секунду начальное среднее составит 7 500 вставок на shard, но я рассчитаю каждый shard как минимум на двойную нагрузку и буду отслеживать p99 по buckets, а не только среднее.
Хеширование ухудшает общие временные range scans по всем устройствам, поэтому такие агрегаты будут поступать через CDC в аналитическое хранилище без fan-out по всем OLTP shards.

Зачем это спрашивают: Сильный ответ балансирует равномерность записи, локальность запросов, запас мощности и будущее перемещение shards.

databasetransactionssharding

Я использую явные диапазоны tenant ID, но заранее выделю крупным tenants отдельные диапазоны, прежде чем они перегрузят общий shard.

Сервис shard map будет маршрутизировать диапазоны tenants, а каждый из пяти tenants с долей больше 8% получит собственный shard с независимым пределом роста и записи.
Общие диапазоны будут рассчитаны на 1 ТБ или 2 000 записей в секунду с триггером разделения при 70% заполнения хранилища или 70% устойчивой мощности записи.
Счета и платежи одного tenant останутся транзакциями одного shard, потому что tenant ID входит во все primary и foreign keys.
Размещение диапазонов упрощает экспорт tenant и соблюдение residency, но последовательный глобальный tenant ID создает горячий растущий край, поэтому новых tenants я буду распределять по заранее созданным диапазонам, а не добавлять в один shard.

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

shardingdesign

Я разделю keyspace Vitess по хешированному merchant ID и сделаю запросы в пределах merchant быстрым путем одного shard.

Я начну с 32 shards, каждый с одним primary и двумя replica tablets, что до учета перекоса merchants дает в среднем около 470 записей в секунду на shard.
VTGate будет маршрутизировать запросы через VSchema с консистентным vindex по merchant ID, а поиск по всему каталогу пойдет в отдельный поисковый индекс вместо scatter по 32 shards.
Чтения, допускающие 5 секунд устаревания, будут использовать тип tablet `replica`, а проверка корзины и запись будут идти на `primary` для сохранения read-after-write.
Online resharding будет использовать VReplication для копирования и потока изменений, `SwitchReads` перед `SwitchWrites` и обратную репликацию на время окна rollback.

Зачем это спрашивают: Интервьюер оценивает конкретную маршрутизацию Vitess, роли tablets, локальность нагрузки и механику online resharding.

consistencyserializationtransactions

Я использую отдельные кластеры CockroachDB для ЕС и Сингапура, потому что строгая резидентность важнее удобства одного глобального кластера.

Кластер ЕС разместит минимум три voters в одобренных зонах доступности ЕС, а кластер Сингапура использует три локальные зоны, поэтому каждый переживет потерю одной зоны без вывоза replicas.
Региональный каталог tenants хранит идентификационные metadata рядом с клиентом, а глобальный router видит только opaque route token и регион назначения; внутри выбранного кластера каждый primary key начинается с tenant ID.
CockroachDB сохраняет serializable transactions и локальные leaseholders внутри каждого кластера, а цель p99 20 мс я проверю отдельно во Франкфурте и Сингапуре при заданных 8 000 записей в секунду.
Межрегиональные SQL-транзакции намеренно недоступны; в глобальную аналитику попадают только одобренные агрегированные или токенизированные данные через CDC, что меняет простоту compliance на эксплуатацию двух кластеров.

Зачем это спрашивают: Сильный ответ явно задает границу резидентности и сопоставляет локальную задержку транзакций с ценой эксплуатации двух кластеров и отсутствием межрегиональных транзакций.

shardingvalidationrollback

Я проведу resharding как онлайн-передачу владения с bulk copy, упорядоченным change capture, валидацией и версионированной маршрутизацией.

Я скопирую snapshots диапазонов с ограничением 400 МБ/с на исходный shard и буду передавать последующие изменения от надежно сохраненной позиции WAL или binlog, не останавливая production-запись.
Перед cutover каждый приемник должен достичь apply lag менее 2 секунд и пройти проверку количества строк по диапазонам, checksums по chunks и выборочные запросы бизнес-инвариантов.
Версионированная shard map сначала атомарно переключит чтения, затем записи; устаревшие клиенты будут отклонены или перенаправлены, а не продолжат писать старому владельцу.
Я сохраню обратный change capture на 60 секунд, ограничу I/O миграции уровнем 25% мощности shard и удалю старые диапазоны только после окна rollback и финальной валидации.

Зачем это спрашивают: Интервьюер проверяет, сохраняет ли resharding порядок записей и корректность маршрутизации при контроле валидации, rollback и конкуренции за ресурсы.

transactionsshardingdistributed

Я использую локальные транзакции резервирования и надежную saga, а не буду держать двухфазный commit открытым во время платежного вызова.

Inventory shard атомарно уменьшит доступный остаток и создаст резервирование с TTL 2 минуты, используя order ID как idempotency key.
Та же локальная транзакция запишет outbox event; relay доставит его как минимум один раз, а payment shard выполнит дедупликацию по order ID перед созданием единственной попытки списания.
Успешный платеж в течение 30 секунд подтвердит резервирование, а отказ или истечение срока запустит идемпотентную компенсацию, которая вернет товар в остаток.
Я применю database 2PC только для коротких операций исключительно между базами с поддержкой durable prepare, если измеренное время locks остается ниже строгого порога, например 200 мс.

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

postgrespartitioningdesign

Я выберу партиционирование RANGE по event_time с месячными партициями, а затем проверю, остаётся ли месяц удобной единицей для запросов и хранения.

Declarative partitioning PostgreSQL даст 13 активных месячных дочерних таблиц и одну будущую, поэтому очистка превратится в DETACH PARTITION с последующим архивированием и DROP вместо огромного DELETE.
Я заранее создам партиции с точными полуоткрытыми границами, направлю некорректные timestamps в контролируемую DEFAULT-партицию и вынесу поздние данные в отдельное задание исправления.
В каждой дочерней таблице будет локальный B-tree по (tenant_id, event_time) для временных выборок арендатора и BRIN по event_time, только если физический порядок данных оправдывает его низкую стоимость хранения.
Дневные партиции уменьшат одну единицу обслуживания, но увеличат накладные расходы на relations, indexes, statistics и planning примерно с 14 активных партиций до 400.

Зачем это спрашивают: Интервьюер оценивает, соответствует ли интервал партиций измеренным срокам хранения, форме запросов и размеру операционной единицы.

databasepostgrespartitioning

Я применю LIST partitioning только для небольшого числа классов размещения, а не создам отдельную партицию для каждого арендатора.

Таблица tenant_directory будет сопоставлять арендатора со стабильным классом shared_eu, shared_us, regulated или dedicated, а LIST-партиции закрепят известные границы размещения.
Каждый primary key и локальный index будет начинаться с tenant_id, а политики PostgreSQL RLS с доверенной настройкой арендатора на время транзакции защитят строки внутри общих партиций.
Крупных арендаторов я перенесу контролируемым копированием и переключением маршрута в выделенные партиции или базы; 40 000 дочерних таблиц сделают DDL, autovacuum, statistics и planning неуправляемыми.
Контролируемая DEFAULT-партиция поймает неописанные варианты размещения, но трафик приложения будет отклонён, если tenant_directory не содержит разрешённого маршрута.

Зачем это спрашивают: Сильный ответ отделяет физическое размещение от авторизации на уровне строк и не допускает метаданные масштаба одной партиции на арендатора.

postgrespartitioningdistributions

Hash partitioning распределит записи арендаторов, но усложнит недельную очистку, поэтому я сделаю верхний уровень RANGE по неделям и добавлю hash-подпартиции только при измеренном hotspot текущей недели.

Верхний уровень будет использовать RANGE по ingested_at, чтобы при достижении 26 недель отсоединять и удалять одну недельную партицию размером 220 ГБ.
Восемь HASH-остатков по tenant_id внутри недели распределят работу indexes и vacuum, но создадут около 216 активных конечных партиций и умножат обслуживание схемы.
Запросы должны содержать ingested_at для range pruning и tenant_id для hash pruning; запрос истории только по арендатору всё равно затронет все 26 недель.
Сначала я протестирую одну недельную партицию, поскольку PostgreSQL по-прежнему пишет через один основной storage stack, а hash-партиции сами не добавляют диски и не масштабируют насыщенный WAL path.

Зачем это спрашивают: Интервьюер проверяет, сочетает ли кандидат методы партиционирования только тогда, когда жизненный цикл и измеренный hotspot оправдывают дополнительные объекты.

postgresqueriespartitioning

Я сделаю предикат непосредственно сопоставимым с ключом партиционирования и докажу pruning во время планирования и выполнения.

EXPLAIN (ANALYZE, BUFFERS) должен показать только одну или две текущие дочерние таблицы; Subplans Removed и узлы never executed отличат pruning во время выполнения от полного сканирования.
Выражения вроде date_trunc('day', recorded_at) = $1 или recorded_at::date = $1 я заменю полуоткрытыми границами recorded_at >= $1 AND recorded_at < $2 с совпадающими типами timestamptz.
PostgreSQL умеет отсекать параметризованные партиции при выполнении, но скрытый cast, volatile function, выражение вокруг partition key или отсутствие предиката по нему могут помешать ожидаемому исключению.
Pruning только выбирает дочерние таблицы, поэтому каждой оставшейся партиции всё равно нужны актуальная статистика и index под остальные фильтры, например (metric_id, recorded_at).

Зачем это спрашивают: Интервьюер оценивает, различает ли кандидат partition pruning и индексный доступ к строкам и умеет ли проверить оба механизма по реальному плану.

postgrespartitioning

Я начну с месячных партиций, потому что примерно 60 активных дочерних таблиц соответствуют сроку хранения и не превращают каждую операцию обслуживания в многотерабайтное действие.

Дневное разбиение создаст около 1 825 дочерних таблиц ещё до indexes, увеличив catalog, память relcache, очередь объектов autovacuum, backup manifests и fan-out DDL.
Годовые партиции приблизятся к 4 или 5 ТБ каждая, поэтому validation при detach, перестроение indexes, восстановление vacuum и повтор архивации получат слишком большой blast radius.
Я воспроизведу реальную смесь запросов и сравню planning time, число затронутых партиций, locks и сквозной p95 для месячных и многолетних выборок до фиксации интервала.
Если один месяц не помещается в окно backup или обслуживания, я сокращу только эту границу и автоматизирую создание будущих таблиц, attachment indexes, ANALYZE и проверки retention.

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

indexespostgrespartitioning

Я не стану утверждать, что локальные indexes обеспечат глобальную уникальность order_number без ключа партиционирования.

PostgreSQL требует включать все столбцы ключа партиционирования в ограничение UNIQUE или PRIMARY KEY партиционированной таблицы, поэтому UNIQUE (order_number, created_at) не запрещает одинаковый номер в двух месяцах.
Если order_number обязан быть глобально уникальным, я зарезервирую его в небольшой непартиционированной таблице order_identity с UNIQUE (order_number), а строку заказа создам в той же транзакции.
Каждая дочерняя таблица получит только подтверждённые нагрузкой indexes, например (tenant_id, created_at DESC) INCLUDE (status, total) и partial index для открытых заказов, потому что каждый дополнительный B-tree нагружает 14 000 QPS и storage.
Новые партиции будут создаваться с совпадающими CHECK-границами и indexes до ATTACH PARTITION, а автоматизация проверит их через pg_indexes и реестр constraints.

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

databasepostgresreplication

Я отделю резерв мощности для failover от reporting и перенесу шестичасовое сканирование в выделенную аналитическую копию.

Одна слабо нагруженная physical standby останется кандидатом на promotion, а reporting получит отдельный logical subscriber, warehouse или columnar store, рассчитанный на сканирования.
Добавление physical replicas не масштабирует writes, и каждая replica обязана воспроизводить тот же WAL; долгие standby-запросы могут отменяться из-за recovery conflicts либо при hot_standby_feedback удерживать мёртвые строки и увеличивать bloat на primary.
Logical replication или CDC опубликует нужные таблицы в reporting schema с индексами под отчёты и materialized aggregates, принимая измеримую свежесть, например пять минут.
Resource groups, statement_timeout, лимиты connections и запланированные refresh ограничат reporting, чтобы шквал повторов не занял storage bandwidth OLTP или резерв для failover.

Зачем это спрашивают: Интервьюер оценивает, учитывает ли масштабирование чтения WAL replay, задержку согласованности и разные роли HA и аналитики.

postgres

Я рассчитаю ёмкость по измеренным пиковым скоростям WAL и dirty pages, а затем зарезервирую место под вариативность checkpoints, replication retention и recovery operations.

При 18 МБ/с кластер создаёт около 16 ГБ WAL за 15 минут и 1,6 ТБ в сутки, поэтому pg_stat_wal, pg_stat_bgwriter и checkpoint logs должны подтвердить постоянную скорость и множитель всплеска.
Я начну тестирование с checkpoint_timeout 15 минут, checkpoint_completion_target около 0.9 и max_wal_size около 64 ГБ, затем настрою их по частоте checkpoints, fsync latency, recovery time и усилению full-page writes.
WAL storage получит низкую fsync latency и свободное место на несколько checkpoint cycles, а replication slots и archive backlog получат alerts по удержанным байтам, поскольку max_wal_size не является жёстким пределом диска.
Ёмкость данных учтёт рост таблиц, долю indexes, temporary files, пространство для vacuum rewrite, replicas, backups и запас при потере одного узла, а не только текущий heap на 10 ТБ.

Зачем это спрашивают: Сильный ответ превращает скорость WAL в конкретный расчёт и учитывает, что checkpoints, slots и обслуживание могут превысить номинальный бюджет.

postgrescapacity

Я спрогнозирую каждый ресурс из драйверов нагрузки и задам migration triggers достаточно рано, чтобы начать работу до насыщения storage или throughput.

При сложном годовом росте 55 процентов объём 32 ТБ станет примерно 77 ТБ через два года и 119 ТБ через три ещё до indexes, temporary space, WAL, backups и копий replicas, поэтому предел 64 ТБ будет достигнут во втором году.
Я отдельно смоделирую reads, writes, rows, WAL bytes, working set, CPU, IOPS, throughput, connections и p99, потому что одни 45 000 QPS не показывают ограничивающий ресурс.
Ежеквартальные load tests с формой production-нагрузки включат пик трафика, обслуживание, догоняющую replica и потерю одного узла с целью ниже примерно 70 процентов устойчивого насыщения bottleneck.
Decision gate на 45 ТБ или при 12 месяцах прогнозного запаса запустит vertical migration, tiering хранения или sharding; read replicas появятся только если предел создают допускающие устаревание reads, а не writes или storage.

Зачем это спрашивают: Интервьюер оценивает расчёт сложного роста, прогнозирование отдельных bottlenecks, резерв на отказ и пороги с достаточным сроком выполнения.

Я выберу по целевому классу отказа: RAC добавляет локальную мощность и доступность instances, а Data Guard создаёт отдельную копию базы для отказа site и storage.

Два узла RAC могут сохранить services после отказа одного instance, но Cache Fusion и private interconnect не устраняют общие failure domains storage, cluster и региона.
Active Data Guard может разгрузить допустимые reads и поддерживать physical standby; synchronous Maximum Availability добавляет commit latency на расстоянии, а asynchronous transport оставляет измеримый RPO по redo lag.
Capacity tests должны доказать, что один оставшийся узел RAC выдержит критическую часть 25 000 QPS, а standby сможет принимать и применять пиковый redo при хранении прогнозных 60 ТБ за десять лет плюс indexes и recovery headroom.
Если нужны и локальная непрерывность, и региональное восстановление, RAC и Data Guard дополняют друг друга, поэтому я сравню их общие licenses и operations с более простой архитектурой single-instance primary и standby.

Зачем это спрашивают: Интервьюер проверяет, различает ли кандидат кластер с общей базой и реплицируемое disaster recovery и умеет ли рассчитать оба варианта мощности.

Закрытые вопросы

21
Таблица events на 400 млн строк обслуживает 180 QPS запроса SELECT id FROM events WHERE tenant_id = $1 AND status = 'open' AND created_at >= $2 ORDER BY created_at DESC; EXPLAIN ANALYZE показывает Bitmap Heap Scan с чтением 42 000 буферов и последующий Sort, общее время 310 мс. Какой составной индекс вы проверите и почему выберете такой порядок колонок?
indexesschemadata-structures
22
В таблице orders на 800 млн строк 98 процентов заказов архивные, а 220 QPS выполняют SELECT id, created_at FROM orders WHERE tenant_id = $1 AND archived_at IS NULL ORDER BY created_at DESC LIMIT 50; EXPLAIN ANALYZE показывает Index Scan, который отбрасывает 38 000 архивных строк и занимает 190 мс. Используете ли вы частичный индекс?
indexesfundamentals
23
Таблица invoices на 120 млн строк обслуживает 300 QPS запроса SELECT id, total, currency FROM invoices WHERE account_id = $1 AND issued_at >= $2; EXPLAIN ANALYZE использует Index Scan по (account_id, issued_at), но делает 8 400 обращений к heap, читает 9 100 буферов и занимает 95 мс. Как вы оцените покрывающий индекс?
decision-makingindexesdata-structures
24
В customers 20 млн строк, а в orders 600 млн; запрос с частотой 12 QPS соединяет заказы одного tenant за последние сутки с customers и возвращает 70 000 строк, но EXPLAIN ANALYZE оценил 300 строк и выбрал Nested Loop с 70 000 обращений к индексу customers, 180 000 буферов и временем 1,8 секунды. Как вы выберете между nested loop и hash join?
indexesjoinsqueries
25
Таблица events на 300 млн строк получает 15 QPS запроса SELECT count(*) FROM events WHERE tenant_id = 42 AND event_type = 'purchase'; tenant 42 создает большинство покупок, но EXPLAIN ANALYZE оценивает 500 строк, получает 8 млн, а выбранный Bitmap Heap Scan читает 620 000 буферов. Как вы исправите оценку кардинальности?
estimationdata-structures
26
Таблица jobs на 1 млрд строк обслуживает 80 QPS запроса SELECT id FROM jobs WHERE queue_id = $1 AND state = 'ready' ORDER BY priority DESC, created_at ASC LIMIT 100; EXPLAIN ANALYZE читает 1,5 млн кандидатов через Parallel Bitmap Heap Scan, затем выполняет top-N heapsort и возвращает результат за 450 мс. Как вы устраните работу сортировки?
data-structures
27
Таблица users на 90 млн строк получает 120 QPS запроса SELECT id FROM users WHERE tenant_id = $1 AND lower(email) = lower($2); EXPLAIN ANALYZE показывает Parallel Seq Scan, который отбрасывает по 29 млн строк на worker, читает 410 000 буферов и занимает 680 мс. Какой индекс по выражению вы предложите?
indexes
28
Таблица documents на 250 млн строк обслуживает 40 QPS запроса SELECT id FROM documents WHERE metadata @> '{"type":"invoice","region":"eu"}'; EXPLAIN ANALYZE показывает Parallel Seq Scan с чтением 1,2 млн буферов и временем 2,4 секунды. Как вы выберете и проверите JSONB GIN индекс?
indexesvalidation
29
Append-only таблица telemetry содержит 6 млрд строк, физически упорядоченных по observed_at, и получает 4 QPS подсчета за семидневный диапазон; EXPLAIN ANALYZE использует Parallel Seq Scan по 14 млн буферов и занимает 11 секунд, а полный B-tree занял бы около 180 ГБ. Используете ли вы BRIN?
30
Таблица payments на 1 млрд строк выдерживает 25 000 записей в секунду, а запрос с частотой 2 QPS фильтрует merchant_id, state и settled_at; EXPLAIN ANALYZE показывает Parallel Seq Scan за 900 мс, а предлагаемый B-tree (merchant_id, state, settled_at) оценивается в 180 ГБ. Как вы докажете, что добавление индекса безопасно и оправданно?
estimationqueries
31
Спроектируйте DB2 11.5 HADR для банковской базы объемом 18 ТБ с 7 000 транзакций в секунду, локальными primary и standby с задержкой 2 мс и удаленным standby с задержкой 60 мс; локальные цели равны RTO 90 секунд и RPO ноль, а региональный RPO составляет 30 секунд.
databasetransactionsdesign
32
Как настроить синхронную кворумную репликацию PostgreSQL 16 для платежной БД объемом 20 ТБ в трех зонах доступности, которая выдерживает 15000 записей в секунду при RTO 90 секунд и RPO ноль?
databasepostgresreplication
33
Спроектируйте межрегиональное аварийное восстановление для PostgreSQL 16 объемом 40 ТБ с заказами, развернутой в трех зонах доступности каждого из двух регионов и создающей 25 МБ/с WAL, при RTO 15 минут и RPO 2 минуты.
databasepostgresdesign
34
Как спроектировать MySQL 8.4 InnoDB Cluster для клиентской БД объемом 8 ТБ в трех зонах доступности с 6000 транзакций в секунду, RTO 2 минуты и RPO ноль?
databasetransactionsdesign
35
Спроектируйте доступность и аварийное восстановление Oracle 23ai для расчетной БД объемом 60 ТБ, создающей 120 МБ/с redo, с RAC в двух зонах доступности основного региона и standby-регионом в 900 км, при RTO 5 минут и RPO 30 секунд.
designavailabilitydatabase
36
Как спроектировать цепочку PITR для аналитической PostgreSQL 16 объемом 25 ТБ в трех зонах доступности, создающей 80 МБ/с WAL, при RTO 4 часа и RPO 5 минут?
databasepostgresdesign
37
Спроектируйте восстановление на момент времени для MySQL 8.4 объемом 12 ТБ в трех зонах доступности, создающей 40 МБ/с binlog, при пропускной способности восстановления 1,5 ГБ/с, RTO 3 часа и RPO 1 минута.
designavailabilitydatabase
38
Как задать расписание полных и инкрементальных копий для хранилища Oracle 19c объемом 100 ТБ в двух зонах доступности с резервным регионом, эффективной скоростью восстановления 2 ГБ/с, RTO 8 часов и RPO 15 минут?
backupsavailabilitywarehouse
39
Спроектируйте неизменяемые offsite-копии для медицинской PostgreSQL 16 объемом 30 ТБ в трех зонах доступности и втором регионе, создающей 30 МБ/с WAL, при RTO 6 часов и RPO 15 минут.
designbackupsavailability
40
Сервис MySQL 8.4 объемом 48 ТБ работает в трех зонах доступности с резервным регионом, создает 50 МБ/с binlog и требует RTO 6 часов и RPO 5 минут. Как рассчитать ресурсы восстановления и спроектировать проверочные учения?
designcapacityavailability
41
У PostgreSQL-сервиса 120 экземпляров приложения, каждый настроен на 20 соединений, в базе max_connections = 500, а транзакции обычно завершаются за 30 мс. Какой режим PgBouncer вы выберете, transaction или session, и как его настроите?
databasetransactionspostgres
42
Восемьдесят экземпляров приложения создают 16 000 транзакций PostgreSQL в секунду, среднее время в базе составляет 40 мс, max_connections равен 800, а нагрузочные тесты показывают рост задержки после 480 активных запросов. Как вы рассчитаете размеры пулов?
databasetransactionspostgres
43
У MySQL-платформы 60 экземпляров приложения, 12 000 чтений и 1 500 записей в секунду, а три реплики могут отставать на две секунды. Как настроить read routing в ProxySQL, не нарушив read-after-write consistency при оформлении заказа?
consistencyproxyreplication
44
При развёртывании приложение может автоматически масштабироваться с 40 до 300 экземпляров за две минуты, каждый запрашивает 25 соединений, но PostgreSQL max_connections равен 1 200. Как защититься от connection storm и зависших запросов на уровне дизайна?
designscalingpostgres
45
Нужно определить права PostgreSQL для 35 сервисов в 600 tenant-схемах с раздельным доступом runtime, миграций, отчётности, backup и мониторинга. Какую ролевую модель вы реализуете?
postgresschemamigrations
46
Двести сервисов используют PostgreSQL, compliance требует менять учётные данные приложений за 24 часа и завершать доступ людей через 15 минут, а пулы могут держать соединения час. Как организовать выдачу и ротацию credentials?
postgres
47
Общий кластер PostgreSQL хранит данные 20 000 tenants в общих таблицах и использует PgBouncer в режиме transaction pooling. Как обеспечить tenant isolation с помощью row-level security?
transactionspostgres
48
У регулируемой платформы 150 сервисов, для всего клиентского и replication-трафика PostgreSQL требуется проверенный TLS, для административных путей mutual authentication, а сертификаты нужно менять каждые 60 дней. Что вы настроите?
postgresreplicationauth
49
Вы обслуживаете базу объёмом 40 ТБ с семилетним хранением зашифрованных backups, ежегодной ротацией master key и требованием заменить скомпрометированные data keys за 24 часа. Как спроектировать шифрование и интеграцию с KMS?
designbackupsdatabase
50
Парк PostgreSQL выполняет 25 000 запросов в секунду, доступ privileged-пользователей и обращения к регулируемым данным нужно хранить семь лет, а аудит должен оставаться доступным для поиска 90 дней. Как спроектировать audit logging без бесполезного потока логов?
postgresdesignlogging
51
Физическая реплика PostgreSQL 16 для базы заказов на 8 ТБ увеличивает отставание с 3 секунд и 1,2 ГБ до 180 секунд и 96 ГБ, пока primary генерирует 70 МБ/с WAL при 20 000 QPS, из-за чего отчеты устаревают. Как вы отреагируете?
databasepostgresreplication
52
Реплика MySQL 8.4 для чтений checkout увеличивает отставание с 2 до 2 400 секунд после bulk update 400 миллионов строк на primary объемом 6 ТБ при 3 500 транзакций в секунду, а `Relay_Log_Space` достигает 180 ГБ. Что вы сделаете?
transactionsreplication
53
Standby Oracle 19c Data Guard для расчетной базы на 25 ТБ получает 90 МБ/с redo с transport lag 2 секунды, но apply lag вырастает до 18 минут, и отчеты standby нарушают цель свежести 60 секунд. Как вы проведете диагностику и восстановление?
database
54
Standby DB2 11.5 HADR для банковской базы на 12 ТБ при 6 000 транзакций в секунду выходит из состояния PEER, переходит в REMOTE_CATCHUP, а log gap растет с 500 МБ до 85 ГБ за 22 минуты при региональном RPO 30 секунд. Как вы поступите?
databasetransactionssoft-skills
55
Логический subscriber PostgreSQL 16 для billing-аналитики отстает на 75 минут, пока publisher обрабатывает 9 000 записей в секунду, replication slot удерживает 420 ГБ WAL, а volume publisher заполнен на 88 процентов. Как вы отреагируете на инцидент?
postgresreplicationincidents
56
База checkout на PostgreSQL 16 с `max_connections = 1200` становится полностью недоступной, когда deploy создает 40 000 попыток подключения в секунду, CPU достигает 100 процентов, а успешность API падает с 99,95 до 0 процентов. Опишите по минутам первые 20 минут.
databasepostgresapi
57
После сбоя координатора база платежей PostgreSQL 16 содержит 37 prepared transactions на общую сумму 12,4 миллиона долларов, старейшей 46 минут, а их locks блокируют 620 checkout-сессий. Как вы безопасно разрешите их?
databasetransactionspostgres
58
Primary PostgreSQL 16 на storage AWS gp3 падает с 8 000 до 600 транзакций в секунду, когда задержка записи растет с 2 до 85 мс, `VolumeQueueLength` достигает 140, а checkout p99 превышает 12 секунд. Как вы отреагируете на отказ из-за задержки storage?
transactionspostgreslatency
59
После падения хоста перезапускается primary MySQL 8.4 объемом 6 ТБ, который обслуживал 3 000 транзакций в секунду; checkout недоступен уже 14 минут, error log показывает InnoDB crash recovery на 62 процентах, а последний checkpoint отстает на 18 ГБ redo. Что вы сделаете?
transactions
60
Amazon RDS for PostgreSQL 16 Multi-AZ для checkout достигает 99 процентов CPU, 4 700 из 5 000 соединений, commit latency 5 секунд и replay lag standby 70 секунд при 18 000 QPS, а оператор предлагает немедленный failover. Каково ваше решение?
databasepostgreslatency
61
В 14:05 один checkout-запрос PostgreSQL 16 замедлился с 90 мс до 4,8 секунды и поднял p99 endpoint с 180 мс до 2,6 секунды при 3 200 QPS. Форма плана не изменилась, но Nested Loop теперь делает 1,9 млн проходов внутреннего узла и читает 14 ГБ вместо получения страниц из cache. Как диагностировать и устранить этот production-инцидент с медленным запросом?
queriespostgrescaching
62
После `ANALYZE` в PostgreSQL 16 подготовленный запрос истории заказов для 40 000 tenants сменил Index Scan за 35 мс на generic Parallel Seq Scan за 3,4 секунды; один tenant владеет 48 процентами из 900 млн строк, а p99 API достиг 5 секунд. Как диагностировать регрессию плана из-за перекоса?
indexesqueriespostgres
63
Часовой settlement-запрос PostgreSQL 16 по 620 млн строк замедлился с 70 секунд до 19 минут, записал 480 ГБ временных файлов, насытил том на 1,5 ГБ/с и задержал платежи на 24 минуты; Sort сообщает `external merge Disk: 96 GB`, а Hash сообщает 128 batches. Что вы сделаете?
queriespostgresbatch
64
Через 10 минут после deployment 2026.07.16 скорость записи checkout в PostgreSQL 16 упала с 2 800 до 300 TPS, 640 сессий ожидали `Lock:transactionid`, а одна транзакция миграции блокировала строку заказа 11 минут. Как распутать цепочку без повреждения заказов?
transactionspostgresmigrations
65
Сервис inventory на PostgreSQL 16 внезапно регистрирует 840 deadlocks в минуту при 6 500 транзакциях в секунду, прерывает 14 процентов checkout, а существующие deadlock reports показывают product IDs 91 затем 37 в одном пути и 37 затем 91 в другом. Как локализовать и устранить инцидент?
transactionspostgreslocking
66
`ALTER TABLE` в MySQL 8.4 для таблицы orders размером 1,2 ТБ ожидал metadata lock 7 минут, поставил в очередь 2 300 сессий checkout, снизил throughput с 4 500 до 40 TPS и вызвал outage на 12 минут. Как восстановить работу и предотвратить повтор?
sessionsthroughputdata-structures
67
В PostgreSQL 16 соединение находится idle in transaction 31 час с фиксированным `backend_xmin`, autovacuum не может удалить 420 млн dead tuples из таблицы events размером 2,8 ТБ, storage вырос на 780 ГБ, а p99 чтения поднялся со 120 мс до 1,9 секунды. Как восстановить систему?
transactionspostgres
68
В двухузловом платежном кластере Oracle 19c RAC при 18 000 TPS commit p99 вырос с 12 до 380 мс, global cache waits заняли 62 процента DB time, а AWR показывает `gc current block busy` на одном index leaf block размером 8 КБ с 48 000 ожиданий в секунду. Как устранить инцидент?
soft-skillsincidentsindexes
69
После обновления статистики в SQL Server 2022 и переключения PARAMETER_SNIFFING с OFF на ON один invoice-запрос поднял CPU хоста с 22% до 78%, замедлился с 40 мс до 2,1 секунды, а p99 API достиг 3,8 секунды при 900 QPS. Как безопасно диагностировать и откатить регрессию?
sqlqueriesapi
70
На hot standby PostgreSQL 16 27 из 30 ночных отчетов были отменены с `conflict with recovery` после 18 минут работы, replay lag достиг 95 секунд при цели 30 секунд, а прежняя проверка `hot_standby_feedback` добавила 260 ГБ bloat в primary размером 9 ТБ. Что вы сделаете сейчас?
postgres
71
Primary PostgreSQL 16 заполнил 96% тома на 2 ТБ, потому что неактивный logical replication slot удерживает 310 ГБ WAL, а WAL растет на 42 ГБ в час; записи остановятся примерно через два часа. Как вы отреагируете?
postgresreplication
72
Tablespace orders в PostgreSQL заполнен на 98% на томе 4 ТБ, свободно 82 ГБ, рост составляет 55 ГБ в день; ошибка выделения места остановит вставки checkout в течение 36 часов. Что вы сделаете?
postgres
73
После кампании, обновившей 1,6 миллиарда строк в PostgreSQL 15, таблица customer_events размером 2,4 ТБ содержит 900 ГБ dead tuples, ее основной index вырос с 480 до 910 ГБ, а p99 запросов увеличился со 180 мс до 2,8 с. Как вы восстановите систему?
indexesqueriespostgres
74
Восемьдесят reporting sessions PostgreSQL запускают hash aggregates, temporary files растут на 25 ГБ в минуту, а temp volume на 500 ГБ достигает 99% за 18 минут, вызывая сбои OLTP-запросов. Как вы стабилизируете базу?
databasepostgresqueries
75
В PostgreSQL 14 возраст самой старой незамороженной транзакции составляет 2,05 миллиарда и растет на 140 миллионов ID в день, а 19-часовая транзакция мешает vacuum; до риска принудительной остановки примерно 17 часов. Что вы сделаете?
transactionspostgres
76
В кластере MySQL 8.0 InnoDB history list length достиг 85 миллионов, undo занимает 1,3 ТБ и растет на 65 ГБ в час, а одна 14-часовая транзакция удерживает старый read view при p99 записи 4 секунды. Как вы отреагируете?
transactions
77
Production-база Oracle 19c заполнила FRA размером 18 ТБ на 99%, создает 180 ГБ archived redo в час, Data Guard отстает на 25 минут, а приложения начинают получать ORA-00257. Как вы будете руководить восстановлением?
database
78
OLTP-база DB2 11.5 израсходовала 39 из 40 активных log files по 1 ГБ, появились ошибки SQL0964C, а трехчасовая batch transaction изменила 1,4 ТБ без commit. Что вы сделаете?
databasetransactionsbatch
79
Checksums PostgreSQL 16 обнаружили 14 поврежденных pages по 8 КБ в платежном кластере на 6 ТБ, ошибки чтения затрагивают 0,3% запросов, а replica может иметь тот же сбой хранилища. Как вы отреагируете?
postgresreplication
80
Credential приложения PostgreSQL с правами INSERT, UPDATE, DELETE и ограниченным DDL на 40 production-таблиц попал в CI logs на 47 минут; его все еще используют 12 pods, а audit logs показывают 2,3 миллиона чтений и восемь неудачных попыток DDL. Как локализовать инцидент без остановки всего production?
postgres
81
В 02:10 последняя резервная копия pgBackRest объемом 18 ТБ не проходит проверку во время сбоя production, а RTO сервиса равен четырем часам. Как вы проведете восстановление под давлением?
validationbackups
82
В 14:32:18 оператор удаляет 26 миллионов строк PostgreSQL, но после этого продолжаются корректные записи; как восстановиться до точной точки перед удалением, не отбросив более поздние изменения?
postgres
83
Восстановление 30 ТБ идет со скоростью всего 1,1 ГБ/с, поэтому одна передача займет около 7,6 часа при RTO четыре часа. Что вы делаете во время инцидента?
incidents
84
При восстановлении MySQL 8.4 физическая копия заканчивается набором GTID `3e11fa47-71ca-11ef-9a44-0242ac120002:1-900000`, но перед продолжением архивной цепочки binlog отсутствуют транзакции `3e11fa47-71ca-11ef-9a44-0242ac120002:900001-905000`. Как вы поступите?
transactionsbackups
85
Базу Oracle объемом 80 ТБ нужно восстановить за шесть часов, но через 25 минут RMAN сообщает о двух недоступных копиях level 1. Как вы руководите восстановлением?
incidentsdatabase
86
Oracle 19c Data Guard Fast-Start Failover дважды переключает primary за 11 минут при периодических потерях WAN на 8 секунд, сервисы недоступны 7 минут, а разрыв redo transport достигает 18 ГБ. Как остановить цикл failover и восстановить стабильный источник истины?
87
Failover продвинул кандидата PostgreSQL с отставанием 96 МБ, и клиенты писали в него восемь минут до обнаружения 1 240 пропавших commits. Что вы делаете?
postgres
88
Региональное продвижение базы завершается за 90 секунд, но через 12 минут приложения все еще не работают из-за кешированного DNS, устаревшего регионального секрета и пулов соединений со старым endpoint. Как восстановить сервис?
databasepoolingcaching
89
Ransomware обнаружен в 03:00, forensic-данные указывают на начало доступа девять дней назад, а последние 14 ежедневных резервных копий могут быть заражены. Как вы восстановитесь?
databasebackups
90
Квартальное учение по восстановлению показывает поврежденные блоки в новейшей копии на 22 ТБ и один отсутствующий сегмент в предыдущей инкрементальной цепочке, поэтому нет доказанной точки в пределах RPO 15 минут. Что вы делаете?
backups
91
Нужно обновить кластер заказов PostgreSQL 15 объемом 14 ТБ с 9 000 записей в секунду до PostgreSQL 17, ограничив остановку записи 90 секундами и сохранив окно отката 30 минут; как вы проведете переключение?
postgresrollback
92
Во время rolling upgrade MySQL InnoDB Cluster с 8.0.36 до 8.4.2 первый обновленный secondary прекращает применение на GTID 7f000000-0000-0000-0000-000000000000:184223, пока checkout-база объемом 6 ТБ обрабатывает 4 500 транзакций в секунду; что вы сделаете до переключения primary?
databasetransactionsconcurrency
93
Перенесите расчетную базу Oracle 19c объемом 20 ТБ с оборудования AIX Power на Linux x86 при окне остановки записи 15 минут, нагрузке 18 000 транзакций в секунду и запрете непроверенного переключения платформы; каков ваш план?
databasetransactions
94
Нужно установить fix pack DB2 11.5.9 на двухплощадочную HADR-базу объемом 11 ТБ с 6 500 транзакций в секунду и остановкой записи менее 3 минут; как вы проведете и проконтролируете rolling upgrade?
databasetransactions
95
Перенесите marketplace-базу MySQL 8.0 объемом 9 ТБ и 35 000 изменений строк в секунду в PostgreSQL 17 с остановкой записи не более 2 минут и окном отката 45 минут; как вы проконтролируете CDC и переключение?
databasepostgresrollback
96
Изменение через gh-ost на таблице orders MySQL 8.0 объемом 1,2 ТБ достигает cutover в 02:14, но отчетная транзакция длительностью 22 минуты удерживает metadata lock, p99 checkout растет с 80 мс до 1,8 секунды, а в очередь встают 600 сессий; как безопасно восстановиться?
transactionssessionsdata-structures
97
Junior DBA выполняет DROP INDEX CONCURRENTLY в PostgreSQL 16 без проверки использования индекса нагрузкой, из-за чего p99 запросов счетов растет со 140 мс до 9 секунд на 24 минуты и API получает 3 200 timeouts; как вы будете наставлять его после восстановления сервиса?
indexesqueriespostgres
98
В 03:20 DBA видит трехузловой MySQL 8.4 InnoDB Cluster: Router сообщает об отсутствии writer, один участник UNREACHABLE, два ONLINE, а backlog приложения растет на 8 000 запросов в минуту; как вы проведете DBA через неоднозначный failover, не забирая клавиатуру?
backlog
99
Шесть junior DBA поддерживают 80 кластеров PostgreSQL 16, получили 180 pages за прошлую неделю и передали seniors 166 из них в первые 3 минуты, хотя 118 закрылись без вмешательства; как вы перестроите on-call за следующие 30 дней?
escalationpostgreson-call
100
В 14:02 кластер платежей PostgreSQL 16 с 7 000 транзакций в секунду теряет storage path primary, Patroni не видит лидера, повторы поднимают CPU до 96%, а команды storage, network и application одновременно предлагают restart, forced promotion и rollback; как вы возглавите первые 20 минут?
transactionspostgresconcurrency

Вопросы

7Спроектируйте топологию Vitess для каталога MySQL 8 размером 90 ТБ с 70 000 чтений и 15 000 записей в секунду, где 80% запросов ограничены merchant ID, а shards нужно добавлять онлайн.

15Историческая таблица PostgreSQL занимает 24 ТБ, обслуживает 3 500 QPS, прибавляет 4 ТБ в год и хранит данные пять лет; выбрать дневные, месячные или годовые партиции?

18Primary PostgreSQL на 10 ТБ выдерживает 16 000 QPS, создаёт 18 МБ WAL в секунду на пике, растёт на 250 ГБ в месяц и хранит данные пять лет; как рассчитать WAL, checkpoints и запас storage?

Закрытые вопросы