T43.1: Implements Mirroring

InterSystems IRIS mirroring proporciona alta disponibilidad a través de replicación lógica de datos entre sistemas físicamente independientes. Un mirror consiste en miembros failover y miembros async opcionales.

Miembros Failover: Un mirror requiere exactamente dos miembros failover para failover automático. En cualquier momento, uno actúa como primary (proporcionando acceso a base de datos) y el otro como backup (manteniendo copias sincronizadas). Cuando el primary no está disponible, el backup toma el control automáticamente sin pérdida de datos. Los miembros failover son coiguales - ninguno es preferido como primary. La latencia de red entre miembros failover impacta significativamente el rendimiento, por lo que deben ubicarse para minimizar latencia.

Miembros Async - Tipo DR: Los miembros async de recuperación ante desastres mantienen copias asíncronas y pueden promoverse manualmente a miembro failover si ambos miembros failover fallan. Un DR async pertenece solo a un mirror, pero puede configurar hasta 14 miembros async. Los DR asyncs proporcionan capacidad de recuperación ante desastres geográficamente dispersa.

Miembros Async - Tipo Reporting: Los miembros async de reporting mantienen copias de solo lectura o lectura-escritura para minería de datos e inteligencia de negocios. No pueden promoverse a miembros failover. Un reporting async puede pertenecer hasta a 10 mirrors simultáneamente, funcionando como un almacén de datos a nivel empresarial que reúne bases de datos de ubicaciones separadas.

Componentes de Soporte: ISCAgent se ejecuta en el sistema host de cada miembro del mirror, proporcionando comunicación cuando los canales normales se interrumpen. El Arbiter proporciona un punto de decisión adicional para failover, previniendo escenarios de cerebro dividido donde ambos miembros piensan que deben ser primary.

Mirroring evita puntos únicos de fallo manteniendo recursos independientes en miembros primary y backup, y usa replicación lógica de datos para evitar riesgos asociados con replicación física como actualizaciones fuera de orden y corrupción por transferencia.

Configurar un mirror involucra establecer los dos miembros failover para comunicarse y replicar datos sincrónicamente. El proceso de configuración establece la relación de mirror y configura canales de comunicación.

Configuración Inicial: Cree el mirror en el primer miembro failover, especificando un nombre de mirror. Luego configure el segundo miembro failover para unirse al mismo nombre de mirror. Durante la configuración inicial, un miembro es designado como primary y el otro como backup, pero estas son designaciones temporales únicamente.

Configuración de Red: Los miembros failover se comunican a través de varios canales usando múltiples direcciones de red:

• Direcciones de conexión de mirror para comunicación miembro a miembro
• Direcciones de conexión de agent para comunicación ISCAgent
• Dirección de conexión de arbiter opcional
• Dirección Virtual IP para redirección de cliente externo (opcional)

Dirección Virtual IP: Los clientes externos típicamente se conectan a través de una VIP que siempre está enlazada al primary actual. Cuando ocurre failover, la VIP se mueve al nuevo primary, redirigiendo automáticamente conexiones de cliente. Sin embargo, los application servers en un distributed cache cluster (ECP) redirigen automáticamente al nuevo primary sin requerir una VIP.

Consideraciones Importantes:

• Los dos miembros failover son coiguales; ninguno es preferido como primary
• Primary y backup son designaciones temporales que cambian durante failover
• La latencia de red entre miembros failover impacta directamente el rendimiento de aplicación
• Los miembros deben ubicarse físicamente para minimizar latencia de red
• Los miembros failover pueden configurarse en centros de datos separados para redundancia adicional

El propósito del miembro failover backup es estar listo para tomar el control como primary. NO se soporta usar el miembro backup directamente para ejecutar consultas o código de aplicación - el comando LOCK fallará con un error PROTECT si se intenta.

Una vez que se crea un mirror, puede agregar bases de datos para ser replicadas entre los miembros failover. Solo las bases de datos explícitamente agregadas a la configuración de mirror serán replicadas.

Prerrequisitos: Antes de agregar una base de datos a un mirror, el journaling debe estar habilitado para esa base de datos. El journaling proporciona el registro completo de todas las modificaciones de base de datos que mirroring usa para replicación. Write image journaling (WIJ) se habilita automáticamente y protege contra corrupción física durante actualizaciones.

Proceso de Agregado: Las bases de datos se agregan al mirror desde el miembro primary usando el Management Portal o métodos programáticos. Cuando se agrega una base de datos: 1. La base de datos se marca como en mirror en el primary 2. Los registros de journal para esa base de datos comienzan a replicarse al backup 3. El backup crea o actualiza su copia de la base de datos 4. Los cambios en curso se replican sincrónicamente

