Réplicas y fragmentos

Con eXtreme Scale, una base de datos o fragmento en memoria puede duplicarse desde una Máquina virtual Java (JVM ) en otra. Un fragmento representa una partición que se coloca en un contenedor. En un contenedor pueden existir varios fragmentos que representan distintas particiones. Cada partición tiene una instancia que es un fragmento primario y un número configurable de fragmentos de réplica. Los fragmentos de réplica son síncronos o asíncronos. Los tipos y la ubicación de los fragmentos de réplica los determina eXtreme Scale mediante una política de despliegue, que especifica el número mínimo y máximo de los fragmentos síncronos y asíncronos.

Tipos de fragmento

La réplica utiliza tres tipos de fragmentos:

  • Fragmento primario
  • Réplica síncrona
  • Réplica asíncrona

El fragmento primario recibe todas las operaciones de inserción, actualización y eliminación. El fragmento primario añade y elimina réplicas, duplica datos en las réplicas y gestiona confirmaciones y retrotracciones de transacciones.

Las réplicas síncronas mantienen el mismo estado que el fragmento primario. Cuando un fragmento primario duplica datos en una réplica síncrona, la transacción no se confirma hasta que se confirma en la réplica síncrona.

Las réplicas asíncronas pueden o no estar en el mismo estado que el fragmento primario. Cuando un fragmento primario duplica datos en una réplica asíncrona, el fragmento primario no espera a que la réplica asíncrona se confirma.

Figura 1. Vía de acceso de comunicación entre un fragmento primario y fragmentos de réplica
Una transacción se comunica con un fragmento primario. El fragmento primario se comunica con los fragmentos de réplica, que pueden existir en una o varias máquinas virtuales Java.

Fragmentos mínimos de réplicas síncronas

Cuando un fragmento primario se prepara para confirmar datos, comprueba cuántos fragmentos de réplicas síncronas han votado por confirmar la transacción. Si la transacción normalmente se procesa en la réplica, vota por confirmarse. Si se ha producido algún error en la réplica síncrona, se vota por no confirmarse. Antes de que un fragmento primario se confirme, el número de fragmentos de réplicas síncronas que votan por confirmarse deben satisfacer el valor minSyncReplica en la política de despliegue. Cuando el número de fragmentos de réplicas síncronas que votan por confirmarse es demasiado bajo, el fragmento primario no confirma la transacción y resulta en un error. Esta acción garantiza que la cantidad necesaria de réplicas síncronas esté disponible con los datos correctos. Las réplicas síncronas que han encontrado errores se han vuelto a registrar para corregir su estado. Si desea más información sobre cómo volver a realizar el registro, consulte Recuperación del fragmento de réplica.

El fragmento primario genera un error ReplicationVotedToRollbackTransactionException si muy pocas réplicas síncronas han votado por confirmarse.

Réplica y cargadores

Normalmente, un fragmento primario graba de forma síncrona en una base de datos los cambios a través del cargador. El cargador y la base de datos siempre están sincronizados. Cuando el fragmento primario realiza una migración tras error en un fragmento de réplica, es posible que la base de datos y el cargador no estén sincronizados. Por ejemplo:

  • El fragmento primario puede enviar la transacción a la réplica y luego sufrir una anomalía antes de confirmarse en la base de datos.
  • El fragmento primario puede confirmarse en la base de datos y luego sufrir una anomalía antes de enviar la réplica.

Los dos enfoques llevan a que la réplica esté una transacción por delante o por detrás de la base de datos. Esta situación no es aceptable. eXtreme Scale utiliza un protocolo especial y un contrato con la implementación de cargador para resolver esta cuestión sin la confirmación de dos fases. El protocolo es el siguiente:

Lado del fragmento primario

  • Enviar la transacción junto con resultados de transacciones anteriores.
  • Grabar en la base de datos e intentar confirmar la transacción.
  • Si la base de datos se confirma, confirmar en eXtreme Scale. Si la base de datos no está confirmada, retrotraer la transacción.
  • Grabar el resultado.

Lado de la réplica

  • Recibir una transacción y almacenarla en el almacenamiento intermedio.
  • Para todos los resultados, enviar con la transacción, confirmar todas las transacciones almacenadas en el almacenamiento intermedio y descartar todas las transacciones retrotraídas.

Lado de réplica en la migración tras error

  • Para todas las transacciones almacenadas en el almacenamiento intermedio, proporcionar las transacciones para el cargador y éste intenta confirmar las transacciones.
  • Es necesario grabar el cargador para que cada transacción sea idempotente.
  • Si la transacción ya está en la base de datos, el cargador no realizar ninguna operación.
  • Si la transacción no está en la base de datos, el cargador aplica la transacción.
  • Una vez que se han procesado todas las transacciones, el nuevo fragmento primario puede empezar a atender a solicitudes.

Este protocolo garantiza que al base de datos está en el mismo nivel que el estado del nuevo fragmento primario.