Punto de Control, Recuperación y Semántica de Entrega
Obtenga información sobre la configuración del punto de control, la recuperación y la entrega desde flujos de datos.
El contrato público pos
Cada registro DML o DDL que no sea de metadatos incluye un token pos opaco por defecto. Internamente, el token contiene suficiente información de posicionamiento GoldenGate para identificar un registro, incluida la información de confirmación o secuencia, la identidad de transacción y la secuenciación de registros. Su codificación no es un formato de coordenadas de origen público y puede variar según el tipo de origen y la versión.
| Hacer | No |
|---|---|
| Almacene la cadena exacta después del procesamiento correcto. | Analizarlo para obtener un SCN de Oracle, un LSN de PostgreSQL, una coordenada de binlog MySQL, un LSN de SQL Server o cualquier otro desplazamiento específico del origen. |
| Ámbito en el flujo de datos, el contrato de pista de origen y el consumidor. | Compare posiciones de forma léxica o numérica para determinar el orden. |
Porcentaje de codificación cuando se utiliza como begin en una URL. |
Recortar, normalizar, concatenar, descifrar o reescribir. |
Utilice campos csn, xid, opSeqno y transInd independientes para el diagnóstico o el análisis de transacciones. |
Reutilice una posición de otro flujo, un contrato de filtro diferente u otro entorno. |
Portabilidad de origen: el algoritmo de recuperación de cliente es intencionalmente el mismo para Oracle, PostgreSQL, MySQL, SQL Server y otros orígenes soportados: mantenga el opaco pos y devuélvalo sin cambios. El análisis de coordenadas específico del origen no es necesario ni está soportado por el contrato de cliente de Data Streams.
Un punto de control debe representar el último registro cuyo efecto de negocio sea duradero. Ahorrar antes de que la empresa escriba puede perder datos después de un bloqueo. Guardar después de una escritura no idempotente en una transacción independiente puede producir un duplicado después de un bloqueo.
Patrones una sola vez de extremo a extremo
| Patrón | Funcionamiento | Utilizar cuando |
|---|---|---|
| Transacción de punto de control y disipador atómico | Escriba el registro de negocio y el nuevo pos en la misma transacción de base de datos. |
El punto de control y el receptor pueden compartir un almacén de datos transaccional. |
| Clave de idempotencia | Utilice pos, o una clave de negocio más una identidad de operación, como clave única; reintentar el mismo registro se convierte en un no operativo. |
El fregadero admite escrituras únicas o condicionales. |
| Log de almacenamiento provisional duradero | Agregue el registro y pos atómicamente a un log duradero y, a continuación, procese el log de forma independiente. |
El procesamiento empresarial es lento, consta de varios pasos o abarca sistemas. |
| Al menos una vez con conciliación | Aceptar duplicados, desduplicar periódicamente y conciliar recuentos o totales de control. | El caso de uso tolera la corrección eventual. |
NOTA: el flujo de datos exactlyOnce describe la supresión duplicada del servicio y la respuesta de recuperación. No produce un efecto secundario descendente arbitrario exactamente una vez porque el protocolo WebSocket no tiene ningún reconocimiento transaccional por registro con el cliente.
Calidad del Servicio
Consulte las directrices de calidad de servicio de la siguiente tabla:
| Modo | Duplicado | Posición guardada no disponible | Uso recomendado |
|---|---|---|---|
exactlyOnce |
Suprime los duplicados reconocidos durante la recuperación y la gestión de reinicio/finalización de pista de origen. | La conexión falla con un error. | Valor por defecto para el procesamiento de negocio duradero. Emparejar con lógica de consumidor atómica o idempotente. |
atLeastOnce |
No suprime los duplicados durante la recuperación y la gestión de reinicio/finalización de pista de origen. | La conexión falla con un error. | Se utiliza cuando se prefiere la reproducción y el consumidor está diseñado para desduplicar. |
atMostOnce |
Suprime los duplicados reconocidos. | El servicio busca el siguiente registro disponible y continúa, lo que puede omitir datos. | Se utiliza solo cuando la pérdida de datos es explícitamente aceptable y el progreso hacia adelante es más importante que la integridad. |
Metadatos y orden de transacciones
Consulte la siguiente tabla para conocer los metadatos de las transacciones y los requisitos de ordenación:
| Campo | Finalidad | Limitaciones |
|---|---|---|
xid |
Agrupa los registros asociados con una transacción de origen. | El formato depende del origen y se debe tratar como una cadena. |
csn |
Expone el número de secuencia de confirmación de origen cuando se configura. | El significado y el formato dependen del origen; no lo utilice como token de reinicio. |
opSeqno |
Número de secuencia de registro dentro de la transacción. | Active y, opcionalmente, cambie el nombre de forma explícita. |
transInd |
B primero, M medio, E último o W transacción completa/de una sola operación. |
El filtrado puede eliminar registros y hacer que la secuencia observada esté incompleta. El procesamiento coordinado también puede reducir la utilidad. |
pos |
Posición de recuperación única para el registro. | Opaco; no ordene ni derive los límites de transacción de su texto. |
No suponga que una conexión siempre comienza en un límite de transacción. Una consulta de registro de hora o un límite de pista retenida pueden comenzar después de que las operaciones anteriores ya no estén disponibles. Si la aplicación requiere transacciones de origen completas, diseñe un buffer de transacción, defina límites para transacciones grandes y especifique qué hacer cuando el inicio de una transacción no esté disponible.
Cuando una posición guardada no está disponible
Para comprobar una posición guardada que deja de estar disponible, compruebe lo siguiente:
-
Confirme que el punto de control pertenece al mismo flujo de datos, pista de origen y contrato de filtro/salida.
-
Confirme que el valor se ha codificado en porcentaje sin cambiarlo.
-
Confirme que el segmento de pista que contiene la posición no se haya depurado.
-
Con
exactlyOnceoatLeastOnce, trate el error como un incidente de recuperación. Restaurar el historial de pistas, elegir un registro de hora aprobado o la primera posición y conciliar el estado descendente antes de reanudar. -
Con
atMostOnce, el servicio puede continuar en el siguiente registro disponible. Registre la brecha de datos resultante y ejecute el procedimiento de conciliación aprobado por la empresa.
Planificación de retención de pista
Defina la retención de pista para superar el objetivo de punto de recuperación más el tiempo de respuesta y detección operativa. Por ejemplo, un consumidor que puede estar fuera de línea durante 24 horas y que necesita 12 horas para la respuesta a incidentes necesita más de 36 horas de pista disponible, con margen adicional para grandes atrasos y mantenimiento. bufferSize no amplía la retención de pista.