Ciclos de vida de los fragmentos

Los fragmentos pasan por estados y sucesos diferentes para poder admitir operaciones de réplica. El ciclo de vida de un fragmento incluye el paso a estar en línea, el tiempo de ejecución, la conclusión, la migración tras error y el manejo errores. Los fragmentos se pueden trasladar de un fragmento de réplica a un fragmento primario para manejar los cambios del estado del servidor.

Sucesos de ciclo de vida

Cuando se colocan y se inician los fragmentos réplica, pasan por una serie de sucesos hasta llegar a estar en línea y en modalidad de escucha.

Fragmento primario

El servicio de catálogo coloca un fragmento primario para una partición. El servicio de catálogo también equilibra las ubicaciones de los fragmentos primarios y e inicia la sustitución por anomalía para fragmentos primarios.

Cuando un fragmento se convierte en un fragmento primario, recibe una lista de réplicas del servicio de catálogo. El fragmento primario nuevo crea un grupo de réplicas y las registra.

Cuando el fragmento primario está listo, se muestra un mensaje de listo para operaciones empresariales en el archivo SystemOut.log del contenedor donde se esté ejecutando. El mensaje abierto o el mensaje CWOBJ1511I, lista el nombre de la correlación, el nombre del conjunto de correlaciones y el número de partición del fragmento primario que se ha iniciado.

CWOBJ1511I: mapName:mapSetName:partitionNumber (primary) is open for business.
Consulte el apartado Colocación de fragmentos para obtener más información sobre cómo coloca fragmentos el servicio de catálogo.
Fragmento réplica

Los fragmentos réplica los controla principalmente el fragmento primario a no ser que la réplica detecte un problema. Durante un ciclo de vida normal, el fragmento primario coloca, registra y elimina el registro de un fragmento de réplica.

Cuando el fragmento primario inicializa un fragmento réplica, un mensaje muestra el archivo de anotaciones cronológicas que describe dónde se ejecuta la réplica para indicar que el fragmento réplica está disponible. El mensaje abierto, o el mensaje CWOBJ1511I, lista el nombre de correlación, el nombre del conjunto de correlaciones y el número de partición del fragmento de réplica. Este mensaje es el siguiente:

CWOBJ1511I: mapName:mapSetName:partitionNumber (synchronous replica) is open for business.
o bien
CWOBJ1511I: mapName:mapSetName:partitionNumber (asynchronous replica) is open for business.

Fragmento réplica asíncrono: un fragmento réplica asíncrono sondea el fragmento primario para obtener los datos. La réplica ajustará automáticamente la temporización del sondeo si no recibe los datos del fragmento primario, que indica que se ha puesto al día con el fragmento primario. Se ajustará también si recibe un error que podría indicar que se ha producido un error en el fragmento primario o si hay un problema de red.

Cuando la réplica asíncrona comienza la réplica, imprime el mensaje siguiente en el archivo SystemOut.log para la réplica. Este mensaje podría imprimirse más de una vez por mensaje CWOBJ1511. Se imprimirá de nuevo si la réplica se conecta a un fragmento primario distinto o si se han añadido correlaciones de plantilla.
CWOBJ1543I: Se ha iniciado la réplica asíncrona objectGridName:mapsetName:partitionNumber o
ha seguido realizando la réplica desde el fragmento principal. Réplica de correlaciones: [mapName]

Fragmento réplica síncrono: cuando se inicia por primera vez el fragmento réplica asíncrono, no está todavía en modalidad de igual. Cuando un fragmento réplica está en modalidad de igual, recibe datos del fragmento primario a medida que los datos van entrando en el fragmento primario. Antes de pasar a la modalidad de igual, el fragmento réplica necesita una copia de todos los datos existentes en el fragmento primario.

La réplica síncrona copia los datos del fragmento primario similar a una réplica asíncrona sondeando los datos. Cuando copia los datos existentes del fragmento primario, cambia a modalidad de igual y comienza a recibir los datos a medida que el fragmento primario recibe los datos.

Cuando un fragmento réplica alcanza la modalidad de igual, imprime un mensaje en el archivo SystemOut.log de la réplica. El tiempo se refiere a la cantidad de tiempo que tardó el fragmento réplica en obtener todos los datos iniciales del fragmento primario. El valor de tiempo puede mostrarse como cero o muy bajo si el fragmento primario no tiene ningún dato que deba replicar.Puede que este mensaje se imprima más de una vez por mensaje CWOBJ1511. Se imprimirá de nuevo si la réplica se conecta a un fragmento primario distinto o si se han añadido correlaciones de plantilla.
CWOBJ1526I: Replica objectGridName:mapsetName:partitionNumber:mapName entering peer mode after X seconds.

Cuando el fragmento de réplica síncrono está en modalidad de igual, el fragmento primario debe hacer una réplica de las transacciones a todas las réplicas síncronas de modalidad de igual. Los datos del fragmento réplica síncrono permanecen al mismo nivel que los del fragmento primario. Si se establece un número mínimo de réplicas síncronas o minSync en la política de despliegue, ese número de réplicas síncronas debe votar confirmarse antes de que la transacción pueda confirmarse satisfactoriamente en el fragmento principal.

Sucesos de recuperación

Las operaciones de réplica se han diseñado para realizar recuperaciones a partir de sucesos de anomalías y errores. Si se produce una anomalía en un fragmento primario, otra réplica pasa a tener el control. Si las anomalías se producen en los fragmentos réplica, éstos intentarán recuperarse. El servicio de catálogo controla la colocación y las transacciones de fragmentos primarios nuevos o fragmentos réplica nuevos.

