Ciclos de Vida de Shard

As partes passam por diferentes estados e eventos para suportarem a replicação. O ciclo de vida de um shard inclui ficar on-line, tempo de execução, encerramento, failover e manipulação de erro. Os shards podem ser promovidos de um shard réplica para um shard primário para manipular alterações do estado do servidor.

Eventos de Ciclo de Vida

Quando as partes primárias e de réplicas são colocadas e iniciadas, elas passam por uma série de eventos para torná-las on-line e deixá-las no modo de escuta.

shard primário

O serviço de catálogo coloca uma parte primária para uma partição. O serviço de catálogo também realiza o trabalho de equilíbrio de locais de partes primárias e o início de failover para partes primárias.

Quando uma parte torna-se uma parte primária, ela recebe uma lista de réplicas do serviço de catálogo. A nova parte primária cria um grupo de réplicas e registra todas as réplicas.

Quando o principal está pronto, uma abertura para a mensagem de negócios é exibida no arquivo SystemOut.log para o contêiner no qual está em execução. A mensagem aberta, ou a mensagem CWOBJ1511I, lista o nome do mapa, nome do conjunto do mapa e número da partição do shard primário que iniciou.

CWOBJ1511I: mapName:mapSetName:partitionNumber (primário) é aberto para negócios.
Consulte Posicionamento de Shard para obter informações adicionais sobre como o serviço de catálogo coloca shards.
Shard de Réplica

As partes da réplica são principalmente controladas pela parte primária, a não ser que a réplica detecte um problema. Durante um ciclo de vida normal, o shard primário posiciona, registra e cancela o registro de um shard de réplica.

Quando a parte primária inicializa uma parte da réplica, uma mensagem exibe o log que descreve onde a réplica é executada para indicar que está disponível a parte da réplica. A mensagem aberta, ou a mensagem CWOBJ1511I, lista o nome do mapa, nome do conjunto do mapa e número da partição do shard de réplica. Essa mensagem é mostrada a seguir:

CWOBJ1511I: mapName:mapSetName:partitionNumber (réplica síncrona) é aberta para negócios.
ou
CWOBJ1511I: mapName:mapSetName:partitionNumber (réplica assíncrona) é aberta para negócios.

Shard de réplica assíncrona: Um shard de réplica assíncrona sonda o primário para dados. A réplica automaticamente ajustará a sincronização da sondagem se não receber dados do primário, o que indica que ela é capturada com o primário. Ela também ajustará se receber um erro que possa indicar que o primário falhou ou se houver um problema de rede.

Quando a réplica assíncrona inicia a replicação, ela imprime a seguinte mensagem para o arquivo SystemOut.log para a réplica. Esta mensagem pode ser impressa mais de uma vez por mensagem CWOBJ1511. Ela será impressa novamente se a réplica conectar a um primário diferente ou se os mapas do modelo forem incluídos.
CWOBJ1543I: A réplica assíncrona objectGridName:mapsetName:partitionNumber iniciou ou 
continuou a replicação a partir do primário. Replicando para mapas: [mapName]

Shard de réplica síncrona: Quando o shard de réplica síncrona é iniciado pela primeira vez, ele ainda não está no modo peer. Quando uma parte da réplica está no modo de mesmo nível, ela recebe dados da primária conforme eles chegam na primária. Antes de digitar o modo de mesmo nível, a parte da réplica precisa de uma cópia de todos os dados existentes na parte primária.

A réplica síncrona copia dados do shard primário semelhante a uma réplica assíncrona sondando os dados. Quando copia os dados existentes do primário, ela alterna para o modo peer e começa a receber dados como o primário recebe os dados.

Quando um shard de réplica alcança o modo peer, ele imprime uma mensagem no arquivo SystemOut.log para a réplica. O tempo refere-se ao período de tempo que o shard de réplica leva para obter todos os seus dados iniciais do shard primário. O tempo pode ser exibido como zero ou mínimo, se a parte primária não tiver nenhum dado existente para replicar. Esta mensagem pode ser impressa mais de uma vez por mensagem CWOBJ1511. Ela será impressa novamente se a réplica conectar a um primário diferente ou se os mapas do modelo forem incluídos.
CWOBJ1526I: Réplica objectGridName:mapsetName:partitionNumber:mapName entrando no modo peer
após X segundos.

Quando o shard de réplica síncrona está no modo peer, o shard primário deve replicar transações para todas as réplicas síncronas do modo peer. Os dados da parte da réplica síncrona permanecem no mesmo nível que os dados da parte primária. Se um número mínimo de réplicas síncronas ou minSync for configurado na política de implementação, esse número de réplicas síncronas deve ser votado para confirmação antes que a transação possa ser confirmada com êxito no primário.

Eventos de Recuperação

A replicação é projetada para recuperar a partir da falha e de eventos de erro. Se uma parte primária falhar, outra réplica será transferida. Se os erros estiverem nas partes da réplica, ela tentará a recuperação. O serviço de catálogo controla a disposição e as transações de novos shards primários ou novos shards de réplica.

O shard de réplica torna-se um shard principal

