Итак, у нас есть отдельная графитовая нода, которая стоит за cname и собирает все метрики. Если это произойдет, это не будет хорошо. Итак, мой вопрос заключается в том, как мне не только реплицировать все существующие данные шепота на другой узел, но и настроить репликацию на месте с помощью углеродного ретранслятора. Как вкратце будет выглядеть рабочий процесс миграции? Как настроить угольное реле? Я хочу сделать это максимально прозрачно с минимальным временем простоя.
Как реплицировать существующий графитовый сервер на новый с помощью углеродного реле
comment
Добро пожаловать в СО. Я понимаю, что вам нужна помощь. Но трудно понять, что происходит без вашего примера кода/данных и т. д. Не могли бы вы изменить свой вопрос? Тогда люди смогут вам помочь.
- person jazzurro schedule 27.09.2014
Ответы (1)
Миграция потребует минимального неизбежного простоя.
Я бы продолжил:
- уменьшите время жизни вашего cname на вашем DNS-сервере (это будет нижняя граница продолжительности вашего простоя)
- подготовьте второй сервер с агрегаторами, кешем и ретранслятором, указывающим на оба ящика (коэффициент репликации 2), но остановите ретранслятор
- остановить графит на вашем первом сервере (время простоя начинается сейчас)
- измените cname, чтобы оно указывало на второй сервер
- заархивировать все метрики на первый сервер, скопировать на второй, извлечь
- запустить реле (окончание простоя)
- в момент смены dns + ttl все ваши клиенты перейдут на второй релей, все данные записываются на оба сервера
Затем вы можете начать делать свою настройку более надежной с ретранслятором на первом сервере (например, с общим виртуальным IP-адресом).
В нашей установке мы отделили серверы ретрансляции (2 из них в активном/активном состоянии) от серверов-агрегаторов+кеширования.
Избыточность в графите, однако, сложна, когда сервер не работает, поскольку он не будет получать пропущенные обновления при повторном включении, вам придется делать это вручную.
person
kamaradclimber
schedule
27.09.2014
