Nuevo en Percona Replication Manager: resincronización de esclavos, parada asíncrona

Percona Replication Manager (PRM) continúa evolucionando y mejorando, quiero presentar dos nuevas funciones: Resincronización de esclavos y parada asíncrona.

Resincronizar esclavo

Este comportamiento es para la replicación regular sin gtid. Cuando un maestro falla y ya no está disponible, ¿cómo nos aseguramos de que todos los esclavos estén en un estado consistente? Es fácil encontrar el esclavo más actualizado y promoverlo para que sea el nuevo maestro en función del puesto de maestro ejecutivo, el agente PRM ya lo ha hecho, pero cómo aplicar las transacciones que faltan a otros esclavos.

Para resolver este problema, modifiqué una herramienta escrita originalmente por Yelp, que emite las sumas MD5 de la carga útil (límites XID) y las posiciones de confirmación de un archivo binlog. Produce salida como:

Donde el primer campo es la posición de confirmación y el segundo campo es la suma md5 de la carga útil. El único tipo de transacción no admitido es «CARGAR DATOS EN». Por supuesto, dado que se basa en valores XID, esto solo funciona con InnoDB. También necesita «log_slave_updates» para habilitarlo. Las fuentes y algunos binarios estáticos se pueden encontrar en el directorio de usuarios en PRM github, el enlace se encuentra en la parte inferior.

Por lo tanto, si el agente detecta un bloqueo maestro y la herramienta prm_binlog_parser está disponible (el parámetro prm_binlog_parser_path predeterminado), luego de la promoción, el nuevo maestro guardará sus registros binarios y publicará en el marcapasos CIB, las últimas 3000 transacciones. bash, la línea de comando debe estar por debajo de 64k. Con algo de trabajo se podría elevar este límite, pero creo, quizás erróneamente, que cubre la mayoría de los casos. Los datos publicados en el atributo CIB también contienen el archivo binlog correspondiente.

El siguiente paso está en los esclavos, cuando reciben la notificación posterior a la promoción. Verifique la suma MD5 de su última transacción en el registro de retransmisión, regrese con la herramienta prm_binlog_parser, busque el archivo correspondiente y la posición en las últimas 3000 transacciones que el nuevo maestro publicó en el CIB y configure la replicación con el archivo y la posición correctos.

El resultado es una solución mucho más resistente que ayuda a mantener el esclavo en un estado constante. Mi próximo objetivo con respecto a esta función será mantener el maestro de fallas e intentar guardar cualquier transacción del binlog maestro anterior en caso de que MySQL falle, pero Pacemaker aún está activo.

Async_stop

La función async_stop, habilitada por el parámetro primitivo «async_stop», permite una conmutación por error más rápida. Sin esta función, al detener mysqld, PRM esperará hasta que esté completamente confirmado antes de realizar una conmutación por error. Cuando hay tantas páginas sucias de InnoDB, todos sabemos que detener mysql puede llevar varios minutos. Jervin Real, un colega de Percona, sugirió que deberíamos decirle a Pacemaker que MySQL se detiene para proceder más rápido con la conmutación por error. Habiendo agregado algunas protecciones, fue una muy buena idea. Guardaré los detalles de implementación, pero ahora, si la configuración está habilitada, tan pronto como mysqld se detenga de manera efectiva, la conmutación por error estará completa. Si sucede que Pacemaker quiere iniciar una instancia de MySQL que se detiene, situación muy común, se generará un error.

Los agentes, las herramientas y la documentación de PRM se pueden encontrar aquí: https://github.com/percona/percona-pacemaker-agents

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