Я отметил следующее утверждение в документации Cassandra о конфигурации архива журнала коммитов:
https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configLogArchive.html
" Восстановление останавливается, когда первая предоставленная клиентом временная метка больше временной метки точки восстановления. Поскольку порядок, в котором база данных получает мутации, не строго следует порядку временной метки, это может привести к тому, что некоторые мутации не будут восстановлены."
Это утверждение заставило нас беспокоиться об использовании восстановления на момент времени на основе журналов фиксации Cassandra, поскольку это указывает на то, что восстановление на момент времени не восстановит все мутации с временной меткой, меньшей указанной временной метки восстановления, если у нас есть мутации вне порядка временных меток (что у нас будет).
Я пытался проверить это поведение с помощью некоторых экспериментов, но не смог воспроизвести это поведение.
Я сделал 2 эксперимента:
Простые вставки строк
Установите restore_point_in_time на 1 час вперед во времени.
вставить 10 строк (используя текущую временную метку по умолчанию)
вставить строку, используя метку времени <2 часа вперед во времени>
вставить 10 строк (используя текущую временную метку по умолчанию)
Теперь я убил свой экземпляр cassandra, убедившись, что он был прерван, и у меня не было возможности перейти на таблицы SS.
Во время запуска я мог видеть из журналов cassandra, что он выполнял воспроизведение CommitLog.
После воспроизведения я запросил таблицу и увидел, что было восстановлено 20 строк, но не была вставлена та, у которой была метка времени. Хотя здесь, основываясь на документации, я ожидал, что были вставлены только первые 10 строк. В журнале casssandra я проверил, что воспроизведение CommitLog выполнено.
Больший эксперимент splitLog CommitLog
Я хотел посмотреть, работает ли задокументированная функция над разделением / переносом коммитов.
Поэтому я установил commitlog_segment_size_in_mb равным 1 МБ, чтобы заставить коммит вести чаще обновляться вместо 32 МБ по умолчанию.
Затем я запустил скрипт для массовой вставки строк, чтобы принудительно разделить журнал фиксации.
Таким образом, результатом было то, что я вставил 12000 записей, затем вставил запись с меткой времени перед моим restore_point_in_time, а затем вставил 8000 записей.
Примерно в 13200 строках мой коммитлог перенесен в новый файл.
Затем я снова убил свой экземпляр Кассандры и перезапустил. Я снова увидел в журнале, что воспроизведение CommitLog выполняется, и после воспроизведения я увидел, что были восстановлены все строки, кроме одной строки с меткой времени до restore_point_in_time.
Примечания
Я проводил аналогичные эксперименты, используя пакетный параметр commitlog_sync, а также, чтобы убедиться, что мои строки не были сброшены в SSTables. Я попытался восстановить снимок с пустыми таблицами перед запуском cassandra, чтобы он выполнял воспроизведение commitlog. Во всех случаях я получил одинаковые результаты.
Полагаю, мой вопрос в том, является ли утверждение в документации все еще действительным? или, может быть, я что-то упускаю в своих экспериментах?
Любая помощь будет принята с благодарностью? Мне нужен ответ для этого, чтобы я смог завершить механизм резервного копирования / восстановления, который мы хотим реализовать в более крупномасштабной настройке кластера кассандры.
Все эксперименты проводились с использованием Cassandra 3.11 (настройка одного узла) в контейнере Docker (официальное изображение докера Cassandra). Я провел эксперименты на изображении «с нуля», поэтому никаких изменений в конфигах, где это было сделано, кроме того, что я включил в описание здесь.