Вариант бесшовной миграции с rabbitmq ver.3 (3.8) (192.168.0.34) to ver.4 (4.2) (192.168.0.33).
1) Настраиваем мониторинг для очистки сиротских очередей, по возможности их удаление. мониторинг на стеке rabbitmq-telegraf-infuldb-grafana.
2) подготовка целевого кластера приемника (4.2)
2.1) внесение в /etc/rabiitmq/rabbitmq.conf след. настроек:
docker exec -it rabbit_mq bash -c 'cat <<EOF >> /etc/rabbitmq/rabbitmq.conf
# rabbitmq.conf file content
default_queue_type = quorum
quorum_queue.property_equivalence.relaxed_checks_on_redeclaration = true
EOF'
Затем рестарт (в докере):
docker exec -it rabbit_mq rabbitmqctl stop_app
docker exec -it rabbit_mq rabbitmqctl start_app
теперь очереди без явного указания будут создаваться кворумные.
3) Забираем конфигурацию строго кластера:
curl -u guest:guest http://192.168.0.34:15672/api/definitions -o definitions.json
3.1) удаляем все явные указания на тип очередей:
jq '(.queues[] | select(.arguments | has("x-queue-type")).arguments) |= del (."x-queue-type")' definitions.json > definitions_quorum.json
3.2) заливаем на новый кластер:
curl -u guest:guest -H "Content-Type: application/json" -X POST --data "@definitions_quorum.json" http://192.168.0.33:15672/api/definitions
проверяем через web интерфейс новый кластер, что все очереди , обменники, хосты появились.
4) Создание федерации (federation queue)
4.1) Включаем плагины:
docker exec -it rabbit_mq rabbitmq-plugins enable rabbitmq_federation rabbitmq_federation_management
4.2) Создаем федерацию, коннектор:
docker exec -it rabbit_mq rabbitmqctl set_parameter federation-upstream cluster-a-upstream '{"uri":"amqp://guest:guest@192.168.0.34", "expires":3600000}'
4.3) на каждый vhost , включая дефолтный, создаем политики федерации:
Для дефолт vhost:
docker exec -it rabbit_mq rabbitmqctl set_policy federate-queues-only ".*" '{"federation-upstream-set":"all"}' --priority 10 --apply-to queues
Для my_vhost:
docker exec -it rabbit_mq rabbitmqctl set_policy federate-queues-only ".*" '{"federation-upstream-set":"all"}' --priority 10 --apply-to queues --vhost "my_vhost"
проверяем на новом раббит, что политики применились ко всем очередям .
5) Тестирование передачи сообщений из очередей старого в новый кластер.
5.1) переключаем консюмеров consumer со старого кластера на новый для одного из vhost.
условием передачи сообщений из старого кластера к новому это:
отсутствие подключения (по tcpip) консюмера к старому кластеру и наличие постоянного (не curl post запросы!) tcpip подключения консюмера к новому кластеру. Только тогда новый кластер поведет себя как клиент и (через federation queue) заберет себе сообщения bp очереди из старого кластера, а старый кластер их отдаст. У старого кластера бузусловный приоритет локальных коннектов пользователей к себе для выбранной очереди!
Новый сообщения появятся в одноименной очереди в новом кластере, которая будет уже кворумная. Клиенты (consumer) которые проверяю по умолчанию наличие classic очереди будут получать нужный им ответ и потреблять сообщения из нового кластера. При этом продюсеры будут писать в старый кластер.
5.2) переключить всех пользователей (если одни те же продюсеры могут писать в разные vhost).
Если точно известно, что продюсер и все консюмеры сосредоточены только в одном vhost, то после переноса всех консюмеров этого продюсера можно перенести и самого продюсера на новый кластер.
6) Переключение продюсеров на новый кластер.
После переноса всех консюмеров, всех vhost на новый кластер, убедиться, что нет клиентских подключений к старому кластеру, кроме федерации.
6.1) по одному переключаем продюсеров к новому кластеру (через смену А записи в DNS, или смены бэкэндов в LB, или dnat на старом сервере раббит для IP продюсера)
7) ссылки, для отработки
git clone https://github.com/deepshig/rabbitmq-docker.git
заменить во раббит приемнике ,мв docker-compose.yml имидж, с rabbitmq:3.8-rc-management на rabbitmq:4-management
развернуть тест можно на https://labs.play-with-docker.com/
Комментариев нет:
Отправить комментарий