Проблема обновления типа экземпляра Datastax в AWS

Я планировал обновить свой экземпляр datastax в AWS с t2.large до t2.2xlarge. Наш текущий кластер содержит 6 узлов SearchGraph.

Datacenter: SearchGraph
=======================
UN  192.168.8.1  469 MiB     1            ?       936a1ac0-6d5e-4a94-8953-d5b5a2016b92  rack1
UN  192.168.8.2  427.71 MiB  1            ?       3f41dc2a-2672-47a1-90b5-a7c2bf17fb50  rack1
UN  192.168.8.3  431.27 MiB  1            ?       29f8fe44-3431-465e-b682-5d24e37d41d7  rack2
UN  192.168.8.4  480.73 MiB  1            ?       1f7de531-ff51-4581-bdb8-d9a686f1099e  rack2
UN  192.168.8.5  498.9 MiB   1            ?       27d37833-56c8-44bd-bac0-7511b8bd74e8  rack2
UN  192.168.8.6  882.4 MiB   1            ?       0822145f-4225-4ad3-b2be-c995cc230830  rack1

Поскольку наш коэффициент репликации равен 3, мы можем выжить, даже если наш 2 экземпляр выйдет из строя для целей обновления экземпляра. Мне нужна ясность в отношении следующего шага обновления, который я планировал выполнить, правильно или нет?

Шаг 1)

nodetool flush 
sudo service dse stop

Шаг 2) Возьмите AMI экземпляра

Шаг 3) Запустите новый экземпляр t2.2xlarge из взятого AMI.
(Примечание: IP-адрес нового экземпляра должен быть таким же, как у предыдущего)

Шаг 4) запуск службы sudo dse


datastax datastax-enterprise datastax-enterprise-graph datastax-startup datastax-php-driver
person Sreeraju V    schedule 08.02.2018    source источник
comment
лучше использовать nodetool drain: документы. datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/   -  person Alex Ott    schedule 08.02.2018
comment
Я ничего не могу сказать об этом - я никогда не пробовал использовать его таким образом.   -  person Alex Ott    schedule 08.02.2018
comment
@AlexOtt Спасибо. Я буду следовать вашей рекомендации вместо шага 1. Нужно ли мне делать какие-либо другие изменения из-за того, что данные старого экземпляра из ami получают репликацию в новом экземпляре? Придется ли мне удалять все сохраненные кеши предыдущего экземпляра.   -  person Sreeraju V    schedule 08.02.2018

Ответы (1)


arrow_upward
0
arrow_downward

Итак, это не обновление, а перенос данных на большую машину. Пока вы сохраняете каталоги данных, узел будет сохранять те же диапазоны токенов и идентификатор узла (все они хранятся в системных таблицах cassandra).

Однако обратите внимание, что это звучит так, как будто вы повторно монтируете снимок AMI, узел будет немного «отставать» по сравнению с другими узлами, поэтому, если ваша согласованность чтения не является кворумом, ваши чтения могут попасть на старый узел и выйти из данные даты. Вероятно, это также хорошая идея, чтобы запустить ремонт, как только вы закончите.

person markc    schedule 08.02.2018
comment
Если даунтайм небольшой, то он должен догнать изменения по подсказкам... А вот насчет запущенного ремонта согласен - просто чтоб все синхронизировалось - person Alex Ott; 09.02.2018
comment
Да хороший момент, я забыл о подсказках! По умолчанию они 3 часа, насколько я помню. Глядя на операции здесь, они, вероятно, будут выполнены в течение 3 часов, но это не гарантируется. Однако стоит отметить, что если вы видите пропущенные сообщения в nodetool tpstats, вам не следует полностью полагаться на подсказки iirc - person markc; 12.02.2018