Orchestrator: administrador de topología de replicación de MySQL

Esta publicación de blog trata sobre Orchestrator: MySQL Replication Topology Manager.

Orchestrator es un administrador de topología de replicación para MySQL.

Tiene muchas características excelentes:

  • La topología y el estado del árbol de replicación se detectan y monitorean automáticamente
  • Se puede usar una GUI, CLI o API para verificar el estado y realizar operaciones
  • Es compatible con la conmutación por error maestra automática y el árbol de replicación se puede reparar cuando fallan los servidores del árbol, de forma manual o automática.
  • No depende de ninguna versión o sabor específico de MySQL (MySQL, Percona Server, MariaDB o incluso servidores binlog MaxScale)
  • Orchestrator admite muchos tipos diferentes de topologías, desde un solo maestro -> esclavo hasta árboles de replicación complejos de varias capas que consisten en cientos de servidores.
  • Orchestrator puede realizar cambios de topología y hacerlo en función del estado en ese momento; no necesita una configuración para definirse con lo que corresponde a la topología de la base de datos
  • La GUI no es solo para informar el estado: una de las mejores cosas que puede hacer es cambiar la replicación simplemente arrastrándola y soltándola en la interfaz web (por supuesto, puede hacer esto y mucho más a través de la CLI y la ‘API también ). )

Aquí hay un gif que muestra esto (haga clic en una imagen para ver una versión más grande):

Orquestador de arrastrar y soltar

el orquestador manual es bastante amplio y detallado, por lo que el propósito de esta entrada de blog no es pasar por todos los pasos de instalación y configuración. Solo brindará una descripción general del desempeño del orquestador, mientras menciona algunos parámetros importantes e interesantes.

Orchestrator es una aplicación go (binaria, incluida)
rpm y
debutante los paquetes son disponible por descarga).

Requiere su propia base de datos MySQL como servidor back-end para almacenar toda la información relacionada con las topologías de clúster de base de datos administradas por Orchestrator.

Debe haber al menos un demonio de Orchestrator, pero se recomienda que ejecute varios demonios de Orchestrator en varios servidores al mismo tiempo, todos usando la misma base de datos de back-end, pero solo un orquestador estará «activo» en cualquier momento. hora. (Puede comprobar cuál está activo en el
Estado menos en la interfaz web, o en la base de datos en el
nodo activo mesa.)

Usar MySQL como backend de base de datos, ¿no es un SPOF?

Si la base de datos de MySQL de Orchestrator desaparece, no significa que los clústeres de MySQL monitoreados dejarán de funcionar. Orchestrator solo ya no podrá controlar las topologías de replicación. Esto es similar a cómo funciona MHA: todo funciona, pero no puede realizar una conmutación por error hasta que MHA regrese.

Por el momento, es necesario tener un backend de MySQL y no hay un soporte claro/comprobado para tener esto incluso en alta disponibilidad (HA). Esto puede cambiar en el futuro.

Requisitos de instalación del servidor de base de datos

Orchestrator solo necesita un usuario de MySQL con privilegios limitados (
SÚPER, PROCESO, REPLICACIÓN ESCLAVO, RECARGAR) para conectarse a los servidores de la base de datos. Con estos permisos, puede verificar el estado de replicación del nodo y realizar cambios de replicación si es necesario. Admite varios modos de replicación: ubicaciones de archivos binlog, MySQL y MariaDB GTID, Pseudo GTID y servidores Binlog.

No es necesario instalar software adicional en los servidores de la base de datos.

Recuperación automática de falla maestra

Un ejemplo de lo que puede hacer un orquestador es promover a un esclavo si un maestro ha caído. te elegiras a ti esclavo más hasta la fecha para ellos promovidos.

Veamos qué aspecto tiene:

dtdggKGF0f

En esta prueba perdimos
rep1 (profesor) y orquestador ascendido
rep4 para ser el nuevo amo, y comenzó a replicar a los otros sirvientes del nuevo amo.

Por defecto, si
rep1 espalda
rep4 continuará la replicación desde
rep1. Este comportamiento se puede cambiar con el parámetro
ApplyMySQLPromotionAfterMasterFailover:Cierto en la configuración.

Orchestrator también tiene una buena interfaz de línea de comandos. Aquí hay unos ejemplos:

Impresión de topología:

Mover un esclavo:

