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.
A replicação usa três tipos de shards:
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.
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.
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:
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
Lado da réplica
Lado da réplica em failover
Esse protocolo assegura que o banco de dados está no mesmo nível que o novo estado primário.