Базы данных
MVCC и изоляция: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту MVCC — видимость снимков, компромиссы isolation level, write skew против lost update, пиннинг bloat и XID wraparound.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь в реальном инциденте — какой isolation level, почему autovacuum застрял, что на самом деле означает 40001 — а не определение для заучивания.
Цель
Убедись, что связываешь видимость снимков, выбор isolation level, аномалии, которые каждый уровень допускает, пиннинг bloat и wraparound — тот синтез, к которому вели семь уроков.
Викторина
Completed
Соединение B выполняет это под READ COMMITTED, пока соединение A коммитит UPDATE между двумя операторами: ```sql -- B: BEGIN; SELECT balance FROM accounts WHERE id = 42; -- вернул 100 -- (A коммитит: UPDATE accounts SET balance = 0 WHERE id = 42) SELECT balance FROM accounts WHERE id = 42; -- вернёт ? ``` Что вернёт второй SELECT и почему?
Heads-up Это поведение REPEATABLE READ. READ COMMITTED пересоздаёт снимок в начале каждого оператора, поэтому второе чтение видит свежезакоммиченное значение — классический non-repeatable read.
Heads-up Postgres здесь ничего не бросает. Конкурентный коммит невидим для выполняющегося оператора и просто становится виден следующему под READ COMMITTED.
Heads-up UPDATE никогда не перезаписывает на месте; он пишет новый tuple и помечает старый мёртвым. Свежий снимок возвращает новую живую версию, а не NULL.
Викторина
Completed
Приложение читает строку, вычисляет новое значение в коде и записывает обратно. Два запроса гонятся: ```sql -- оба соединения, конкурентно: BEGIN; SELECT stock FROM items WHERE id = 7; -- оба прочли 10 -- приложение считает 10 - 1 = 9 UPDATE items SET stock = 9 WHERE id = 7; COMMIT; ``` Под уровнем по умолчанию итоговый stock равен 9, а не 8. Что это и каков минимальный фикс?
Heads-up Новых строк нет; оба соединения трогают одну существующую строку. Phantom — это строка, входящая в переоценённый предикат, а не затёртое значение.
Heads-up Write skew требует, чтобы транзакции модифицировали РАЗНЫЕ строки. Здесь они модифицируют ОДНУ строку тем же значением, это lost update, а не write skew.
Heads-up MVCC даёт каждой транзакции валидный снимок, но не сериализует слепые записи в одну строку под READ COMMITTED; одно обновление молча теряется.
Викторина
Completed
У таблицы doctors есть инвариант «хотя бы один доктор on_call». Две транзакции под REPEATABLE READ: ```sql -- T1: -- T2 (конкурентно): SELECT count(*) FROM doctors SELECT count(*) FROM doctors WHERE on_call; -- 2 WHERE on_call; -- 2 UPDATE doctors SET on_call=false UPDATE doctors SET on_call=false WHERE name='alice'; WHERE name='bob'; COMMIT; COMMIT; ``` Обе коммитят; теперь ноль докторов на дежурстве. Что произошло и какой уровень это предотвращает?
Heads-up Каждый UPDATE трогает другую строку (alice против bob), поэтому ни один не перезаписывает другой. Конфликта версий строк, который ловит REPEATABLE READ, нет; аномалия затрагивает прочитанный набор — это write skew.
Heads-up Snapshot isolation предотвращает non-repeatable и phantom reads, но явно допускает write skew. Этот сценарий — канонический пример write skew.
Heads-up Ни одна транзакция не перечитывает изменившуюся строку; обе держат замороженный снимок. Баг — две независимые записи, совместно нарушающие инвариант, то есть write skew.
Викторина
Completed
Autovacuum проработал 30 минут на таблице orders 200 ГБ и логирует «287 million are dead but not yet removable, oldest xmin: 28391456». n_dead_tup не падает. Какова первопричина и что проверить первым?
Heads-up Cost limit лишь регулирует скорость сканирования autovacuum; он не меняет того, что ему ПОЗВОЛЕНО удалять. Лог говорит, что tuples не removable — это пиннинг oldest xmin, а не проблема скорости.
Heads-up VACUUM FULL возвращает место файла; это не предусловие для обычного autovacuum. Обычный vacuum работает — он просто не может удалить tuples, ещё видимые запиненному oldest xmin.
Heads-up Wraparound запускает отдельный аварийный anti-wraparound vacuum со своей формулировкой в логе. «Dead but not yet removable» со значением oldest xmin — это пиннинг снимка.
Викторина
Completed
Перевод между двумя счетами в банке читает оба баланса, дебетует один, кредитует другой. DBA предлагает READ COMMITTED с SELECT ... FOR UPDATE на обеих строках (с блокировкой в согласованном порядке) вместо SERIALIZABLE, который в 5 раз медленнее на пике. Это корректно?
Heads-up Write skew требует действий над строками, которые НЕ модифицируешь. Точечный перевод читает и пишет те же две строки, поэтому FOR UPDATE на обеих функционально эквивалентен SERIALIZABLE здесь — резервируй SSI для инвариантов поверх немодифицируемых строк.
Heads-up REPEATABLE READ + ретраи патологичны на горячих счетах: каждый конкурентный перевод на популярный счёт отменяется и ретраится, обрушивая пропускную способность, без выигрыша в корректности против RC + FOR UPDATE для паттерна из двух строк.
Heads-up FOR UPDATE не отключает MVCC; он берёт блокировку строки, чтобы вторая транзакция ждала коммита первой, затем перечитывает свежую версию. Видимость MVCC всё ещё применяется.
Викторина
Completed
Нагрузка делает много SELECT ... FOR KEY SHARE (неявная блокировка от проверок внешних ключей) и натыкается на предупреждение autovacuum о wraparound гораздо раньше, чем предсказывает её пропускная способность транзакций. Какой счётчик является ограничением?
Heads-up FOR KEY SHARE создаёт MultiXactId, а не лишние XID. FK-тяжёлая нагрузка нагружает именно пространство MultiXact, которое может обернуться задолго до счётчика XID.
Heads-up Страницы CLOG обрезаются по мере заморозки старых транзакций; их исчерпание — не тот режим отказа. Разделяемые блокировки давят на отдельные часы wraparound MultiXact.
Heads-up Разделяемые блокировки не расходуют соединения. MultiXactId выделяются на заблокированную строку независимо от числа соединений, и именно их wraparound поднимает предупреждение.
Итог
Сквозная линия юнита — одно правило видимости и решения, надстроенные над ним. Снимки решают, что видит каждая транзакция (на каждый оператор под READ COMMITTED, на транзакцию под REPEATABLE READ). Isolation level решает, какими аномалиями владеешь ты: RC оставляет lost update приложению, REPEATABLE READ бросает 40001 на конкурентных обновлениях строки, но всё ещё допускает write skew, SERIALIZABLE добавляет SSI для ловли циклов write skew. Налог хранения — мёртвые tuples — autovacuum возвращает лишь до глобального oldest xmin, поэтому долгая транзакция или orphan slot — первый подозреваемый при разрастании bloat. А 32-битные счётчики XID и MultiXact оба требуют заморозки до wraparound. Выбирай самый слабый уровень, ещё защищающий твой инвариант, затем оборони границу.