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

Edge para nuvem privada v. 4.17.09

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 do Edge determina os nós em que as réplicas são colocadas.

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 um significa que há apenas uma cópia de cada linha no cluster do Cassandra. Um fator de replicação de dois significa que há duas 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á uma 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 fator de replicação padrão para 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:

  1. Faça login em um nó do Cassandra.
  2. Execute o seguinte comando:
    > /opt/apigee/apigee-cassandra/bin/cassandra-cli -h $(hostname -i) <<< "show scheme;"

    Em que $(hostname -i) é resolvido para o endereço IP do nó do Cassandra. Ou substitua $(hostname -i) pelo endereço IP do nó.

Para cada keyspace, você verá a saída no formato:

create keyspace kms
  with placement_strategy = 'NetworkTopologyStrategy'
  and strategy_options = {dc-1 : 3}
  and durable_writes = true;

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.

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

Por exemplo, se você aumentar o número de nós do Cassandra para seis, mas deixar o fator de replicação em três, não garantirá que todos os nós do Cassandra tenham uma cópia de todos os dados. Se um nó ficar inativo, um fator de replicação maior significa uma maior probabilidade de que os dados no nó existam em um dos nós restantes. A desvantagem de um fator de replicação mais alto é uma latência maior nas gravações de dados.

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.

Durante a conexão com o Cassandra para operações de leitura e gravação, os nós do servidor de gerenciamento e processamento de mensagens costumam usar o valor Cassandra de LOCAL_QUORUM para especificar o nível de consistência de um keyspace. No entanto, alguns keyspaces são definidos para usar um nível de consistência de um.

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 para um ambiente de produção do Edge 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 baixo para um número inteiro).

Com LOCAL_QUORUM = 2, pelo menos dois dos três nós do Cassandra no data center precisam responder a uma operação de leitura/gravação para que a operação seja bem-sucedida. Portanto, para um cluster do Cassandra de três nós, ele poderia tolerar um nó inativo por data center.

Ao especificar o nível de consistência como LOCAL_QUORUM, o Edge evita a latência exigida validando operações em vários data centers. Se um keyspace usava o valor QUORUM do Cassandra como nível de consistência, as operações de leitura/gravação teriam que ser validadas em todos os data centers.

Para ver o nível de consistência usado pelos nós do Processador de mensagens do Edge ou do Servidor de gerenciamento:

  1. Faça login em um nó do processador de mensagens.
  2. Mude para o diretório /opt/apigee/edge-message-processor/conf:
    > cd /opt/apigee/edge-message-processor/conf
  3. Para consistência de gravação:
    > grep -ri "write.consistencylevel" *
  4. Para consistência de leitura:
    > grep -ri "read.consistencylevel" *
  5. Faça login no nó do servidor de gerenciamento.
  6. Mude para o diretório /opt/apigee/edge-management-server/conf:
    > cd /opt/apigee/edge-management-server/conf
  7. Repita as etapas 3 e 4.

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