Los clústeres de seguidores son una función de ScaleGrid que le permite mantener sincronizados dos sistemas de bases de datos independientes (del mismo tipo). A diferencia de la clonación o la replicación, esto le permite mantener una copia activa y puntual de sus datos de producción. Este clúster adicional, conocido como clúster seguidor, se puede aprovechar para múltiples casos de uso, incluso para analizar, optimizar y probar el rendimiento de su aplicación para MongoDB, MySQL y PostgreSQL. En esta publicación de blog, cubriremos los tres escenarios principales para aprovechar los clústeres de seguidores para su aplicación.
¿En qué se diferencian los clústeres de seguidores de la replicación?
A diferencia de un clon estático, estos datos se importan en un horario establecido para que su grupo de seguidores esté siempre sincronizado con su grupo de producción. Aquí hay algunas formas críticas en las que difiere de la replicación:
- Puede controlar la frecuencia con la que el sistema de destino se sincroniza desde la fuente:una vez a la semana, una vez al día o incluso con menos frecuencia. Esto ayuda a reducir la carga en el sistema de origen.
- Dado que son dos sistemas independientes, tiene mucha más flexibilidad sobre los datos que se sincronizan. Puede tener diferentes credenciales de usuario e incluso eliminar algunos datos del destino en función de los requisitos de seguridad (nota:esto requiere secuencias de comandos del lado del usuario; no es una función integrada de los clústeres de seguidores).
- Se puede escribir en el sistema de "seguidor", por lo que puede usarlo como un entorno de ensayo para probar los cambios de su aplicación. Esto no es algo que pueda hacer en un nodo de réplica.
Nota:ScaleGrid implementa clústeres de seguidores mediante instantáneas de almacenamiento. No está disponible para nuestras ofertas de bases de datos en memoria, como alojamiento para Redis™*.
1. Configuración de prueba/desarrollo de base de datos
Todos hemos estado allí:una pieza de código supuestamente bien probada se implementa en producción y luego se desata el infierno. Los flujos de trabajo de producción fallan o son tan lentos que son básicamente inutilizables. Los ingenieros se despiertan de sus camas para comenzar una operación de extinción de incendios en toda regla. Un montón de noches sin dormir más tarde, surge esa temida causa raíz.
La aplicación se comporta de manera diferente en las configuraciones de producción e ingeniería.
En otras palabras, lo probamos en "datos de prueba". Lo cual, como resultado, no se parecía en nada a los datos de producción. En absoluto.
La forma obvia de evitar esta situación es ejecutar pruebas en sus datos de producción. No la producción real, por supuesto, eso será coquetear con el desastre. En una copia clonada de los datos de producción. Si bien las preocupaciones sobre la privacidad y la seguridad de los datos hacen que esto sea impracticable en muchos escenarios, si los requisitos de privacidad lo permiten, esta es la mejor solución. Ya no necesitamos depender de ingenieros que generen conjuntos de datos apropiados; si transmite datos de prueba, transmitirá datos de producción.
Es decir, hasta que los datos de prueba se desincronicen tanto con la producción que ya no sea una buena aproximación. Y estamos de vuelta en el punto de partida.
Aquí es donde entran en juego los grupos de seguidores.
Al usar grupos de seguidores, puede importar periódicamente datos de su base de datos de producción a la base de datos de desarrollo/prueba. Y dado que toda la importación se realiza mediante instantáneas de almacenamiento, en lugar de un volcado lógico, el proceso es casi instantáneo. Puede programar sus importaciones una vez cada 24 horas, una vez a la semana o la frecuencia que se adapte a su escenario particular.
Con sus clústeres de desarrollo y control de calidad configurados para seguir al clúster de producción, puede estar tranquilo. Si su aplicación pasa el conjunto de datos de prueba, ¡definitivamente está en condiciones de implementarse en producción!
2. Análisis de datos
Si ha trabajado como DBA, probablemente haya tenido una conversación con su equipo sobre la desaceleración "misteriosa" del rendimiento del sistema en ciertos momentos. En la mayoría de los casos, el culpable resulta ser un trabajo de análisis que accede a toneladas de datos y termina ralentizando todo el sistema.
Como proveedor de DBaaS, hemos tenido esta conversación varias veces con nuestros clientes. Estas son las dos opciones que normalmente sugerimos:
- Si el trabajo de análisis se ejecuta en el servidor primario/maestro, muévalo a un servidor secundario/réplica.
- Si el trabajo de análisis ya se está ejecutando en un nodo secundario y la degradación del rendimiento es inaceptable, recomendamos mover los trabajos a un clúster de análisis dedicado.
Usando nuestra función de clúster de seguidores, es muy fácil mantener un clúster de análisis actualizado con los datos de producción reales. Puede crear una programación de seguidores para sincronizar los últimos datos de producción justo antes de que comience su trabajo de análisis.
¿La mejor parte? La sincronización de seguidores no realiza ninguna operación a nivel de base de datos, ¡simplemente restaura la última instantánea! Por lo tanto, no hay impacto en su clúster de producción.
3. Informes
Otro caso de uso común en el que nuestros clientes utilizan la función de grupos de seguidores es para la generación de informes. Los procesos de generación de informes normalmente se ejecutan con poca frecuencia, pero acceden a grandes cantidades de datos y ocupan la mayor parte de los recursos de un clúster de base de datos. Cuando la degradación del rendimiento es inaceptable, recomendamos a nuestros clientes que trasladen la carga de trabajo de generación de informes a un nuevo clúster.
Dado que las operaciones de informes son poco frecuentes, muchos de nuestros clientes prefieren aprovechar nuestra función de pausa/reanudar para "pausar" los grupos de informes cuando no están en uso. Esto ayuda a ahorrar enormemente en costos de infraestructura. Por lo general, los clústeres de informes también son mucho más "pequeños" (menos CPU/RAM), para ayudar a reducir los costos.
Después de haber creado un grupo de seguidores desde nuestra interfaz de usuario, puede usar este flujo de trabajo para automatizar su flujo de informes:
- Utilice nuestra API de reanudación para reanudar el clúster.
- Espere hasta que el clúster vuelva a estar en estado de ejecución (puede usar su API get-status para este propósito).
- Active una copia de seguridad en su clúster de producción, si es necesario (por lo general, si se programan copias de seguridad periódicas en su producción, puede omitir este paso. Sin embargo, si desea que sus informes se ejecuten con los datos más recientes, esto es esencial).
- Espere a que se complete la copia de seguridad.
- Desencadene un trabajo de sincronización en el seguidor:esto encuentra la instantánea más reciente en el clúster de origen y la restaura en el destino.
- Espere a que se complete el trabajo de sincronización.
- Ejecute sus tareas de informes.
- Utilice nuestra API de pausa para pausar el clúster hasta su próximo trabajo de generación de informes.
¿Crees que los grupos de seguidores son una buena opción para tu caso de usuario en particular? ¡Puede aprender todo sobre cómo implementar y administrar clústeres de seguidores para MongoDB, MySQL y PostgreSQL en nuestros documentos de ayuda!
Si no está seguro de si los clústeres de seguidores son la solución correcta para su caso de uso, deje un comentario o comuníquese con nosotros a [email protected]. estaremos encantados de analizar qué función se adapta mejor a sus necesidades.
