El error más peligroso de los CDC en la recuperación ocurre después del fracaso.

Cuando falla un sistema de gestión de datos de centros de datos (CDC), el instinto es automático: hay que volver a ponerlo en marcha. Y rápido.

Mientras tanto, es posible que la fuente siga procesando transacciones. La acumulación de trabajo pendiente podría seguir aumentando. Es posible que los informes, las aplicaciones y los procesos posteriores ya estén trabajando con datos obsoletos.

Y tarde o temprano, alguien pregunta: ¿Podemos simplemente reiniciarlo?

Ese suele ser el momento en que la recuperación se vuelve más difícil.

Porque el verdadero problema a menudo no es el fallo en sí, sino todo lo que ocurrió mientras la replicación no estaba en funcionamiento.

• ¿Qué ocurrió durante ese lapso?
• ¿Podemos retomar la actividad donde la dejamos sin peligro?
• ¿Necesitamos resincronizar o recargar por completo?
• ¿Cómo sabemos que no se nos pasó nada por alto?

Un reinicio exitoso demuestra una sola cosa: la replicación se está reanudando.

Esto no demuestra que el objetivo sea completo, actual o correcto.

Los fallos más peligrosos de los CDC no siempre son aquellos en los que se detiene la replicación. Son aquellos en los que la replicación se reanuda y nadie puede explicar qué ocurrió durante la interrupción ni demostrar que los datos recuperados sean fiables.

El objetivo no es simplemente reiniciar lo más rápido posible, sino evitar que un fallo se convierta en una recuperación más difícil. Que se detenga un trabajo de replicación no significa automáticamente que se hayan perdido transacciones, y que un reinicio exitoso no signifique automáticamente que el destino sea correcto.

Cómo comprobar si un fallo en la canalización de CDC provocó la pérdida de datos y si se puede reiniciar de forma segura.

El primer paso es no pulsar Reiniciar.

La guía actual del NIST sobre respuesta a incidentes distingue entre detección, respuesta, recuperación y mejora continua. Esta disciplina más amplia respalda la tarea de determinar qué sucedió y preservar el contexto suficiente para tomar una decisión de recuperación justificable antes de modificar el entorno.*

Se trata de determinar dónde se detuvo el procesamiento, qué siguió ocurriendo en la fuente, en qué estado se encuentra para la recuperación y qué pruebas se necesitarán posteriormente.

Las siete preguntas que aparecen a continuación, tomadas en orden, le ayudarán a llevar a cabo ese proceso.

¿Qué fue exactamente lo que falló y cuándo?

El mensaje "La replicación se detuvo" no es lo suficientemente específico como para elegir una ruta de recuperación.

Primero determine dónde ocurrió el problema. ¿Fue una replicación?

• ¿Se detuvo por completo?
• ¿Sigues corriendo pero te estás quedando atrás?
• ¿Capturar los cambios pero ser incapaz de impulsarlos?
• ¿No se pueden aplicar los cambios en el destino?
• ¿Afectado por un evento del sistema de origen?
• ¿Afectado por el objetivo, la red u otra parte del entorno?

Luego, establezca la cronología. El momento en que alguien notó el problema puede no ser el momento en que comenzó.

Controlar

• ¿Cuándo se produjo la última actividad de replicación exitosa confirmada?
• ¿Sigue avanzando la captura de la fuente?
• ¿Está progresando el procesamiento posterior?
• ¿Está progresando la solicitud de Target?
• ¿La fuente continuó procesando transacciones?
• ¿Está disponible el objetivo?
• ¿Hubo algún cambio aproximadamente al mismo tiempo: esquema, configuración, seguridad, infraestructura, mantenimiento o carga de trabajo?

Por qué es importante

Un fallo en la captura, un fallo en la aplicación, una acumulación de tareas pendientes y una interrupción del servicio son problemas distintos. Pueden requerir equipos y acciones de recuperación diferentes. Estarás listo para avanzar cuando puedas decir: Aquí es donde se detuvo el procesamiento, aquí es cuando ocurrió y esto es lo que se vio afectado. No simplemente: «La replicación está fallando en algún punto».

