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.
La réplica utiliza tres tipos de fragmentos:
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.
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.
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:
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
Lado de la réplica
Lado de réplica en la migración tras error
Este protocolo garantiza que al base de datos está en el mismo nivel que el estado del nuevo fragmento primario.