Espejo lógico

4D Server ofrece una solución integrada que permite configurar un sistema de copias de seguridad mediante un espejo lógico.

¿Qué es un espejo lógico?

Un espejo lógico es un modo de copia de seguridad sofisticado, principalmente destinado a bases de datos críticas o de alta carga.

El uso de un espejo lógico consiste en operar un proyecto en una máquina y mantener una copia que se actualiza periódicamente en una segunda máquina. Las dos máquinas se comunican a través de la red, y la máquina en funcionamiento transmite periódicamente a la máquina espejo cualquier cambio realizado en los datos a través del archivo de historial.

De esta manera, cuando hay un incidente que afecta a la base de datos operativa, la base de datos espejo se puede utilizar para restablecer el funcionamiento rápidamente y sin pérdida de datos. Además, la base de datos operativa nunca está “bloqueada” por operaciones de copia de seguridad.

¿Por qué elegir hacer una copia de seguridad utilizando un espejo lógico?

El uso de un espejo lógico responde a necesidades específicas. La estrategia estándar, basada en copias de seguridad periódicas y en el uso de un archivo de registro, ofrece en la mayoría de los casos una solución sencilla, fiable y económica. Se realizan copias de seguridad de la base de datos con regularidad (por lo general, cada 24 horas). Durante la copia de seguridad, todos los procesos se detienen. Este periodo de indisponibilidad parcial es muy breve e incluso en el caso de bases de datos de gran tamaño (superiores a 2 GB), no dura más de 5 minutos. Esta operación se puede programar para que se realice fuera de los horarios habituales de uso de la base de datos.

No obstante, en el caso de determinados tipos de organizaciones, como los hospitales, por ejemplo, las bases de datos críticas deben estar plenamente operativas las 24 horas del día. La base de datos no puede estar en proceso de copia de seguridad (y, por lo tanto, no estar disponible), ni siquiera durante un período muy corto. En este caso, configurar un espejo lógico es la solución adecuada.

nota

Una solución espejo solo refleja los cambios realizados en los datos. Este modo de copia de seguridad no es adecuado para proyectos en proceso de desarrollo, donde las frecuentes modificaciones estructurales harán que el espejo quede rápidamente obsoleto o requerirán actualizar repetidamente la estructura de la base de datos espejo.

Principios de funcionamiento

La configuración de un sistema de copia de seguridad mediante un espejo lógico se basa en dos comandos: New log file y INTEGRATE MIRROR LOG FILE.

Se aplican los siguientes principios:

• La aplicación se instala en la máquina principal 4D Server (máquina operativa) y se instala una copia idéntica de la aplicación en la máquina espejo 4D Server.
• Una prueba al inicio de la aplicación (por ejemplo, para la presencia de un archivo específico en una subcarpeta de la aplicación 4D Server) se utiliza para distinguir entre las dos versiones (operativas y réplicas) y así ejecutar las operaciones apropiadas.
• En la máquina 4D Server en funcionamiento, el archivo de historial se "segmenta" en intervalos regulares utilizando el comando New log file. Dado que no se realiza ninguna copia de seguridad en el servidor principal, la aplicación permanece disponible en todo momento en modo de lectura y escritura.
• Cada "segmento" del archivo de historial se envía a la máquina espejo, donde se integra en la aplicación de espejo utilizando el comando INTEGRATE MIRROR LOG FILE.

La configuración de este sistema requiere la programación de código específico, en concreto:

• Un temporizador en el servidor principal para gestionar los ciclos de ejecución del comando New log file,
• Un sistema de transferencia de los "segmentos" del archivo de historial entre la máquina operativa y la máquina espejo (utilizando HTTP, Servicios Web, etc.),
• Un proceso en la máquina espejo destinado a supervisar la llegada de nuevos "segmentos" del archivo de historial e integrarlos utilizando el comando INTEGRATE MIROR LOG FILE
• Un sistema de comunicación y de gestión de errores entre el servidor principal y el servidor espejo.

atención

Un sistema de copia de seguridad que utiliza un espejo lógico no es compatible con las copias de seguridad normales en una aplicación en ejecución en uso, ya que el uso simultáneo de estos dos modos de copia de seguridad provocaría la desincronización de las aplicaciones operativa y espejo. Por consiguiente, debe asegurarse de que no se realizan copias de seguridad, ya sean automáticas o manuales, sobre la aplicación operativa. En cambio, es posible realizar una copia de seguridad de la aplicación espejo o configurar un "espejo-espejo".

