Esta página foi traduzida pela API Cloud Translation.

Sobre o fator de replicação e o nível de consistência do Cassandra

Sobre o fator de replicação do Cassandra

O Cassandra armazena réplicas de dados em vários nós para garantir confiabilidade e tolerância a falhas. A estratégia de replicação para cada keyspace de borda determina os nós em que as réplicas estão colocados.

O número total de réplicas de um keyspace em um cluster do Cassandra é chamado de fator de replicação do keyspace. Um fator de replicação de 1 significa que há apenas um cópia de cada linha do cluster do Cassandra. Um fator de replicação igual a dois significa que cópias de cada linha, em que cada cópia está em um nó diferente. Todas as réplicas são igualmente importantes. não há réplica principal ou mestre.

Em um sistema de produção com três ou mais nós do Cassandra em cada data center, o padrão o fator de replicação de um keyspace do Edge é três. Como regra geral, o fator de replicação não pode exceder o número de nós do Cassandra no cluster.

Use o procedimento a seguir para visualizar o esquema do Cassandra, que mostra o fator de replicação de cada keyspace do Edge:

Faça login em um nó do Cassandra.
Execute este comando:
```
/opt/apigee/apigee-cassandra/bin/cqlsh $(hostname -i) [-u cassuser -p casspass] -e "select keyspace_name, replication from system_schema.keyspaces;"
```
Em que $(hostname -i) é resolvido para o endereço IP do nó do Cassandra. Ou substitua $(hostname -i) pelo endereço IP do nó.

cassuser: se você tiver ativado a autenticação do Cassandra, transmita o nome de usuário do Cassandra. Isso é opcional e poderá ser ignorado se a autenticação do Cassandra não estiver ativada.

casspass: se você tiver ativado a autenticação do Cassandra, transmita a senha do Cassandra. Isso é opcional e poderá ser ignorado se a autenticação do Cassandra não estiver ativada.

O resultado será semelhante ao mostrado abaixo, em que cada linha representa um keyspace:

  keyspace_name       | replication                                                                 
  kms                 | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
  system_distributed  | {'class': 'org.apache.cassandra.locator.SimpleStrategy', 'replication_factor': '3'}
  apprepo             | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}

Observe que para o data center 1, dc-1, o fator de replicação padrão para o keyspace kms é três para uma instalação com três nós do Cassandra. Para determinados keyspaces internos ao Cassandra (como system, system_schema etc.), a estratégia e o fator de replicação podem ser diferentes. Esse é um comportamento intencional do sistema.

Se você adicionar outros nós do Cassandra ao cluster, o fator de replicação padrão não será afetadas.

Sobre o nível de consistência do Cassandra

O nível de consistência do Cassandra é definido como o número mínimo de nós do Cassandra que precisam confirmar uma operação de leitura ou gravação antes que ela possa ser considerada bem-sucedida. Diferentes níveis de consistência podem ser atribuídos a diferentes keyspaces do Edge.

Ao se conectar ao Cassandra para operações de leitura e gravação, o processador e o gerenciamento de mensagens Os nós de servidor geralmente usam o valor LOCAL_QUORUM do Cassandra para especificar o nível de consistência de um keyspace. No entanto, alguns keyspaces são definidos para usar uma com o nível de consistência 1.

O cálculo do valor de LOCAL_QUORUM para um data center é:

LOCAL_QUORUM = (replication_factor/2) + 1

Conforme descrito acima, o fator de replicação padrão de um ambiente de produção de borda com três nós do Cassandra é três. Portanto, o valor padrão de LOCAL_QUORUM = (3/2) +1 = 2 (o valor é arredondado para um número inteiro).

Com LOCAL_QUORUM = 2, pelo menos dois dos três nós do Cassandra nos dados center precisa responder a uma operação de leitura/gravação para que ela seja bem-sucedida. Para um nó com três nós cluster do Cassandra, o cluster poderia tolerar a inatividade de um nó por data center.

Ao especificar o nível de consistência como LOCAL_QUORUM, o Edge evita a latência necessárias para validar operações em vários data centers. Se um keyspace usou o formato do Cassandra QUORUM como nível de consistência, as operações de leitura/gravação teriam que ser validados em todos os data centers.

Para ver o nível de consistência usado pelos nós do processador de mensagens de borda ou do servidor de gerenciamento:

Faça login em um nó do processador de mensagens.
Use o diretório /opt/apigee/edge-message-processor/conf:
```
cd /opt/apigee/edge-message-processor/conf
```
Para consistência na leitura e gravação:
```
grep -ri "consistency.level" *
```
Faça login no nó do servidor de gerenciamento.
Use o diretório /opt/apigee/edge-management-server/conf:
```
cd /opt/apigee/edge-management-server/conf
```
Repita a etapa 3.

Se você adicionar outros nós do Cassandra ao cluster, o nível de consistência não será afetado.