Diseño, latencia y cartera de pedidos finalmente coherentes
Un grupo de replicación es consistente cuando las consultas SQL en un nodo de replicación del grupo producen el mismo resultado en todos los nodos de replicación del grupo. Para mantener idénticas las bases de datos de distintos nodos, IBM® Netezza® Replication Services utiliza el método de coherencia eventual.
Con el método eventualmente consistente, puede haber ocasiones en las que un nodo (el primario) tenga un contenido de base de datos más reciente que los demás. La cantidad de tiempo que la réplica va por detrás del primario se denomina latencia, y la cantidad de datos que deben ser replicados y aplicados por la réplica es el backlog.
La latencia y el retraso dependen de la configuración específica y de la carga de trabajo. Las causas específicas de latencia en IBM Netezza Replication Services son las siguientes:
- La capacidad de los nodos primarios para realizar transacciones de actualización SQL (que incluyen, por ejemplo, INSERT, DELETE o UPDATE) contra datos replicados en paralelo está sujeta a los niveles de aislamiento de las transacciones actuales (que pueden ser serializables o de aislamiento instantáneo). Las réplicas ejecutan las transacciones replicadas en serie en el orden en que fueron confirmadas en el primario. El tiempo que se tarda en completar un conjunto de transacciones replicadas concurrentes en el primario es equivalente al tiempo que tarda la transacción más larga. Sin embargo, el tiempo que se tarda en completar estas mismas transacciones en una réplica es la suma de los tiempos de ejecución de cada transacción.
- Los datos del archivo de carga se replican en los hosts réplica después de que se hayan cargado completamente en el primario. Todos los datos del archivo de carga se capturan primero por completo en el registro del gestor de colas de replicación primario y, a continuación, los datos se transmiten a la réplica. Sólo cuando todos los datos de una transacción se han transferido completamente, la réplica comienza a aplicar los datos. El tiempo de transferencia del registro de replicación es la cantidad total de datos dividida por el ancho de banda limitado por ventanas de la conexión del gestor de colas de replicación y contribuye directamente a la latencia. Para múltiples cargas secuenciales en la misma transacción, IBM Netezza Replication Services no espera a que se completen todas las cargas antes de comenzar la transferencia; la latencia cae entre el tiempo para transmitir la última carga grande y el tiempo para transmitir todos los datos.
El diseño finalmente coherente tiene implicaciones para las aplicaciones que utilizan IBM Netezza Replication Services para implementaciones a mayor escala. Algunas consideraciones de diseño son las siguientes:
- Las consultas que deben ejecutarse con latencia cero deben emitirse en el primario actual. El primario actual puede identificarse a partir de las vistas operativas del conjunto de replicación.
- Las aplicaciones que realizan consultas que deben ejecutarse con baja latencia comprueban las vistas operativas del conjunto de réplicas para determinar la latencia actual de las réplicas y, a continuación, envían las consultas a las réplicas cuyas latencias se encuentran dentro de los límites aceptables.
- Las consultas que no son sensibles a la latencia pueden enviarse a cualquier nodo NPS del conjunto de replicación.
- Puede diseñar consultas que utilicen datos de fila, como una fecha, hora, ejecución por lotes u otro valor de columna identificativo, para excluir los resultados que sean más recientes que un valor determinado.