diff --git a/docs/cluster_group.svg b/docs/cluster_group.svg
new file mode 100644
index 0000000000000000000000000000000000000000..00260c54cbcbeaf872454104e59a5c74008f1fe8
Binary files /dev/null and b/docs/cluster_group.svg differ
diff --git a/docs/glossary.md b/docs/glossary.md
index 3343d9519d5f5da113e069d3159fe86cd5f943f7..f26b56d36fbd6e0d9633c5b754bd9933afe56c88 100644
--- a/docs/glossary.md
+++ b/docs/glossary.md
@@ -1,37 +1,248 @@
 # Глоссарий
 ## Общие сведения
-Данный документ содержит список терминов и их определений для основных программных компонентов и понятий, которые используются в Picodata. У глоссария две простые цели:
+Данный раздел содержит описание основных терминов, используемых в Picodata.
 
-- Дать точное и непротиворечивое определение каждому термину применительно к его использованию в Picodata.
-- Обеспечить единообразие терминологии во внутренних документах (комментарии в коде, readme и прочие Markdown-документы в наших репозиториях).
+## Подсистемы
+### Raft
+**Raft** является алгоритмом распределенного консенсуса, который нужен, чтобы несколько участников могли совместно решить, произошло ли событие или нет, и что за чем следовало. Raft используется в Picodata для согласования работы узлов и поддержания консистентности в кластере. Концепция распределенного консенсуса предполагает, что в кластере всегда есть только один лидер и некоторое количество голосующих узлов. Эти узлы в нормальном состоянии подтверждают легитимность лидера, а при отказе текущего лидера организуют выборы нового.
+См. [подробнее](https://raft.github.io/raft.pdf).
 
-Список ниже будет дополняться и исправляться в течение времени.
+### Терм (term)
+Период между выборами лидера в raft-группе называется **термом** (term). Каждый терм начинается в момент объявления выборов нового лидера. Обычно это происходит после потери связи с прежним лидером. Терм состоит из двух частей: выборов и периода нормальной работы raft-группы. Исключением служат термы, в течение которых не удалось выбрать лидера группы: у таких термов есть только первая часть (выборы).
+Важно помнить, что в одном терме не может существовать более одного лидера raft-группы.
 
-## Список терминов и определений
-**Инстанс** — программный узел, входящий в состав кластера. Каждый инстанс является экземпляром приложения Picodata, а также репликой в составе репликасета. Среда выполнения приложения может быть как виртуальной, так и физической.
+### Состояния узлов в Raft-группе <a name="raft-group"></a>
+В raft-группе любой узел может быть в одном из трех состояний:
 
-**Кластер** — набор программных узлов, составляющих отдельную группу.
+**Пассивный узел (follower)** — состояние по умолчанию для каждого инстанса после запуска. Follower — обычный голосующий узел, который лишь отвечает на запросы, но не генерирует их.
 
-**Raft** — алгоритм синхронной репликации, обеспечивающий целостность кластера (raft-группы). Raft отвечает за автоматический выбор лидера raft-группы (лидер может меняться). В raft-группе есть лидер, а остальные узлы называются follower’ами.
+**Кандидат в лидеры (candidate)** — состояние инстанса во время выборов лидера. Когда начинается новый терм, инстансы в статусе follower увеличивают значение терма и переходят в статус кандидатов, голосуют сами за себя и затем ждут результатов выбора. Выходов из этого состояния три: 
 
-**Отказоустойчивость** — повышение надежности данных с помощью репликации.
+- Кандидат побеждает в выборах и становится лидером.
+- Кандидат возвращается в статус follower, так как другой инстанс становится лидером.
+- Кандидат остается кандидатом, так как не удается выбрать лидера. Raft увеличивает терм еще раз и организует повторные выборы.
 
-**Репликация** — создание и поддержание в актуальном состоянии резервных копий инстансов.
+**Лидер raft-группы (leader)** — избранный узел, который отвечает за обработку запросов и репликацию raft-журнала.
 
-**Фактор репликации** — число инстансов в репликасете.
+### Raft-лидер	
+**Лидер в raft-группе** — это один из узлов, который несет ответственность за репликацию raft-журнала. Лидер избирается на голосовании и признается таковым всеми участниками голосования. Задача лидера состоит в приеме сообщений от клиентов кластера и отправке сообщений на узлы кластера таким образом, чтобы в любой момент времени все узлы имели консистентную, непротиворечивую версию raft-журнала. Лидерство в Raft предполагает, что все остальные узлы признают приоритет версии журнала, предлагаемую лидером.
 
-**Репликасет** — буквально «набор реплик», экземпляров приложений, в которых хранится один и тот же набор реплицированных данных. В зависимости от роли реплик, в Picodata есть реплики _active (RW)_ и _standby (RO)_. 
+Если лидер становится недоступным, то алгоритм Raft организует выборы нового лидера среди оставшихся участников. Если после этих выборов прежний лидер снова присоединится к кластеру, он уже будет иметь права обычного голосующего узла (но не лидера).
 
-**Failure domain** — букв. _"домен отказа"_. Термин обозначает зону доступности инстанса Picodata, т.е. признак физического размещения сервера, на котором запущен инстанс (географический регион, датацентр, стойка и т.д.). Зона доступности используется для того чтобы в один репликасет по возможности попадали инстансы с разным размещением, повышая таким образом отказоустойчивость как отдельного репликасета, так и кластера в целом.
+### Репликация raft-журнала
+**Репликация raft-журнала** нужна для того, чтобы на каждом узле кластера (raft-группы) была одинаковая история команд. Когда лидеру группы нужно добавить в журнал новую команду, он сначала отправляет ее всем узлам, ждет подтверждения записи (commit), и лишь затем добавляет эту команду в собственный журнал. В случае, если журнал обычного узла отличается от журнала лидера, то лидер настаивает на приоритете своего журнала и перезаписывает журнал обычного узла, считая его устаревшим.
+Для упрощения репликации алгоритм Raft придерживается двух правил при сравнении журналов разных узлов:
 
-**Bucket** (бакет) — виртуальная неделимая единица хранения данных, обеспечивающая локальность данных (т. е. их нахождение на каком-то одном репликасете).
+- Если записи имеют одинаковые индексы и термы, то они содержат одинаковые команды.
+- Если записи имеют одинаковые индексы и термы, то считается, что все предыдущие записи соответствующих журналов одинаковы.
 
-**Горизонтальное масштабирование** — шардинг, т.е. распределение bucket'ов между различными репликасетами, находящихся на разных серверах. Каждый такое репликасет называется шардом.
+Так как а) записи в журнале не могут менять порядок и б) каждой записи соответствует только один индекс и терм, то указанные выше правила гарантирует консистентность журнала.
 
-**Discovery** — алгоритм взаимного обнаружения инстансами друг друга во время объединения в кластер.
 
-**Space** (спейс) — пространство хранения данных в СУБД. В резидентных СУБД спейс является синонимом _таблицы_ из реляционных СУБД.
 
-**Grade** (грейд) — специфичный для Picodata способ обозначения состояния инстанса. Грейд отражает то, как инстанс сконфигурирован его соседями. Существуют _текущий_ (current) и _целевой_ (target) типы грейдов. За приведение первого ко второму отвечает _governor_ (губернатор).
+### Web UI
+**Веб-консоль** — это вариант графического интерфейса к функциям Picodata. Данная подсистема находится в разработке и будет представлена в следующем релизе Picodata. Веб-консоль в наглядном виде отображает и позволяет менять конфигурацию и состав кластера, параметры отдельных узлов, схему данных и т.д. Веб-консоль является удобным инструментов локального и удаленного администрирования Picodata.
+
+### CLI (Command-line interface)
+**CLI** — это интерфейс командной строки для запуска и управления как отдельными инстансами, так и всем кластером Picodata.
+
+### Дискавери (discovery)
+**Discovery** —  алгоритм, по которому инстансы обнаруживают друг друга. Этот шаг необходим на старте каждого инстанса для корректной работы кластера.
+
+### Vshard
+**Vshard** — библиотека из экосистемы СУБД Tarantool, используемая в Picodata для горизонтального масштабирования — сегментирования данных по нескольким узлам в кластере. Это становится важным по мере увеличения объема хранимых данных, ввода в строй новых узлов — т.е. роста кластера.
+Библиотека Vshard встроена в Picodata и является неотъемлемой ее частью. 
+В клиентских интерфейсах Vshard желательно прятать за фасадом, но при острой необходимости ничто не помешает им воспользоваться.
+
+## Сущности
+В начале идет общее обозначение термина, затем в скобках указан предпочтительный вариант употребления в коде (без пробелов в “змеином регистре”). 
+
+### Инстанс (instance) <a name="instance"></a>
+**Обозначение единицы кластера СУБД и сервера приложений**
+При описании кластера мы различаем программный и логический уровни.
+
+На программном уровне единицей кластера является экземпляр приложения Picodata, также на техническом жаргоне называемый инстансом. Среда выполнения приложения может быть как виртуальной, так и физической. В разрезе операционных систем каждый инстанс порождает два процесса: собственно экземпляр приложения и вспомогательный процесс (supervisor), управляющий жизненным циклом первого. 
+
+На логическом уровне единицей кластера является узел. Под узлом, в зависимости от контекста, может пониматься как отдельная вычислительная единица, обладающая пулом ресурсов (физический сервер, виртуальная машина, контейнер), так и программный экземпляр Picodata, уже входящий в состав кластера.
+
+Также инстанс является репликой в составе репликасета и может входить в указанную при его запуске группу инстансов.
+
+### Кластер (cluster) <a name="cluster"></a>
+**Кластер** — набор логических и программных узлов, составляющих отдельную централизованно управляемую группу с общим пространством хранения.
+
+**Кластер** является наиболее крупной сущностью в системе хранения, в некотором смысле он и есть система хранения. Внутри кластера находятся инстансы, объединенные в репликасеты (см. ниже). Дополнительно, в Picodata используется понятие групп инстансов — отдельного способа более гибко управлять большим числом инстансов в зависимости от их ролей, характера нагрузки и топологии сети.
+
+Схематичное представление кластера, в составе которого есть некоторое число инстансов, репликасетов и групп инстансов, показано ниже.<a name="cluster_group"></a>
+
+![Cluster](cluster_group.svg)
+
+### Репликасет (replicaset) <a name="replicaset"></a>
+**Репликасет** — буквально «набор реплик», экземпляров приложений, в которых хранится один и тот же набор данных. Реплика в составе репликасета может быть в одном из двух состояний:
+
+- активная (active) — доступная на запись, иногда ее называют мастером или лидером репликасета.
+- резервная (standby) — доступная только на чтение, read-only.
+В нормальных условиях в репликасете активной является ровно одна реплика, но в отдельных случаях их может быть несколько или не быть вообще.
+
+### Лидер (leader)
+<p name="leader">В Picodata есть две разновидности лидеров:</p>
+
+- “raft-лидер” — лидер raft-группы,
+- и “репликасет-лидер” — лидер репликасета.
+
+Термин _лидер_ часто путают с _мастером_ применительно к репликации Tarantool. В Picodata они хоть и близки, но все же отличаются по смыслу. Под _мастером_ следует понимать инстанс, который выполняет пользовательские DML-операции (insert / update / delete). На практике чаще всего такой инстанс один, и в таком случае оба термина описывают один и тот же инстанс (отсюда и путаница), но в Tarantool архитектурно заложена возможность вести запись на нескольких узлах репликасета одновременно — т.н. режим мультимастера (multi-master). Даже в таком режиме операции DDL (`create_space` и т.д.) должен выполнять лишь один инстанс из всех, и здесь становится важно отличать _лидера_ от _мастера_. Несмотря на то, что в Picodata режим мультимастера пока не реализован, документация и код должны использовать эти термины корректно.
+
+### Группа инстансов (instance_group)
+**Группа инстансов** — это логическое объединение инстансов с общим фактором репликации и ролями. Каждая группа шардируется индивидуально.
+
+Концепция групп является аналогом [vshard_group](https://www.tarantool.io/ru/doc/latest/book/cartridge/cartridge_cli/commands/replicasets/#list-vshard-groups) из Cartridge, но дополнительно позволяет назначать роли группам (в Cartridge роли настраивались индивидуально для каждого репликасета). 
+
+**Группа инстансов** является более крупным образованием, чем репликасет. См пояснительную [картинку](glossary.md#cluster_group).
+
+Каждый шардированный спейс принадлежит одной конкретной инстанс-группе. На инстансах из других групп спейс физически не создается. Но т.к. схема данных является общей на весь кластер, создавать два спейса с одинаковым именем в разных группах не разрешается. Принадлежность инстанс-группе определяется только для шардированных спейсов, глобальные спейсы создаются повсюду.
+
+### Домен отказа (failure_domain)
+**Домен отказа** является признаком физического расположения сервера, на котором запущен инстанс. Указание домена отказа позволяет обозначить наличие единой точки отказа у двух инстансов. Смысл данного параметра состоит в том, чтобы в один репликасет попадали инстансы из разных физических локаций, что повышает отказоустойчивость кластера.
+
+**Домен отказа** представляет собой набор пар “ключ=значение”, которые соответствуют отдельным зонам (географический регион, датацентр, стойка и т.д.). Зоны задаются пользователем исходя из фактической конфигурации оборудования, будь то виртуальные машины в облаке (`“region=eu”`) или физические сервера (`“dc=msk”`). Домен отказа может включать несколько зон (`“dc=msk,srv=msk-1”`).
+
+Можно использовать любые ключи и значения. Picodata не делает предположений об иерархии зон или их физическом смысле и просто сравнивает строки. Тем не менее, чтобы избежать человеческих ошибок, Picodata требует, чтобы набор зон (ключей) на всех инстансах был одинаковым.
+
+Если домены отказа двух инстансов имеют хотя бы одну общую зону (и ключ, и значение), то допускается возможность одновременной потери связи с обоими. Поэтому инстансы, делящие общую зону, не будут объединены в репликасет. Picodata также стремится распределить голосующие raft-узлы таким образом, чтобы их домены отказа имели по минимуму общих зон.
+
+### Фактор репликации (replication_factor)
+**Фактор репликации** — число инстансов в репликасете. Задается общим на группу инстансов (так же как и набор ролей). Отредактировать фактор репликации, сохраненный в конфигурации кластера, можно командой `picodata set-replication-factor`. Редактирование конфигурации сказывается только на вновь добавляемых инстансах, но не затрагивает уже работающие.
+
+
+### Бакет (bucket) <a name="bucket"></a>
+**Bucket (бакет)** — виртуальная неделимая единица хранения данных, обеспечивающая их локальность (т. е. нахождение на каком-то одном репликасете).
+
+### Спейс (space)
+**Space (спейс)** — пространство хранения данных. В резидентных СУБД спейс является синонимом таблицы из реляционных СУБД. В Picodata есть следующие виды спейсов:
+
+1. Глобальные (_global_) — их содержимое реплицируется на весь кластер.
+2. Шардированные (_sharded_) — каждый репликасет хранит лишь часть общего
+   набора данных. Данные реплицируются внутри репликасета.
+
+Метаданные всех спейсов Picodata присутствуют на всех узлах кластера.
+Фактически для пользователя не существует понятия “не кластерных”
+спейсов, он лишь выбирает между стратегиями шардирования и репликации
+тех спейсов, с которыми он работает.
+
+### Индекс (index)
+**Индекс** — это специальная структура данных, которая хранит группу ключевых значений и указателей. Индекс строится по какому-либо одному столбцу таблицы и используется для эффективного поиска значений этого столбца. У каждого спейса обязательно должен быть первичный индекс и опционально некоторое число вторичных индексов. 
+
+### LSN (log sequence number)
+Термин **LSN** (log sequence number) относится к архитектурным особенностям Tarantool, в котором все обновления БД фиксируются в журнале упреждающей записи (WAL, write-ahead log) в виде отдельных записей. Каждая запись представляет собой запрос на изменение данных (`insert` | `update` | `delete`) и маркируется монотонно возрастающим номером LSN. Наибольший номер обозначает номер наиболее свежей записи, находящейся в конце журнала WAL. 
+
+### Vclock (vector clock)
+Репликация в Tarantool предполагает обмен записями между репликами в репликасете. Благодаря этому обмену, на каждой отдельной реплике имеется специальный набор записей, полученный от разных реплик с разными LSN — это и есть **Vclock** (vector clock, векторные часы). Vclock описывает состояние БД для отдельного инстанса в репликасете.
+
+Vclock репликасет-лидера играет важную роль в поддержании консистентности при переключении лидера (consistent switchover). В случае аварийного переключения (фейловера, failover), когда консистентность сохранить невозможно и она жертвуется в угоду доступности, отслеживание vclock позволяет строить метрики точек восстановления (RPO, recovery point objective).
+
+### Сетевой адрес (address) <a name="address"></a>
+**Сетевой адрес** — это комбинация `host:port`, используемая для связи инстансов друг с другом по сети. Другие названия для связки `host:port` (например URL, URI) мы стараемся искоренить. Расширенная версия `user:pass@host:port` все равно определяется термином _адрес_.
+
+### Грейд (grade)
+**Grade (грейд)** — специфичный для Picodata способ обозначения состояния инстанса. Грейд отражает то, как инстанс сконфигурирован его соседями. Существуют текущий (`current`) и целевой (`target`) типы грейдов. За приведение первого ко второму отвечает governor (губернатор).
+
+### Губернатор (governor)
+**Governor (губернатор)** — внутренняя централизованная сущность, управляющая конфигурациями и жизненными циклами инстансов в соответствие с изменениями их грейдов. "Губернатор" выполняется на лидере raft-группы.
+
+### Крейт (crate)
+**Крейт** (буквально “ящик”) — наименьшая логическая единица проекта, написанного на Rust. С точки зрения компилятора rustc, любой отдельный фрагмент кода является крейтом. Из одного крейта может быть скомпилирован бинарный исполняемый файл, либо разделяемая библиотека. Несколько крейтов могут вместе составлять пакет (package). Пакет может состоять также и из одного крейта. Если крейтов в пакете несколько, то из них только один может предоставлять разделяемую библиотеку.
+
+### Снапшот (snapshot) <a name="snapshot"></a>
+**Снапшот**, в самом широком смысле этого слова — это снимок состояния распределенного конечного автомата. В контексте Picodata можно говорить о двух независимых (почти) распределенных конечных автоматах, и, соответственно, о двух видах снапшотов — Tarantool и Raft.
+
+Picodata прилагает все усилия, чтобы эти состояния были одинаковыми на каждом узле кластера, но т.к. изменения на нодах происходят через применение команд из журнала (WAL или raft), то даже в штатном режиме случаются не одновременно.
+
+Более детально, состояние инстанса включает в себя две части:
+
+- персистентные данные, которые можно сериализовать и сохранить на диск;
+- транзиторное (transient) состояние — все структуры, которые Tarantool строит в оперативной памяти для обработки DML-запросов.
+
+См. также:
+
+- [RFC — Storage schema — Raft snapshot](https://docs.google.com/document/d/1MEpGnpKKj6WezLKytvvonZzbpy1tlWtAK5ccxaeAOrE/edit#heading=h.687c3wywf9ub)
+- [Tarantool — Persistence](https://www.tarantool.io/en/doc/latest/concepts/data_model/persistence/)
+
+
+## Процессы и алгоритмы
+### Компактизация raft-журнала (raft log compaction)
+**Компактизация** — процесс, не допускающий бесконтрольного роста журнала записей Raft. Компактизация заключается в удалении части журнала, относящейся к сделанному ранее снапшоту.
+
+### Создание снапшотов (snapshotting)
+**Создание снапшотов** — процесс периодического сохранения состояния инстанса на жесткий диск. Наличие снапшотов (т.е. снимков состояния) позволяют восстановить инстанс в прежнем виде после его перезапуска.
+
+### Фенсинг (fencing)
+**Фенсинг** — это подпись всех запросов в кластере номером эпохи или терма, и отказ обслуживать запросы с устаревшей эпохой. Данный инструмент используется для корректной работы распределенной блокировки, т.е. ситуации, когда из нескольких узлов нужно гарантированно выбрать один для выполнения запроса.
+
+### CaS (compare and swap) <a name="cas"></a>
+**Compare and swap** — особый алгоритм в составе Picodata. Он обеспечивает уровень изоляции транзакций [serializable](glossary.md#isolation), тем самым не допуская случаев несогласованности данных в результате выполнения конкурирующих запросов/транзакций. Таким случаем, например, может быть ситуация, когда одна транзакция затирает результат действия другой, выполняющейся в тоже время. _Compare and swap_ решает эту проблему с помощью проверки предиката, т.е. меняет данные какого-либо параметра кластера только в том случае, если исходное ожидаемое значение этого параметра соответствует исходному фактическому. 
+Технически данный алгоритм реализован в виде хранимой процедуры `proc_cas()`. 
+
+### Бутстрап (bootstrap) <a name="bootstrap"></a>
+**Bootstrap** — процесс первоначального объединения разрозненных инстансов в единый кластер. В контексте Picodata речь обычно идет о бутстрапе инстанса, когда инстанс запускается в чистой директории без снапшотов. При необходимости можно уточнить, бутстрапится _лидер реплиасета_ или _read-only-реплика_ — алгоритмы для них отличаются.
+
+Случай, когда инстанс запускается на существующих снапшотах, называется _восстановлением из снапшота_ (recovery from a snapshot). Этот процесс сопутствует перезапуску инстанса.
+
+Другой эксплуатационный сценарий, когда при перезапуске удаляются все данные инстанса, называют _ребутстрапом_ (rebootstrap), т.е. повторным запуском. Ребутстрап всегда сопровождается сменой `raft_id`, хотя `instance_id` может при этом переиспользоваться.
+
+_Бутстрап кластера_ — бутстрап первого инстанса + [присоединение](#joining) некоторого количества других. 
+
+_Бутстрап репликасета_ — бутстрап лидера репликасета + присоединение к нему реплик.
+
+### Присоединение (joining) инстанса к кластеру <a name="joining"></a>
+_Присоединение инстанса_ близко по смыслу к [бутстрапу](#bootstrap), но делает акцент на процессах, происходящих в самом кластере. Чтобы инстанс мог присоединиться, другие (уже существующие) члены кластера должны сначала сохранить информацию о нем в raft-журнал.
+
+### Репликация (replication) <a name="replication"></a>
+**Репликация** — один из механизмов [актуализации](#actualization) данных между инстансами. В Picodata существует два вида репликации: Tarantool (внутри [репликасета](#replicaset)) и Raft (глобальная на весь кластер). Под термином репликация обычно имеют в виду пересылку записей журналов (`wal` или `raft` в зависимости от того, о каком виде репликации идет речь).
+
+### Актуализация (catch-up) инстанса <a name="actualization"></a>
+Актуализация — это по сути синхронизация данных между инстансами. Существует два механизма актуализации: посредством [репликации](#replication) журнала (catch-up by log replication), и посредством применения [снапшота](#snapshot) (catch-up by snapshot).
+
+Актуализация снапшотом поддерживается только для Raft, но не для Tarantool. Она требуется, когда на raft-лидере отсутствуют нужные записи в raft-журнале. Если аналогичная ситуация происходит с WAL Tarantool, пользователю не остается выбора кроме как делать [ребутстрап](#bootstrap) инстанса.
+
+### Proc API
+
+**Proc API** — Stored Procedures API (хранимые процедуры). Хранимыми процедурам являются Rust-функции с аттрибутом `#[tarantool::proc]`. Процедуры могут быть вызваны с помощью любого тарантул-коннектора, в частности, с помощью Lua-модуля `net.box` или Rust-модуля `tarantool::network::client`. В Picodata хранимые процедуры используются для коммуникации между инстансами. 
+
+Примерами хранимых процедур в Picodata могут служить:
+- `.proc_cas`  (низкоуровневый вызов механизма [Compare and Swap](#cas) на выбранном инстансе);
+- `.proc_read_index` (получение текущего значения raft-индекса выбранного инстанса).
+
+## Общие концепции
+### Отказоустойчивость <a name="failsoft"></a>
+**Отказоустойчивость** — свойство кластера сохранять наличие и доступность данных при выходе из строя части узлов. В Picodata отказоустойчивость обеспечивается репликацией и грамотным проектированием алгоритмов.
+
+### Горизонтальное масштабирование <a name="sharding"></a>
+**Горизонтальное масштабирование** (оно же сегментирование или шардирование, sharding) — подход, предполагающий разделение данных на сегменты (бакеты, buckets), которые могут храниться на отдельных репликасетах кластера. С точки зрения набора хранимых данных, каждый репликасет называется шардом. Деление на шарды — это еще один вариант логического деления кластера, но без привязки к серверам, на которых выполняются инстансы.
+
+### Линеаризуемость <a name="linearizability"></a>
+В контексте распределенных баз данных **линеаризуемость** обозначает свойство хранилища обеспечивать целостность и согласованность данных на разных репликах БД. Линеаризуемость в Picodata обеспечивается алгоритмом консенсуса Raft, который обновляет данные на мастер-реплике только после того, как они записаны на резервные реплики.
+
+
+В схеме данных кластера для каждого шардированного спейса (таблицы) задается параметр распределения — _ключ шардирования_, состоящий из одной или нескольких колонок. Пример:
+
+```
+sharding_key:
+    - id
+    - name
+```
+### Уровень изоляции транзакций <a name="isolation"></a>
+Уровень изоляции транзакций является одним из компонентов ACID (_atomicity, consistency, isolation, durability_), который представляет собой набор требований к СУБД согласно стандарту [ANSI/ISO SQL](https://en.wikipedia.org/wiki/ISO/IEC_9075). Уровень изоляции транзакций определяет степень строгости, которую СУБД применяет к возможной несогласованности данных при исполнении нескольких транзакций одновременно. Различают следующие уровни (по мере повышения строгости и усиления блокировок):
+
+- **Read uncommitted**. Низший уровень изоляции, допускающий чтение незафиксированных данных. В результат чтения могут попасть данные от других, еще не завершившихся операций записи.
+- **Read committed.** Чтение уже зафиксированных данных. Данный уровень гарантирует, что в момент чтения данные были ранее зафиксированы, однако позволяет изменять данные сразу после этого. Т.е. повторное чтение внутри транзакции уже не гарантирует получение такого же набора данных.
+- **Repeatable read**. Повторяемое чтение данных, при которых нельзя изменять данные до тех пор, пока читающая их транзакция не завершилась.
+- **Serializable**. Наивысший уровень изоляции, предполагающий полное упорядочивание (сериализацию) транзакций. Результат выполнения нескольких параллельных транзакций должен быть таким, как если бы они выполнялись последовательно.
+
+### Read phenomena (проблемы чтения данных)
+Уровни изоляции транзакций существуют для учета и решения следующих проблем, возникающих при одновременном (параллельном) чтении данных:
+
+- **Lost update** (потерянное обновление). При одновременном изменении данных разными транзакциями теряются все изменения, кроме последнего.
+- **Dirty read** (неточное чтение). В результат чтения добавятся данные, привнесенные другой транзакцией, которая впоследствие будет отменена (не получит статуса committed).
+- **Non-repeatable read** (проблема однократного чтения). Несколько последовательных операций чтения одних и тех же данных дают разный результат, т.к. между ними вклинилась сторонняя операция записи.
+- **Phantom read** (фантомное чтение). Проблема схожа с предыдущей и также касается изменения данных после начала операции чтения. Однако, “фантомное чтение” предполагает изменение самой выборки (параллельная операция записи добавляет/удаляет строки).
+
 
-**Governor** (губернатор) — внутренняя централизованная сущность, управляющая конфигурациями и жизненными циклами инстансов в соответствие с изменениями их грейдов.