Use o Data Transmission Service (DTS) para migrar um banco de dados Redis autogerenciado para o Tair (compatível com Redis OSS) sem interromper o serviço. O DTS oferece suporte a migração completa e incremental, mantendo o banco de dados source online durante todo o processo.
Escolha um método de migração
|
Método |
Funcionamento |
Mais indicado para |
Tempo de inatividade |
|
Full + incremental migration (recomendado) |
Usa a replicação nativa do Redis para transmitir um snapshot de memória e sincroniza alterações incrementais em tempo real |
Bancos de dados de produção que não podem ter tempo de inatividade |
Nenhum |
|
Apenas migração completa |
Usa o comando SCAN para percorrer e copiar todas as chaves |
Bancos de dados onde não é possível executar PSYNC ou SYNC, ou onde as gravações podem ser pausadas |
Pausa breve recomendada durante o cutover |
|
Importação de arquivo AOF |
Importa um Append-Only File (AOF) usando redis-cli |
Migrações offline ou cenários leves |
Obrigatório |
Este tópico aborda a migração baseada em DTS (completa ou completa + incremental). Para importação via AOF, consulte Migrar dados de um arquivo AOF.
Como funciona
A migração completa copia todos os dados existentes do banco de dados source para o destino. Esse processo é gratuito.
A migração incremental ocorre após a migração completa. Após a cópia inicial, o DTS sincroniza continuamente novas gravações do source para o destino usando replicação nativa do Redis (PSYNC ou SYNC). A cobrança baseia-se na duração da migração, e não no volume de dados. Para detalhes de preços, consulte Itens de faturamento.
Antes de iniciar uma migração incremental, desative o limite do buffer de saída de replicação no banco de dados source para evitar quedas de conexão:
CONFIG SET client-output-buffer-limit 'slave 0 0 0'Pré-requisitos
Antes de começar, verifique se:
Instância de destino
Uma instância Tair (compatível com Redis OSS) foi criada. Consulte Criar uma instância.
A instância de destino tem pelo menos 10% a mais de memória do que a memória atualmente usada pelo banco de dados source. Memória insuficiente causa inconsistência de dados ou falha na tarefa.
O Transparent Data Encryption (TDE) está not ativado na instância de destino. O DTS não oferece suporte a migração para instâncias com TDE habilitado.
Source Database
Se usar migração incremental, confirme que o source permite o comando
PSYNCouSYNC.A conta do banco de dados source tem permissões de leitura. Se usar uma conta personalizada, o formato da senha é
<user>:<password>— por exemplo,admin:Rp829dlwa.
Rede
Caso o source esteja em um data center on-premises ou em uma nuvem de terceiros, adicione os endereços IP dos servidores DTS da sua região à lista de permissões do firewall do source. Consulte Adicionar os blocos CIDR dos servidores DTS a uma whitelist.
Observações de uso
Não dimensione a instância, altere o tipo da instância ou modifique o endpoint do banco de dados source ou de destino durante a migração. Essas operações causam falha na tarefa e exigem reconfiguração desde o início.
A migração consome recursos em ambos os bancos de dados. Execute a migração fora dos horários de pico.
A conta do banco de dados de destino deve ter permissões de gravação.
Migrar seu banco de dados Redis
Etapa 1: Abrir a lista de tarefas de migração
Faça logon no console do Data Management (DMS).
Na barra de menu superior, selecione Data + AI > Data Transmission Service (DTS) > Data Migration.
À direita de Migration Tasks, selecione a região onde a instância de destino está localizada.
Etapa 2: Crie uma tarefa
Clique em Create Task.
Etapa 3: Configure bancos de dados source e de destino
Preencha as informações dos bancos de dados source e de destino e clique em Test Connection and Proceed.
Source Database
|
Campo |
Valor |
|
Task Name |
O DTS gera um nome automaticamente. Especifique um nome descritivo para facilitar a identificação. O nome não precisa ser único. |
|
Select DMS database instance |
Se o source já estiver adicionado ao DMS, selecione-o aqui e ignore os campos restantes do source. |
|
Database Type |
Selecione Tair/Redis. |
|
Connection Type |
Escolha com base no local de implantação do source: Public IP para on-premises ou nuvem de terceiros; Self-managed Database On ECS para um banco de dados em uma instância ECS. |
|
Instance Region |
Selecione a região da instância ECS ou a região mais próxima do source se ele estiver fora do Alibaba Cloud. |
|
Cross-Alibaba Cloud account |
Selecione No para migrações dentro da mesma conta. |
|
ECS instance ID |
Selecione a instância ECS que hospeda o banco de dados source. Para arquiteturas de cluster, selecione a instância ECS de qualquer nó mestre. |
|
Instance mode |
Selecione Basic Edition para arquitetura mestre-réplica ou Cluster Edition para arquitetura de cluster. No modo cluster, insira a porta de qualquer nó mestre. |
|
Port |
Insira a porta do Redis source. Padrão: 6379. |
|
Authentication method |
Selecione Password Logon ou Password-free Logon. |
|
Database Password |
Insira a senha no formato |
|
Connection method |
Selecione Unencrypted Connection ou SSL Encrypted Connection. |
Destination Database
|
Campo |
Valor |
|
Select DMS database instance |
Se o destino já estiver adicionado ao DMS, selecione-o aqui. |
|
Database Type |
Tair/Redis (definido por padrão). |
|
Connection Type |
Selecione Cloud Instance. |
|
Instance Region |
Selecione a região da instância de destino. |
|
Instance ID |
Selecione a instância de destino. |
|
Authentication method |
Selecione Password Logon, a menos que você tenha ativado o acesso sem senha para VPCs. |
|
Database Password |
Insira a senha no formato |
|
Connection method |
Selecione Unencrypted Connection ou SSL Encrypted Connection. |
Etapa 4: Selecione objetos e tipo de migração
Configure os objetos da tarefa e clique em Next: Advanced Configuration.
|
Campo |
Valor |
|
Migration types |
Full Migration + Incremental Migration (padrão): transmite um snapshot de memória e depois sincroniza gravações contínuas. Selecione Full Data Migration se não for possível executar PSYNC ou SYNC no source. Com a Full Data Migration, o DTS usa o comando SCAN para percorrer todo o banco de dados source — não grave novos dados no source durante essa migração para garantir a consistência dos dados. |
|
Processing Mode for Existing Tables in Destination |
Precheck and Block on Error (padrão): bloqueia a tarefa se alguma chave já existir no destino. Ignore and Continue: ignora a verificação e substitui quaisquer chaves com nomes correspondentes. |
|
Source objects e Selected objects |
Selecione os bancos de dados a serem migrados (DB 0–255) e mova-os para Selected Objects. Para desmarcar, mova-os de volta usando a seta inversa. |
Etapa 5: Defina configurações avançadas (opcional)
Na maioria dos casos, mantenha os padrões. Clique em Next: Data Validation quando terminar.
|
Campo |
Padrão |
Descrição |
|
Retry time for failed connections |
720 min (intervalo: 10–1440 min) |
O DTS tenta reconectar durante este período. As cobranças continuam durante as novas tentativas. Defina como 30 minutos ou mais. |
|
Retry time for other issues |
10 min (intervalo: 10–1440 min) |
O DTS repete erros de não conectividade durante este período. Defina como 10 minutos ou mais. |
|
Enable throttling for incremental data migration |
Não |
Limita linhas e volume de dados por segundo para reduzir a carga na instância de destino. |
|
Environment tag |
— |
Tag opcional para identificar a instância. |
|
Extend key expiration time in the destination database |
1800s |
Estende os TTLs das chaves migradas. Chaves já expiradas no momento da migração não são migradas. |
|
Use slave node |
Não (lê do mestre) |
Para sources em modo cluster, escolha se deseja ler de um nó réplica. |
|
Configure ETL |
Não |
Ative para configurar o processamento de extração, transformação e carga (ETL). Consulte Configurar ETL em uma tarefa de migração ou sincronização do DTS. |
|
Monitoring and alerting |
Não |
Ative para receber alertas quando a migração falhar ou a latência exceder um limiar. Consulte Configurar alertas durante a configuração da instância. |
Etapa 6: Configure validação de dados (opcional)
Mantenha os padrões na maioria dos casos. Clique em Next: Save Task and Precheck. Para detalhes, consulte Configurar validação de dados para uma instância de sincronização ou migração do DTS.
Etapa 7: Execute a pré-verificação
Clique em Next: Purchase após a conclusão bem-sucedida da pré-verificação.
Se algum item mostrar Warning ou Failed:
Clique em View Details para visualizar as instruções de correção de cada item.
Opcionalmente, clique em Confirm Alert Details para ignorar um aviso — mas ignorar avisos pode causar inconsistência de dados.
Após corrigir todos os problemas, execute a pré-verificação novamente.
Para erros comuns de pré-verificação, consulte Problemas de pré-verificação.
Etapa 8: Comprar e iniciar
Na página Purchase:
(Opcional) Selecione um Resource Group para o link de migração. O grupo de recursos padrão será usado se nenhum for especificado.
(Opcional) Selecione uma classe de instância. Uma classe superior oferece migração mais rápida, mas custa mais. O padrão é large. Para especificações, consulte Especificações de link de migração de dados.
Leia e aceite os termos de serviço e clique em Purchase and Start.
Após a compra, a tarefa de migração é iniciada. Acompanhe o progresso na página Data Migration.
Próximos passos
Apenas migração incremental: Depois que todos os dados estiverem sincronizados, pare ou libere manualmente a tarefa no console do DTS antes de alternar sua aplicação para a nova instância.
Verifique dados migrados: Consulte Validar dados migrados.
Perguntas frequentes
Por que o teste de conexão falha?
Verifique o formato da senha — as credenciais do Redis usam a sintaxe user:password. Para mais detalhes sobre métodos de login, consulte Métodos de logon para uma instância. Se o source estiver atrás de um firewall (on-premises ou nuvem de terceiros), adicione os endereços IP dos servidores DTS da sua região à lista de permissões. Consulte Adicionar os blocos CIDR dos servidores DTS a uma whitelist.
Por que a tarefa de migração falhou?
As causas mais comuns são:
Dimensionamento, alteração do tipo de instância ou mudança de endpoint durante a migração — essas ações exigem reconfigurar a tarefa do zero.
Falta de memória na instância de destino ou um shard em uma instância de cluster atingindo seu limite de memória. O DTS relata um erro OOM (out of memory) e para.
TDE ativado na instância de destino — o DTS não oferece suporte a esta configuração.
Por que há inconsistência de dados após a migração?
Alguns cenários conhecidos causam isso:
Chaves expiradas: Chaves com uma política de TTL (time-to-live) podem expirar antes de serem excluídas. O destino pode ter menos chaves que o source.
Duplicate List entries: Para objetos List, o DTS não limpa os dados existentes no destino ao usar PSYNC ou SYNC. Isso pode produzir duplicatas.
Novas tentativas de rede durante a migração completa: Se a rede for interrompida, o DTS tenta novamente e substitui chaves com o mesmo nome. Operações de exclusão do source durante essa janela de nova tentativa não são sincronizadas, deixando o destino com mais dados que o source.
Por que a pré-verificação valida a política de evicção do Redis?
A maxmemory-policy padrão para Tair (compatível com Redis OSS) é volatile-lru. Se o destino ficar sem memória, essa política remove chaves e causa inconsistência de dados. Definir a política como noeviction faz com que as gravações falhem quando a memória estiver cheia — a tarefa para, mas nenhum dado é descartado silenciosamente. Para detalhes sobre políticas de evicção, consulte Políticas de evicção de dados do Redis.
Por que existe uma chave DTS_REDIS_TIMESTAMP_HEARTBEAT no meu banco de dados source?
O DTS grava uma chave de heartbeat com o prefixo DTS_REDIS_TIMESTAMP_HEARTBEAT para rastrear timestamps de atualização. Para sources em cluster, ele grava uma chave por shard. A chave é filtrada durante a migração e expira automaticamente após o término da tarefa.
Quais comandos a migração incremental suporta?
O DTS captura todos os comandos de gravação padrão do Redis, incluindo:
APPEND, BITOP, BLPOP, BRPOP, BRPOPLPUSH, DECR, DECRBY, DEL, EVAL, EVALSHA, EXEC, EXPIRE, EXPIREAT, FLUSHALL, FLUSHDB, GEOADD, GETSET, HDEL, HINCRBY, HINCRBYFLOAT, HMSET, HSET, HSETNX, INCR, INCRBY, INCRBYFLOAT, LINSERT, LPOP, LPUSH, LPUSHX, LREM, LSET, LTRIM, MOVE, MSET, MSETNX, MULTI, PERSIST, PEXPIRE, PEXPIREAT, PFADD, PFMERGE, PSETEX, PUBLISH, RENAME, RENAMENX, RESTORE, RPOP, RPOPLPUSH, RPUSH, RPUSHX, SADD, SDIFFSTORE, SELECT, SET, SETBIT, SETEX, SETNX, SETRANGE, SINTERSTORE, SMOVE, SPOP, SREM, SUNIONSTORE, ZADD, ZINCRBY, ZINTERSTORE, ZREM, ZREMRANGEBYLEX, ZUNIONSTORE, ZREMRANGEBYRANK, ZREMRANGEBYSCORE, XADD, XCLAIM, XDEL, XAUTOCLAIM, XGROUP CREATECONSUMER, XTRIM
Para scripts Lua executados via EVAL ou EVALSHA, o DTS não consegue confirmar se o script teve sucesso porque o destino não retorna um resultado explícito.