Deja de enviar archivos a tu sistema de reserva: transmite los registros de forma continua en Actian NoSQL 11.1

Antes de Actian NoSQL 11.1, no era posible tener una base de datos en espera en funcionamiento. La base de datos en espera se mantenía en modo SUSPENDIDO (= imposible de iniciar) y era necesario aplicar manualmente los archivos de archivo a dicha base de datos.

Además, las transacciones confirmadas se guardaron en registros de archivo, y el administrador de bases de datos debe aplicar cada archivo a la base de datos en espera y solo podría restaurarla con vbackup -resume, en caso de que la base de datos principal resultara dañada.

En caso de conmutación por error, una persona llevaba a cabo, bajo presión, un procedimiento de restauración de varios pasos. Un error en dicho procedimiento supuso el fracaso de la recuperación.

Actian NoSQL 11.1 elimina ese paso manual. La nueva logstream La utilidad transmite los objetos modificados por la transacción confirmada desde la base de datos principal a la de reserva a través de una conexión TCP, aplicándolos de forma continua y manteniendo la base de datos de reserva en MODO de solo lectura en todo momento.

A continuación se muestra una tabla en la que se recogen algunas diferencias clave entre el procedimiento «Rollforward» y el nuevo procedimiento «logstream»:

Qué cambia

Los dos logros operativos son:

1. La recuperación ya no depende de una restauración manual de los archivos de copia de seguridad.
2. Ahora se puede utilizar la base de datos de reserva para leer objetos, al tiempo que se reciben los cambios de rollforward.

Arquitectura

Hay dos procesos de logstream que mantienen abierto un socket entre ellos.

• logstream -out Se ejecuta en el servidor principal. Lee los registros de roll-forward a medida que la base de datos los genera, los agrupa en lotes de red y los envía al servidor de reserva.
• logstream -in Se ejecuta en la base de datos de reserva. Escucha en el puerto que elijas, recibe los lotes y aplica los registros a la base de datos de reserva a medida que van llegando.

Flujo de trabajo de la utilidad Logstream

Los objetos se transfieren directamente desde la base de datos principal a la de reserva sin ningún paso manual intermedio.

El puerto es cualquier puerto no utilizado del host en espera. No hay un valor predeterminado fijo; en los ejemplos de esta entrada se utiliza el 5051. Asegúrate de que el puerto elegido esté libre antes de poder vincularlo \logstream -in\ a ello.

El estado se conserva en ambos lados

Estos dos procesos de logstream son independientes del número de secuencia de registros de roll-forward al que se haya llegado. El \-out\ el lado conoce el último registro que transmitió; el \-in\ El lado conoce el último registro que aplicó.

Esta arquitectura tiene una regla de funcionamiento: empezar \logstream -in\ en el servidor de la base de datos de reserva antes de iniciar \logstream -out\ en el servidor principal. El remitente necesita un receptor en el servidor de reserva al que conectarse.

El modo de espera realiza lecturas mientras se sincroniza

Crea la línea de base de espera en modo de espera:

vbackup -restore -standbyMode\

Una base de datos restaurada con \-standbyMode\ acepta los bloques de escritura entrantes procedentes de \logstream -in\ sin dejar de estar disponible para que las aplicaciones puedan leerla. Las aplicaciones cliente pueden conectarse y ejecutar consultas en ella. Cualquier intento de modificar o escribir datos en cualquier objeto almacenado en la base de datos de reserva falla con \SM_DB_IS_READONLY\, ya que la base de datos se encuentra en modo de espera (=SOLO LECTURA).

En la práctica, esto significa que puedes dirigir las cargas de trabajo de generación de informes, los servicios con un uso intensivo de lectura o los entornos de pruebas al servidor en espera durante el funcionamiento normal, en lugar de pagar por un segundo servidor que no hace nada hasta que se produce una conmutación por error.

Cómo hacer frente a una caída de la red

Dado que ambos extremos mantienen su posición en la secuencia, una conexión interrumpida solo detiene el flujo y nada más.

Resiliencia de la utilidad Logstream

