Acerca del Replicat coordinado

En modo coordinado, Replicat funciona de la siguiente manera:

La diferencia entre el modo clásico y el modo coordinado es que Replicat tiene varios hilos conductores en modo coordinado. En una única instancia de Replicat, varios threads leen la pista de forma independiente y aplican transacciones en paralelo. Cada thread maneja el filtrado, la asignación, la conversión, la construcción de SQL y el manejo de errores para la carga de trabajo asignada. Un thread de coordinador coordina las transacciones entre threads para contabilizar las dependencias entre los threads.

Las transacciones origen se pueden dividir entre los procesos CR de forma que no se mantenga la integridad de la transacción origen total. La parte de la transacción procesada por un proceso CR se realiza en orden comprometido, pero la transacción completa en todos los procesos CR no lo hace.

Coordinated Replicat permite la partición definida por el usuario de la carga de trabajo a fin de aplicar transacciones de gran volumen simultáneamente. Además, coordina automáticamente la ejecución de transacciones que requieren coordinación, como DDL, y actualizaciones de clave primaria con la partición THREADRANGE. Dicha transacción se ejecuta como una transacción en el destino con sincronización completa: espera hasta que todas las transacciones anteriores se apliquen primero y todas las transacciones después de esta transacción de barrera tienen que esperar hasta que se aplique esta transacción de barrera.

Solo se necesita un archivo de parámetros para un Replicat coordinado, independientemente del número de threads. Utilice la opción THREAD o THREADRANGE en la sentencia MAP para especificar qué threads procesan las transacciones para esos objetos y especifique el número máximo de threads al crear el grupo Replicat.

Esta figura ilustra la arquitectura de Coordinated Replicat.

Descripción de coordinatedreplicat.jpg a continuación

Como se muestra en esta figura, el Replicat coordinado incluye los dos procesos siguientes:

Acerca de las transacciones de barrera

Las transacciones de barrera se gestionan automáticamente en una configuración coordinada de Replicat. Las transacciones de barrera son transacciones que requieren coordinación entre threads. Entre los ejemplos se incluyen sentencias DDL, transacciones que incluyen actualizaciones de claves primarias y determinadas acciones EVENTACTIONS.

Opcionalmente, puede forzar que otras transacciones se traten como una transacción de barrera mediante el uso de "COORDINATED keyword in a MAP statement. One use case for this would be force a SQLEXEC" para que se ejecuten de forma similar a una ejecución en serie. Esto podría ser beneficioso si los resultados pueden volverse ambiguos a menos que el estado del destino sea consistente en todas las transacciones.

Nota: Coordinated Replicat no realiza cálculos de dependencia para transacciones que no son de la barrera cuando una tabla asignada se particiona en función de THREADRANGE. Se basa en columnas THREADRANGE especificadas para calcular un valor hash. Particiona los datos entrantes en función del valor hash y envía todos los registros que coinciden con este valor hash al mismo thread.

Procesamiento de transacciones de barrera

Todos los threads convergen y esperan al inicio de una transacción de barrera. La transacción de barrera se suspende hasta que los otros hilos alcanzan su posición de inicio. Si alguno de los threads ya estaba procesando parte de la transacción de barrera, dichos threads realizan un rollback. Las transacciones agrupadas, como las controladas por los parámetros BATCHSQL o `GROUPTRANSOPS`, también se revierten y luego se vuelven a aplicar hasta que llegan al inicio de la transacción de barrera.

Todos los hilos convergen y esperan al comienzo de la siguiente transacción después de la transacción de barrera también. Los dos puntos de sincronización, antes y después de la transacción de barrera, garantizan que las operaciones de metadatos y las acciones EVENTACTIONS se produzcan en el orden adecuado relevante para las operaciones de datos.

Una vez sincronizados los threads al inicio de la transacción de barrera, el thread que tiene el ID de thread más bajo entre todos los threads especificados en las sentencias MAP procesa la transacción de barrera en serie y, a continuación, se reanuda el procesamiento paralelo entre threads. Puede forzar que las transacciones de barrera se procesen a través de un thread específico, que siempre es thread 0, especificando el parámetro USEDEDICATEDCOORDINATIONTHREAD en el archivo de parámetros Replicat.