Alternar entre o Kafka e o Woodpecker
Esta página descreve como alternar a fila de mensagens (MQ) de um cluster Milvus entre o Kafka (integrado ou externo) e o Woodpecker (backend MinIO), em ambos os sentidos. Para conhecer o fluxo de trabalho geral e os pré-requisitos, consulte Alternar a fila de mensagens.
Pré-requisito: A funcionalidade «Alternar MQ» está disponível no Milvus 3.0 e versões posteriores. Atualize a sua instância do Milvus para o Milvus 3.0 ou posterior antes de começar — a funcionalidade não está disponível em versões anteriores.
A troca da fila de mensagens é uma operação de alto risco. Escolha a secção que corresponde ao seu método de implementação — «Com o Helm» ou «Com o Milvus Operator» — e siga-a do início ao fim. Não misture comandos do Helm com os do Operator.
Com o Helm
Mudar do Kafka para o Woodpecker (Helm)
Passo 1: Verifique se a instância do Milvus está em execução. Certifique-se de que o seu cluster do Milvus está a funcionar corretamente — por exemplo, criando uma coleção de teste, inserindo dados e executando uma consulta.
Passo 2: Execute a mudança de MQ. Exponha a interface de gestão do MixCoord e, em seguida, chame a API de mudança:
kubectl port-forward --address 0.0.0.0 service/my-release-milvus-mixcoord 29091:9091
Noutro terminal:
curl -X POST http://127.0.0.1:29091/management/wal/alter \
-H "Content-Type: application/json" \
-d '{"target_wal_name": "woodpecker"}'
Passo 3: Verifique se a mudança foi concluída.
kubectl logs <mixcoord-pod> | grep "successfully updated mq.type configuration in etcd"
Uma mudança bem-sucedida regista « [mqTypeValue=woodpecker] ».
Passo 4: (Opcional) Parar o Kafka e limpar. Para o Kafka integrado, remova os pods do Kafka e os respetivos PVCs. Para o Kafka externo, limpe os tópicos do Milvus na instância externa do Kafka — estes seguem o formato <cluster_prefix>-dml_<seqNo>_<TimeTick><Version>.
Se pretender voltar a utilizar o Kafka mais tarde, elimine primeiro os dados/tópicos para evitar conflitos.
Mudar do Woodpecker para o Kafka (Helm)
Passo 1: Verifique se a instância do Milvus está em execução.
Passo 2: Configure a ligação ao Kafka de destino e reinicie o Milvus. A transição requer que o Milvus já conheça a ligação ao Kafka; por isso, insira-a em user.yaml através de extraConfigFiles e aplique com helm upgrade (o que reinicia os pods). O streaming.enabled=true é necessário para a funcionalidade Switch MQ. Para detalhes sobre SASL/SSL, consulte «Ligar-se ao Kafka com SASL/SSL».
# values.yaml
extraConfigFiles:
user.yaml: |+
kafka:
brokerList:
- <your_kafka_address>:<your_kafka_port>
saslUsername:
saslPassword:
saslMechanisms: PLAIN
securityProtocol: SASL_SSL
helm upgrade -i my-release zilliztech/milvus \
--set kafka.enabled=true \
--set woodpecker.enabled=false \
--set streaming.enabled=true \
-f values.yaml
Aguarde até que todos os pods estejam prontos e, em seguida, confirme se a configuração de acesso ao Kafka foi incorporada na configuração do Milvus.
Passo 3: Execute a mudança para o MQ.
Certifique-se de que o Kafka de destino não contém tópicos do Milvus de uma configuração anterior. Se esta for a sua primeira transição para o Kafka, ignore esta nota; caso contrário, elimine primeiro os tópicos residuais do Milvus com os mesmos nomes.
kubectl port-forward --address 0.0.0.0 service/my-release-milvus-mixcoord 29091:9091
Noutro terminal:
curl -X POST http://127.0.0.1:29091/management/wal/alter \
-H "Content-Type: application/json" \
-d '{"target_wal_name": "kafka"}'
Passo 4: Verifique se a transição está concluída.
kubectl logs <mixcoord-pod> | grep "successfully updated mq.type configuration in etcd"
Uma transição bem-sucedida regista « [mqTypeValue=kafka] ».
Passo 5: (Opcional) Limpe os dados do Woodpecker. Elimine os dados do Woodpecker no MinIO/S3 (na pasta <rootPath>/wp/..., normalmente files/wp/...) e os metadados do Woodpecker no etcd (etcdctl get woodpecker --prefix). Se pretender voltar a utilizar o Woodpecker mais tarde, elimine primeiro estes ficheiros.
Com o Milvus Operator
Mudar do Kafka para o Woodpecker (Milvus Operator)
Passo 1: Verifique se a instância do Milvus está em execução.
Passo 2: Execute a mudança de MQ. O serviço MixCoord não está exposto, por isso execute a API de mudança a partir do interior do pod do MixCoord:
kubectl exec -it <mixcoord-pod> -- \
curl -X POST http://localhost:9091/management/wal/alter \
-H "Content-Type: application/json" \
-d '{"target_wal_name": "woodpecker"}'
Passo 3: Verifique se a mudança foi concluída.
kubectl logs <mixcoord-pod> | grep "successfully updated mq.type configuration in etcd"
Uma mudança bem-sucedida regista [mqTypeValue=woodpecker].
Passo 4: Atualize o tipo de MQ no Operator. Atualize a configuração gerida pelo Operator para que este não reverta a mudança. Crie change_configmap.yaml:
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
name: my-release
labels:
app: milvus
spec:
dependencies:
msgStreamType: woodpecker
kubectl patch -f change_configmap.yaml --patch-file change_configmap.yaml --type merge
Passo 5: (Opcional) Parar o Kafka e limpar. Para o Kafka integrado, remova os pods do Kafka e os respetivos PVCs. Para o Kafka externo, limpe os tópicos do Milvus (formato <cluster_prefix>-dml_<seqNo>_<TimeTick><Version>).
Mudar do Woodpecker para o Kafka (Operador Milvus)
Passo 1: Verifique se a instância do Milvus está em execução.
Passo 2: Configure a ligação ao Kafka de destino e reinicie o Milvus. Coloque a ligação ao Kafka em spec.config (o Operator converte spec.config em user.yaml) e defina o tipo de MQ; ao aplicar o CR, os pods são atualizados com a nova configuração. Para detalhes sobre SASL/SSL, consulte «Ligar-se ao Kafka com SASL/SSL».
# change_configmap.yaml
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
name: my-release
labels:
app: milvus
spec:
config:
kafka:
brokerList:
- <your_kafka_address>:<your_kafka_port>
saslUsername:
saslPassword:
saslMechanisms: PLAIN
securityProtocol: SASL_SSL
dependencies:
msgStreamType: kafka
kubectl patch -f change_configmap.yaml --patch-file change_configmap.yaml --type merge
Aguarde até que todos os pods estejam prontos e, em seguida, confirme se a configuração de acesso ao Kafka foi incorporada na configuração do Milvus.
Passo 3: Execute a mudança para o MQ.
Certifique-se de que o Kafka de destino não contém tópicos do Milvus de uma configuração anterior. Se esta for a sua primeira mudança para o Kafka, ignore esta nota; caso contrário, elimine primeiro os tópicos residuais do Milvus com os mesmos nomes.
kubectl exec -it <mixcoord-pod> -- \
curl -X POST http://localhost:9091/management/wal/alter \
-H "Content-Type: application/json" \
-d '{"target_wal_name": "kafka"}'
Passo 4: Verifique se a transição está concluída.
kubectl logs <mixcoord-pod> | grep "successfully updated mq.type configuration in etcd"
Uma transição bem-sucedida regista « [mqTypeValue=kafka] ».
Passo 5: (Opcional) Limpe os dados do Woodpecker. Elimine os dados do Woodpecker no MinIO/S3 (em <rootPath>/wp/..., normalmente files/wp/...) e os metadados do Woodpecker no etcd (etcdctl get woodpecker --prefix). Se pretender voltar a utilizar o Woodpecker mais tarde, elimine primeiro estes ficheiros.
Cenários suportados
| MQ de origem | MQ de destino | Helm | Operador Milvus |
|---|---|---|---|
| Kafka integrado | Woodpecker (MinIO) | Compatível | Compatível |
| Kafka externo | Woodpecker (MinIO) | Compatível | Compatível |
| Woodpecker (MinIO) | Kafka externo | Compatível | Compatível |
| Kafka | Woodpecker (local) | Compatível, mas não recomendado (todos os pods necessitam de um sistema de ficheiros partilhado) | Não suportado |
