Кластерная очистка

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

Кластерная очистка предназначена для обеспечения eventual consistency и предотвращения ненужной инвалидации вторичных индексов. Для этого каждая база данных отслеживает определённое количество исторических запросов на очистку, полученных базой данных, а также текущее значение purge_seq. Внутренние репликации и вторичные индексы обрабатывают запросы на очистку базы данных и периодически обновляют соответствующие документы контрольных точек очистки, сообщая о purge_seq, обработанных ими. Для обеспечения eventual consistency база данных удаляет сохранённые исторические запросы на очистку только после того, как они будут обработаны заданиями внутренней репликации и вторичными индексами.

Внутренние структуры

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

purge_tree: UUID -> {PurgeSeq, DocId, Revs}
purge_seq_tree: PurgeSeq -> {UUID, DocId, Revs}

Каждый интерактивный запрос к _purge API создаёт упорядоченный набор пар с возрастающими значениями purge_seq и purge_request, где purge_request — это кортеж, содержащий docid и список ревизий. Для каждого purge_request генерируется uuid. Запрос на очистку добавляется во внутренние деревья очистки: кортеж {UUID -> {PurgeSeq, DocId, Revs}} добавляется в purge_tree, кортеж {PurgeSeq -> {UUID, DocId, Revs}} добавляется в to purge_seq_tree.

Уплотнение запросов на очистку

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

Локальные документы контрольных точек очистки

Индексы и внутренние репликации базы данных с запросами на очистку создают и периодически обновляют локальные документы контрольных точек очистки: _local/purge-{type}-{hash}. Эти документы сообщают о последнем purge_seq, обработанном ими, и времени последней обработки. Эти документы видны в _local_docs, только если добавить параметр include_system=true, например /test-db/_local_docs?include_system=true. Пример локального документа контрольной точки очистки:

{
  "_id": "_local/purge-mrview-86cacdfbaf6968d4ebbc324dd3723fe7",
  "type": "mrview",
  "purge_seq": 10,
  "updated_on": 1540541874,
  "ddoc_id": "_design/foo",
  "signature": "5d10247925f826ae3e00966ec24b7bf6"
}

На изображении ниже показаны возможные локальные документы контрольных точек, которые могут быть в базе данных.

Local Purge Checkpoint Documents — Локальные документы контрольных точек очистки

Внутренняя репликация

Запросы на очистку воспроизводятся на всех узлах с обеспечением eventual consistency. Внутренняя репликация запросов на очистку состоит из двух этапов:

1. Репликация с получением данных. Сначала внутренняя репликация получает запросы на очистку с целевого узла и применяет их на исходном узле, чтобы гарантировать, что документы/ревизии исходного узла, уже очищенные на целевом узле, не будут повторно добавлены на целевой узел. На этом этапе используются документы контрольных точек очистки, сохранённые на целевом узле, чтобы отслеживать последний purge_seq целевого узла, обработанный исходным узлом. Мы находим запросы на очистку, появившиеся после этого purge_seq, и воспроизводим их на исходном узле. Этот этап выполняется путём обновления документов контрольных точек очистки целевого узла с указанием последнего обработанного purge_seq и времени обработки.

2. Репликация с отправкой данных. Затем внутренняя репликация выполняется как обычно, добавляя дополнительный этап отправки запросов на очистку исходного узла на целевой узел. На этом этапе используются локальные документы контрольных точек внутренней репликации, которые обновляются как на целевом, так и на исходном узле.

В обычных условиях интерактивный запрос на очистку уже отправлен каждому узлу, содержащему реплику шарда базы данных, и применён на каждой реплике. Внутренняя репликация запросов на очистку между узлами — это лишь дополнительный этап для обеспечения согласованности между репликами, при котором все запросы на очистку одного узла воспроизводятся на другом. Чтобы не воспроизводить один и тот же запрос на очистку на реплике повторно, каждому интерактивному запросу на очистку присваивается уникальный uuid. Внутренняя репликация отфильтровывает запросы на очистку с UUID, которые уже есть в purge_tree реплики, и применяет только запросы на очистку с UUID, которых нет в purge_tree. Именно поэтому потребовались два внутренних дерева очистки: 1) purge_tree: {UUID -> {PurgeSeq, DocId, Revs}} позволяет быстро находить запросы на очистку с UUID, которые уже есть в реплике; 2) purge_seq_tree: {PurgeSeq -> {UUID, DocId, Revs}} позволяет перебирать данные, начиная с заданного purge_seq, чтобы собрать все запросы на очистку, появившиеся после этого purge_seq.

Индексы

Каждый запрос на очистку увеличивает update_seq базы данных, поэтому каждый вторичный индекс также обновляется, чтобы применить запросы на очистку и обеспечить согласованность с основной базой данных.

Параметры конфигурации

Эти параметры можно изменить в файле default.ini или local.ini:

Поле	Описание	Значение по умолчанию

max_revisions_number	Максимально допустимое количество накопленных ревизий в одном запросе на очистку	infinity
allowed_purge_seq_lag	Дополнительный буфер для хранения запросов на очистку, разрешённый помимо purged_infos_limit	100
index_lag_warn_seconds	Допустимое время, в течение которого индекс не обновляется для локального документа контрольной точки очистки	86400

Во время уплотнения базы данных проверяются все документы контрольных точек очистки. Значение последнего purge_seq, о котором сообщил клиент (индекс или задание внутренней репликации), может быть меньше текущего purge_seq шарда базы данных на величину (purged_infos_limit + allowed_purge_seq_lag). Если значение purge_seq клиента ещё меньше и клиент не обновлял контрольную точку в течение index_lag_warn_seconds, это препятствует уплотнению деревьев очистки, и для этого клиента необходимо записать в журнал следующее предупреждение:

Purge checkpoint '_local/purge-mrview-9152d15c12011288629bcffba7693fd4’
not updated in 86400 seconds in
<<"shards/00000000-1fffffff/testdb12.1491979089">>

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

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

"Invalid purge doc '<<"_design/bar">>' on database
<<"shards/00000000-1fffffff/testdb12.1491979089">>
with purge_seq '50'"

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