¿Dónde se puede reanudar la replicación de forma segura?

Esta es una de las preguntas más importantes en la recuperación. Las plataformas de replicación pueden almacenar el estado del proceso o del reinicio, lo que ayuda a determinar dónde se puede reanudar el procesamiento después de una interrupción.

Dependiendo de la fuente y la plataforma, es posible que encuentre términos como:

• Estado de reinicio
• Control
• Marcador
• Posición del registro
• Puesto de currículum
• Otra coordenada de recuperación específica de la fuente

No des por sentado que esos términos significan exactamente lo mismo en todas las plataformas. La cuestión importante es si puedes identificar dónde se interrumpió el procesamiento y si esa información es lo suficientemente fiable como para permitir la recuperación.

Marcadores de recuperación de CDC de mainframe: estado de reinicio, posiciones de registro y RBA/LRSN de Db2 para z/OS

Dependiendo de la plataforma de origen y replicación, los equipos pueden encontrar diferentes marcadores de recuperación y terminología de posición de procesamiento. En entornos Db2 para z/OS, estos conceptos pueden incluir RBA o LRSN.

La cuestión clave es si existe información de recuperación válida guardada y si el equipo comprende qué representa dicha información. Para los procesos de captura de datos de cambios de RDRS compatibles, la información de estado guardada permite que el procesamiento continúe en la posición correcta específica de la fuente después del reinicio. La posición y la terminología dependen de la tecnología de origen.

Controlar

• ¿Está disponible el estado guardado del reinicio/proceso?
• ¿Qué representa exactamente ese estado?
• ¿Cuándo se actualizó por última vez?
• ¿Corresponde al estado de procesamiento que esperas?
• ¿Sigue estando disponible el historial de fuentes correspondiente?
• ¿Ha ocurrido algo en el objetivo que modifique las previsiones de recuperación?

Por qué es importante

Un puesto de trabajo conocido es muy diferente a reconstruir dónde crees que se interrumpió el proceso tras un incidente. Estás listo para seguir adelante cuando el equipo tiene un estado de reinicio/proceso identificable y comprende lo que esto significa para el origen y el destino.

¿Qué ocurrió mientras la replicación estaba inactiva y sigue estando disponible el historial de origen necesario?

Si el origen siguió funcionando, es posible que las transacciones continuaran mientras el destino dejaba de recibir cambios. Esto significa que el equipo debe comprender tanto la brecha de replicación como el impacto en las consecuencias.

Compruebe la brecha

• ¿Cuánto tiempo lleva rezagado el objetivo?
• ¿Qué tan grande es la acumulación de tareas pendientes?
• ¿La acumulación de pedidos pendientes está creciendo, se mantiene estable o está disminuyendo?
• ¿Qué historial de fuentes sigue estando disponible para el período afectado?
• ¿Se produjeron inserciones, actualizaciones, eliminaciones o cambios en el esquema compatible?
• ¿La plataforma ofrece una ruta de recuperación compatible para esta combinación de origen y destino?

Para CDC basado en registros, verifique la retención de registros de origen y el historial archivado. En algunos entornos de CDC basado en registros, los registros de origen retenidos o archivados pueden ser relevantes para procesar los cambios acumulados durante una interrupción. Los requisitos previos exactos varían según:

• fuente
• plataforma
• configuración
• historia conservada
• topología
• duración y naturaleza de la interrupción

No asuma que la existencia de registros archivados implica automáticamente que todas las rutas de recuperación siguen estando disponibles. Confirme qué admite la plataforma para el entorno específico. Compruebe quién ya está utilizando el destino:

• ¿Qué aplicaciones, informes, análisis, API o procesos operativos dependen de ello?
• ¿Siguen consumiendo los datos?
• ¿Saben esos equipos que puede estar obsoleto?
• ¿Se acerca la fecha límite para un pago, un informe, un lote, un cliente u otro aspecto comercial?

Por qué es importante

Un proceso aún puede recuperarse técnicamente, aunque los datos obsoletos de la fase posterior ya se estén convirtiendo en un problema para el negocio. Estarás listo para seguir adelante cuando comprendas qué sucedió durante el período de inactividad, cuánto retraso tienes y quiénes podrían verse afectados.

