XDCRpor diseño, ofrece a los clientes la flexibilidad de ajustar el número de réplicas para un cubo determinado en función del rendimiento deseado. La nueva replicación requiere el streaming de todos los documentos existentes en el bucket y, por tanto, presenta una tasa de mutación mayor que las mutaciones en curso. Como tal, la nueva replicación utiliza más recursos, lo que a veces afectaba negativamente al rendimiento de las réplicas existentes. Con nuestra próxima versión 6.5, XDCR proporcionará a los usuarios la capacidad de priorizar las réplicas en curso sobre las réplicas iniciales. La asignación de recursos se realizará en función de la prioridad especificada.
Al crear una nueva replicación, el cliente tiene la opción de asignar prioridades al flujo de replicación. Las opciones proporcionadas serían ALTA, MEDIA o BAJA.
Para entendernos, supongamos que las réplicas en curso son ALTAS y consideremos los siguientes escenarios mencionados para las nuevas réplicas :
ALTO :
La asignación máxima de recursos se proporcionaría a esta nueva replicación durante la etapa inicial de backfill (hasta que todas las mutaciones del bucket de origen se repliquen en el bucket de destino). Esto puede repercutir negativamente en el rendimiento de las réplicas existentes.
Esto puede resultar extremadamente útil en casos de distribución de cargas de trabajo y localización de datos, en los que los clientes desean añadir un nuevo clúster a la topología, ponerlo en marcha inmediatamente y garantizar la coherencia entre clústeres lo antes posible.
Este es el comportamiento actual de XDCR y también será la configuración por defecto.
MEDIO :
La nueva replicación recibirá recursos mínimos durante la etapa de relleno para alcanzar lentamente la paridad con las réplicas en curso. Una vez que todas las réplicas estén al día, la prioridad de este flujo de réplicas cambiará automáticamente a ALTA y la distribución de recursos será uniforme en todas las réplicas ALTAS.
Se trata de una configuración útil para casos de uso de alta disponibilidad y recuperación ante desastres. Cuando un cliente no quiere tener ningún impacto negativo en los clústeres existentes y puede permitirse esperar a que un nuevo clúster se ponga al día, esta es una configuración perfecta.
BAJA :
La nueva replicación recibirá recursos mínimos durante todo el proceso de replicación. Durante la replicación inicial y durante las etapas de replicación en curso, este flujo tendrá menor prioridad.
Se trata de una configuración útil cuando un cliente desea configurar un clúster frío y uno caliente, donde puede permitirse un rendimiento de replicación lento para el clúster frío con una asignación de recursos mínima.
Para los usuarios de XDCR, sólo hay un cambio visible:
Se añadirá un nuevo ajuste de replicación, "Prioridad", a las vistas de creación y edición de replicación. Tomará tres valores posibles, Alta/Media/Baja.
Dado que el rendimiento de la replicación depende en gran medida del ancho de banda de la red y de la CPU asignada, los clientes pueden asignar las prioridades en función de la criticidad de la necesidad empresarial y conservar los recursos. La utilización eficaz de esta funcionalidad mediante la asignación de prioridades en función de las necesidades de la empresa podría reducir el coste de propiedad, especialmente en el caso de las implantaciones en la nube.
Las actualizaciones de la gestión de recursos mediante la asignación de prioridades son totalmente opcionales. Pueden modificarse en cualquier momento en el futuro, sin ningún impacto negativo como reinicios de replicación.
La priorización de la replicación proporciona a los clientes un mejor control sobre la gestión de sus recursos. Esta característica mejora el comportamiento general de replicación de XDCR, ya que podemos elegir no tener ningún impacto en las réplicas en curso debido a las réplicas recién creadas.
Todos estos cambios también se pueden realizar a través de CLI/REST API. Para más detalles, por favor lea la documentación.
Por favor, comparte tu experiencia sobre el uso de esta función a través de los comentarios o en nuestro foro.
Recursos
Descargar
Descargar Couchbase Server 6.5
Documentación
Notas de la versión de Couchbase Server 6.5
Novedades de Couchbase Server 6.5
Blogs
Blog: Anuncio de Couchbase Server 6.5 GA - Novedades y mejoras
Blog: Couchbase lleva las Transacciones Distribuidas Multidocumento ACID a NoSQL
Hola Chaitra,
En la sección que describe el comportamiento para MEDIUM, se menciona
"Cuando un cliente no quiere tener ningún impacto negativo en los clústeres existentes y puede permitirse esperar a que un nuevo clúster se ponga al día, este es un escenario perfecto".
Así que la suposición es que ya hay 2 (o más) clusters y por lo tanto ya hay una configuración XDCR entre esos clusters y ahora se está añadiendo un 3er cluster. Creemos que lo mismo se aplicará en caso de que ya haya 2 clusters en XDCR y se esté creando una nueva replicación para un bucket (que no estaba replicado previamente). Así que el backfill para este bucket ocurrirá con una asignación de recursos mínima mientras que las réplicas en curso (para otros buckets entre los mismos 2 clusters) continuarán con prioridad ALTA.
Por lo tanto, incluso para las réplicas en curso, hay un cambio, es decir, se aplicarán las prioridades. Sin embargo, las nuevas réplicas dispondrán de 3 prioridades (ALTA/MEDIA/BAJA), mientras que para las réplicas en curso sólo habrá 2 (ALTA/BAJA).
Así pues, la versión XDCR 6.5 no sólo ofrece la posibilidad de dar prioridad a las réplicas en curso sobre las iniciales, sino que también da prioridad a las réplicas en curso, ¿no es así?
Gracias