Réplica de solo lectura de Orchestrator

Orchestrator mantiene una réplica de solo lectura de su base de datos operativa de lectura y escritura, con el principal propósito de mejorar el rendimiento. Algunas cargas de trabajo de solo lectura se dirigen hacia la réplica de solo lectura con el fin de optimizar el consumo de la réplica de escritura. Esto permite que los datos se lean y carguen más rápido, lo que a su vez garantiza el rendimiento de tu sistema.

Como resultado de esta implementación puede ocurrir un ligero retraso entre las acciones de escritura y lectura. Esto es de esperar, y no tiene impacto en que los datos estén disponibles.

Un ejemplo de este escenario es recuperar un elemento de cola tan pronto como se añadió: cuando se realiza desde la interfaz, los nuevos elementos de cola pueden no mostrarse al instante, ya que hay una ligera asincronía entre la base de datos operativa (donde se escribe el elemento) y la réplica (que se llama para leer el elemento). Sin embargo, puedes evitar esto utilizando la actividad Obtener elemento de transacción en lugar de Obtener elementos de cola, ya que el primero incluye el elemento de cola en su respuesta.

Casos de uso

Si tu base de datos admite una réplica de solo lectura (ApplicationIntent=ReadOnly), Orchestrator la utilizará para recuperar los siguientes elementos:

• Artículos en cola
• datos de supervisión
• datos de trabajos

De lo contrario, Orchestrator utilizará la base de datos de lectura-escritura.

Recuperación de elementos de cola

Los datos de los artículos en cola pueden recuperarse de la réplica de solo lectura.

Puedes habilitar esto a través del parámetro Features.Queues.QueryUseReadOnlyReplica en el archivo UiPath.Orchestrator.dll.config. Detalles...

Monitorización de Orchestrator

Los datos utilizados para mostrar tus vistas de supervisión pueden recuperarse de la réplica de solo lectura.

Puedes habilitar esto a través del parámetro Monitoring.UseReadOnlyReplica en el archivo UiPath.Orchestrator.dll.config. Detalles...