One place for hosting & domains

      Migrar

      Cómo hacer una copia de seguridad, restablecer y migrar una base de datos de MongoDB en Ubuntu 20.04


      El autor seleccionó COVID-19 Relief Fund para que reciba una donación como parte del programa Write for DOnations.

      Introducción

      MongoDB es uno de los motores de base de datos más populares de NoSQL. Es famoso por ser escalable, sólido, confiable y fácil de usar. En este artículo, respaldará, restaurará y migrará una base de datos de MongoDB de muestra.

      Importar y exportar una base de datos implica gestionar los datos en un formato legible por el ser humano y compatible con otros productos de software. Por el contrario, las operaciones de copia de seguridad y restauración de MongoDB crean o utilizan datos binarios específicos de MongoDB, que preservan no solo la uniformidad y la integridad de sus datos, sino también sus atributos específicos de MongoDB. Por lo tanto, para migrar, generalmente es preferible usar la copia de seguridad y la restauración siempre que los sistemas de origen y destino sean compatibles.

      Requisitos previos

      Antes de seguir este tutorial, asegúrese de completar los siguientes requisitos previos:

      Salvo que se indique lo contrario, todos los comandos que requieren privilegios root en este tutorial deben ejecutarse como usuario no root con privilegios sudo.

      Paso 1: Usar JSON y BSON en MongoDB

      Antes de continuar con este artículo, es necesario tener algunos conocimientos básicos sobre la materia. Si tiene experiencia con otros sistemas de base de datos NoSQL como Redis, es posible que encuentre algunas similitudes cuando trabaje con MongoDB.

      MongoDB utiliza los formatos JSON y BSON (JSON binario) para almacenar su información. JSON es el formato legible por el ser humano perfecto para exportar y, finalmente, importar sus datos. Además, puede administrar los datos exportados con cualquier herramienta que sea compatible con JSON, incluyendo un editor de texto simple.

      Un ejemplo de documento JSON tiene el siguiente aspecto:

      Example of JSON Format

      {"address":[
          {"building":"1007", "street":"Park Ave"},
          {"building":"1008", "street":"New Ave"},
      ]}
      

      Es conveniente trabajar con JSON, pero no es compatible con todos los tipos de datos disponibles en BSON. Eso significa que habrá la llamada “pérdida de fidelidad” de la información si utiliza JSON. Para respaldar y restaurar, es mejor usar el BSON binario.

      En segundo lugar, no tiene que preocuparse por crear explícitamente una base de datos de MongoDB. Si la base de datos que especifica para la importación no existe todavía, se creará automáticamente. Aún mejor es el caso de la estructura de las colecciones (tablas de base de datos). A diferencia de otros motores de bases de datos, en MongoDB, la estructura se crea de nuevo automáticamente al insertar el primer documento (fila de la base de datos).

      En tercer lugar, en MongoDB, leer o insertar grandes cantidades de datos, como las tareas de este artículo, puede requerir de muchos recursos y utilizar gran parte de su CPU, memoria y espacio de disco. Eso es crucial teniendo en cuenta que MongoDB se suele utilizar para las grandes bases de datos y los macrodatos. La solución más sencilla a este problema es ejecutar las exportaciones y las copias de seguridad durante la noche o en horas no pico.

      En cuarto lugar, la consistencia de la información podría ser un problema si tiene un servidor MongoDB ocupado en el que la información cambia durante el proceso de exportación o respaldo de la base de datos. Una posible solución para este problema es la replicación, que puede considerar cuando avance en el tema de MongoDB.

      Aunque puede usar las funciones de importación y exportación para respaldar y restaurar los datos, hay mejores formas de garantizar la integridad total de sus bases de datos de MongoDB. Para respaldar sus datos, debe usar el comando mongodump. Para restaurar, utilice mongorestore. Veamos cómo funcionan.

      Paso 2: Utilizar mongodump para respaldar una base de datos de MongoDB

      Primero, vamos a respaldar su base de datos de MongoDB.

      Un argumento esencial para mongodump es --db, que especifica el nombre de la base de datos que desea respaldar. Si no se especifica el nombre de la base de datos, mongodump hace una copia de seguridad de todas las bases de datos. El segundo argumento importante es --out, que define el directorio en el que se verterán los datos. Por ejemplo, vamos a respaldar la base de datos newdb y vamos a almacenarla en el directorio /var/backups/mongobackups. Lo ideal es que tengamos cada una de nuestras copias de seguridad en un directorio con la fecha actual como /var/backup/mongobackups/10-29-20.

      Primero, cree el directorio /var/backup/mongobackups:

      • sudo mkdir /var/backups/mongobackups

      Luego, ejecute mongodump:

      • sudo mongodump --db newdb --out /var/backups/mongobackups/`date +"%m-%d-%y"`

      Verá un resultado similar a este:

      Output

      2020-10-29T19:22:36.886+0000 writing newdb.restaurants to 2020-10-29T19:22:36.969+0000 done dumping newdb.restaurants (25359 documents)

      Tenga en cuenta que en la ruta del directorio anterior, hemos usado date +"%m-%d-%y", que obtiene automáticamente la fecha actual. Eso nos permitirá tener copias de seguridad dentro del directorio, como /var/backup/10-29-20/. Esto es especialmente conveniente cuando automatizamos las copias de seguridad.

      En este punto, tenemos una copia de seguridad competa de la base de datos newdb en el directorio /var/backup/mongobackups/10-29-20/newdb/. Esta copia de seguridad tiene todo lo necesario para restaurar el newdb de forma adecuada y preservar la llamada “fidelidad”.

      Como regla general, debe realizar copias de seguridad con regularidad y preferiblemente cuando el servidor está menos cargado. Por lo tanto, puede configurar el comando mongodump como tarea de cron para que se ejecute regularmente, por ejemplo, cada día a la 03:03 a.m.

      Para ello, abra crontab, el editor de Cron:

      Tenga en cuenta que cuando ejecute sudo crontab, editará las tareas de cron para el usuario root. Esto se recomienda porque si establece los crones de su usuario, podrían no ejecutarse correctamente, especialmente si su perfil sudo requiere verificación de contraseña.

      Dentro de la línea de comandos de crontab, inserte el siguiente comando mongodump:

      crontab

      3 3 * * * mongodump --out /var/backups/mongobackups/`date +"%m-%d-%y"`
      

      En el comando anterior, omitimos el argumento --db a propósito porque normalmente querrá tener todas las bases de datos respaldadas.

      Dependiendo del tamaño de su base de datos de MongoDB, es posible que pronto se quede sin espacio en el disco con demasiadas copias de seguridad. Es por eso que también se recomienda limpiar las copias de seguridad antiguas con regularidad o comprimirlas.

      Por ejemplo, para eliminar todas las copias de seguridad de más de siete días, puede usar el siguiente comando bash:

      • find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} ;

      De forma similar al comando mongodump anterior, también puede añadirlo como tarea de cron. Debe ejecutarse justo antes de iniciar la siguiente copia de seguridad, por ejemplo, a las 03:01 a.m. Para ello, abra crontab de nuevo:

      Después de eso, inserte la siguiente línea:

      crontab

      1 3 * * * find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} ;
      

      Guarde y cierre el archivo.

      Completar todas las tareas en este paso garantizará una solución de respaldo adecuada para sus bases de datos de MongoDB.

      Paso 3: Usar mongorestore para restaurar y migrar una base de datos de MongoDB

      Cuando restaura su base de datos de MongoDB desde una copia de seguridad anterior, tiene la copia exacta de su información de MongoDB en un momento determinado, incluyendo todos los índices y los tipos de datos. Esto es especialmente útil cuando desea migrar sus bases de datos de MongoDB. Para restaurar MongoDB, usaremos el comando mongorestore, que funciona con las copias de seguridad binarias que produce mongodump.

      Continuemos nuestros ejemplos con la base de datos newdb y veremos cómo podemos restaurarla desde la copia de seguridad tomada anterior. Primero, especificaremos el nombre de la base de datos con el argumento --nsInclude Usaremos newdb* para restaurar todas las colecciones. Para restaurar una colección única como los restaurantes, utilice newdb.restaurants en su lugar.

      Luego, con --drop, nos aseguraremos de que la base de datos de destino se elimine primero para que la copia de seguridad se restaure en una base de datos limpia. Como argumento final, especificaremos el directorio de la última copia de seguridad, que tendrá un aspecto similar a este: /var/backup/mongobackups/10-29-20/newdb/.

      Una vez que tenga una copia de seguridad con marca de tiempo, puede restaurarla usando este comando:

      • sudo mongorestore --db newdb --drop /var/backups/mongobackups/10-29-20/newdb/

      Verá un resultado similar a este:

      Output

      2020-10-29T19:25:45.825+0000 the --db and --collection args should only be used when restoring from a BSON file. Other uses are deprecated and will not exist in the future; use --nsInclude instead 2020-10-29T19:25:45.826+0000 building a list of collections to restore from /var/backups/mongobackups/10-29-20/newdb dir 2020-10-29T19:25:45.829+0000 reading metadata for newdb.restaurants from /var/backups/mongobackups/10-29-20/newdb/restaurants.metadata.json 2020-10-29T19:25:45.834+0000 restoring newdb.restaurants from /var/backups/mongobackups/10-29-20/newdb/restaurants.bson 2020-10-29T19:25:46.130+0000 no indexes to restore 2020-10-29T19:25:46.130+0000 finished restoring newdb.restaurants (25359 documents) 2020-10-29T19:25:46.130+0000 done

      En el caso anterior, estamos restaurando los datos en el mismo servidor donde creamos la copia de seguridad. Si desea migrar los datos a otro servidor y usar la misma técnica, deberá copiar el directorio de la copia de seguridad, que es /var/backups/mongobackups/10-29-20/newdb/ en nuestro caso, al otro servidor.

      Conclusión

      Ahora, ha realizado algunas tareas esenciales relacionadas con el respaldo, la restauración y la migración de sus bases de datos de MongoDB. Ningún servidor MongoDB de producción debería funcionar sin una estrategia de respaldo fiable, como la que se describe aquí.



      Source link

      Como fazer backup, restaurar e migrar um banco de dados MongoDB no Ubuntu 20.04


      O autor selecionou a COVID-19 Relief Fund​​​​​ para receber uma doação como parte do programa Write for DOnations.

      Introdução

      O MongoDB é um dos mecanismos de banco de dados NoSQL mais populares. Ele é famoso por ser escalonável, robusto, confiável e fácil de usar. Neste artigo, você vai fazer backup, reiniciar e migrar um banco de dados MongoDB de exemplo.

      Importar e exportar um banco de dados significa lidar com dados em um formato legível para humanos que seja compatível com outros produtos de software. Em contrapartida, o backup e as operações de restauração do MongoDB criam ou usam dados binários específicos do MongoDB, que preservam não apenas a consistência e integridade dos seus dados, mas também seus atributos específicos do MongoDB. Assim, para a migração, geralmente é preferível usar o backup e restauração, desde que o sistema de origem e de destino sejam compatíveis.

      Pré-requisitos

      Antes de seguir este tutorial, certifique-se de completar os seguintes pré-requisitos:

      Exceto se explicitamente dito, todos os comandos que exigem privilégios root neste tutorial devem ser executados como um usuário não root com privilégios sudo.

      Passo 1 — Usando o JSON e BSON no MongoDB

      Antes de ir adiante com este artigo, é necessária uma compreensão básica sobre o assunto. Se você tiver experiência com outros sistemas de banco de dados NoSQL como o Redis, pode encontrar algumas similaridades ao trabalhar com o MongoDB.

      O MongoDB usa os formatos JSON e BSON (JSON binário) para armazenar suas informações. O JSON é o formato legível para humanos que é perfeito para exportar e, eventualmente, importar seus dados. Você pode gerenciar ainda mais seus dados exportados com qualquer ferramenta compatível com JSON, incluindo um editor de texto simples.

      Um documento json de exemplo se parece com este:

      Example of JSON Format

      {"address":[
          {"building":"1007", "street":"Park Ave"},
          {"building":"1008", "street":"New Ave"},
      ]}
      

      É conveniente se trabalhar com o JSON, mas ele não suporta todos os tipos de dados disponíveis em BSON. Isso significa que haverá a chamada “perda de fidelidade” das informações se usar o JSON. Para fazer backup e restaurar, é melhor usar o binário BSON.

      Em segundo lugar, você não precisa se preocupar com a criação explícita de um banco de dados MongoDB. Se o banco de dados especificado para importar ainda não existir, ele é criado automaticamente. O caso com a estrutura das coleções (tabelas de bancos de dados) é ainda melhor. Diferentemente de outros mecanismos de bancos de dados, no MongoDB, a estrutura é também criada automaticamente no momento da inserção do primeiro documento (linha do banco de dados).

      Em terceiro lugar, no MongoDB, ler ou inserir grandes quantidades de dados, como as tarefas deste artigo, pode gerar um uso intensivo de recursos e consumir grande parte do seu CPU, memória e espaço em disco. Isso deve ser considerado, já que o MongoDB é frequentemente usado para grandes bancos de dados e Big Data. A solução mais simples para esse problema é executar as exportações e backups durante a noite ou horários fora do pico.

      Em quarto lugar, a consistência das informações pode ser problemática se você tiver um servidor MongoDB ocupado, no qual as informações mudam durante a exportação do banco de dados ou o processo de backup. Uma solução possível para esse problema é a replicação, que você pode considerar quando avançar no tópico do MongoDB.

      Embora você possa usar as funções de importação e exportação para fazer backup e restaurar seus dados, há melhores maneiras de garantir a integridade total dos seus bancos de dados MongoDB. Para fazer backup dos seus dados, você deve usar o comando mongodump. Para restaurar, use o mongorestore. Vamos ver como eles funcionam.

      Passo 2 — Usando o mongodump para fazer backup de um banco de dados MongoDB

      Vamos mostrar primeiro como fazer backup do seu banco de dados MongoDB.

      Um argumento essencial para o mongodump é o --db, que especifica o nome do banco de dados do qual você deseja fazer backup. Se você não especificar um nome de banco de dados, o mongodump faz backup de todos os seus bancos de dados. O segundo argumento importante é o --out, que define o diretório no qual os dados serão despejados. Por exemplo, vamos fazer backup do banco de dados newdb e armazená-lo no diretório /var/backups/mongobackups. Idealmente, teremos cada um dos nossos backups em um diretório com a data atual como /var/backups/mongobackups/10-29-20.

      Primeiramente, crie o diretório /var/backups/mongobackups:

      • sudo mkdir /var/backups/mongobackups

      Em seguida, execute o mongodump:

      • sudo mongodump --db newdb --out /var/backups/mongobackups/`date +"%m-%d-%y"`

      Você verá uma saída como esta:

      Output

      2020-10-29T19:22:36.886+0000 writing newdb.restaurants to 2020-10-29T19:22:36.969+0000 done dumping newdb.restaurants (25359 documents)

      Note que no caminho de diretório acima, usamos date +"%m-%d-%y" que obtém automaticamente a data atual. Isso permitirá que tenhamos backups dentro de um diretório como /var/backups/10-29-20/. Isso é ainda mais conveniente quando automatizamos os backups.

      Neste ponto, você possui um backup completo do banco de dados newdb no diretório /var/backups/mongobackups/10-29-20/newdb/. Esse backup possui todo o necessário para restaurar o newdb corretamente e preservar sua chamada “fidelidade”.

      Como uma regra geral, você deve fazer backups regulares e, de preferência, quando o servidor estiver menos carregado. Assim, você pode definir o comando mongodump como uma tarefa cron para que ele seja executado regularmente, por exemplo, todos os dias às 03:03.

      Para fazer isso, abra o crontab, o editor do cron:

      Note que quando executa sudo crontab, você estará editando as tarefas cron para o usuário root. Isso é recomendado, porque se você definir os crons para seu usuário, eles podem não ser executados corretamente, especialmente se seu perfil sudo exigir uma verificação por senha.

      Dentro do prompt do crontab, insira o seguinte comando mongodump:

      crontab

      3 3 * * * mongodump --out /var/backups/mongobackups/`date +"%m-%d-%y"`
      

      No comando acima, omitimos o argumento --db de propósito, porque geralmente é interessante fazer backup de todos os nossos bancos de dados.

      Dependendo dos tamanhos dos seus bancos de dados MongoDB, é possível esgotar rapidamente o espaço em disco com muitos backups. É por isso que é recomendável limpar os backups antigos regularmente ou compactá-los.

      Por exemplo, para excluir todos os backups com idade maior que sete dias, use o seguinte comando bash:

      • find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} ;

      De maneira similar ao comando mongodump anterior, também é possível adicionar isso como uma tarefa cron. Ele deve ser executado pouco antes de iniciar o próximo backup, por exemplo, às 03:01. Para esse fim, abra novamente o crontab:

      Em seguida, insira a linha a seguir:

      crontab

      1 3 * * * find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} ;
      

      Salve e feche o arquivo.

      A realização de todas as tarefas neste passo garantirá uma solução de backup adequada para seus bancos de dados MongoDB.

      Passo 3 — Usando o mongorestore para restaurar e migrar um banco de dados MongoDB

      Ao restaurar seu banco de dados MongoDB de um backup anterior, você obtém uma cópia exata das suas informações do MongoDB obtidas em um momento específico, incluindo todos os índices e tipos de dados. Isso é especialmente útil quando quiser migrar seus bancos de dados MongoDB. Para restaurar o MongoDB, usaremos o comando mongorestore, que funciona com os backups binários que o mongodump produz.

      Vamos continuar nossos exemplos com o banco de dados newdb e ver como podemos restaurá-lo a partir do backup obtido anteriormente. Primeiramente, vamos especificar o nome do banco de dados com o argumento --nsInclude. Vamos usar o newdb.* para restaurar todas as coleções. Para restaurar uma única coleção como restaurants, use o newdb.restaurants ao invés disso.

      Em seguida, usando o --drop, vamos garantir que o banco de dados de destino seja primeiro descartado, para que depois o backup seja restaurado em um banco de dados limpo. Como um argumento final, vamos especificar o diretório do último backup, que será parecido com isto: /var/backups/mongobackups/10-29-20/newdb/.

      Assim que tiver um backup com carimbo de data/hora, restaure-o usando este comando:

      • sudo mongorestore --db newdb --drop /var/backups/mongobackups/10-29-20/newdb/

      Você verá uma saída como esta:

      Output

      2020-10-29T19:25:45.825+0000 the --db and --collection args should only be used when restoring from a BSON file. Other uses are deprecated and will not exist in the future; use --nsInclude instead 2020-10-29T19:25:45.826+0000 building a list of collections to restore from /var/backups/mongobackups/10-29-20/newdb dir 2020-10-29T19:25:45.829+0000 reading metadata for newdb.restaurants from /var/backups/mongobackups/10-29-20/newdb/restaurants.metadata.json 2020-10-29T19:25:45.834+0000 restoring newdb.restaurants from /var/backups/mongobackups/10-29-20/newdb/restaurants.bson 2020-10-29T19:25:46.130+0000 no indexes to restore 2020-10-29T19:25:46.130+0000 finished restoring newdb.restaurants (25359 documents) 2020-10-29T19:25:46.130+0000 done

      No caso acima, estamos restaurando os dados no mesmo servidor onde criamos o backup. Se quiser migrar os dados para outro servidor e usar a mesma técnica, você deve copiar o diretório de backup — em nosso caso, /var/backups/mongobackups/10-29-20/newdb/ — para o outro servidor.

      Conclusão

      Agora, você terminou de realizar algumas tarefas essenciais relacionadas ao backup, restauração e migração dos seus bancos de dados MongoDB. Nenhum servidor MongoDB de produção deve ser executado sem uma estratégia de backup confiável, como aquela descrita aqui.



      Source link

      Cómo migrar datos de Redis con replicación en Ubuntu 18.04


      Introducción

      Redis es un sistema de almacenamiento de claves y valores en memoria conocido por su flexibilidad, rendimiento, soporte amplio en varios idiomas y funciones integradas como la replicación. La replicación es la práctica de copiar periódicamente datos de una base de datos a otra con el fin de contar con una réplica que sea siempre un duplicado exacto de la instancia principal. Un uso común de la replicación de Redis es la migración de un almacén de datos de Redis existente a un nuevo servidor, lo que se podría hacer al expandir la infraestructura para mejorar el rendimiento.

      A través de este tutorial, se describe el proceso de uso de las funciones de replicación integradas de Redis para migrar los datos de un servidor de Ubuntu 18.04 (la “fuente”) a otro (el “destino”). Esto implica realizar algunos cambios de configuración en cada servidor, establecer el servidor de destino para que funcione como una replica de la fuente y luego promover la réplica de modo que vuelva a convertirse en la instancia principal una vez que la migración termine.

      Requisitos previos

      Para completar este tutorial, necesitará lo siguiente:

      Paso 1: (Opcional) Cargar su instancia de Redis de fuente con datos de ejemplo

      En este paso opcional, se incluye cargar su instancia de Redis de fuente con algunos datos de ejemplo para que pueda experimentar con la migración de datos a su instancia de destino. Si ya tiene datos que desea migrar a su destino, puede proceder con el paso 2 , en el que se explicará cómo hacer un respaldo.

      Para comenzar, establezca conexión con el servidor de Ubuntu que usará como su instancia de Redis de fuente como su usuario no root:

      • ssh sammy@source_server_ip

      Luego ejecute el siguiente comando para acceder a su servidor Redis:

      Si configuró su servidor de Redis para solicitar la autenticación con contraseña, ejecute el comando auth seguido de su contraseña de Redis:

      • auth source_redis_password

      A continuación, ejecute los siguientes comandos. Con esto se crearán varias claves que almacenarán algunas cadenas, un hash, una lista y un conjunto:

      • 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!"

      Además, ejecute los siguientes comandos expire para que se proporcionen algunas de estas claves con un tiempo de espera. Esto los volverá volátiles, lo cual significa que en Redis se eliminarán después de un tiempo determinado (en este caso, 7500 segundos):

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

      Con eso, tendrá algunos datos de ejemplo que puede exportar a su instancia de destino de Redis. Mantenga la solicitud redis-cli abierta por ahora, ya que ejecutaremos algunos comandos más desde este en el siguiente paso para respaldar estos datos.

      Paso 2: Respaldar su instancia de fuente Redis

      Cada vez que planee mover datos de un servidor a otro, existirá el riesgo de que algo pueda salir mal y como resultado podría perder los datos. Aunque este riesgo es pequeño, usaremos el comando bgsave de Redis para crear una copia de respaldo de su base de datos de fuente de Redis en caso de que observe un error durante el proceso de replicación.

      Comience abriendo la interfaz de línea de comandos de Redis si aún no está abierta:

      También, si configuró su servidor Redis para que se solicite la autenticación con contraseña, ejecute el comando auth seguido de su contraseña de Redis:

      A continuación, ejecute el comando bgsave. Con esto, se creará una instantánea de su conjunto de datos actuales y se exportará a un archivo de volcado almacenado en el directorio de trabajo de Redis:

      Nota: puede obtener una instantánea de su base de datos de Redis con los comandos save o bgsave. No obstante, la razón por la que aquí usamos el comando bgsave radica en que el comando save se ejecuta de forma sincrónica, lo cual significa que bloqueará a cualquier otro cliente conectado a la base de datos. Debido a esto, en la documentación de comandos save se indica que casi nunca se debe ejecutar en un entorno de producción.

      En su lugar, se sugiere usar el comando bgsave que se ejecuta de forma asíncrona. Esto hará que en Redis se bifurque la base de datos en dos procesos: el proceso principal se seguirá proporcionando a los clientes mientras que el secundario guardará la base de datos antes de cerrarse:

      Tenga en cuenta que si los clientes añaden o modifican datos mientras la operación bgsave está en ejecución, estos cambios no se capturarán en la instantánea.

      Después de esto, puede cerrar la conexión con su instancia de Redis ejecutando el comando exit:

      Si se necesita en el futuro, puede encontrar el archivo de volcado de datos en el directorio de trabajo de su instancia de Redis. Recuerde que en el tutorial de instalación de Redis de los requisitos previos configuró su instancia de Redis para que use /var/lib/redis como directorio de trabajo.

      Enumere los contenidos de su directorio de trabajo de Redis para confirmar que contiene el archivo de volcado de datos:

      Si el archivo de volcado se exportó correctamente, lo verá en el resultado de este comando. Por defecto, este archivo se llama dump.rdb:

      Output

      dump.rdb

      Después de confirmar que sus datos se hayan respaldado correctamente, estará listo para configurar su servidor de Redis de fuente para aceptar las conexiones externas y permitir la replicación.

      Paso 3: Configurar su instancia Redis de fuente

      Por defecto, Redis no está configurado para escuchar las conexiones externas, lo cual significa que cualquier réplica que configure no se podrá sincronizar con su instancia de fuente a menos que actualice su configuración. En este caso, actualizaremos el archivo de configuración de la instancia de fuente para permitir las conexiones externas y también estableceremos una contraseña que se usará en la instancia de destino para la autenticación una vez que se inicie la replicación. Después de esto, añadiremos una regla de firewall para permitir las conexiones al puerto en el que se ejecuta Redis.

      Abra el archivo de configuración de su instancia de Redis de fuente con su editor de texto preferido. En este caso, utilizaremos nano:

      • sudo nano /etc/redis/redis.conf

      Diríjase a la línea que comienza con la directiva bind. Por defecto se parecerá a lo siguiente:

      /etc/redis/redis.conf

      . . .
      bind 127.0.0.1
      . . .
      

      Con esta directiva, se une Redis a 127.0.0.1, una dirección IPv4 de bucle invertido que representa localhost. Esto significa que esta instancia de Redis está configurada para escuchar solo las conexiones que se originan en el mismo servidor en el que se instala. Para permitir que su instancia de fuente acepte cualquier conexión establecida con su dirección IP pública, como las que se realizan desde su instancia de destino, añada la dirección IP de su servidor de fuente de Redis después de 127.0.0.1. Tenga en cuenta que no debe incluir ninguna coma después de 127.0.0.0.1:

      /etc/redis/redis.conf

      . . .
      bind 127.0.0.1 source_server_IP
      . . .
      

      A continuación, si aún no lo ha hecho, utilice la directiva requirepass para configurar una contraseña que los usuarios deben ingresar para poder interactuar con los datos de la instancia de fuente. Hágalo eliminando los comentarios de la directiva y configurando una contraseña o frase de contraseña compleja:

      /etc/redis/redis.conf

      . . .
      requirepass source_redis_password
      . . .
      

      Asegúrese de anotar la contraseña que estableció aquí, ya que la necesitará cuando configure el servidor destino.

      Después de ese cambio, puede guardar y cerrar el archivo de configuración de Redis. Si lo editó con nano, podrá hacerlo presionando CTRL+X, Y y luego INTRO.

      Luego, reinicie el servicio Redis para implementar estos cambios:

      • sudo systemctl restart redis

      Eso es todo lo que necesita hacer para configurar Redis, pero si configuró un firewall en su servidor, seguirá bloqueando cualquier intento de establecer conexión con la fuente por parte de su servidor de destino. Suponiendo que configuró su firewall con ufw, podrá actualizarlo para permitir las conexiones con el puerto en el que se ejecuta Redis con el comando siguiente. Tenga en cuenta que Redis está configurado para usar el puerto 6379 por defecto:

      Después de realizar ese último cambio, habrá completado la configuración de su servidor de Redis de fuente. Proceda con la configuración de su instancia de Redis de destino para que funcione como una réplica de la fuente.

      Paso 4: Configurar su instancia de Redis de destino

      En este punto, tendrá configurada su instancia de Redis de fuente para que acepte las conexiones externas. Sin embargo, debido a que bloqueó el acceso a la fuente eliminando los comentarios de la directiva requirepass, su instancia de destino no podrá replicar los datos almacenados en la fuente. En este caso, configurará su instancia de Redis de destino para poder autenticar su conexión con la fuente y permitir, así, la replicación.

      Comience conectando su servidor de Redis de destino como usuario no root:

      • ssh sammy@target_server_ip

      A continuación, abra el archivo de configuración de Redis de su servidor de destino:

      • sudo nano /etc/redis/redis.conf

      Si aún no lo ha hecho, debería configurar una contraseña para su instancia de Redis de destino con la directiva requirepass:

      /etc/redis/redis.conf

      . . .
      requirepass target_redis_password
      . . .
      

      A continuación, elimine el comentario de la directiva masterauth y configúrela con la contraseña de autenticación de su instancia de Redis de fuente. Realizando esto, su servidor de destino podrá autenticarse en la instancia de fuente una vez que usted habilite la replicación:

      /etc/redis/redis.conf

      . . .
      masterauth source_redis_password
      . . .
      

      Por último, si hay clientes que escriben información en su instancia de fuente, querrá configurarlos para que también escriban datos en su instancia de destino. De esta manera, si un cliente escribe datos después de que usted vuelve a convertir la instancia de destino en una principal, estos no se perderán.

      Sin embargo, para realizarlo deberá ajustar la directiva replica-read-only. Esto se fija en el valor yes por defecto, lo cual significa que está configurado para convertirse en una réplica de “solo lectura” en la que los clientes no podrán hacer tareas de escritura. Fije el valor de la directiva en no para permitir que los clientes hagan tareas de escritura en ella:

      /etc/redis/redis.conf

      . . .
      replica-read-only no
      . . .
      

      Esos son todos los cambios que debe hacer en el archivo de configuración de la instancia de destino para poder guardarlo y cerrarlo.

      Luego, reinicie el servicio de Redis para implementar estos cambios:

      • sudo systemctl restart redis

      Una vez reiniciado el servicio de Redis, el servidor de destino estará listo para convertirse en una réplica de la instancia de fuente. Lo único que deberá hacer para que esto suceda es ejecutar un solo comando, procedimiento que pronto haremos.

      Nota: Si tiene clientes que escriben datos en su instancia de Redis de fuente, este sería un buen momento para configurarlos para que también escriban datos en su destino.

      Paso 5: Iniciar y verificar la replicación

      En este punto, tendrá configuradas su instancia de Redis de fuente, para que acepte las conexiones de su servidor de destino, y su instancia de Redis de destino, para que pueda autenticarse en la fuente como una réplica. Una vez implementados estos elementos, estará listo para convertir su instancia de destino en una réplica de la fuente.

      Comience abriendo la interfaz de línea de comandos de Redis en su servidor de Redis de destino:

      Ejecute el comando auth para autenticar la conexión:

      A continuación, convierta la instancia de destino en una réplica de la fuente con el comando replicaof. Asegúrese de sustituir source_server_ip por la dirección IP pública de su instancia de fuente y source_port por el puerto usado por Redis en su instancia de fuente:

      • replicaof source_server_ip source_port

      Desde la solicitud, ejecute el siguiente comando scan. Con esto, se mostrarán todas las claves que actualmente se almacenan en la réplica:

      Si la replicación funciona como se espera, verá todas las claves de su instancia de fuente almacenadas en la réplica. Si cargó su fuente con los datos de ejemplo en el paso 1, el resultado del comando scan será el siguiente:

      Output

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

      Nota: Tenga en cuenta que con este comando se pueden mostrar las claves en un orden diferente del de este ejemplo.

      Sin embargo, si con este comando no se muestran las mismas claves que se almacenan en su instancia de Redis de fuente, es posible que en uno de los archivos de configuración de sus servidores se haya producido un error que impida que la base de datos de destino establezca conexión con la fuente. En este caso, cierre la conexión con su instancia de Redis de destino y compruebe que haya editado correctamente los archivos de configuración en los servidores de Redis de fuente y destino.

      Mientras la conexión esté abierta, también puede confirmar que las claves que configuró para caducar sigan siendo volátiles. Hágalo ejecutando el comando ttl con una de estas claves como un argumento:

      Con esto, se mostrará el número de segundos que transcurrirán antes de que se elimine esta clave:

      Output

      5430

      Una vez que confirme que los datos de su instancia de fuente se hayan sincronizados correctamente con su destino, puede promover la instancia de destino de modo que vuelva a convertirse en una instancia principal ejecutando una vez más el comando replicaof. Sin embargo, esta vez en lugar de seguir replicaof con una dirección IP y un puerto, sígalo con no one. Esto hará que en la instancia de destino se detenga la sincronización con la fuente de inmediato:

      Para confirmar que los datos replicados desde la fuente persisten en el destino, vuelva a ejecutar el comando scan que ingresó previamente:

      scan 0
      

      En el resultado de este comando debería ver las mismas claves que vio al ejecutar el comando scan, cuando el destino seguía replicando la fuente:

      Output

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

      Con esto, habrá migrado correctamente todos los datos de su instancia de Redis de fuente a su destino. Si tiene clientes que aún estén escribiendo datos en la instancia de fuente, este sería un buen momento para configurarlos de modo que solo realicen tareas de escritura en el destino.

      Conclusión

      Además de replicación, existen varios métodos que puede usar para migrar datos de una instancia de Redis a otra. Sin embargo, la replicación tiene las ventajas de exigir pocos cambios de configuración para el funcionamiento y solo un comando para el inicio o la detención.

      Si desea aprender más sobre cómo trabajar con Redis, le sugerimos consultar nuestra serie de tutoriales Cómo administrar una base de datos de Redis. Además, si desea mover sus datos de Redis a una instancia de Redis administrada por DigitalOcean, siga nuestra guía para hacerlo.



      Source link