#Использование Shovel для миграции сообщений

Используйте RabbitMQ Shovel, когда нужно перемещать сообщения между broker'ами, clusters или virtual hosts. Shovel хорошо подходит для миграции из очереди в очередь, временной пересылки или контролируемого повторного воспроизведения сообщений в другой среде.

Shovel не является механизмом синхронизации всего cluster. Он не синхронизирует пользователей, permissions, virtual hosts, exchanges, queues, bindings, Kubernetes resources или application configuration. Подготовьте эти объекты отдельно, прежде чем полагаться на Shovel для миграции рабочей нагрузки.

#Применимые сценарии

Используйте Shovel, когда вам нужно одно или несколько из следующего:

• Мигрировать сообщения из одной очереди в другую очередь в новом cluster.
• Повторно воспроизвести сообщения в целевую среду во время контролируемой миграции.
• Переместить накопленные сообщения между sites во время запланированного переключения.

Используйте аварийное восстановление RabbitMQ с Federated Exchanges, когда вам нужна асинхронная репликация на основе exchange вместо передачи из очереди в очередь.

#Предварительные требования

Перед настройкой Shovel убедитесь, что выполнены следующие условия:

1. В cluster, где размещается Shovel, включен plugin rabbitmq_shovel.
2. Включите rabbitmq_shovel_management, если вам нужна видимость Dynamic Shovels в management UI или HTTP API.
3. Source и destination RabbitMQ endpoints доступны из cluster, где размещается Shovel.
4. Пользователи source и destination имеют необходимые permissions.
5. Destination exchanges или queues уже существуют, либо у вас есть явный процесс их создания до миграции.

#Включение plugins Shovel

В следующем примере включаются необходимые plugins в cluster, на котором выполняется Shovel:

apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: rabbitmq-migrator
  namespace: <namespace>
spec:
  rabbitmq:
    additionalPlugins:
      - rabbitmq_shovel
      - rabbitmq_shovel_management

Проверьте включенные plugins:

kubectl -n <namespace> exec rabbitmq-migrator-server-0 -- \
  rabbitmq-plugins list -e

#Процедура

#1. Выберите host cluster для dynamic Shovel

Dynamic Shovels хранятся как runtime parameters RabbitMQ. Создайте Shovel в cluster, который обеспечивает надежную сетевую связность и с source, и с destination broker.

#2. Создайте dynamic Shovel

В следующем примере сообщения перемещаются из очереди orders на source broker в очередь orders-migrated на destination broker:

kubectl -n <namespace> exec rabbitmq-migrator-server-0 -- \
  rabbitmqctl set_parameter -p / shovel move-orders \
  '{
    "src-protocol":"amqp091",
    "src-uri":"amqp://<source-user>:<source-password>@<source-host>:5672/%2f",
    "src-queue":"orders",
    "dest-protocol":"amqp091",
    "dest-uri":"amqp://<dest-user>:<dest-password>@<dest-host>:5672/%2f",
    "dest-queue":"orders-migrated",
    "ack-mode":"on-confirm",
    "reconnect-delay":5,
    "delete-after":"never"
  }'

%2f — это URL-encoded default virtual host /. Замените его на URL-encoded имя virtual host, которое вы фактически используете. Если имя пользователя или пароль содержат зарезервированные URI-символы, закодируйте их с помощью URL encoding.

Используйте ack-mode="on-confirm" для production migrations, чтобы source side подтверждалась только после того, как destination подтвердит публикацию.

#3. Проверьте статус Shovel

Убедитесь, что Shovel выполняется:

kubectl -n <namespace> exec rabbitmq-migrator-server-0 -- \
  rabbitmqctl shovel_status

Также можно проверить runtime parameters:

kubectl -n <namespace> exec rabbitmq-migrator-server-0 -- \
  rabbitmqctl list_parameters -p /

#4. Проверьте перемещение сообщений

Проверьте глубину очередей source и destination:

rabbitmqadmin \
  --host <source-management-host> \
  --port 15672 \
  --username <admin-user> \
  --password <admin-password> \
  --vhost / \
  list queues name messages consumers

rabbitmqadmin \
  --host <dest-management-host> \
  --port 15672 \
  --username <admin-user> \
  --password <admin-password> \
  --vhost / \
  list queues name messages consumers

#5. Удалите Shovel после завершения миграции

Если Shovel используется временно, удалите его после завершения миграции:

kubectl -n <namespace> exec rabbitmq-migrator-server-0 -- \
  rabbitmqctl clear_parameter -p / shovel move-orders

#Операционные примечания

• Shovel перемещает сообщения, а не полное состояние broker.
• Если destination queue не существует, Shovel завершится с ошибкой, если только выбранный destination exchange и routing behavior не позволяют создать нужный путь.
• Сетевые сбои вызывают попытки повторного подключения в соответствии с настроенным reconnect delay.
• Для длительных задач миграции отслеживайте рост очередей, consumer lag и broker alarms как на source, так и на destination стороне.

#Связанная информация

• Аварийное восстановление RabbitMQ с Federated Exchanges
• Управление определениями RabbitMQ
• RabbitMQ Shovel
• Dynamic Shovel