Reinicio desde punto de control o resincronización completa: ¿qué método de recuperación se aplica?

Aquí es donde los equipos suelen sentir la presión de tomar una decisión rápida. Según la plataforma, el estado de recuperación guardado puede denominarse punto de control, marcador, estado de reinicio, posición de procesamiento o de otra forma.

Lo importante es si existe una ruta de recuperación compatible para el escenario de fallo real. A veces, la replicación puede reanudarse desde un estado guardado y ponerse al día. Otras veces, se requiere una comparación o resincronización más específica. Y en ocasiones, es apropiado un reinicio general.

Dependiendo del origen, el destino, la configuración, el historial retenido y el escenario de fallo, las rutas disponibles pueden incluir:

• Reiniciar desde el estado del proceso guardado
• El proceso conservó los cambios históricos.
• Comparar la fuente y el destino para identificar diferencias.
• Reparar o resincronizar los datos afectados utilizando un método apropiado.
• Resincronizar parcialmente los conjuntos de datos afectados.
• Realizar una resincronización más amplia o una recarga completa.

Cómo reiniciar una canalización CDC después de un fallo sin una carga inicial completa.

En algunos entornos, una carga inicial completa puede no ser necesaria. La posibilidad de que la recuperación se lleve a cabo sin ella depende de condiciones tales como:

• Estado de reinicio/proceso utilizable
• Historial de origen requerido disponible
• El estado del objetivo
• Comportamiento de origen y destino respaldado
• El tipo de fallo
• Mecanismos de recuperación documentados de la plataforma de replicación

El objetivo no es evitar a toda costa una recarga, sino determinar si un reinicio compatible o una recuperación es la opción adecuada para este incidente.

Controlar

• ¿Está disponible y se comprende el estado de reinicio/proceso guardado?
• ¿Sigue estando disponible el historial de origen necesario para la recuperación propuesta?
• ¿Se encuentra el objetivo en un estado que permita la recuperación?
• ¿Ocurrió algo en el origen o en el destino que modifique las hipótesis de recuperación?
• ¿Puede una comparación ayudar a determinar si solo una parte de los datos se ve afectada?
• ¿Cuánto tiempo se prevé que dure la recuperación?
• ¿Pueden los sistemas posteriores tolerar ese período de estancamiento?
• ¿Qué rutas de recuperación admite la plataforma para esta configuración exacta de origen/destino?

Por qué es importante

Los expertos describen la dolorosa alternativa con total claridad: «reinicio completo» o incluso «resincronización desde cero». La pregunta clave es: ¿Cuándo podemos recuperarnos sin empezar de nuevo y cuándo no? Estarás listo para seguir adelante cuando el equipo pueda explicar por qué la ruta de recuperación seleccionada se ajusta a este incidente en particular.

¿Qué podría faltar, estar duplicado, eliminado, obsoleto o fuera de orden?

Un reinicio exitoso no prueba por sí solo que el objetivo sea correcto. Dependiendo de los datos y la arquitectura, los equipos deben buscar:

• Cambios faltantes
• Cambios duplicados o reprocesados
• Eliminaciones faltantes
• Valores obsoletos
• Inconsistencias parciales o relacionadas en los registros.
• Problemas de ordenación donde la secuencia importa
• Cambios de esquema compatibles que ocurrieron en torno al incidente

Un problema particularmente fácil de pasar por alto es la eliminación. Una canalización puede parecer en buen estado mientras un registro que fue eliminado en el origen aún permanece en el destino.

Controlar

• ¿Qué comportamiento de transacción/cambio documenta la plataforma para este origen y destino?
• ¿Qué ocurre durante el reintento o el reprocesamiento?
• ¿Cómo se gestionan las eliminaciones de origen?
• ¿Qué escenarios de cambio de esquema son compatibles?
• ¿Qué hábitos de organización influyen en tu carga de trabajo?
• ¿Qué podría no detectar una comprobación de estado normal?

Por qué es importante