Un fragmento réplica se convierte en un fragmento primario

Un fragmento réplica se convierte en un fragmento primario por dos razones: el fragmento primario se ha detenido o ha fallado, o se ha realizado una decisión de equilibrio para mover el fragmento primario anterior a una nueva ubicación.

El servicio de catálogo selecciona un nuevo fragmento primario de los fragmentos réplica síncronos existentes. Si debe tener lugar un movimiento de fragmento primario y no hay réplicas, se colocará una réplica temporal para completar la transición. El fragmento primario nuevo registra todas las réplicas existentes y acepta transacciones como el nuevo fragmento primario. Si los fragmentos réplica existentes tienen el nivel correcto de datos, los datos actuales se conservan a medida que los fragmentos réplica se registran con el nuevo fragmento primario. Se sondearán las réplicas asíncronas con el nuevo fragmento primario.

Figura 1. Colocación de ejemplo de un conjunto de correlaciones ObjectGrid para la partición partition0. La política del despliegue tiene un valor minSyncReplicas de 1, un valor maxSyncReplicas de 2 y un valor maxAsyncReplicas de 1.
La máquina A tiene un fragmento primario de una partición 0. La máquina B y C tienen unos fragmentos de réplica síncrona. La máquina D tiene un fragmento de réplica asíncrona.
Figura 2. El contenedor del fragmento primario falla.
El contenedor del fragmento primario, que se ejecuta en la máquina A, falla.
Figura 3. El fragmento de réplica síncrona en el contenedor 2 de ObjectGrid pasa a ser el fragmento primario.
En la máquina B, el fragmento de réplica síncrona pasa a ser el fragmento primario.
Figura 4. La máquina B contiene el fragmento primario. En función de cómo se establece la modalidad de reparación automática y la disponibilidad de los contenedores, un nuevo fragmento de réplica síncrona se podría colocar o no en una máquina.
La máquina B ahora tiene un fragmento primario, y una máquina C tiene un fragmento de réplica síncrona y una máquina D tiene un fragmento de réplica asíncrona.

Recuperación de un fragmento réplica

El fragmento primario controla al fragmento réplica síncrono. No obstante, si un fragmento réplica detecta un problema, puede desencadenar un suceso de volver a registrar para corregir el estado de los datos. La réplica borra los datos actuales y obtiene una nueva copia del fragmento primario.

Cuando un fragmento réplica inicia un suceso de volver a registrar, la réplica imprime un mensaje de anotaciones cronológicas.

CWOBJ1524I: Replica listener
objectGridName:mapSetName:partition must re-register with the primary.
Reason: Exception listed
Si una transacción provoca un error en un fragmento réplica durante el proceso, el fragmento réplica está en un estado desconocido. La transacción se ha procesado correctamente en el fragmento primario, pero se ha producido una anomalía en la réplica. Para corregir esta situación, la réplica inicia un suceso de volver a registrar. Con una nueva copia de los datos del fragmento primario, el fragmento réplica puede continuar. Si se vuelve a repetir el problema, el fragmento réplica no vuelve a registrarse de forma continuada. Si desea más información, consulte Sucesos de errores.

Sucesos de errores

Una réplica puede detener la réplica de datos si encuentra situaciones de error para las que no se puede recuperar la réplica.

Demasiados intentos de registro

Si una réplica desencadena un suceso de volver a registrar varias veces, pero no se confirman los datos correctamente, la réplica se detiene. Al detenerse, se evita que la réplica entre en un bucle infinito de sucesos de volver a registrarse. De manera predeterminada, un fragmento réplica intenta volver a registrarse tres veces seguidas antes de detenerse.

Si un fragmento réplica vuelve a registrarse demasiadas veces, imprimirá el siguiente mensaje en el archivo de anotaciones cronológicas.

CWOBJ1537E: objectGridName:mapSetName:partition exceeded the maximum number
of times to reregister (timesAllowed) without successful transactions..
Si la réplica no se recupera mediante operaciones de volver a registrarse, podría existir un problema generalizado con las transacciones relativas al fragmento réplica. Un problema posible podría ser que faltan recursos en la variable CLASSPATH si se produce un error al inflar las claves o valores de la transacción.

Anomalía al entrar en modalidad de igual

Si una réplica intenta entrar en modalidad de igual y se produce un error al procesar los datos en bloque del fragmento primario (datos del punto de control), la réplica concluye. Esto impide que la réplica se inicie con datos iniciales incorrectos. Puesto que recibe los mismos datos del primario si se vuelve a registrar, no se vuelve a intentar la réplica.

Si un fragmento réplica no puede entrar en modalidad de igual, imprimirá el siguiente mensaje en el archivo de anotaciones cronológicas:

CWOBJ1527W Replica objectGridName:mapSetName:partition:mapName failed to enter peer mode after numSeconds seconds.
En el archivo de anotaciones cronológicas se muestra otro mensaje que explica por qué la réplica no ha podido entrar en modalidad de igual.

Recuperación después de una anomalía al volver a registrarse o de la modalidad de igual

Si una réplica falla al volver a registrarse o al entrar en la modalidad de igual, la réplica está en un estado inactivo hasta que se produce un nuevo suceso de colocación. Un nuevo suceso de colocación podría ser un nuevo servidor que se inicia o detiene. También puede iniciar un suceso de colocación utilizando el método triggerPlacement en el MBean PlacementServiceMBean.