Con Couchbase Server 4.x, los clientes solían crear Índices Equivalentes para satisfacer el doble requisito de mantener los índices altamente disponibles y equilibrar la carga de las consultas N1QL. Esto significaba que se utilizaba exactamente la misma definición de índice para crear índices con diferentes nombres. ¿Qué hay en un nombre? se preguntará... una rosa es una rosa ;)
1 2 3 |
crear índice índice1 en cubo(campo1); crear índice índice2 en cubo(campo1); |
Las consultas N1QL podían dirigirse a cualquiera de los dos índices en función de la carga de cada uno de ellos y, además, si alguno de los índices se caía, el otro continuaba sirviendo el tráfico de consulta. Los índices equivalentes planteaban algunos problemas:
- Había que crear manualmente índices con nombres diferentes
- No existía un esquema simplificado para distribuir los índices entre los nodos de índice elegidos. Cuando se añadían o eliminaban nodos de índice, era una operación manual volver a crear esas copias de índices.
- Las consultas que utilizaban la sugerencia USE Index o Prepared Statements solían venirse abajo si se perdía el nodo de índice, debido a la estrecha afinidad con el índice varios nombres de índice.
Con Couchbase Server 5.0, puedes pasar de usar Índices Equivalentes a Réplicas de Índices. Con las Réplicas de Índices, necesitas lanzar la definición del índice sólo una vez, pero indicando el número de réplicas que quieres o los nodos en los que tienen que ser colocadas, y a partir de entonces, Couchbase se encarga de todo el trabajo de repartir el tráfico de consultas y también de reequilibrar adecuadamente cuando se añaden o eliminan nodos. Cuando quedan suficientes réplicas en el sistema (es decir, si no todos los nodos que contienen las réplicas de índices están caídos), Index Service asegura que los índices permanezcan online incluso durante fallos del sistema. Si falla el escaneo de un índice en una de las réplicas, el escaneo se intentará en otra réplica. En cuanto se crea alguna de las réplicas, el servicio de índices comienza a enviar el tráfico de consulta.
1 |
crear índice índice1 en cubo(campo1) con {"num_réplica":2} |
Si utiliza el parámetro num_replica al crear el índice, el servicio de índices crea réplicas adicionales según lo mencionado en el parámetro. Por lo tanto, si el número de réplicas es 2, habrá 3 (número de réplicas + 1) copias del índice (es decir, 2 copias adicionales). Tenga en cuenta:
- Si hay menos nodos comparados con el número de réplicas, entonces create_index falla con un mensaje legible indicando que el número de nodos indexadores no es suficiente para crear el índice con el número de réplicas especificado. Por lo tanto, es aconsejable que el número de nodos indexadores sea mayor que el num_replica especificado en la sentencia create index.
- Couchbase elige los nodos que tienen menos índices; y no coloca más de una copia del índice (es decir, réplica) en el mismo nodo.
- Si los nodos índice están repartidos en grupos de servidores (Rack Zone Awareness), entonces Couchbase reparte las réplicas entre tantos grupos de servidores como sea posible. Si el número de réplicas es mayor que el número de grupos de servidores, entonces algunos de los grupos de servidores tendrán más réplicas que el resto.
Si desea especificar manualmente los nodos sobre los que crear los índices, es posible sustituyendo el parámetro num_replica por el parámetro 'nodes'.
1 |
crear índice índice1 en cubo(campo1) con {"nodos":["1.2.3.4:8091", "1.2.3.5:8091", "1.2.3.6:8091"]} |
Es aconsejable que al usar esta sintaxis con el parámetro 'nodes' especificado, elijas los nodos que están en múltiples grupos de servidores; esta sintaxis da la flexibilidad de elegir los nodos, pero a diferencia de la sintaxis en la que se usa num_replica, Couchbase Index Service no anula la configuración de nodos suministrada por el usuario.
Todas las réplicas siguen recibiendo el tráfico de consulta; es decir, no existe el concepto de maestro-esclavo en las réplicas de índices y todas las réplicas de índices están activas. Esto ayuda a equilibrar la carga.
Traslado de réplicas de índices
Si el índice (junto con sus réplicas) está repartido en los nodos : "10.10.10.1:8091", "10.10.10.2:8091", "10.10.10.3:8091" Y si quieres mover manualmente una réplica (digamos 10.10.10.2:8091) a un nodo diferente, la siguiente llamada REST (para ser lanzada en cualquiera de los nodos de indexación) hace el trabajo:
1 |
rizo -u <em>usuario:contraseña</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"]}' |
Couchbase sabe que sólo la réplica en "10.10.10.2:8091″ necesita ser movida a "10.10.10.4:8091″ y no toca las réplicas en "10.10.10.1:8091″ y "10.10.10.3:8091″; y por lo tanto sólo se mueve una réplica.
Mover índice no cambia (aumenta o disminuye) el recuento de réplicas; el número de nodos que se menciona en el parámetro "nodes" en esta llamada REST tiene que coincidir con el número de nodos en los que ya están repartidas las réplicas.
Índice de caída
La sentencia Drop index elimina todas las réplicas. Hasta que se eliminan todas las réplicas, el índice permanece en línea.
¿Cómo pasar de índices equivalentes a réplicas de índices? Más información aquí.
Las réplicas de índices están soportadas tanto para MOI como para GSI(Plasma) en Couchbase Server 5.0. Los retos que se citaron anteriormente con índices equivalentes no existen con Index Replicas. Pulse aquí para descargar Couchbase Server 5.0 y jugar con Index Replicas. Puedes dejar tus comentarios en nuestro Foro.
"Las réplicas de índices están soportadas tanto para MOI como para GSI(Plasma) en Couchbase Server 5.0"
¿Significa eso que no son compatibles con los índices GSI(ForestDB) (es decir, los índices de la Community Edition)?