XDCRO sistema de replicação de dados, por padrão, oferece aos clientes a flexibilidade de ajustar o número de replicações para um determinado bucket, dependendo do desempenho desejado. A nova replicação exige o streaming de todos os documentos existentes no bucket e, portanto, apresenta uma taxa de mutação mais alta do que as mutações contínuas. Dessa forma, a nova replicação usa mais recursos, o que às vezes afetava negativamente o rendimento das replicações existentes nesse meio tempo. Com nossa próxima versão 6.5, XDCR fornecerá aos usuários a capacidade de priorizar as replicações em andamento em relação às replicações iniciais. A alocação de recursos ocorrerá com base na prioridade especificada.
Ao criar uma nova replicação, o cliente tem a opção de atribuir prioridades ao fluxo de replicação. As opções fornecidas seriam ALTA, MÉDIA ou BAIXA.
Para nossa compreensão, vamos supor que as réplicas em andamento sejam ALTAS e considerar os cenários mencionados abaixo para novas réplicas:
ALTO :
A alocação máxima de recursos seria fornecida a essa nova replicação durante o estágio inicial de backfill (até que todas as mutações no bucket de origem sejam replicadas para o bucket de destino). Isso pode ter algum impacto negativo no desempenho das replicações existentes.
Isso pode ser extremamente útil na distribuição de cargas de trabalho e em casos de uso de localidade de dados em que os clientes desejam adicionar um novo cluster à topologia, colocá-lo em funcionamento imediatamente e garantir a consistência entre os clusters o mais rápido possível.
Esse é o comportamento atual do XDCR e também será a configuração padrão.
MÉDIO :
A nova replicação receberá recursos mínimos durante o estágio de backfill para se equiparar lentamente às replicações em andamento. Assim que a replicação estiver totalmente recuperada, a prioridade desse fluxo de replicação será automaticamente alterada para ALTA e a distribuição de recursos será uniforme em todas as replicações ALTAS.
Essa é uma configuração útil para casos de uso de alta disponibilidade e recuperação de desastres. Quando um cliente não quer causar nenhum impacto negativo nos clusters existentes e pode se dar ao luxo de esperar que um novo cluster seja recuperado, essa é a configuração perfeita.
BAIXO :
A nova replicação receberá recursos mínimos durante todo o processo de replicação. Durante a replicação inicial e durante os estágios de replicação em andamento, esse fluxo terá prioridade mais baixa.
Essa é uma configuração útil quando um cliente deseja configurar um cluster hot e cold, no qual ele pode permitir um desempenho de replicação lento para o cluster cold com alocação mínima de recursos.
Para os usuários do XDCR, há apenas uma alteração visível:
Uma nova configuração de replicação, "Prioridade", será adicionada às exibições de criação e edição de replicação. Ela terá três valores possíveis, Alto/Médio/Baixo.
Como o desempenho da replicação depende muito da largura de banda da rede e da CPU alocada, os clientes podem alocar as prioridades de acordo com a importância da necessidade comercial e economizar recursos. A utilização eficaz dessa funcionalidade, atribuindo prioridades com base na necessidade comercial, pode levar à redução do custo de propriedade, especialmente para implementações em nuvem.
As atualizações do gerenciamento de recursos por meio da atribuição de prioridades são totalmente opcionais. Elas podem ser modificadas a qualquer momento no futuro, sem nenhum impacto negativo, como reinicializações de replicação.
A priorização da replicação oferece aos clientes um controle aprimorado sobre o gerenciamento de recursos. Esse recurso melhora o comportamento geral de replicação do XDCR, pois podemos optar por não causar nenhum impacto nas replicações em andamento devido às replicações recém-criadas.
Todas essas alterações também podem ser feitas por meio da API CLI/REST. Para obter mais detalhes, leia a documentação.
Compartilhe sua experiência de uso desse recurso por meio de comentários ou em nosso fórum.
Recursos
Baixar
Faça o download do Couchbase Server 6.5
Documentação
Notas de versão do Couchbase Server 6.5
Couchbase Server 6.5 O que há de novo
Blogs
Blog: Anunciando o Couchbase Server 6.5 GA - O que há de novo e aprimorado
Blog: O Couchbase traz as transações ACID multi-documento distribuídas para o NoSQL
Oi Chaitra,
Na seção que descreve o comportamento do MEDIUM, você mencionou
"Quando um cliente não quer causar nenhum impacto negativo nos clusters existentes e pode se dar ao luxo de esperar que um novo cluster seja atualizado, essa é a configuração perfeita."
Portanto, supõe-se que já existam 2 (ou mais) clusters e, portanto, já há uma configuração de XDCR entre esses clusters e agora um terceiro cluster está sendo adicionado. Acredite, o mesmo se aplicará caso já existam 2 clusters no XDCR e uma nova replicação esteja sendo criada para um bucket (que não foi replicado anteriormente). Portanto, o backfill para esse bucket ocorrerá com alocação mínima de recursos, enquanto as replicações em andamento (para outros buckets entre os mesmos 2 clusters) continuarão com prioridade ALTA.
Portanto, mesmo para as replicações em andamento, há uma alteração, ou seja, as prioridades serão aplicadas. No entanto, 3 prioridades (ALTA/MÉDIA/BAIXA) estarão disponíveis para novas replicações, enquanto que para as replicações em andamento, haverá apenas 2 (ALTA/BAIXA).
Portanto, a versão 6.5 do XDCR não fornecerá apenas a capacidade de priorizar as réplicas em andamento em relação às réplicas iniciais; ela também traz a prioridade entre as réplicas em andamento, não é mesmo?
Agradecimentos