Decir que "todo vuelve a la normalidad" no indica si algo se pasó por alto durante el proceso. Se puede avanzar cuando se conocen los modos de fallo relevantes en el entorno y las pruebas que podrían revelarlos.

¿Cómo demostraremos que no se perdió nada?

No espere hasta después de la recuperación para decidir cómo la validará. Antes de reiniciar, defina qué evidencia será necesaria antes de que los equipos posteriores sepan que el objetivo está listo para usarse nuevamente. Dependiendo del entorno, la validación puede incluir:

• Comparación de origen a destino compatible
• Registros o llaves de la empresa
• Recuentos
• Hashes o sumas de verificación cuando corresponda
• Marcas de tiempo o posiciones de procesamiento
• Diagnóstico de la plataforma de replicación
• Ejemplos de transacciones críticas para el negocio
• Validación posterior

Ningún método por sí solo lo demuestra todo. La pregunta importante para cada verificación de validación es:

¿Qué demuestra esto y qué no demuestra?

Preguntar

• ¿Qué período de recuperación está contemplado?
• ¿Qué datos deben revisarse?
• ¿Qué controles abordan los riesgos identificados en la pregunta 5?
• ¿Qué discrepancias requerirían una investigación más exhaustiva?
• ¿Quién debe revisar el resultado?
• ¿Qué pruebas deben conservarse?

Por qué es importante

El error que suelen cometer los equipos de recuperación es suponer que "La replicación se está ejecutando de nuevo" y "Se puede volver a confiar en el destino" son la misma conclusión.

No lo son.

Una se refiere al estado del sistema. La otra, a la integridad de los datos. La recuperación no se considera completa hasta que se disponga de evidencia de ambas. Se puede avanzar cuando el equipo cuenta con un enfoque de validación adecuado para el origen, el destino, el incidente y el riesgo empresarial.

¿Cómo sabemos que la recuperación es realmente completa?

Un proceso puede estar en marcha mientras persiste la acumulación de datos pendientes. Puede estar poniéndose al día mientras los datos posteriores permanecen obsoletos. Y puede mostrar un estado de proceso saludable mientras que las preguntas sobre los datos recuperados siguen sin resolverse. Antes de cerrar el incidente, verifique tanto el proceso como el resultado.

Controlar

• ¿Está volviendo el retardo al rango esperado?
• ¿Realmente se está reduciendo la lista de espera?
• ¿Sigue avanzando la replicación?
• ¿Siguen produciéndose errores o reintentos?
• ¿Se han validado los datos objetivo pertinentes?
• ¿Se les ha informado a los propietarios afectados aguas abajo qué productos son seguros de usar?
• ¿Queda alguna discrepancia o excepción pendiente?
• ¿Se ha documentado el estado del incidente?
• ¿Comprendemos lo suficiente lo sucedido como para responder mejor si vuelve a ocurrir?

Por qué es importante

Cerrar un incidente demasiado pronto puede dejar datos sin resolver, validaciones pendientes o preguntas sobre el impacto en los procesos posteriores ocultas tras un estado de proceso aparentemente correcto. El incidente se puede cerrar cuando el equipo puede confirmar que la replicación es estable, que los datos relevantes se han validado, que los equipos posteriores comprenden el estado actual y que podemos explicar lo sucedido.

Planificación de la recuperación frente a validación de la recuperación

Las siete preguntas de este artículo ayudan a identificar qué pudo haber fallado y de qué depende la recuperación. No demuestran que la información recuperada sea correcta. Tras la recuperación, el siguiente paso es determinar si alguno de esos riesgos se materializó y si se puede confiar en la información recuperada.

Recurso relacionado: El proceso se ha reanudado. ¿Puede confiar en los datos?

La decisión que realmente estás tomando

Estas siete preguntas no tratan sobre si puedes pulsar Reiniciar, sino sobre si puedes responder a las siguientes preguntas: ¿Dónde podemos reanudar? ¿Qué ocurrió durante la pausa? ¿Podemos recuperarnos sin tener que empezar de cero? ¿Y cómo demostraremos que no se perdió nada?

Esa es la diferencia entre volver a poner en marcha el sistema y recuperar un estado fiable.

