hazelcast 3.6 правильно закрывает узел

Я пытаюсь понять, почему я теряю данные, когда отключаю один узел. У меня есть кластер разработки с 2 узлами, на которых запущено приложение hazelcast 3.6. Приложение HZ настроено на 271 раздел, и я записываю 271 уникальный ключ в кластер через удаленный клиент. Я проверил, что данные правильно распределяются между двумя узлами и сохраняются и сохраняются на другом узле.

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

Hazelcast.shutdownAll();
for (int i = 0; i < 12; i++) {
    log.info("Verifying whether it is safe to close this instance");
    boolean isSafe = getResultsForAllInstances(hzi -> hzi
            .getPartitionService()
            .forceLocalMemberToBeSafe(10, TimeUnit.SECONDS));
    if (isSafe) {
        log.info("Verifying whether cluster is safe.");
        isSafe = getResultsForAllInstances(hzi -> hzi
                .getPartitionService()
                .isClusterSafe());
        if (isSafe) {
            break;
        }
    }

    Uninterruptibles.sleepUninterruptibly(1, TimeUnit.SECONDS);
}

private boolean getResultsForAllInstances(Function<HazelcastInstance, Boolean> hazelcastInstanceBooleanFunction) {
    return getAllHazelcastInstances().stream()
            .map(hazelcastInstanceBooleanFunction)
            .reduce(true, (old, next) -> old && next);
}

к сожалению, другой узел регистрирует потерянный раздел, и я теряю данные.

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

Я также нашел отчеты об ошибках для сценариев. когда узлы были отключены мгновенно, но в моем случае я пытаюсь изящное завершение работы узла, и у него есть время, чтобы связаться с другим узлом. Так что мне здесь не хватает:]

Благодарность!


person kamiseq    schedule 18.11.2016    source источник


Ответы (2)


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

<hazelcast>
  <map name="default">
    <backup-count>1</backup-count>
  </map>
</hazelcast>

Резервная копия по умолчанию - одна. Это означает, что каждая сущность сохраняется только один раз, поэтому существует только в одном узле. Поэтому, если вышеупомянутый узел выходит из строя, вы теряете все его данные. Надеюсь это поможет :)

person Reveka    schedule 18.11.2016
comment
Я проверил, что данные правильно распределяются между двумя узлами и сохраняются и сохраняются на другом узле. поэтому мои данные копируются на другом узле. - person kamiseq; 19.11.2016
comment
Возможно, стоит добавить, что я использую свой собственный сервис, основанный на SPI. - person kamiseq; 19.11.2016
comment
в любом случае я вижу, что данные реплицируются между узлами в кластере - person kamiseq; 19.11.2016
comment
А как насчет чтения из резервной копии? Это у тебя есть? Кроме того, когда узел выключается, есть ли у другого узла резервные копии (смотрите это в режиме отладки, а не запрашивая данные у узла). - person Reveka; 21.11.2016
comment
поскольку я пишу свой собственный сервис с использованием SPI, я еще не добавил эту опцию;]. Хорошо, посмотрю на режим отладки. но я почти уверен, что у других узлов есть данные. И ... оказывается, что самая большая проблема заключается в том, что клиент выдает исключения тайм-аута, когда я выключаю узел. наверное поэтому я вижу потерю данных - логика моего клиента такова, когда нет ответа / ошибки / и т.д. / решение писать. Я уже изменил это, но я не ожидал, что клиент сбросит таймаут ... - person kamiseq; 22.11.2016
comment
Я ожидал, что если я вызову instance.shutdown (), он будет общаться с другими узлами и клиентами об этом факте, переключится в режим OUT_OF_SERVICE, обработает весь входящий запрос, ждет, пока другой узел станет владельцем, а затем отключится. Понимаю, это не так просто: D - person kamiseq; 22.11.2016
comment
Ревека, под режимом отладки вы имеете в виду просто изменить уровень журнала по умолчанию для hazelcast, верно? если да, то я уже сделал это для своей службы, и вы можете просмотреть его в группах. google.com/forum/#!topic/hazelcast/oMR65_kqlbM - person kamiseq; 22.11.2016
comment
хммм ... под отладкой я имел в виду из вашей IDE, но поскольку вы не можете воспроизвести ошибку локально, это не поможет. Вы пробовали добавить третий узел? Распространяются ли данные? И если вы закроете этот узел, какая часть данных будет потеряна. Я просто бросаю идеи отладки, чтобы минимизировать переменные, потому что теперь я серьезно не понимаю, почему кластер будет вести себя так. - person Reveka; 23.11.2016
comment
так что давая эту секунду, хотя я убежден, что данные хранятся и резервное копирование правильно. Возможно, я думал, что потерял их, потому что PartitionLostListener регистрировал информацию об этом. Так что, возможно, это единственная причина, по которой я был подозрительным и смущенным. В документации по ФАПЧ немного. - person kamiseq; 23.11.2016
comment
То есть вы имеете в виду, что у вас никогда не было проблем, когда вы запрашивали данные? Ваши данные были там все время? - person Reveka; 25.11.2016
comment
Думаю, да, поэтому не понимаю, почему публикуются события PartitionLost. - person kamiseq; 29.11.2016
comment
Возможно, вам стоит обновить свой вопрос и отметить его как решенный. Хорошего дня :) - person Reveka; 05.12.2016

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

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

@Reveka, спасибо за терпение! :]

person kamiseq    schedule 05.12.2016