Обработка сбоя требований к долговечности в Couchbase

Обновление для этого вопроса:

Couchbase 6.5 представила поддержку транзакций:

transactions.run((txnctx) -> {
    // get the account documents for Andy and Beth  
    TransactionJsonDocument andy = txnctx.getOrError(collection, "Andy");
    JsonObject andyContent = andy.contentAsObject();
    int andyBalance = andyContent.getInt("account_balance");
    TransactionJsonDocument beth = txnctx.getOrError(collection, "Beth"); 
    JsonObject bethContent = beth.contentAsObject();
    int bethBalance = bethContent.getInt("account_balance");

    // if Beth has sufficient funds, make the transfer
    if (bethBalance > transferAmount) {
            andyContent.put("account_balance", andyBalance + transferAmount);
            txnctx.replace(andy, andyContent);
            bethContent.put("account_balance", bethBalance - transferAmount);
            txnctx.replace(beth, bethContent);
    }
    else throw new InsufficientFunds();  
    // Commit transaction - if omitted will be automatically committed 
    txnctx.commit();
});

Также была улучшена долговечность, и теперь вы можете выбирать между 3 уровнями: большинство, persistToActive, persistToMajority.

Подробнее :

• https://blog.couchbase.com/distributed-multi-document-acid-transactions-in-couchbase/
• https://blog.couchbase.com/couchbase-transactions-java-api/< /а>

Короткий ответ:

Включите автоматическую отработку отказа, и все будет в порядке.

Подробный ответ:

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

1. Вы сохраняете документ с помощью SDK и устанавливаете для него требование устойчивости persists_to.
2. Couchbase подтверждает, что документ был сохранен в памяти.
3. SDK начинает проверку, чтобы убедиться, что он сохраняется на диске и/или реплицируется.
4. В течение очень короткого промежутка времени узел выходит из строя. Документ был сохранен на диске, но не был реплицирован на другой узел и основной узел не перешел на другой узел.
5. Операция SDK вернет ошибку, говорящую о том, что она не соответствует требованиям устойчивости. (Я могу ошибаться в этом, он может возвращать другую ошибку, а значит, вы можете действовать по-другому).
6. Вы уведомляете пользователя о том, что что-то не удалось.
7. Узел возвращается, снова присоединяется к кластеру, и документ там.
8. Запутавшийся пользователь?

Если это так, то ключом является шаг 4. Во-первых, это кажется довольно редким пограничным случаем. Все три из этих вещей должны быть правдой, чтобы беспокоиться об этой ситуации. Мои внутренние знания Couchbase не являются надежными, так что эта ситуация может быть невозможной (но я буду продолжать, как если бы это было так).

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

Опять же, я не эксперт по внутренностям Couchbase, так что это все, насколько мне известно, но похоже, что все, что вам нужно сделать, это включить автоматическое переключение при сбое, и все будет в порядке. По умолчанию он выключен; идея состоит в том, что вы должны сначала понять, что это такое, и принять решение. Но для большинства систем используйте автоматический переход на другой ресурс.

Итак, вот что я узнал, разговаривая с ребятами из Couchbase:

Сценарий 1

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

Сценарий 2

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

Поэтому я задал вопрос: "Когда прежний первичный сервер снова подключится к сети с локально сохраненными, но не реплицированными элементами и начнет повторную синхронизацию, эти элементы будут удалены или что-то в этом роде?" -

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

Конечно, на практике, поскольку репликация выполняется из памяти в память, а дисковый ввод-вывод имеет тенденцию к более высокой задержке (репликация элемента и сохранение элементов планируются одновременно), вещи будут реплицироваться чаще, чем сохраняться, но нет никакой гарантии. Кроме того, приложение (через SDK) также может влиять на результаты с помощью функций «Требования к долговечности», о которых мы говорили.

Полный диалог находится здесь.