Лучший способ добавления нескольких узлов в существующий кластер cassandra

Question

У нас есть кластер из 12 узлов с двумя центрами обработки данных (каждый DC имеет 6 узлов) с RF-3 в каждом DC.

Мы планируем увеличить емкость кластера, добавив 3 узла в каждый DC (всего 6 узлов). Каков наилучший способ добавления нескольких узлов одновременно (ya, может быть с разницей в 2 минуты).

1. auto_bootstrap: ложь - Использование auto_bootstrap: ложь (как это быстрее процесс запуска узлов) на всех новые узлы, запустить все узлы & затем запустить «nodetool восстановить», чтобы получить данные передаются на эти новые узлы из exisitng узлов ,

Если я иду таким образом, где запросы на чтение скоро начинаются с этих новых узлов, так как на данный момент у него есть только назначенный им диапазон токенов (новые узлы), но НЕТ данных не передается на эти узлы, это вызовет Сбой чтения запроса/проблемы с CL/любая другая проблема?

ИЛИ

<ол начать = «2»>
2. auto_bootstrap: правда - Использование auto_bootstrap: верно, а затем запустить один узел в то время, ждать, пока потокового завершения процесса (это может занять некоторое время, я думаю, как мы огромные данные около 600 ГБ + на каждом узле) перед запуском следующего узла. Если я иду таким образом, мне нужно подождать, пока весь процесс потоковой передачи не будет выполнен на узле, прежде чем приступать к добавлению следующего нового узла.

Просьба предложить лучший способ добавления нескольких узлов одновременно.

PS: Мы используем c * -2.0.3.

Заранее спасибо.

Answer 1

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

Если у вас есть кластер с одним постоянным током, и латентность минимальна между всеми узлами, то для вас должен быть установлен новый узел с auto_bootstrap: true. Кроме того, если хотя бы одна копия ваших данных была реплицирована в локальный центр обработки данных (тот, к которому вы присоединяетесь к новому узлу), это также является предпочтительным методом.

С другой стороны, для нескольких контроллеров домена я нашел больше успеха с настройкой auto_bootstrap: false и с использованием nodetool rebuild. Причина этого заключается в том, что nodetool rebuild позволяет указать центр обработки данных в качестве источника данных. Этот путь дает вам контроль, чтобы содержать потоковое вещание для определенного DC (и, что более важно, не для других контроллеров домена). И, как и в предыдущем случае, если вы строите новый центр обработки данных, и ваши данные еще не были полностью реплицированы на него, то вам потребуется , чтобы использовать nodetool rebuild для передачи данных из другого постоянного тока.

как будут обрабатываться запросы на чтение?

В обоих этих сценариях диапазоны токенов будут вычисляться для вашего нового узла, когда он присоединяется к кластеру, независимо от того, действительно ли там данные. Поэтому, если запрос на чтение должен был быть отправлен на новый узел в CL ONE, то должен быть перенаправлен на узел, содержащий вторичную реплику (при условии RF> 1).Если вы запросили у CL QUORUM (с RF = 3), то должен найти два других. Это, конечно, предполагает, что узлы, которые собирают слабину, не преодолевают своей потоковой деятельностью, что они также не могут обслуживать запросы. Это большая причина, почему существует правило «2 минуты».

Суть в том, что ваши запросы имеют более высокую вероятность сбоя до того, как новый узел будет полностью потоковым. Ваши шансы на успех запроса увеличиваются с размером вашего кластера (больше узлов = больше масштабируемости, и каждый из них несет гораздо меньшую ответственность за потоки). В принципе, если вы переходите от 3 узлов к 4 узлам, вы можете получить сбои. Если вы переходите от 30 узлов до 31, ваше приложение, вероятно, ничего не заметит.

Будет ли новый узел пытаться вытащить данные из узлов в других центрах обработки данных?

Только если ваш запрос не использует ЛОКАЛЬНЫЙ уровень согласованности.