Introdução

Existem vários métodos que você pode usar para migrar dados de uma instância Redis para outra, tais como a replicação ou o snapshotting. No entanto, as migrações podem ficar mais complicadas quando você está movendo dados para uma instância Redis gerenciada por um provedor de nuvem, uma vez que os bancos de dados gerenciados muitas vezes limitam o controle que você tem sobre a configuração dos mesmos.

Este tutorial descreve um método que você pode usar para migrar dados para uma instância do Redis gerenciada pela DigitalOcean. O método usa o comando interno migrate do Redis para transmitir dados com segurança por um túnel TLS configurado com o stunnel. Este guia também abordará algumas outras estratégias de migração comumente usadas, e por que elas são problemáticas ao migrar para um Banco de dados gerenciado na DigitalOcean.

Pré-requisitos

Para concluir este tutorial, você precisará de:

Nota: Para ajudar a manter as coisas claras, este guia fará referência à instância Redis hospedada no seu servidor Ubuntu como a “origem”. Da mesma forma, ele se referirá à instância gerenciada pela DigitalOcean como o “destino” ou o “Banco de Dados Gerenciado”.

Coisas a Considerar ao Migrar Dados do Redis para um Banco de Dados Gerenciado

Existem vários métodos que você pode empregar para migrar dados de uma instância Redis para outra. No entanto, algumas dessas abordagens apresentam problemas ao migrar dados para uma instância Redis gerenciada pela DigitalOcean.

Por exemplo, você pode usar a replicação para transformar sua instância Redis de destino em uma cópia exata da origem. Para fazer isso, você se conectaria ao servidor Redis de destino e executaria o comando replicaof com a seguinte sintaxe:

  • replicaof ip_ou_hostname_da_origem porta_da_origem

Isso fará com que a instância de destino replique todos os dados mantidos na origem sem destruir nenhum dado que estava armazenado anteriormente nela. Depois disso, você promoveria a réplica de volta a ser uma instância primária com o seguinte comando:

  • replicaof no one

No entanto, as instâncias Redis gerenciadas pela DigitalOcean são configuradas para se tornarem somente réplicas de leitura. Se você tiver clientes gravando dados no banco de dados de origem, você não poderá configurá-los para gravar na instância gerenciada, pois ela está replicando dados. Isso significa que você perderia todos os dados enviados pelos clientes após promover a instância gerenciada como uma réplica e antes de configurá-los para começar a gravar dados nela, tornando a replicação uma solução de migração ineficiente.

Outro método para migrar dados do Redis é tirar um snapshot ou instantâneo dos dados mantidos em sua instância de origem com um dos comandos save ou bgsave do Redis. Ambos os comandos exportam o snapshot para um arquivo que termina em .rdb, que você então transfere para o servidor de destino. Depois disso, você reiniciaria o serviço Redis para que ele possa carregar os dados.

No entanto, muitos provedores de bancos de dados gerenciados — incluindo a DigitalOcean — não permitem acessar o sistema de arquivos subjacente do servidor de banco de dados gerenciado. Isso significa que não há como fazer upload do arquivo de snapshot ou fazer as alterações necessárias no arquivo de configuração do banco de dados de destino para permitir que os Redis importe os dados.

Como a configuração dos bancos de dados gerenciados da DigitalOcean limita a eficácia tanto da replicação e quanto do snapshotting como meio de migração de dados, este tutorial utilizará o comando migrate do Redis para mover dados da origem para o destino. O comando migrate é projetado para mover apenas uma chave de cada vez, mas vamos usar alguns truques de linha de comando para mover um banco de dados Redis inteiro com um único comando.

Passo 1 — (Opcional) Populando sua Instância Redis de Origem com Dados de Amostra

Este passo opcional envolve o carregamento da instância Redis de origem com alguns dados de amostra para que você possa experimentar a migração de dados para o banco de dados Redis gerenciado. Se você já possui dados que deseja migrar para sua instância de destino, você pode avançar para o Passo 2.

Para começar, execute o seguinte comando para acessar o seu servidor Redis:

  • redis-cli

