Cassandra не балансирует данные по существующим узлам в кластере

Здравствуйте, я настроил кластер Cassandra 1.2.12 с 3 узлами, и я могу подключиться к мастеру и создать пространства ключей и таблицы на всех узлах. Однако я хочу запустить YCSB в своем кластере, поэтому, когда я запускаю YCSB и загружаю данные, все они загружаются на Master. Поскольку я загружаю 1000000 записей, я рассчитал начальные токены, разделив это число на количество узлов, которые у меня есть. Когда я запускаю nodetool, я получаю что-то вроде:

Address    Rack    Status    State    Load    Owns    Token
10.3.2.8   2       Up        Normal   1.08GB  100%    0
10.3.1.231 2       Up        Normal   67.58KB  0%     330000
10.3.1.128 2       Up        Normal   52.79KB  0%     660000

У кого-то была такая же проблема? Я попытался использовать tokengentool для назначения токенов и разделов diffrenet (Murmur3 и Random), и все было так же, просто загрузив все данные на главный узел.

С уважением, Вероника.


cassandra data-partitioning ycsb
person Nika    schedule 17.12.2013    source источник

Ответы (1)


arrow_upward
4
arrow_downward

«Строка» не равна токену в Cassandra. Независимо от количества строк, которые вы собираетесь хранить, Cassandra RandomPartitioner поддерживает токены 2^127. Для кластера с 3 узлами эти начальные токены должны быть увеличены на 56 713 727 820 156 410 577 229 101 238 628 035 242 друг от друга.

Используя скрипт DataStax Python для вычисления начальных токенов, эти значения RandomPartitioner должны работать для вас:

node 0: 0
node 1: 56713727820156410577229101238628035242
node 2: 113427455640312821154458202477256070485

Если вы используете разделитель Murmur3 (токены от -2^63 до +2^63), используйте следующие значения:

node 0: -9223372036854775808
node 1: -3074457345618258603
node 2: 3074457345618258602

Итак, на данный момент у вас есть два варианта:

1 - Выведите из эксплуатации 10.3.1.231 и 10.3.1.128, остановите узлы, измените их значения initial_token, чтобы они соответствовали указанным выше, и перезапустите их. Но, учитывая тот факт, что вы упомянули, что пробовали и Murmur3, и RandomPartitioner, я думаю, что вам будет лучше выбрать вариант № 2 ниже.

2 – Остановите все узлы, удалите свои данные, следуйте этим инструкциям и перезагрузите данные.

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

person Aaron    schedule 17.12.2013
comment
Скорее всего, вы захотите указать значения для Murmur3, который является разделителем по умолчанию для cass 1.2.12. - person RussS; 18.12.2013
comment
Я вижу, тогда моя логика была совершенно неправильной. Я собираюсь попробовать то, что вы предложили, и надеюсь, что это сработает. Так как я несколько часов пытался заставить его работать и не смог. С уважением - person Nika; 18.12.2013
comment
Большое спасибо. Я попробовал второй вариант, определив num_tokens, и это сработало. - person Nika; 18.12.2013