Lista de verificación de decisiones de recuperación de los CDC

Cuando un problema de recuperación se convierte en un problema de plataforma

Todas las plataformas de los CDC experimentarán, en algún momento, fallos, interrupciones o eventos de recuperación.

La cuestión no es si ocurren incidentes, sino cuánto esfuerzo, incertidumbre y riesgo conllevan cuando suceden.

Un incidente negativo no significa automáticamente que necesites una plataforma de CDC diferente. Pero el dolor recurrente durante la recuperación merece una conversación aparte.

Pregunte si está viendo repetidamente lo siguiente:

• Un creciente retraso en la fuente
• Recargas completas o resincronizaciones amplias porque no se confía en ninguna otra vía de recuperación.
• Una recuperación que depende de que una o dos personas conozcan los pasos correctos.
• Horas dedicadas a determinar si el problema se encuentra en el origen, en la capa de replicación o en el destino.
• Validación manual o inconsistente de origen a destino
• Incertidumbre sobre si se omitieron cambios o eliminaciones.
• Escasa visibilidad del estado de la tubería o de la recuperación.
• Impacto del sistema de origen durante el procesamiento normal o la puesta al día.
• Preguntas recurrentes posteriores sobre si se puede confiar en los datos

En entornos de mainframe donde Db2 para z/OS, VSAM, IMS o ADABAS son sistemas de registro, el comportamiento de recuperación debe evaluarse para la fuente específica, y no asumirse a partir de una afirmación genérica de "compatibilidad con mainframe".

En ese momento, la pregunta cambia de "¿Cómo solucionamos este incidente?" a "¿Nuestro enfoque actual de replicación nos proporciona la capacidad de recuperación y la visibilidad que realmente necesitamos?".

Dónde encaja Rocket Data Replicate & Sync

La recuperación es una de las capacidades más importantes a evaluar en cualquier plataforma de los CDC.

Rocket Data Replicate & Sync (RDRS) gestiona la replicación empresarial entre entornos de mainframe y plataformas modernas distribuidas y en la nube.

Si está evaluando RDRS para un entorno como el descrito anteriormente, aplique el mismo estándar que aplicaría a cualquier plataforma de replicación.

Las siete preguntas de este artículo: qué falló, dónde podemos reanudar, qué sucedió durante el lapso, qué ruta de recuperación se aplica, qué podría estar mal, cómo lo demostraremos y cómo sabremos que hemos terminado, son las mismas preguntas que hay que responder sobre cualquier plataforma, incluido RDRS, antes de confiar en un objetivo recuperado.

Solicite una demostración de cómo funciona la recuperación en su configuración específica de origen y destino:

• Donde el procesamiento puede reanudarse después de una interrupción
• ¿Qué sucede con los cambios que se acumulan durante el intervalo?
• Lo que los operadores pueden observar mientras se lleva a cabo la recuperación y la puesta al día.
• ¿Qué opciones existen cuando un reinicio normal no es suficiente?
• ¿Qué capacidades de comparación o validación de origen a destino están disponibles?
• ¿Qué ocurre con el impacto del sistema de origen durante el funcionamiento normal y la puesta al día?
• ¿Qué pruebas puede utilizar el equipo antes de comunicar a los usuarios finales que los datos están listos de nuevo?

La posibilidad de recuperarse de un fallo concreto sin una resincronización más amplia o una recarga completa depende del origen, el destino, la topología, el historial conservado, la configuración y la naturaleza del fallo.

La pregunta más útil no es: "¿La plataforma admite la recuperación?"

La consigna es: “Muéstrennos cómo funciona la recuperación en los escenarios de falla a los que se enfrenta realmente nuestro entorno”.

*NIST SP 800-61 Rev. 3: Recomendaciones y consideraciones para la respuesta a incidentes

Siguiente: Demostrar la recuperación

Poner en marcha de nuevo la replicación es solo una parte del trabajo. La siguiente pregunta es:

¿Cómo demostramos que los datos recuperados están completos?

Aprenda a definir el período de recuperación, determinar qué evidencia está disponible, investigar discrepancias y establecer cuándo el objetivo está listo para su uso posterior.