Uma parte da réplica torna-se uma parte primária por dois motivos. A parte primária parou ou falhou, ou uma decisão de equilíbrio foi tomada para mover a parte primária anterior para um novo local.

O serviço de catálogo seleciona uma nova parte primária a partir das partes de réplicas síncronas existentes. Se um movimento primário tiver que ocorrer e não houver nenhuma réplica, uma réplica temporária será colocada para concluir a transição. A nova parte primária registra todas as réplicas existentes e aceita as transações como a nova parte primária. Se as partes da réplica existentes tiverem o nível correto de dados, os dados atuais serão preservados conforme as partes de réplicas são registradas com a nova parte primária. As réplicas assíncronas serão sondadas em relação ao novo primário.

Figura 1. Posicionamento de exemplo de um conjunto de mapas do ObjectGrid para a partição partition0. A política de implementação tem um valor de minSyncReplicas de 1, um valor de maxSyncReplicas de 2, e um valor de maxAsyncReplicas de 1.
A máquina A tem um shard primário da partição 0. A máquina B e a C têm shards de réplica síncronas. A máquina D tem um shard de réplica assíncrona.
Figura 2. O contêiner para o shard primário falha
O contêiner para o shard primário, que está executando na Máquina A, falha.
Figura 3. O Shard de Réplica Síncrona no Contêiner 2 do ObjectGrid se Torna o Shard Primário
Na máquina B, o shard de réplica assíncrona se torna o shard primário.
Figura 4. A máquina B contém o shard primário. Dependendo de como o modo de reparo automático é configurado e da disponibilidade dos contêineres, um novo shard de réplica síncrona pode ou não ser posicionado em uma máquina.
A máquina B agora tem um shard primário, e a máquina C tem um shard de réplica síncrona, e a máquina D tem um shard de réplica assíncrona

Recuperação de shard de réplica

Um shard de réplica síncrona é controlado pelo shard primário. No entanto, se uma réplica detectar um problema, ela poderá acionar um evento novamente registrado para corrigir o estado dos dados. A réplica remove os dados atuais e obtém uma cópia atual da primária.

Quando uma parte da réplica inicia um evento novamente registrado, a réplica copia uma mensagem de log.

CWOBJ1524I: Listener de réplica 
objectGridName:mapSetName:partition deve registrar novamente com o shard primário. 
Razão: Exceção listada
Se uma transação provocar um erro em uma parte da réplica durante o processamento, então a parte da réplica estará em um estado desconhecido. A transação foi processada com êxito na parte primária, mas aconteceu algo errado na réplica. Para corrigir essa situação, a réplica inicia um evento novamente registrado. Com uma nova cópia de dados da primária, a parte da réplica pode continuar. Se ocorrer novamente o mesmo problema, a parte da réplica não será novamente registrada de forma contínua. Consulte Eventos de Falha para obter detalhes adicionais.

Eventos de Falha

Uma réplica pode parar a replicação de dados se ela encontrar situações de erro nas quais ela não pode ser recuperada.

Muitas tentativas de registro

Se uma réplica acionar várias vezes um novo registro sem confirmar dados com êxito, ela irá parar. A parada evita que uma réplica entre em um loop de novo registro sem fim. Por padrão, uma parte da réplica tenta registrar novamente três vezes seguidas antes de parar.

Se uma parte da réplica registrar novamente muitas vezes, ela copiará a mensagem a seguir no log.

CWOBJ1537E: objectGridName:mapSetName:partition excedeu o número máximo 
de vezes para registrar novamente (timesAllowed) sem transações com êxito.
Se a réplica não conseguir ser recuperada pelo novo registro, poderá existir um problema predominante com as transações relativas à parte da réplica. Um possível problema poderia ser recursos ausentes no caminho de classe, se ocorrer um erro ao aumentar as chaves ou valores da transação.

Falha ao entrar no modo peer

Se uma réplica tentar digitar o modo de mesmo nível e tiver um erro no processamento de dados existentes em massa a partir do primário (os dados do ponto de verificação), a réplica será encerrada. O encerramento evita que uma réplica seja iniciada com dados iniciais incorretos. Como ela recebe os mesmos dados do shard primário, caso seja novamente registrada, a réplica não tentará novamente.

Se uma parte da réplica falhar ao entrar no modo de mesmo nível, ela copiará a mensagem a seguir no log:

CWOBJ1527W A réplica objectGridName:mapSetName:partition:mapName ao entrar no modo de mesmo nível depois de numSeconds segundos.
Uma mensagem adicional é exibida no log que explica o motivo pelo qual a réplica falhou ao entrar no modo de mesmo nível.

Recuperação após falha ao registrar novamente ou do modo de mesmo nível

Se uma réplica falhar ao registrar novamente ou ao entrar no modo de mesmo nível, a réplica estará em um estado inativo até um novo evento de posicionamento ocorrer. Um novo evento de posicionamento pode ser um novo servidor que está iniciando ou parando. Também é possível iniciar um evento de posicionamento usando o método triggerPlacement no Mbean PlacementServiceMBean.