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.
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.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 bienCWOBJ1511I: 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.
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.
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.
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.
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
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.