Copia de seguridad de un espejo y espejo del espejo

4D Server se puede utilizar para realizar copias de seguridad de la aplicación en el servidor espejo.

Cualquier medio convencional puede utilizarse para realizar copias de seguridad en la máquina espejo: copias de seguridad manuales utilizando el comando del menú Archivo, copias de seguridad programadas establecidas en las Propiedades o copias de seguridad por código utilizando comandos del lenguaje.

Para evitar riesgos de desincronización con la máquina operativa, 4D bloquea automáticamente la máquina espejo cuando está llevando a cabo una de dos operaciones básicas: la integración del archivo de registro desde la máquina operativa y la copia de seguridad de la aplicación espejo.

• Cuando un archivo de historial se está integrando, no es posible realizar una copia de seguridad. Si el comando BACKUP se utiliza, se produce el error 1417.
• Cuando se está realizando una copia de seguridad, todos los procesos se bloquean y no es posible iniciar la integración de un archivo de registro.

Puede activar el archivo de historial actual en el servidor espejo, lo que le permite configurar un "espejo-espejo" (o incluso una serie de servidores espejo), o bien una arquitectura de espejos de tipo "hub-and-spoke" (varios servidores espejo para la misma aplicación operativa). En el primer caso, el archivo de historial actual del servidor espejo se envía a su vez a otro servidor espejo (el "espejo-espejo") para su integración, y así sucesivamente si utiliza una serie de servidores espejo. En el segundo caso, el archivo de historial actual se envía directamente a varios servidores espejo idénticos. Este tipo de redundancia garantiza la disponibilidad continua del servidor, incluso en caso de que se produzca un fallo simultáneo del servidor y del servidor espejo principal.

Escenario operativo de un espejo lógico

El siguiente escenario ilustra, desde el punto de vista de cada máquina 4D Server, la configuración y el funcionamiento de un sistema de copias de seguridad mediante un espejo:

Step	Máquina en funcionamiento	Máquina espejo
1	Inicio de la aplicación, copia de seguridad del archivo de datos. El archivo de historial está activado por defecto; para mayor seguridad, guarde este archivo en un disco duro independiente.
	4D crea el archivo MyApp.journal.
	Se ha cerrado la aplicación.
	Copia de todos los archivos de la base de datos (incluido el archivo de registro) en el servidor espejo.
2	Reinicio de la aplicación e inicio de la operación (verifique que no haya una copia de seguridad completa planificada).	Inicio de la aplicación espejo. 4D Server solicita el archivo de historial actual: seleccione el archivo MyApp.journal que se transfirió desde la base de datos operativa. Este archivo se utilizará al configurar un servidor espejo-espejo.
3	Se toma la decisión de actualizar el servidor espejo (por ejemplo, después de un cierto período de operación).
	Ejecución del método que contiene el comando Nuevo archivo de registro. El archivo guardado se llama MyApp[0001-0001].journal.
	Envío del archivo MyApp[0001-0001].journal mediante programación a la máquina espejo.
	La aplicación está en funcionamiento.
4		Detección de un archivo que está pendiente de integración. Ejecución del método que contiene el comando INTEGRATE MIRROR LOG FILE para integrar el archivo MyApp[0001-0001].journal. Si utiliza un servidor espejo-espejo, ejecución en el servidor espejo de un procedimiento similar al del paso 3 (a repetirse cada vez que se integra un archivo de historial).
5	Se produce un incidente en la máquina; la base de datos es inutilizable. Se ha tomado la decisión de cambiar a la máquina espejo.
	Copia del archivo de historial actual MyApp.journal en el servidor espejo, a través de la carpeta de destino habitual
6	Análisis de incidencias y reparaciones.	Detección de un archivo que está pendiente de integración. Ejecución del método que contiene el comando INTEGRATE MIRROR LOG FILE para integrar el archivo MyApp.journal.
		La aplicación está en funcionamiento.
7	La máquina está reparada. Reemplazo de los archivos de la base de datos por los de la base de datos espejo. Inicio de la aplicación. 4D Server solicita el archivo de historial: seleccione el archivo que se transfirió desde el servidor espejo.	Se ha cerrado la aplicación. Volver al paso 2.