Se você configurou seu servidor Redis para exigir autenticação por senha, execute o comando auth seguido da sua senha Redis:

  • auth senha

Em seguida, execute os seguintes comandos. Isso criará um número de chaves contendo algumas strings, um hash, uma lista e um set:

  • mset string1 "Redis" string2 "is" string3 "fun!"
  • hmset hash1 field1 "Redis" field2 "is" field3 "fast!"
  • rpush list1 "Redis" "is" "feature-rich!"
  • sadd set1 "Redis" "is" "free!"

Além disso, execute os seguintes comandos expire para fornecer um tempo limite para algumas dessas chaves. Isso as tornará voláteis, o que significa que o Redis as excluirá após o período especificado, 7500 segundos:

  • expire string2 7500
  • expire hash1 7500
  • expire set1 7500

Com isso, você tem alguns dados de exemplo que podem ser exportados para sua instância Redis de destino. Você pode manter o prompt do redis-cli aberto por enquanto, pois executaremos mais alguns comandos a partir dele no próximo passo para fazer backup desses dados.

Passo 2 — Fazendo Backup dos Seus Dados

Anteriormente, discutimos o uso do comando bgsave do Redis para tirar uma snapshot de um banco de dados Redis e migrá-lo para outra instância. Embora não utilizemos o bgsave como meio de migrar os dados do Redis, vamos usá-lo aqui para fazer backup dos dados, caso encontremos um erro durante o processo de migração.

Se você ainda não o tiver aberto, comece abrindo a interface de linha de comandos do Redis:

  • redis-cli

Além disso, se você configurou o seu servidor Redis para exigir autenticação por senha, execute o comando auth seguido da sua senha Redis:

  • auth senha

Em seguida, execute o comando bgsave. Isso criará um snapshot do seu data set atual e o exportará para um arquivo de dump cujo nome termina em .rdb:

  • bgsave

Nota: Conforme mencionado na seção anterior Coisas a Considerar, você pode tirar um snapshot do seu banco de dados Redis com os comandos save ou bgsave. A razão pela qual usamos o comando bgsave aqui é que o comando save é executado de forma síncrona, o que significa que ele bloqueará quaisquer outros clientes conectados ao banco de dados. Por isto, a documentação do comando save recomenda que esse comando quase nunca seja executado em um ambiente de produção.

Em vez disso, ela sugere o uso do comando bgsave, que executa de forma assíncrona. Isso fará com que o Redis faça um fork do banco de dados em dois processos: o processo pai continuará a servir os clientes enquanto o filho salva o banco de dados antes de sair:

Observe que se os clientes adicionarem ou modificarem dados enquanto a operação bgsave estiver em execução ou após a conclusão, essas alterações não serão capturadas no snapshot.

Depois disso, você pode fechar a conexão com sua instância Redis executando o comando exit:

  • exit

Se você precisar no futuro, você poderá encontrar este arquivo de dump no seu diretório de trabalho da instalação do Redis. Se você não tiver certeza de qual diretório é esse, pode verificar abrindo seu arquivo de configuração Redis com o seu editor de texto preferido. Aqui, usaremos o nano:

  • sudo nano /etc/redis/redis.conf

Navegue até a linha que começa com dbfilename. Por padrão, ele se apresentará assim:

/etc/redis/redis.conf
. . .
# The filename where to dump the DB
dbfilename dump.rdb
. . .

Esta diretiva define o arquivo para o qual o Redis exportará snapshots. A próxima linha (após qualquer comentário) ficará assim:

/etc/redis/redis.conf
. . .
dir /var/lib/redis
. . .

A diretiva dir define o diretório de trabalho do Redis onde os snapshots são armazenados. Por padrão, isso é definido como /var/lib/redis, como mostrado neste exemplo.

Feche o arquivo redis.conf. Supondo que você não tenha alterado o arquivo, você pode fazer isso pressionando CTRL+X.

Em seguida, liste o conteúdo do seu diretório de trabalho Redis para confirmar que ele está mantendo o arquivo de dump de dados exportado:

  • sudo ls /var/lib/redis

