Теория

Прежде чем продолжить, нам понадобится немного теории.

Как вы видите в etc/default.ini, есть раздел под названием [cluster]

[cluster]
q=2
n=3

q — количество шардов.
n — количество копий каждого документа. Реплики.

При создании базы данных вы можете передать собственные значения в запросе и тем самым переопределить значения по умолчанию в default.ini.

Количество копий документа с одной и той же ревизией, которые необходимо прочитать, прежде чем CouchDB вернёт 200, равно половине общего количества копий документа плюс один. Для количества узлов, которые должны сохранить документ, прежде чем операция записи будет завершена с 201, действует то же правило. Если узлов меньше этого количества, возвращается 202. Количество узлов для чтения и записи можно указать в запросе с помощью параметров r и w соответственно.

Пока что мы сосредоточимся на шардах и репликах.

Шард — это часть базы данных. Его можно реплицировать несколько раз. Чем больше копий шарда, тем больше возможностей для горизонтального масштабирования. Если у вас 4 реплики, это означает, что все 4 копии этого конкретного шарда будут размещены не более чем на 4 узлах. На одном узле не может быть больше одной копии каждой реплики шарда. Начиная с версии 3.0.0, значения по умолчанию в CouchDB — q=2 и n=3. Это означает, что каждая база данных (и вторичный индекс) делится на 2 шарда, у каждого из которых по 3 реплики, то есть всего создаётся 6 файлов реплик шардов. Для кластера CouchDB, в котором размещена только одна база данных с этими значениями по умолчанию, для горизонтального масштабирования можно использовать не более 6 узлов.

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

n=1 Все узлы должны быть доступны.
n=2 Может быть отключён любой 1 узел.
n=3 Могут быть отключены любые 2 узла.
и т. д.

Компьютеры выходят из строя, а системные администраторы время от времени в ярости выдёргивают сетевые кабели, поэтому использование n<2 чревато простоем. Слишком высокое значение n ведёт к увеличению количества серверов и усложнению системы без какой-либо реальной пользы. Оптимальное значение — n=3.

Предположим, что у нас есть база данных с 3 репликами и 4 шардами. Это даёт нам максимум 12 узлов: 4*3=12.

Мы можем потерять любые 2 узла и при этом продолжать чтение и запись всех документов.

Что произойдёт, если мы потеряем больше узлов? Это зависит от того, насколько нам повезёт. Пока в сети остаётся хотя бы одна копия каждого шарда, мы можем читать и записывать все документы.

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