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

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

0 голосов
/ 04 октября 2018

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

Итак, вот фрагмент из ACID Properties и Couchbase :

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

Так что представьте себе следующее.Я вставляю / обновляю документ, и основной узел перестает работать, пока данные не попадут в любую реплику.Допустим, первичный ушел в течение длительного времени.Сейчас я не знаю, были ли данные записаны на диск ... Так что страшная часть в том, что "Couchbase все еще может сохранить документ и в конечном итоге распределить его по кластеру" .То есть, насколько клиент может судить, данные не сделали этого, поэтому пользователь увидит ошибку, но затем она внезапно может появиться в системе, если основной вернется в оперативный режим.

AmЯ правильно прочитал это утверждение?Если да, то как лучше всего справиться с этим с помощью Couchbase?

Ответы [ 3 ]

0 голосов
/ 16 октября 2018

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

Сценарий # 1

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

Сценарий # 2

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

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

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

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

Полный разговор здесь .

0 голосов
/ 19 августа 2019

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

В 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

Подробнее:

0 голосов
/ 05 октября 2018

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

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

Более длинный ответ:

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

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

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

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

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

...