Ao atualizar a especificação de tráfego de uma instância do ApsaraMQ for Kafka, o cluster pode expandir com a adição de brokers. Após essa expansão, as partições dos tópicos existentes permanecem nos brokers originais e continuam sujeitas aos limites de tráfego anteriores à atualização. Rebalanceie o tráfego dos tópicos para redistribuir as partições entre todos os brokers, incluindo os novos, e permitir que os tópicos existentes utilizem a capacidade adicional.
Os tópicos criados após a expansão são distribuídos automaticamente entre todos os brokers e não estão sujeitos aos limites de tráfego anteriores à atualização.
Em instâncias serverless do ApsaraMQ for Kafka, o rebalanceamento de tópicos ocorre automaticamente. Nenhuma ação manual é necessária.
Pré-requisitos
Antes de começar, verifique se você tem:
Uma instância do ApsaraMQ for Kafka no estado Running (Pending Rebalancing)
Uma instância entra no estado Running (Pending Rebalancing) após a expansão do cluster. Para obter mais informações sobre a atualização de especificações de tráfego e as condições que acionam a expansão, consulte Atualizar configurações da instância.
Rebalancear o tráfego de tópicos no console
Faça login no console do ApsaraMQ for Kafka.
Na seção Resource Distribution da página Overview, selecione a região onde sua instância está localizada.
Na página Instances, clique em nome da instância que deseja gerenciar.
Na página Instance Details, clique em Rebalance Topic Traffic no canto superior direito da seção Overview.
No painel Rebalance Topic Traffic for Instance, selecione um Traffic Rebalancing Method. Para detalhes sobre cada método, consulte Métodos de rebalanceamento.
Após selecionar um método, todos os tópicos da instância entram no estado Pending Rebalancing. Verifique o status do tópico na coluna Status da página Topics.
Resultado
Depois que o tráfego dos tópicos é rebalanceado, todos os tópicos retornam ao estado Running. Confirme o status do tópico na coluna Status da página Topics.
Métodos de rebalanceamento
Escolha o método de rebalanceamento adequado aos requisitos da sua carga de trabalho. A tabela a seguir resume os métodos disponíveis:
|
Método |
Duração |
Alteração na contagem de partições |
Impacto na ordenação de mensagens |
|
Migrate Data from Partitions of All Topics (Recommended) (recomendado) |
Segundos (armazenamento em nuvem) a horas (armazenamento local) |
Não |
Não |
|
Add Partitions to All Topics |
Segundos |
Sim |
Sim |
|
Do Not Rebalance (Not Recommended) |
Imediato |
Não |
Não |
Migrar dados das partições de todos os tópicos (recomendado)
Redistribui as partições existentes entre todos os brokers sem alterar a contagem de partições. Este é o método recomendado para todos os cenários de expansão.
O comportamento varia conforme o mecanismo de armazenamento:
|
Mecanismo de armazenamento |
Funcionamento |
Impacto |
Duração |
|
Armazenamento em nuvem |
Modifica o mapeamento entre partição e broker sem migrar dados. |
Nenhum tráfego interno temporário é gerado. |
Segundos. Cada tópico leva aproximadamente 30 segundos. |
|
Armazenamento local |
Utiliza a ferramenta |
Gera tráfego interno temporário durante a migração. |
Minutos a horas, dependendo do volume de dados. Para grandes conjuntos de dados, a migração pode levar várias horas ou mais. |
A definição do armazenamento local como mecanismo de armazenamento só é possível durante a criação de tópicos em instâncias da Professional Edition. Para migrações com armazenamento local, execute o rebalanceamento fora dos horários de pico para minimizar o impacto do tráfego interno temporário nas suas cargas de trabalho.
Adicionar partições a todos os tópicos
Cria novas partições nos novos brokers para todos os tópicos existentes. Trata-se do método mais rápido, porém altera a contagem de partições.
Duração: Segundos.
Impacto:
Novas mensagens nas partições adicionadas podem chegar fora de ordem.
A contagem total de partições aumenta. Caso seu cliente não detecte automaticamente as novas partições, reinicie-o ou atualize o código do cliente. Essa situação aplica-se a cenários de extração, transformação e carga (ETL) e a casos em que as mensagens são enviadas ou consumidas de partições específicas.
Mais indicado para: Cargas de trabalho que não exigem ordenação de partições, onde o tópico de destino não é especificado para produção de mensagens e o modo de consumo é por assinatura.
Não rebalancear
Nenhuma ação é executada. Os tópicos existentes permanecem nos brokers anteriores à expansão. Já os tópicos criados após a expansão são distribuídos uniformemente entre todos os brokers.
Duração: Entra em vigor imediatamente.
Impacto:
Os tópicos existentes continuam sujeitos à especificação de tráfego adquirida antes da expansão.
Se o volume de tráfego dos tópicos existentes for alto, o tráfego dos brokers pode ficar desequilibrado.
Recomendado quando: O tráfego dos tópicos existentes é baixo e improvável de aumentar, ou quando a maior parte do tráfego é direcionada a novos tópicos criados após a expansão.
Ignorar o rebalanceamento impede que os tópicos originais utilizem a capacidade atualizada.
Observações de uso
Enquanto a instância estiver no estado Running (Pending Rebalancing):
Continue enviando e recebendo mensagens normalmente.
Não crie recursos, como tópicos e grupos de consumidores, até que o rebalanceamento seja concluído.
O rebalanceamento é opcional. Se não for necessário que os tópicos originais usem a capacidade atualizada, selecione Do Not Rebalance. Para mais detalhes, consulte Não rebalancear.