Réplicas e Shards

Com o eXtreme Scale, um banco de dados de memória ou shard pode ser replicado a partir de uma Java Virtual Machine (JVM) para outra. Uma parte representa uma partição que é colocada em um contêiner. Várias partes que representam diferentes partições podem existir em um único contêiner. Cada partição tem uma instância que é um shard primário e um número configurável de shards de réplica. Os shards de réplica são síncronos ou assíncronos. Os tipos e a disposição dos shards de réplica são determinados pelo eXtreme Scale utilizando uma política de implementação, que especifica o número mínimo e máximo de shards síncronos e assíncronos.

Tipos de Shard

A replicação usa três tipos de shards:

  • Principal
  • Réplica síncrona
  • Réplica assíncrona

A parte primária recebe todas as opções insert, update e remove. A parte primária inclui e remove réplicas, replica dados para as réplicas e gerencia confirmações e recuperações de transações.

As réplicas síncronas mantêm o mesmo estado que o primário. Quando um primário replica dados para uma réplica síncrona, a transação não é confirmada, até que seja confirmada na réplica síncrona.

As réplicas assíncronas podem ou não ter o mesmo estado que o primário. Quando um primário replica dados para uma réplica assíncrona, o primário não aguarda a confirmação da réplica assíncrona.

Figura 1. Caminho de Comunicação Entre um Shard Primário e Shards de Réplica
Uma transação se comunica com um shard primário. O shard primário se comunica com shards de réplica, que podem existir em uma ou mais Java virtual machines.

Mínimo de Shards de Réplica Síncrona

Quando um primário prepara para consolidar dados, ele verifica quantas partes de réplicas síncronas foram aprovadas para confirmar a transação. Se a transação processar normalmente na réplica, ela aprovará a confirmação. Se aconteceu algo errado na réplica síncrona, ela não aprovará a confirmação. Antes de um principal confirmar, o número de shards de réplica síncronas que são aprovadas para confirmação devem corresponder à configuração minSyncReplica da política de implementação. Quando o número de partes de réplicas síncronas sendo aprovado para confirmação for muito baixo, o primário não confirma a transação e resulta em um erro. Essa ação assegura que o número requerido de réplicas síncronas está disponível com os dados corretos. As réplicas síncronas que encontraram erros são novamente registradas para corrigir seu estado. Para obter mais informações sobre novo registro, consulte Recuperação de shard de réplica.

O primário lança um erro ReplicationVotedToRollbackTransactionException, se poucas réplicas síncronas foram aprovadas para confirmação.

Replicação e Utilitários de Carga

Normalmente, uma parte primária grava as alterações de forma síncrona por meio do Utilitário de Carga em um banco de dados. O Utilitário de Carga e o banco de dados sempre estão em sync. Quando o primário falha sobre uma parte da réplica, o banco de dados e o Utilitário de Carga podem não estar em synch. Por exemplo:

  • O primário pode enviar a transação para a réplica e, em seguida, falhar antes de confirmar com o banco de dados.
  • O primário pode confirmar com o banco de dados e, em seguida, falhar antes de enviar para a réplica.

A abordagem é conduzida para ou a réplica está sendo uma transação em frente de ou atrás do banco de dados. Essa situação não é aceitável. OeXtreme Scale utiliza um protocolo especial e um contrato com a implementação do Utilitário de Carga para resolver este problema sem two phase commit. O protocolo é mostrado a seguir:

Lado primário

  • Envie a transação juntamente com os resultados da transação anterior.
  • Grave no banco de dados e tente confirmar a transação.
  • Se o banco de dados for confirmado, então confirme no eXtreme Scale. Se ele não for confirmado, recupere a transação.
  • Registre a saída.

Lado da réplica

  • Receba uma transação e armazene-a.
  • Para todos os resultados, envie com a transação, confirme todas as transações armazenadas em buffer e descarte todas as transações recuperadas.

Lado da réplica em failover

  • Para todas as transações armazenadas em buffer, forneça as transações ao Utilitário de Carga e o Utilitário de Carga tenta confirmá-las.
  • O Utilitário de Carga precisa ser gravado para tornar cada transação idempotente.
  • Se a transação já estiver no banco de dados, o Utilitário de Carga não realizará nenhuma operação.
  • Se a transação não estiver no banco de dados, o Utilitário de Carga aplica a transação.
  • Após todas as transações serem processadas, o novo primário pode começar a receber os pedidos.

Esse protocolo assegura que o banco de dados está no mesmo nível que o novo estado primário.