Una partición de red detiene la transmisión y el logstream activo mantiene su posición de secuencia actual. En caso de que la conexión se restablezca al poco tiempo, ambos procesos de logstream seguirán activos. Durante ese tiempo, el registro lógico del servidor principal crece, al tiempo que se guardan todas las transacciones confirmadas.

Cuando se restablezca la conexión, los procesos de LogStream se reanudarán a partir del último número de secuencia aplicado. No es necesario que el operador realice ninguna acción para reiniciar ninguno de los procesos de LogStream, ni siquiera en caso de un problema transitorio de red.

Lo que sigue siendo responsabilidad del administrador de bases de datos

Logstream elimina la necesidad de realizar una restauración manual, pero el administrador de bases de datos (DBA) debe seguir supervisando los procesos. El DBA debe:

1. Ambos procesos deben estar en ejecución. El arroyo solo fluye mientras ambos logstream -out está en las primarias y logstream -in está en modo de espera. Incluye ambos procesos de logstream en los procedimientos de supervisión que haya definido la empresa.
2. Supervisa el archivo «logical.log» en el servidor principal. Mientras la conexión TCP entre los dos procesos esté interrumpida, el primario no puede reenviar ningún objeto modificado por transacciones confirmadas, por lo que su logical.log El archivo aumenta de tamaño.

La rapidez con la que crece depende del número de aplicaciones cliente que escriban en el disco primario; en un sistema con mucha actividad, puede crecer muy rápidamente. Si la partición del disco que contiene logical.log se llena por completo, la base de datos principal se apaga. Por lo tanto, una interrupción prolongada de la red puede provocar una interrupción de la base de datos principal, y ambos procesos de «logstream» pueden terminarse tras un tiempo de espera TCP prolongado si no se supervisan de forma rutinaria.

Una buena práctica consiste en configurar una «alerta» tanto para el estado «activo» de los procesos de logstream como para el espacio libre de esa partición.

Ajustar la transmisión

Dos parámetros en logstream -out controlar cuándo se envía un lote.

El primer umbral alcanzado, ya sea el tiempo transcurrido o el llenado del lote, activa la transferencia.

El -aggression Este parámetro establece el número máximo de segundos durante los que se retiene un lote parcial antes de su envío (por defecto, 60). -batchsize Establece el número máximo de entradas de registro en un lote (por defecto, 100). Una base de datos con poca actividad envía un lote pequeño cuando vence el temporizador; una base de datos con mucha actividad llena primero el lote y envía con más frecuencia.

Los valores predeterminados son adecuados para entornos de prueba y constituyen un buen punto de partida en producción. El comportamiento real de la replicación no depende únicamente de estos dos valores: la configuración TCP del sistema operativo, la carga del sistema en ambos hosts y la utilización de la red también influyen, por lo que no existe un único ajuste que se pueda indicar. Si detectas un problema de rendimiento en producción, abre un caso con el equipo de soporte técnico de Actian antes de modificar cualquiera de estos valores. El equipo de soporte te pedirá un pequeño conjunto de archivos para identificar la causa y, si el análisis apunta a la replicación por lotes, te recomendarán valores específicos y confirmarán contigo la mejora obtenida.

Comprobación del estado de la sincronización

vbackup -info informa de la posición de cada parte del par. En las primarias:

> vbackup -info primarydb
Currently transferring logs, next sequential number: #427...

En espera:

> vbackup -info standbydb
Currently injecting logs...
Records applied up to sequential number #10532...

Cuando ambos procesos de logstream se estén ejecutando simultáneamente, verás un número de secuencia en la salida de supervisión y en los registros de cada uno de ellos. No es necesario que coincidan para que el estado sea correcto.

Cuando ambos procesos de logstream se estén ejecutando simultáneamente, verás un número de secuencia en la salida de supervisión y en los registros de cada uno de ellos. No es necesario que coincidan para que el estado sea correcto.

Promoción del modo de espera: logstream -finish

