VictoriaMetrics_ru

спасибо. при предложенной схеме делать миграцию старых данных я не буду - не имеет смысла (они же все равно доступны)

Если хотите ускорить четвертый шаг, то можно мигрировать данные со старого кластера в новый с помощью vmctl ( https://docs.victoriametrics.com/victoriametrics/vmctl/ ), и после миграции остановить сторедж ноды старого кластера. Но в этом случае вам нужно будет включить дедупликацию данных на стороне vmselect, опрашивающих старые и новые сторедж ноды, т.к. во время миграции данные будут дублироваться в старом и новом кластере. Т.е. вам нужно будет указать флаг командной строки -dedup.minScrapeInterval=1ms на этих vmselect нодах. См. https://docs.victoriametrics.com/victoriametrics/cluster-victoriametrics/#deduplication . Значение 1ms (одна миллисекунда) нужно, чтобы дедуплицировать только семплы с одинаковым таймстемпом (VictoriaMetrics хранит таймстемпы с миллисекундной точностью). Подводные камни такой ускоренной миграции: 1. Она может занять много времени и потребовать дополнительных ресурсов диска, сети, памяти и процессора. Если этих ресурсов будет недостаточно, то это может плохо отразиться на общей стабильности и производительности системы. 2. Дедупликация требует дополнительных ресурсов процессора на vmselect нодах. Также дублирующиеся данные могут потребовать больше пропускной способности сети, чтобы передать их от vmstorage в vmselect. Эти факторы могут снизить скорость выполнения запросов на время миграции данных.

спасибо огромное, так сработает.

ВО!!!!

это я как раз в курсе. я скорее всего буду делать с каждым тенантом в отдельности в порядке 1. переключать агента на новую базу 2. копировать исторические данные из старой. была надежда, что можно "зеркалить" текущие данные прямо из базы в базу. было бы проще - не потребовалось бы скакать по всем тенантам

В вашем случае наиболее простое и эффективное решение: 1. Поставить отдельный набор vmselect нод перед сторедж нодами старого и нового кластера (т.е. перечислить все сторедж ноды с обоих кластеров во флаге командной строки -storageNode этих vmselect нод). 2. Переключить чтение данных со старого кластера на vmselect ноды, опрашивающие сторедж ноды старого и нового кластера. После этого можно остановить vmselect ноды старого кластера, если вы не собираетесь делать отдельные запросы к старому кластеру. 3. Переключить запись новых данных со старого на новый кластер. После этого можно остановить vminsert годы старого кластера, т.к. они больше не нужны. 4. Подождать, пока данные на старом кластере не "протухнут" по ретеншну. 5. Переключить чтение на новый кластер. После этого можно остановить vmselect ноды, запущенные на первом шаге. 6. Удалить все vmstorage ноды старого кластера.

vmagent может писать сразу в оба кластера

это возможно будет интереснее, кстати.

Один селект на обе группы стороджей

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