Imprima la topología de nuevo:

Como podemos ver,
rep2 ahora es replicado por
rep4 .

Una buena adición a la GUI es cómo muestra consultas lentas en todos los servidores en el árbol de replicación. También puede eliminar las preguntas incorrectas de la GUI.

Consultas largas de la GUI de Orchestrator

La configuración del demonio de Orchestrator se puede encontrar en
/etc/orquestador.conf.json. Hay varias opciones de configuración, algunas de las cuales hemos cubierto aquí:

  • SlaveLagQuery – Se pueden definir consultas personalizadas para verificar el retraso del esclavo.
  • AgentAutoDiscover – Se sentó en
    Cierto , Orchestrator detectará automáticamente la topología.
  • Contraseña de autenticación HTTP y
    HTTPAuthUser – Evite que todos accedan a la GUI web y cambien su topología.
  • RecoveryPeriodBlockSecondsRecoveryPeriodBlockSeconds – Evita golpes.
  • RecoverMasterClusterFilters – Defina qué clústeres fallarán o se recuperarán automáticamente.
  • Procesos previos a la conmutación por error – El orquestador ejecutará este comando antes de la conmutación por error.
  • Procesos posteriores a la conmutación por error – El orquestador ejecutará este comando después de la conmutación por error.
  • ApplyMySQLPromotionAfterMasterFailover Separe el esclavo promovido después de que falle.
  • Patrón de centro de datos – Si hay varios centros de datos, puede marcarlos con una plantilla (tendrán diferentes colores en la GUI):Orchestrator cree que ahora cada servidor está en un controlador de dominio diferente.

A pesar de ser una aplicación muy rica en funciones, todavía faltan algunas funciones y limitaciones que debemos tener en cuenta.

Una de las características clave que faltan es que no hay una manera fácil de promover a un esclavo para que sea el nuevo maestro. Esto podría ser útil en escenarios donde el servidor maestro necesita actualizarse, hay una conmutación por error planificada, etc. (esto es un conocido aplicación de funciones).

Algunas limitaciones conocidas:

  • Los esclavos no pueden ser promovidos manualmente para ser maestros
  • No es compatible con la replicación de múltiples fuentes.
  • No es compatible con todos los tipos de replicación paralela.
  • En este momento, no se admite la combinación de Percona XtraDB Cluster (Galera)

Para integrar esto en su arquitectura HA o incluirlo en sus procesos alternativos, aún necesita administrar varios aspectos manualmente, lo que se puede hacer con los diversos enlaces disponibles en Orchestrator:

  • Actualización de la conexión de la aplicación:
    • Tratamiento VIP,
    • Actualizar DNS
    • Actualice la conexión del servidor Proxy (MaxScale, HAProxy, ProxySQL…).
  • Configuración automática de esclavos para leer solo para evitar que se escriba en no maestros y cause inconsistencias en los datos
  • Pantalla (STONITH) del maestro muerto, para evitar el cerebro dividido en caso de que un maestro bloqueado vuelva a estar en línea (y las aplicaciones siempre intentan conectarlo)
  • Si se va a utilizar la replicación semisíncrona para evitar la pérdida de datos en caso de que falle el maestro, esto debe agregarse manualmente a los ganchos.

El trabajo que hay que hacer es comparable a tener una instalación con MHA o MySQLFailover.

Esta publicación no describe completamente el proceso de decisión que toma Orchestrator para determinar si un servidor está cerrado o no. Tal como lo entendemos ahora, un nodo activo del orquestador tiene que tomar la decisión de si un nodo ha caído o no. Compruebe el estado de replicación del esclavo de un nodo roto para determinar si Orchestrator no es el único que pierde la conexión (en cuyo caso no tiene nada que ver con los servidores de producción). Esto ya es una gran mejora con respecto a MySQLFailover, MHA o incluso MaxScale failoverscripts, pero también puede causar algunos problemas en algunos casos (se puede encontrar más información en Shlomi Noach’s). Blog).

La cantidad de flexibilidad, potencia y diversión que esta herramienta le brinda con un proceso de instalación muy simple también se puede combinar. Shlomi Noaj hizo un gran trabajo al desarrollar esto cerebro, Booking.com y ahora a GitHub.

Si está buscando MySQL Topology Manager, definitivamente vale la pena echarle un vistazo a Orchestrator.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario