Был в состоянии воссоздать более простой сценарий, см. Обновление около дна
Сначала немного заглянем в проблему. Я делаю несколько экспериментов Кассандры на Amazon EC2. У меня 4 узла на востоке, 4 на западе в одном кластере. Чтобы смоделировать мой вариант использования, я использовал инструмент внутреннего стресса cassandras, запущенный на отдельном экземпляре East-EC2, для выдачи:
. / Стресс -d us-eastnode1, ..., us-eastnode4 - стратегия репликации NetworkTopologyStrategy - стратегия-свойства us-east: 3, us-west: 3 -e LOCAL_QUORUM -c 200 -i 10 -n 1000000
Затем я запустил ту же запись, одновременно начав соответствующее чтение local_quorum на другом отдельном экземпляре West-EC2:
. / Стресс -d us-westnode1, ..., us-westnode4 -o читать -e LOCAL_QUORUM -c 200 -i 10 -n 1000000
После первых 300 тыс. Чтений один из западных узлов начал блокировать с ~ 80% процессором iowait и снизить общую скорость чтения на ~ 90%. Между тем записи закончились очень хорошо на скорости, близкой к нормальной. В попытке выяснить, что является причиной того, что этот единственный узел блокирует iowait, я запустил только ридер и сразу же обнаружил ту же проблему.
Мои токены таковы, что он сбалансирован вокруг восточных узлов, с каждым западным узлом +1 по каждому соответствующему восточному узлу, т.е. us-eastnode1: 0, us-westnode1: 1, us-eastnode2: 42535295865117307932921825928971026432 и т. д. Фактическая нагрузка оказалась сбалансированной по всему набору, поэтому я исключил это из возможных причин для этого.
В конце концов я запустил крупное уплотнение (несмотря на то, что для CF было только 10 sstables, и незначительные уплотнения не запускались в течение> часа). После того, как я попробовал снова прочитать стресс, узел был в порядке ... Однако у следующего последовательного узла возникла та же проблема. Это самая большая подсказка, которую я нашел, но я не знаю, к чему это приведет.
Я спросил в IRC Кассандры, но не получил никаких идей оттуда. У кого-нибудь есть идеи для новых вещей, которые я мог бы попытаться выяснить, что здесь происходит не так?
Обновление на следующий день
Некоторое дальнейшее углубление в жизнь Я смог воспроизвести это, просто запустив стресс записи дважды, затем запустив чтение. Команда nodetool cfstats после первой записи показывает, что каждый узел отвечает за ~ 750 000 ключей, что имеет смысл для 1 000 000 ключей и RF: 3 для 4 узлов в контроллере домена. Однако после второй стрессовой записи у us-westnode1 есть ~ 1 500 000 ключей, а у us-westnode1-3 - около 875 000 ключей. Когда он затем пытается прочитать, узел с вдвое большей нагрузкой, чем он должен был, зависает.
Это заставляет меня думать, что проблема в инструменте стресса. Он перезаписывает те же строки 0000000-0999999 с одинаковыми столбцами c0-c199. Тем не менее, каким-то образом ни один из узлов не остается при той же нагрузке на данные, что и при первом запуске.
Простой отдых
Сузили проблему, удалив второй DC как переменную. Теперь работает 1 DC, 4 узла с 25% -ным владением каждый, RandomPartitioner и запись следующего вида:
. / Стресс -d узел1, ..., узел4 - коэффициент репликации 3 -e QUORUM -c 200 -i 10 -n 1000000
После одной записи (и незначительных уплотнений) каждый узел имел нагрузку ~ 7,5 ГБ.
После двух операций записи (и незначительных уплотнений) каждый узел имел нагрузку ~ 8,6 ГБ, за исключением узла 2 с ~ 15 ГБ.
После выполнения крупного уплотнения на всех узлах каждый узел вернулся к нагрузке ~ 7,5 ГБ.
Является ли это просто странной проблемой уплотнения, возникающей при эффективной перезаписи всего набора данных, как это делает инструмент стресса?