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