Sincronización: El proceso de mirroring mantiene copias exactas de bases de datos en mirror en ambos miembros failover. Cuando los datos se modifican en el primary: 1. El cambio se escribe al journal del primary 2. Los registros de journal se envían al backup 3. Backup reconoce recepción 4. Backup aplica los cambios a su copia de base de datos 5. La transacción hace commit en primary después de reconocimiento del backup

Esta replicación sincrónica asegura cero pérdida de datos durante failover. El backup siempre tiene las transacciones comprometidas más recientes.

Acceso a Base de Datos: En el primary, las bases de datos en mirror son lectura-escritura. En el backup, son de solo lectura - cualquier intento de modificar datos generará un error PROTECT. Después del failover, las bases de datos del nuevo primary se vuelven lectura-escritura y las del nuevo backup se vuelven de solo lectura.

Mapeo de Namespace: Las aplicaciones acceden datos a través de namespaces, que mapean a bases de datos. La configuración de namespace debe ser consistente a través de ambos miembros del mirror para asegurar que las aplicaciones funcionen correctamente después del failover.

Monitorear el estado del mirror es esencial para asegurar alta disponibilidad e identificar problemas potenciales antes de que causen caídas. InterSystems IRIS proporciona monitoreo completo a través del Mirror Monitor y herramientas relacionadas.

Mirror Monitor: Accedido a través del Management Portal (System Administration > Mirror Monitor), el Mirror Monitor muestra:

• Identificación de miembro primary y backup actual
• Estado de miembro (Primary, Backup, Connected, Disconnected, etc.)
• Estado de sincronización de base de datos
• Retraso de dejournaling (qué tan atrás está el backup en aplicar registros de journal)
• Estado de conectividad de agent
• Eventos recientes de failover

Indicadores de Salud:

• Verde/Normal: Miembro funcionando correctamente, bases de datos sincronizadas
• Amarillo/Advertencia: Problemas menores como retraso de dejournaling o desconexión temporal
• Rojo/Error: Problemas serios como miembro caído, agent desconectado o retraso mayor de sincronización

Estado de Dejournaling: El backup aplica continuamente (dejournal) registros de journal del primary. Monitor muestra:

• Posición actual de dejournaling
• Tiempo de retraso o conteo de archivos de journal detrás del primary
• Tasa de progreso de dejournaling
• Cualquier error o problema de dejournaling

Monitoreo de Conexión: Rastree el estado de canales de comunicación:

• Conexión de mirror entre miembros failover
• Conexiones ISCAgent
• Conexión de arbiter (si está configurada)
• Conexiones de application server (ECP) al mirror

Historial de Eventos: El monitor mantiene un historial de eventos de mirror incluyendo:

• Ocurrencias de failover (automático y manual)
• Cambios de estado de miembro
• Eventos de conexión/desconexión
• Cambios de configuración
• Condiciones de error

Monitoreo Proactivo: El monitoreo regular le permite:

• Detectar problemas de red afectando comunicación de mirror
• Identificar retraso de dejournaling que podría impactar tiempo de recuperación de failover
• Verificar sincronización exitosa de base de datos
• Confirmar que ambos miembros están saludables y listos para failover
• Rastrear frecuencia y causas de failover

También puede monitorear estado de mirror programáticamente usando métodos de clase %SYS.Mirror y consultas SQL contra tablas de estado de mirror para integración con sistemas de monitoreo empresarial.

Failover es el proceso donde el miembro backup se convierte en el nuevo primary cuando el primary actual no está disponible. El failover puede ser automático (disparado por detección del sistema) o manual (iniciado por administrador).

Proceso de Failover Automático: 1. Primary no está disponible (caída, fallo de red, apagado) 2. Backup detecta pérdida de comunicación con primary 3. Backup contacta ISCAgent en host de primary para verificar que primary realmente está caído 4. Si arbiter está configurado, backup contacta arbiter para confirmación 5. Backup se promueve a sí mismo a rol primary 6. Virtual IP (si se usa) se mueve al nuevo primary 7. Las bases de datos en nuevo primary se vuelven lectura-escritura 8. Application servers (ECP) se reconectan automáticamente al nuevo primary 9. Clientes externos se reconectan vía VIP o redirección de conexión

Disparadores de Failover Automático:

• La instancia InterSystems IRIS primary se cuelga o detiene
• Fallo del sistema host primary
• Interrupción de red entre primary y backup
• Primary no responde a verificaciones de salud

Failover Manual (Planeado): El failover manual es iniciado por un administrador para:

• Mantenimiento planeado en miembro primary
• Actualizaciones de sistema operativo o hardware
• Actualizaciones de versión de InterSystems IRIS
• Probar procedimientos de failover
• Rebalancear carga después de recuperarse de failover no planeado