La promoción convierte la base de datos en espera en una base de datos estándar normal de lectura y escritura. Se utiliza en dos situaciones: una conmutación por error tras la pérdida de la base de datos primaria y una retirada planificada de la base de datos primaria, por ejemplo, un cambio de hardware. En ambos casos, las dos logstream Primero hay que detener los procesos. La promoción no puede ni debe ejecutarse mientras alguno de los procesos esté activo, y el comando de promoción se niega a ejecutarse si detecta un proceso de logstream activo. A continuación se indican los pasos para promover el servidor en espera.

1. Detén la transmisión. Alto logstream -out en el primario, si aún se puede acceder a él, entonces detente logstream -in en modo de espera.
2. Llevar a cabo la promoción: logstream -finish standbydb. Esto CAMBIA LA BASE DE DATOS DE RESERVA de «solo lectura» a «multiusuario» y cierra la base de datos de forma ordenada.
3. Inicia la base de datos: startdb standbydb. Inicia la base de datos en modo multiusuario. Depende de ti si vas a utilizarla como tu nueva base de datos principal; en ese caso, debes ejecutar «vbackup -rollforward -backup«

La promoción es un proceso unidireccional. Una vez realizada la promoción, la base de datos ya no recibe actualizaciones de la fuente original. Si necesitas una nueva instancia en espera, créala a partir de la nueva primaria con el comando «vbackup -restore -standbyMode» e inicia una nueva secuencia.

Migraciones planificadas

Este mismo mecanismo gestiona las actualizaciones de hardware y los traslados de centros de datos sin necesidad de interrumpir el servicio para el envío de archivos.

1. Comprueba. Con ambas bases de datos activas, ejecuta vbackup -info en cada lado para comprobar que ambos procesos de logstream estén activos y que el proceso en espera esté totalmente al día.
2. Detén la transmisión en orden. Alto logstream -out en las primarias, entonces logstream -in en modo de espera, mientras la red funciona correctamente.
3. Promocionar. Ejecute logstream -finish y startdb en el hardware de destino, tal y como se ha descrito anteriormente.
4. Retirar del servicio. Desactiva el archivado en el antiguo servidor principal con vbackup -off primarydb y retirarlo.

La conmutación consiste en unos pocos comandos, y el nuevo servidor principal lleva gestionando el tráfico de lectura desde el momento en que decidisteis probarlo previamente.

Licencias y disponibilidad

Logstream se suministra con Actian NoSQL 11.1. No requiere ningún componente con licencia adicional: la licencia que utilices para Actian NoSQL 11.0 es válida para la versión 11.1.

Primeros pasos

1. Activa el rollforward en la base de datos principal, lo cual se realiza mediante vbackup -rollforward -backup para poder restaurar posteriormente esta copia de seguridad en la base de datos de reserva.
2. Actualiza ambos servidores a Actian NoSQL 11.1 y crea la configuración de referencia del servidor en espera con vbackup -restore -standbyMode.
3. Elige un puerto libre en espera. Iniciar logstream -in ahí, pues logstream -out en las primarias.
4. Añade ambos procesos y el del primario logical.log partición a tu sistema de supervisión.
5. Ver vbackup -info por ambos lados. Deja -aggression y -batchsize con sus valores predeterminados, a menos que el servicio de asistencia recomiende lo contrario.

Los comandos de esta entrada muestran únicamente las opciones principales, incluida la nueva -standbyMode opción. Sintaxis completa para vbackup, logstream, y startdb, incluyendo los parámetros de host y puerto y las notas sobre la plataforma, se encuentra en la documentación de Actian NoSQL 11.1.

¿Tienes alguna pregunta o comentario sobre Logstream? Ponte en contacto con el equipo de Actian NoSQL a través de la comunidad de Actian o de tu representante comercial.

Acerca del autor

Acerca de Ulf Schenk

Ulf Schenk es director de soporte técnico de los productos NoSQL Database y FastObjects, y lleva más de 20 años trabajando en Actian. Al haber participado en el diseño y la implementación de estos productos, conoce a fondo la arquitectura de los sistemas de bases de datos orientados a objetos y aprovecha esos conocimientos para ayudar a los clientes a resolver problemas técnicos y asesorar a empresas y organizaciones sobre cómo diseñar, optimizar e implementar soluciones de NoSQL Database y FastObjects que les permitan alcanzar sus objetivos.