Se o arquivo de dump foi exportado corretamente, você o verá na saída deste comando:

Output
dump.rdb

Depois de confirmar que você fez backup dos seus dados com êxito, você pode iniciar o processo de migração para o seu Banco de Dados Gerenciado.

Passo 3 — Migrando os Dados

Lembre-se de que este guia usa o comando interno migrate do Redis para mover as chaves uma a uma do banco de dados de origem para o destino. No entanto, ao contrário dos passos anteriores deste tutorial, não executaremos este comando no prompt redis-cli. Em vez disso, vamos executá-lo diretamente no prompt bash do servidor. Isso nos permitirá usar alguns truques do bash para migrar todas as chaves no banco de dados de origem com um comando.

Nota: Se você tiver clientes gravando dados na sua instância Redis de origem, agora seria um bom momento para configurá-los para também gravar dados no seu Banco de Dados Gerenciado. Dessa forma, você pode migrar os dados existentes da origem para o seu destino sem perder nenhuma gravação que ocorra após a migração.

Além disso, esteja ciente de que este comando de migração não substituirá nenhuma chave existente no banco de dados de destino, a menos que uma das chaves existentes tenha o mesmo nome da chave que você está migrando.

A migração ocorrerá após a execução do seguinte comando. Antes de executá-lo, porém, vamos dividi-lo parte por parte:

  • redis-cli -n banco_de_dados_de_origem -a senha_da_origem scan 0 | while read key; do redis-cli -n banco_de_dados_de_origem -a senha_da_origem MIGRATE localhost 8000 "$key" banco_de_dados_de_destino 1000 COPY AUTH senha_do_redis_gerenciado; done

Vamos analisar cada parte deste comando separadamente:

  • redis-cli -n banco_de_dados_de_origem -a senha_da_origem scan 0 . . .

A primeira parte do comando, redis-cli, abre uma conexão com o servidor Redis local. A flag -n especifica a qual dos bancos de dados lógicos do Redis se conectar. O Redis possui 16 bancos de dados prontos para uso (com o primeiro sendo numerado como 0, o segundo numerado como 1 e assim por diante), portanto, banco_de_dados_de_origem pode ser qualquer número entre 0 e 15. Se sua instância de origem mantém apenas dados no banco de dados padrão (numerado como 0), você não precisará incluir a flag -n ou especificar um número de banco de dados.

A seguir, vem a flag -a e a senha da instância de origem, que juntos autenticam a conexão. Se sua instância de origem não exigir autenticação por senha, você não precisará incluir a flag -a.

Em seguida, ele executa o comando scan do Redis, que itera sobre as chaves mantidas no data set e as retorna como uma lista. O scan requer ser seguido de um cursor — a iteração começa quando o cursor está definido como 0, e termina quando o servidor retorna um cursor 0. Portanto, seguimos o scan com um cursor 0 para iterar sobre todas as chaves do conjunto.

  • . . . | while read key; do . . .

A próxima parte do comando começa com uma barra vertical (|). Nos sistemas tipo Unix, as barras verticais são conhecidas como pipes e são usadas para direcionar a saída de um processo para a entrada de outro.

A seguir, é iniciado o loop while. No bash, assim como na maioria das linguagens de programação, um loop while é uma declaração de fluxo de controle que permite repetir um determinado processo, código ou comando, enquanto uma certa condição permanecer verdadeira.

A condição neste caso é o subcomando read key, que lê a entrada que foi canalizada e a atribui à variável key. O ponto-e-vírgula (;) significa o final da declaração condicional do loop while, e o do a seguir precede a ação que será repetida enquanto a expressão while permanecer verdadeira. Toda vez que a instrução do for concluída, a instrução condicional lerá a próxima linha canalizada a partir do comando scan e atribuirá essa entrada à variável key.

Essencialmente, esta seção diz “enquanto houver saída do comando scan para ser lida, execute a seguinte ação”.

  • . . . redis-cli -n banco_de_dados_de_origem -a senha_da_origem migrate localhost 8000 "$key" . . .