Para realizar failover manual: 1. Acceda Mirror Monitor en el nuevo primary previsto 2. Seleccione acción "Become Primary" 3. Confirme la operación de failover 4. Sistema realiza intercambio controlado de roles 5. Antiguo primary se convierte en nuevo backup 6. Bases de datos y conexiones transicionan suavemente

Duración de Failover: El failover automático típico se completa en segundos a decenas de segundos, dependiendo de:

• Latencia de red entre miembros
• Retraso de dejournaling en backup
• Número y tamaño de bases de datos en mirror
• Tiempo de reconexión de application server

Failover y Aplicaciones:

• Aplicaciones usando ECP: reconexión automática al nuevo primary, disrupción mínima
• Aplicaciones usando VIP: redirección automática cuando VIP se mueve
• Aplicaciones con conexiones codificadas: pueden requerir reconexión manual
• Transacción en progreso durante failover: revertida, aplicación debe reintentar

Pérdida Cero de Datos: Porque mirroring usa replicación sincrónica, el backup reconoce recepción de registros de journal antes de que el primary haga commit de transacciones. Esto garantiza que todas las transacciones comprometidas estén en el backup al momento del failover, asegurando pérdida cero de datos.

Post-Failover: Después del failover:

• Monitoree el nuevo primary para operación normal
• Investigue causa de failover si fue no planeado
• Cuando el miembro fallido se recupere, se reúne automáticamente como backup
• Considere failover manual de vuelta al primary original si se desea

Importante: Si se detecta un problema en el primary y el backup está disponible, el failover ocurre inmediatamente incluso si el problema del primary podría resolverse por sí solo. Esto asegura disponibilidad máxima pero significa que problemas transitorios pueden disparar failover.

El arbiter es un componente opcional pero recomendado que proporciona un punto de decisión adicional durante failover. Previene escenarios de "cerebro dividido" donde ambos miembros failover podrían creer simultáneamente que deben ser primary debido a problemas de red.

Propósito de Arbiter: Cuando el backup pierde contacto con el primary, debe determinar si:

• El primary realmente ha fallado (debe convertirse en primary)
• Problemas de red previenen comunicación pero primary todavía está ejecutándose (NO debe convertirse en primary)

El arbiter proporciona una tercera perspectiva. Si el backup puede contactar el arbiter pero no el primary, esto indica que el primary probablemente falló en lugar de solo una partición de red.

Prevención de Cerebro Dividido: Sin un arbiter, problemas de red entre miembros failover podrían causar que ambos actúen como primary simultáneamente, llevando a:

• Copias de base de datos divergentes
• Conflictos de datos
• Procedimientos de recuperación complejos
• Pérdida potencial de datos

El arbiter previene esto sirviendo como testigo - el miembro que puede contactar el arbiter se permite ser primary.

Requisitos de Arbiter:

• Proceso ligero con requisitos mínimos de CPU/memoria
• Debe ejecutarse en host diferente de ambos miembros failover
• Idealmente en ubicación/segmento de red física diferente de los miembros
• Requiere conectividad de red confiable a ambos miembros failover
• Disponible como contenedor Docker o instalación estándar

Instalación de Arbiter: El arbiter puede ser:

• Instalado como parte de ISCAgent en cualquier sistema
• Ejecutado como contenedor Docker (imagen intersystems/arbiter)
• Desplegado en hardware virtual o físico
• Alojado en tercer sistema en infraestructura de mirror

Configuración de Arbiter: 1. Instale arbiter en sistema host elegido 2. Configure dirección IP y puerto de arbiter 3. Agregue configuración de arbiter a ambos miembros failover 4. Los miembros failover contactan automáticamente arbiter durante decisiones de failover 5. No se necesita gestión continua - arbiter opera autónomamente

Comunicación de Arbiter: Durante failover: 1. Backup pierde contacto con primary 2. Backup intenta contactar ISCAgent en host primary 3. Backup contacta arbiter 4. Si backup puede alcanzar arbiter pero no primary/agent, backup se convierte en primary 5. Si backup no puede alcanzar arbiter, permanece como backup (primary probablemente todavía activo)

Recomendaciones de Arbiter:

• Siempre use un arbiter en configuraciones de mirror de producción
• Coloque arbiter en segmento de red independiente si es posible
• Monitoree conectividad de arbiter como parte del monitoreo de mirror
• Considere arbiter al planificar arquitectura de red
• Pruebe escenarios de failover con arbiter desconectado para comprender comportamiento

Sin Arbiter: Si no se configura arbiter, las decisiones de failover dependen solo de ISCAgent. Esto es aceptable para pruebas pero no se recomienda para producción debido al riesgo aumentado de escenarios de cerebro dividido.