Com o Couchbase Server 4.x, os clientes costumavam criar índices equivalentes para satisfazer os dois requisitos de manter os índices altamente disponíveis e equilibrar a carga das consultas N1QL. Isso significava que exatamente a mesma definição de índice era usada para criar índices com nomes diferentes. O que há em um nome, você pode se perguntar... uma rosa é uma rosa é uma rosa ;)
|
1 2 3 |
criar índice índice1 em balde(campo1); criar índice índice2 em balde(campo1); |
As consultas N1QL poderiam atingir qualquer um dos dois índices com base na carga observada por cada um desses índices; além disso, se um dos índices caísse, o outro índice continuaria a atender ao tráfego de consultas. Havia alguns desafios com índices equivalentes, a saber:
- Você teve que criar manualmente índices com nomes diferentes
- Não havia um esquema simplificado para distribuir os índices entre os nós de índice escolhidos. Quando os nós de índice eram adicionados ou removidos, era uma operação manual criar essas cópias de índice novamente.
- As consultas que usam a dica USE Index ou Prepared Statements costumavam ser interrompidas se o nó do índice fosse perdido, devido à estreita afinidade com o múltiplos nomes de índices.
Com o Couchbase Server 5.0, você pode fazer a transição do uso de índices equivalentes para réplicas de índice. Com as réplicas de índice, você precisa disparar a definição do índice apenas uma vez, mas indicar o número de réplicas que deseja ou os nós nos quais elas devem ser colocadas e, depois disso, o Couchbase se encarrega de todo o trabalho de distribuir o tráfego de consulta e também de reequilibrar adequadamente quando os nós são adicionados ou removidos. Quando há réplicas suficientes no sistema (ou seja, se nem todos os nós que contêm as réplicas de índice estiverem inativos), o Index Service garante que os índices permaneçam on-line mesmo durante falhas no sistema. Se uma varredura de índice falhar em uma das réplicas, a varredura será tentada em outra réplica. Assim que qualquer uma das réplicas é criada, o serviço de índice começa a enviar o tráfego de consulta.
|
1 |
criar índice índice1 em balde(campo1) com {"num_réplica":2} |
Se você usar o parâmetro num_replica ao criar o índice, o serviço de índice criará réplicas adicionais, conforme mencionado no parâmetro. Portanto, se o num_replica for 2, haverá 3 (num_replica + 1) cópias do índice (ou seja, 2 cópias extras). Observe:
- Se houver menos nós em comparação com o num_replica, o create_index falhará com uma mensagem legível informando que a contagem de nós do indexador não é suficiente para criar o índice com a contagem de réplicas especificada. Portanto, é recomendável que o número de nós do indexador seja maior que o num_replica especificado na instrução create index.
- O Couchbase escolhe os nós que têm menos índices e não coloca mais de uma cópia do índice (ou seja, réplica) no mesmo nó.
- Se os nós de índice estiverem distribuídos em grupos de servidores (Rack Zone Awareness), o Couchbase distribuirá as réplicas para o maior número possível de grupos de servidores. Se a contagem de réplicas for maior do que o número de grupos de servidores, alguns dos grupos de servidores terão mais réplicas do que os demais.
Se você quiser especificar manualmente os nós nos quais criar os índices, isso é possível substituindo o parâmetro num_replica pelo parâmetro 'nodes'.
|
1 |
criar índice índice1 em balde(campo1) com {"nós":["1.2.3.4:8091", "1.2.3.5:8091", "1.2.3.6:8091"]} |
É recomendável que, ao usar essa sintaxe com o parâmetro "nodes" especificado, você escolha os nós que estão em vários grupos de servidores; essa sintaxe oferece a flexibilidade de escolher os nós, mas, diferentemente da sintaxe em que num_replica é usado, o Couchbase Index Service não substitui as configurações de nó fornecidas pelo usuário.
Todas as réplicas continuam a receber o tráfego de consulta, ou seja, não há o conceito de mestre-escravo nas réplicas de índice e todas as réplicas de índice estão ativas. Isso ajuda no balanceamento de carga.
Movendo réplicas de índices
Se o índice (junto com suas réplicas) estiver espalhado nos nós : "10.10.10.1:8091", "10.10.10.2:8091", "10.10.10.3:8091" E se você quiser mover manualmente uma réplica (por exemplo, 10.10.10.2:8091) para um nó diferente, a seguinte chamada REST (a ser disparada em qualquer um dos nós de indexação) fará o trabalho:
|
1 |
enrolar -u <em>usuário:senha</em> 10.10.10.1:9102/moveIndex -d '{"index" : "def_city", "bucket" : "travel-sample", "nodes" : ["10.10.10.1:8091", "10.10.10.4:8091", "10.10.10.3:8091"]}' |
O Couchbase sabe que apenas a réplica em "10.10.10.2:8091″ precisa ser movida para "10.10.10.4:8091″ e não toca nas réplicas em "10.10.10.1:8091″ e "10.10.10.3:8091″; portanto, apenas uma réplica é movida.
Mover o índice não altera (aumenta ou diminui) a contagem de réplicas; o número de nós a ser mencionado no parâmetro "nodes" nessa chamada REST deve corresponder ao número de nós nos quais as réplicas já estão distribuídas.
Índice de queda
A instrução Drop index descarta todas as réplicas. Até que todas as réplicas sejam descartadas, o índice permanecerá on-line.
Como fazer a transição/mudança de índices equivalentes para réplicas de índices? Leia mais aqui.
As réplicas de índice são compatíveis com o MOI e o GSI (Plasma) no Couchbase Server 5.0. Os desafios citados anteriormente com índices equivalentes não existem com as réplicas de índice. Clique aqui para fazer o download do Couchbase Server 5.0 e brincar com as réplicas de índice. Você pode deixar seus comentários em Nosso Fórum.
"As réplicas de índice são compatíveis com o MOI e o GSI (Plasma) no Couchbase Server 5.0"
Isso significa que eles não são compatíveis com os índices GSI (ForestDB) (ou seja, índices Community Edition)?