Lab — Role-swap con Assure Quick EDD

Objetivo

Ejecutar un role-swap controlado: la LPAR target asume el rol de producción mientras source pasa a estar inactiva. Validar la integridad de los datos en el nuevo "producción". Volver al estado original (swap-back).

Este lab simula uno de los entregables más importantes para preventa y senior: demostrar que la replicación es viable como HA y no solo como copia.

Tiempo estimado

180 minutos (planificación + ejecución + validación + retorno).

Prerequisitos

•Lab Quick EDD replicación básica completado y replicación operativa.
•Las dos LPARs en estado conocido: cohorte coordinada para no interferir.
•Conocer el procedimiento de switch del cliente (en lab, el del producto).

Concepto

Quick EDD ofrece procedimientos de switch personalizables ejecutables en tres modos:

•Paso a paso — operador da OK por etapa (recomendado para primer drill).
•Interactivo — operador da OK por bloques.
•Batch — automático, una vez probado y aprobado.

El switch involucra: detener apply, validar consistencia, voltear roles, levantar aplicaciones en el nuevo nodo, redirigir usuarios.

(Fuente: Precisely — Assure QuickEDD product page)

Paso 1 — Verificar estado previo

Antes del swap, todo tiene que estar limpio:

•Grupo de replicación: Active.
•Lag: cercano a cero.
•Auditoría reciente: sin divergencias pendientes.
•Apply jobs: running.

Si alguno de estos no está OK, resolver primero antes de seguir. Un swap con divergencias activas se hace pero genera deuda de validación post-switch.

Paso 2 — Snapshot de validación (para verificación post-swap)

Generar un set conocido de filas de prueba en source para verificar después que están en el nuevo "producción" (que será el target):

INSERT INTO QELAB.PRODUCTOS VALUES('SWAP001 - PRE-SWAP TEST                                                                                     ');
INSERT INTO QELAB.PRODUCTOS VALUES('SWAP002 - PRE-SWAP TEST                                                                                     ');
INSERT INTO QELAB.PRODUCTOS VALUES('SWAP003 - PRE-SWAP TEST                                                                                     ');

Esperar 60 segundos y validar que están en target (SELECT * FROM QELAB.PRODUCTOS WHERE PRODUCTOS LIKE 'SWAP%').

Paso 3 — Iniciar el switch en modo "paso a paso"

Desde la interfaz de Quick EDD:

•Seleccionar el grupo de replicación.
•Iniciar switch procedure en modo paso a paso.
•Confirmar las etapas a medida que se presentan.

Etapas típicas (los nombres exactos varían por versión):

| Etapa | Qué hace | |---|---| | Quiesce de source | Detiene actividad sobre los objetos del grupo en source. | | Drain de apply en target | Espera que apply procese todos los pendientes. | | Validación final | Audit de consistencia. | | Detener replicación | Apply queda detenido. | | Voltear roles | Lo que era target ahora es "source"; lo que era source pasa a "target lógico". | | Levantar apply inverso | Se prepara la replicación inversa (para drift que ocurra durante el swap). | | Habilitar source nuevo | Aplicaciones / usuarios pueden empezar a operar contra el nuevo source (ex-target). |

Paso 4 — Validación post-switch

Trabajando ya contra el nuevo source (la LPAR que era target):

SELECT * FROM QELAB.PRODUCTOS WHERE PRODUCTOS LIKE 'SWAP%';

Las 3 filas SWAP001, SWAP002, SWAP003 deben estar presentes.

Generar un cambio nuevo en el nuevo source para verificar que es escribible:

INSERT INTO QELAB.PRODUCTOS VALUES('POST001 - POST-SWAP                                                                                          ');

Paso 5 — Validar que la replicación inversa opera

Esperar 60 segundos. Verificar en la LPAR original (ex-source, ahora target lógico):

SELECT * FROM QELAB.PRODUCTOS WHERE PRODUCTOS LIKE 'POST%';

Debe mostrar POST001. Si está, la replicación inversa funciona y podríamos volver al estado original con otro swap.

Paso 6 — Swap-back (volver al estado original)

Repetir el procedimiento de switch en sentido inverso:

•Iniciar switch desde el nuevo source de vuelta hacia el original.
•Validar las etapas paso a paso.
•Confirmar que la LPAR original vuelve a ser source productivo.

Paso 7 — Validación final

En la LPAR original (ahora otra vez source):

SELECT * FROM QELAB.PRODUCTOS WHERE PRODUCTOS LIKE 'POST%' OR PRODUCTOS LIKE 'SWAP%';

Deben aparecer todas las filas creadas durante el ejercicio (SWAP001-003 + POST001), confirmando que el dato fluyó en ambas direcciones sin pérdida.

Paso 8 — Cleanup

DELETE FROM QELAB.PRODUCTOS WHERE PRODUCTOS LIKE 'SWAP%';
DELETE FROM QELAB.PRODUCTOS WHERE PRODUCTOS LIKE 'POST%';

(Esperar 30 segundos a que se replique al target y dejar todo en sincronía.)

Validación esperada al cierre

•Los dos swaps (ida y vuelta) completaron sin error.
•No hay pérdida de datos.
•Lag tras cada swap volvió a ~0.
•La cohorte/instructor verifican el reporte completo del producto.

Lecciones que el lab busca dejar

•Un switch no es solo "darle a un botón" — son etapas con dependencias.
•La replicación inversa es lo que permite swap-back rápido; sin ella, el cliente está atado al nuevo nodo hasta resolver el drift manualmente.
•En producción real hay que coordinar DNS/IPs, conexiones de aplicación, batch programado, usuarios conectados. El lab simplifica esto, pero conviene mencionarlo.
•⚠️ Un switch fallido es escalación inmediata, no se improvisa. Ver RB-QE-008.

Errores comunes y mitigación

| Síntoma | Mitigación | |---|---| | Switch se queda en quiesce | Hay actividad pendiente sobre los objetos; verificar locks (WRKOBJLCK) | | Apply inverso no levanta | Validar journaling en el nuevo source (que era target) | | Aplicación cliente no conecta al nuevo source | DNS/IPs no actualizados; revisar plan de cliente | | Drift entre swap y swap-back | Replicación inversa no estaba corriendo; reconciliar con audit |