Tair (Redis® OSS-Compatible):Migração unidirecional entre instâncias

Comparação dos métodos de migração

¹ Recomenda-se usar a mesma versão de banco de dados na origem e no destino para evitar problemas de compatibilidade.

² Antes de migrar de uma instância com arquitetura padrão para uma instância com arquitetura cluster ou de divisão de leitura/escrita, revise os limites de comandos dessas arquiteturas.

Como o DTS migra dados

O DTS oferece dois tipos de migração. Selecione ambos ao configurar uma tarefa para migrar dados sem interromper o banco de dados de origem.

• Full Migration + Incremental Migration (padrão): usa a lógica nativa SYNC/PSYNC do Redis para gravar dados de um snapshot de memória no destino e, em seguida, sincroniza atualizações incrementais em tempo real. A migração completa é gratuita; a migração incremental é faturada por duração.

• Full Data Migration: usa o comando SCAN para percorrer todo o banco de dados de origem. Não grave na origem durante esse tipo de migração, pois isso pode causar inconsistência de dados.

Pré-requisitos

Antes de começar, verifique se:

• Existe uma instância de destino Tair (compatível com Redis OSS).

• A instância de destino tem mais memória total do que a quantidade atualmente usada pela instância de origem — pelo menos 10% a mais. Por exemplo, se a origem estiver usando 10 GB, o destino precisa de pelo menos 11 GB de memória total. Memória insuficiente no destino causa inconsistência de dados ou falha na tarefa.

• O Transparent Data Encryption (TDE) not está ativado na instância de destino. O DTS não suporta migração para instâncias com TDE habilitado.

• A instância de destino não está executando a versão 2,8 do Tair (compatível com Redis OSS). O DTS não suporta instâncias 2,8.

Limitações

• Não dimensione, altere o tipo de instância ou modifique o endpoint do banco de dados de origem ou de destino enquanto uma tarefa de migração estiver em execução. Essas operações causam falha na tarefa e exigem reconfiguração.

• Execute a migração fora dos horários de pico, pois o processo consome recursos em ambas as instâncias.

• A pré-verificação confirma se a política de evicção do banco de dados de destino está definida como noeviction. A política padrão do Tair (compatível com Redis OSS) é volatile-lru. Se o destino ficar sem memória com volatile-lru, os dados serão removidos silenciosamente, causando inconsistência. Definir noeviction faz com que as gravações falhem (e a tarefa também falhe) caso a memória acabe, mas nenhum dado é removido silenciosamente. Para mais informações, consulte Políticas de evicção de dados do Redis.

Configurar uma tarefa de migração

Perguntas frequentes

Por que o teste de conexão falha?

Verifique os seguintes pontos:

• A conta ou senha está incorreta. O formato da senha do Redis é user:password. Para mais informações, consulte Métodos de login para uma instância.

• Se o banco de dados de origem estiver em um data center local ou em uma nuvem de terceiros, um firewall de rede pode estar bloqueando o DTS. Adicione os endereços IP dos servidores DTS da sua região à lista de permissões do firewall. Para instruções, consulte Adicionar os blocos CIDR dos servidores DTS a uma lista de permissões.

Por que a tarefa de migração falha?

• Dimensionar, alterar o tipo de instância ou mudar o endpoint da instância de origem ou de destino durante a migração causa falha na tarefa. Reconfigure a tarefa após a conclusão da operação.

• Se a instância de destino ou um shard do cluster ficar sem memória (erro OOM), a tarefa falhará. Certifique-se de que o destino tenha memória suficiente antes de iniciar.

• Se o TDE estiver habilitado na instância de destino, a migração via DTS não é suportada.

Por que há inconsistência de dados?

• Chaves TTL: Se algumas chaves na origem tiverem uma política de tempo de vida (TTL), o destino poderá ter menos chaves porque as chaves expiradas podem não ser excluídas imediatamente.

• Objetos List: O DTS não executa um FLUSH nos dados List existentes no destino ao usar PSYNC ou SYNC, o que pode resultar em entradas duplicadas.

• Tentativas de migração completa: Se a rede for interrompida durante a migração completa, o DTS tenta novamente e sobrescreve chaves com o mesmo nome. Se a origem excluir uma chave durante uma nova tentativa, essa exclusão não será sincronizada, então o destino pode temporariamente ter mais dados que a origem.

Por que não consigo selecionar uma instância Tair (compatível com Redis OSS) 2,8?

O DTS não suporta instâncias Tair (compatíveis com Redis OSS) 2,8.

Por que a pré-verificação confirma se a política de evicção está definida como noeviction?

A política de evicção padrão (maxmemory-policy) do Tair (compatível com Redis OSS) é volatile-lru. Se o destino ficar sem memória, essa política aciona a evicção de dados, causando inconsistência entre origem e destino sem falhar a tarefa. Definir a política como noeviction evita perda silenciosa de dados: se a memória acabar, as gravações falham e a tarefa falha, mas nenhum dado é removido. Para mais informações, consulte Políticas de evicção de dados do Redis.

Por que existe uma chave DTS_REDIS_TIMESTAMP_HEARTBEAT no banco de dados de origem?

Para monitorar a qualidade da migração e sincronização, o DTS insere uma chave com o prefixo DTS_REDIS_TIMESTAMP_HEARTBEAT no banco de dados de origem para rastrear timestamps de atualização. Em arquiteturas cluster, o DTS insere essa chave em cada shard. O DTS filtra essa chave durante a migração, e ela expira automaticamente quando a tarefa termina.

Quais comandos são suportados para migração incremental?

Os seguintes comandos são suportados:

• 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

Nota: Para scripts Lua chamados por EVAL ou EVALSHA, o DTS não consegue confirmar se o script foi executado com sucesso no destino, pois o destino não retorna um resultado explícito de execução.

Referências

Se você deseja clonar todos os dados de uma instância Tair (compatível com Redis OSS) para uma nova instância em vez de migrar para uma existente, use o recurso de backup e restauração:

• Restaurar a partir de um conjunto de backups

• Restaurar para um ponto no tempo