Последовательный ремонт Кассандры не восстанавливает все узлы за один прогон? - PullRequest
0 голосов
/ 02 января 2019

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

nodetool repair -full -seq -tr <keyspace> <table> > <logfile>

Теперь узел, на котором была выполнена команда, был исправлен должным образом, что можно сделать из приведенной ниже команды

nodetool cfstats -H <keyspace.columnFamily>

То же самое нельзя сказать о других узлах, поскольку для них я получаю случайное значение% ремонта, значительно меньшее.

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

Спасибо!

1 Ответ

0 голосов
/ 02 января 2019

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

Ключевым моментом, который вы пропустили, является то, что при такой настройке каждый конкретный узел не содержит вседанные.Сколько всего данных в нем содержится?Давайте сделаем простую математику: если количество фактических данных, вставленных в таблицу, равно X, то общий объем данных, хранящихся в кластере, равен 3 * X (поскольку RF = 3, существует три копии каждого фрагмента данных).Эта сумма распределена по 5 узлам, поэтому каждый узел будет содержать (3 * X) / 5, т. Е. 3/5 * X.

Когда вы начинаете восстановление на одном конкретном узле, он восстанавливает только данныекоторый этот узел имеет, то есть, как мы только что рассчитали, 3/5 от общего объема данных.Это исправление выполняется для каждого фрагмента данных, хранящегося в этом узле, он сравнивает эти данные с копиями, хранящимися в других репликах, исправляет несоответствия и исправляет все этих копий.Это означает, что когда восстановление закончено, в узле, который мы восстановили, все его данные были восстановлены.Но для других узлов не все их данные были восстановлены - только части, которые пересекались с узлом, который инициировал это восстановление.Это пересечение должно составлять примерно 3/5 * 3/5 или 36% данных (конечно, все распределено случайным образом, так что вы, вероятно, получите число, близкое к 36%, но не точно 36%).

Итак, как вы, вероятно, уже поняли, это означает, что «восстановление nodetool» - это не операция всего кластера.Если вы запустите его на одном узле, то гарантированно будет восстановлено только все данные на одном узле, а на других узлах - меньше.Таким образом, вы должны выполнить восстановление на каждом из узлов по отдельности.

Теперь вы можете спросить: так как восстановление узла 1 также восстановило 36% узла 2, не будет ли бесполезно также ремонтировать узел2, так как мы уже сделали 36% работы?Действительно, это пустая трата времени.Таким образом, у Cassandra есть опция восстановления «-pr» («основной диапазон»), которая гарантирует, что только одна из 3 реплик для каждого элемента данных будет восстанавливать его.При RF = 3, "nodetool repair -pr" будет в три раза быстрее, чем без "-pr";Вам все еще нужно запускать его отдельно на каждом из узлов, и когда все узлы завершат работу, ваши данные будут на 100% восстановлены на всех узлах.

Все это довольно неудобно, а также трудно восстановить после временных сбоевво время длительного ремонта.Вот почему как коммерческие предложения Cassandra - от Datastax и ScyllaDB - предлагают отдельный инструмент восстановления, который более удобен, чем «восстановление nodetool», гарантируя, что весь кластер восстанавливается наиболее эффективным способом, и восстанавливаясь после временных проблем безповторяя длительный процесс восстановления с самого начала.

...