Limitaciones MySQL BINLOG

Question

Tengo una instancia de MySQL que se ejecuta en AWS, con alrededor de 5000 insertos por segundo.¿Alguna idea de cuál será el impacto del rendimiento si uso binlog (fila) y un binlog sailer?

Comprobar este enlace

Desde mi comprensión, un saurs de registro de contenedores encuestó periódicamente el binlog MySQL para hacer posible una conexión de datos 'en tiempo real'.El binlog Sailer corre en Nodejs.

El punto es que tengo que usar MySQL y quiero usar Meteor para obtener los datos en tiempo real para mis clientes.De ahí mi idea de usar este binlog sault.

Debido a que el MYSQL DB se llenará de manera bastante intensiva (5000 insertos por segundo), quiero saber en qué punto el binlog / binlog sader obtiene problemas severos de rendimiento.

grts, tom

Answer 1

He desarrollado software con una funcionalidad similar, la capacidad de usar el flujo de replicación MySQL (registro binario, binlog) para capturar eventos en tiempo casi real en respuesta a insertos / actualizaciones / eliminaciones en la base de datos.

Aquí hay algunas observaciones que he hecho con respecto a la actuación. Afortunadamente, los puntos calientes potenciales son en gran medida independientes entre sí.

asumiré, ya que no estaba familiarizado con el paquete de nodos que citó y solo ahora solo le dio su código una revisión cursoria, que en realidad no están "de cola" el binlog a través de la votación, pero en realidad están emulando un esclavo / réplica Servidor y conexión al maestro y solicitando el flujo de replicación.

El primer cuello de botella potencial es la capacidad del maestro para escribir la cantidad de datos de binlog requeridos (el rendimiento de E / S es la Cobstraint Principal). Si su maestro ya está registrando en el formato ROW, entonces este problema ya está resuelto. Si no, entonces cambie su formato binlog y vea. Yo prefiero Formato ROW, de todos modos, porque es muy útil para la recuperación de datos cuando las consultas van mal o la aplicación hace algo a los datos que no debería tener. Es posible (utilizando herramientas de terceros) para capturar lo que sucedió y revertirlo, en la configuración predeterminada, cuando se produce un borrado (por ejemplo), los datos eliminados se escriben en realidad en el registro binario.

El siguiente punto de consumo de recursos es la conexión esclava realizada por una herramienta de este tipo al maestro, donde el maestro presiona los datos. Un error común es que un esclavo "encuestas" al maestro. De hecho, el esclavo inicia la conexión, pero el maestro empuja los datos. Esta es en realidad una carga en el Maestro que tiene muy poco impacto en el rendimiento cuando el número de esclavos conectados es pequeño (por ejemplo, 5 o menos). Esta carga se puede eliminar del Maestro completamente conectando la "BinLog SALTER", no al maestro, sino a un esclavo existente del maestro, con log_slave_updates configurado.

El transporte de los datos del maestro a la pseudo-esclavo puede comer un ancho de banda de red significativo, por lo que su utilidad externa debe admitir el protocolo de compresión de cliente / servidor MYSQL para reducir este ancho de banda. Habilitar esta capacidad puede lograr relaciones de compresión de 10: 1 dependiendo de la carga útil.

El punto de dolor final es la utilidad externa en sí. El formato Binlog MySQL es un formato binario muy empaquetado (por lo tanto, "registro binario") que debe ser analizado y decodificado. La eficiencia con la que la utilidad externa puede desempacar y manipular este flujo de datos determinará qué tan cerca se puede emitir los eventos detectados en tiempo real, ya que el código ineficiente hará que su flujo de eventos decidido se retrasará más y más detrás del maestro, aunque este factor no tendrá ningún impacto de rendimiento en el propio servidor maestro.

En resumen, si su maestro puede manejar la carga de trabajo de generar binlogs de formato de fila para el volumen de tráfico que espera, el resto de los problemas potenciales siguen siendo problemas potenciales, pero no deben tener implicaciones de rendimiento significativas en el servidor maestro , en sí.