Esta seção do comando é a que executa a migração real. Após outra chamada do redis-cli, ela especifica mais uma vez o número do banco de dados de origem com a flag -n e autentica com a flag -a. Você precisa incluí-las novamente, porque essa chamada redis-cli é distinta daquela no início do comando. Mais uma vez, porém, você não precisa incluir a flag -n ou o número do banco de dados se a instância Redis de origem mantém apenas dados no banco de dados padrão 0, e você não precisa incluir a flag -a se ela não requer autenticação por senha.

A seguir, está o comando migrate. Sempre que você usar o comando migrate, deverá segui-lo com o nome do host ou endereço IP do banco de dados de destino e o número da porta. Aqui, seguimos a convenção estabelecida no tutorial de pré-requisito do stunnel e apontamos o comando migrate para localhost na porta 8000.

$key é a variável definida na primeira parte do loop while e representa as chaves de cada linha da saída do comando scan.

  • . . . banco_de_dados_de_destino 1000 copy auth senha_do_redis_gerenciado; done

Esta seção é uma continuação do comando migrate. Ela começa com banco_de_dados_de_destino, que representa o banco de dados lógico na instância de destino em que você deseja armazenar os dados. Novamente, este pode ser qualquer número entre 0 e 15.

Em seguida está um número que representa um tempo limite. Esse tempo limite é a quantidade máxima de tempo de comunicação inativa entre as duas máquinas. Observe que este não é um limite de tempo para a operação, apenas que a operação deve sempre fazer algum nível de progresso dentro do tempo limite definido. Tanto o número do banco de dados quanto os argumentos de tempo limite são necessários para cada comando migrate.

Após o tempo limite está a flag opcional copy. Por padrão, o migrate excluirá cada chave do banco de dados de origem depois de transferi-la para o destino; Ao incluir esta opção, você está instruindo o comando migrate a meramente copiar as chaves para que elas persistam na origem.

Após o copy, aparece a flag auth, seguido da senha do seu Banco de Dados Redis Gerenciado. Isso não é necessário se você estiver migrando dados para uma instância que não requer autenticação, mas é necessário quando você estiver migrando dados para um banco gerenciado pela DigitalOcean.

A seguir, outro ponto-e-vírgula, indicando o final da ação a ser executada enquanto a condição while for verdadeira. Finalmente, o comando fecha com done, indicando o fim do loop. O comando verifica a condição na instrução while e repete a ação na instrução do até que ela não seja mais verdadeira.

Em conjunto, este comando executa os seguintes passos:

  • Examina um banco de dados na instância Redis de origem e retorna todas as chaves nela contidas
  • Passa cada linha da saída do comando scan para um loop while
  • Lê a primeira linha e atribui seu conteúdo à variável key
  • Migra qualquer chave no banco de dados de origem que corresponda à variável key para um banco de dados na instância Redis na outra extremidade do túnel TLS mantida em localhost na porta 8000
  • Volta e lê a próxima linha, e repete o processo até que não haja mais chaves para ler

Agora que examinamos cada parte do comando de migração, você pode prosseguir e executá-lo.

Se sua instância de origem tiver apenas dados no banco de dados 0 padrão, você não precisa incluir quaisquer das flags -n ou seus argumentos. Se, no entanto, você estiver migrando dados de qualquer banco de dados que não seja o 0 na sua instância de origem, você deve incluir as flags -n e alterar as duas ocorrências de banco_de_dados_de_origem para alinhar com o banco de dados que você deseja migrar.

Se o seu banco de dados de origem exigir autenticação por senha, certifique-se de alterar senha_da_origem para a senha real da instância do Redis. Caso contrário, certifique-se de remover ambas as ocorrências de -a senha_da_origem do comando. Além disso, altere senha_do_redis_gerenciado para a senha do seu Banco de Dados Gerenciado e certifique-se de alterar banco_de_dados_de_destino para o número do banco de dados lógico na sua instância de destino em que você deseja gravar os dados:

Nota: Se você não tiver a senha do seu banco de dados Redis gerenciado em mãos, poderá encontrá-la navegando primeiramente para o Painel de controle da DigitalOcean. A partir daí, clique em Databases no menu da barra lateral esquerda e depois clique no nome da instância Redis para a qual você deseja migrar os dados. Role para baixo até a seção Connection Details, onde você encontrará um campo chamado password. Clique no botão show para revelar a senha e copie e cole-a no comando de migração — substituindo senha_do_redis_gerenciado - para autenticar.

  • redis-cli -n banco_de_dados_de_origem -a senha_da_origem scan 0 | while read key; do redis-cli -n banco_de_dados_de_origem -a senha_da_origem MIGRATE localhost 8000 "$key" banco_de_dados_de_destino 1000 COPY AUTH senha_do_redis_gerenciado; done

Você verá uma saída semelhante à seguinte:

Output
NOKEY OK OK OK OK OK OK

Nota: Observe a primeira linha da saída do comando que lê NOKEY. Para entender o que isso significa, execute a primeira parte do comando de migração sozinho:

  • redis-cli -n banco_de_dados_de_origem -a senha_da_origem scan 0

Se você migrou os dados de amostra adicionados no Passo 2, a saída deste comando será parecida com esta:

Output
1) "0" 2) 1) "hash1" 2) "string3" 3) "list1" 4) "string1" 5) "string2" 6) "set1"

O valor "0" mantido na primeira linha não é uma chave mantida no seu banco de dados Redis de origem, mas um cursor retornado pelo comando scan. Como não há chaves no servidor denominadas “0”, não há nada lá para o comando migrate enviar à sua instância de destino e ele retorna NOKEY.

No entanto, o comando não falha e sai. Em vez disso, ele continua lendo e migrando as chaves encontradas nas próximas linhas da saída do comando scan.

Para testar se a migração foi bem-sucedida, conecte-se ao seu Banco de Dados Redis Gerenciado:

  • redis-cli -h localhost -p 8000 -a senha_do_redis_gerenciado

Se você migrou dados para qualquer banco de dados lógico que não o padrão, conecte-se a esse banco de dados com o comando select:

  • select banco_de_dados_de_destino

Execute um comando scan para ver quais chaves são mantidas lá:

  • scan 0

Se você concluiu o Passo 2 deste tutorial e adicionou os dados de exemplo ao seu banco de dados de origem, você verá resultados como este:

Output
1) "0" 2) 1) "set1" 2) "string2" 3) "hash1" 4) "list1" 5) "string3" 6) "string1"

Por fim, execute um comando ttl em qualquer chave que você configurou para expirar para confirmar que ela ainda é volátil:

  • ttl string2
Output
(integer) 3944

Esta saída mostra que, embora você tenha migrado a chave para o seu Banco de Dados Gerenciado, ela ainda está configurada para expirar com base no comando expireat que você executou anteriormente.

Depois de confirmar que todas as chaves do seu banco de dados Redis de origem foram exportadas para o destino com êxito, você pode fechar sua conexão com o Banco de Dados Gerenciado. Se você tiver clientes gravando dados na instância Redis de origem e já os configurou para enviar suas gravações para o destino, nesse momento você pode configurá-los para parar de enviar dados para a origem.

Conclusão

Ao concluir este tutorial, você transferiu os dados do seu repositório de dados Redis autogerenciado para uma instância Redis gerenciada pela DigitalOcean. O processo descrito neste guia pode não ser o ideal em todos os casos. Por exemplo, você teria que executar o comando de migração várias vezes (uma vez para cada banco de dados lógico que contém dados) se sua instância de origem estiver usando bancos de dados diferentes do padrão. No entanto, quando comparado a outros métodos, como replicação ou snapshotting, este é um processo bastante direto que funciona bem com a configuração de um Banco de Dados Gerenciado pela DigitalOcean.

Agora que você está usando um Banco de Dados Redis Gerenciado pela DigitalOcean para armazenar seus dados, você pode medir seu desempenho executando alguns testes de benchmarking. Além disso, se você é novo no trabalho com o Redis, você pode conferir nossa série Como Gerenciar um Banco de Dados Redis.

0 Comments

Creative Commons License