Каков наилучший способ разрешения конфликтов документов CouchDB между двумя экземплярами БД?

Question

У меня есть одно приложение, работающее на NodeJS, и я пытаюсь создать распределенное приложение. Все запросы на запись отправляются приложению Node, и они записывают в CouchDB A, и в случае успеха они записывают в CouchDB B. Мы читаем данные через ELB (который читает из 2 БД). Это нормально работает.

Но недавно я столкнулся с проблемой, мой CouchDB B выключился, и после того, как CouchDB B поднялся, теперь есть несоответствие документа _rev между двумя экземплярами.

Каков наилучший подход для разрешения вышеуказанного сценария без простоев?

Answer 1

Если оба ваших узла 1.6.x синхронизируют сегменты с использованием стандартной репликации, отключение одного узла не должно быть проблемой. На узле вверх он получает все обновления без конфликтов - потому что не было никакого способа сделать их, узел был недоступен.

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

Для обнаружения документов, имеющих конфликты, вы можете использовать стандартные представления: документ, полученный функцией представления, имеет свойство _conflicts, если существуют конфликтующие редакции. Используя соответствующий вид, вы можете обнаружить конфликты и объединить документы. В любом случае, независимо от того, как вы обнаруживаете конфликты, вам нужен внешний код для их разрешения.

Если ваши противоречивые данные по своей природе являются числовыми, рассмотрите возможность использования структур CRDT и стандартной карты / сокращения, чтобы получить окончательное значение. Если ваши данные имеют текстовый характер, вы также можете попытаться использовать CRDT, но для достижения разумной производительности вам необходимо использовать редукторы, написанные на языке Erlang.

Что касается 2.x. Я не рекомендую использовать 2.x для вашего случая (фактически, для любого реального случая, кроме экспериментов). Во-первых, использование 2.x не устранит конфликты, поэтому не решит вашу проблему. Кроме того, принимая во внимание, что 2.x требует большого количества плохо документированных ручных операций между узлами и неспособен перебалансировать, вы получите больше боли, чем пользы.

Кстати, использование любого кластерного решения не имеет большого смысла для двух узлов.

Что касается вышеупомянутых CVE 12635 и CouchDB 1.6.x: вы можете использовать этот патч https://markmail.org/message/kunbxk7ppzoehih6 для покрытия уязвимости.

Answer 2

Если ваши CouchDB A и CouchDB B находятся в одном и том же центре обработки данных, то @ Flimzy предлагает использовать CouchDB 2.0 в кластерном развертывании. Вы можете настроить n узлы CouchDB в кластере с балансировщиком нагрузки, расположенным над кластером, и доставлять трафик HTTP (s) на любой работающий узел.

Если A & B географически разделены, вы можете использовать CouchDB Replication для перемещения данных из A -> B и B -> A, что обеспечит идеальную синхронизацию обоих экземпляров. Каждый A & B может представлять собой кластеры из 3 или более узлов CouchDB 2.0 или отдельные экземпляры CouchDB 1.7.

Ни одно из этих решений не "исправит" проблему, с которой вы сталкиваетесь, когда две копии базы данных изменяются по-разному одновременно. Это «конфликтное» состояние является способом предотвращения потери данных в CouchDB, когда две записи конфликтуют. Ваше приложение может разрешить конфликт, выбрав выигрышную версию или написав новую. Это не условие сбоя, оно помогает вашему приложению восстанавливаться после потери данных во время одновременной записи в распределенную систему.

Вы можете узнать больше о конфликтах документов в этой серии постов в блоге .