¿Cuál es el propósito del motor BLACKHOLE de MySQL?

Question

¿Por qué guardarías algo que no pudieras recuperar más tarde? ¿Cuál es el punto de?

Answer 1

Es útil en un entorno replicado donde todas las sentencias de SQL se ejecutan en todos los nodos, pero solo desea que algunos nodos realmente almacenen el resultado. Este es un caso de uso dado en la documentación: http://dev.mysql.com/doc/refman/5.0/en/blackhole-storage-engine.html

Otros usos dados en la documentación incluyen:

• Verificación de la sintaxis del archivo de volcado.
• Medición de la sobrecarga a partir del registro binario, comparando el rendimiento utilizando BLACKHOLE con y sin el registro binario habilitado.
• BLACKHOLE es esencialmente un motor de almacenamiento "no operativo", por lo que podría usarse para encontrar cuellos de botella de rendimiento no relacionados con el motor de almacenamiento en sí.

Answer 2

Supongamos que tiene dos computadoras, cada una con un servidor MySQL. Una computadora aloja la base de datos principal y la segunda aloja un esclavo replicante que usted usa como respaldo.

Además, suponga que su servidor primario contiene algunas bases de datos o tablas de las que no quiere hacer una copia de seguridad. Tal vez sean tablas de caché de alta rotación y no importa si pierde su contenido. Por lo tanto, para ahorrar espacio en el disco y evitar el uso innecesario de la CPU, la memoria y la E / S del disco, utiliza las opciones de replicación para configurar el esclavo para ignorar las declaraciones que afectan a las tablas de las que no quiere hacer una copia de seguridad.

Pero como los filtros de replicación solo se aplican en el servidor esclavo , los registros de bin para todas las declaraciones ejecutadas en el servidor maestro aún deben transmitirse a través de la red. Hay ancho de banda desperdiciado aquí; el servidor maestro está enviando binlogs para transacciones que el esclavo simplemente va a tirar al recibirlos. ¿Podemos hacerlo mejor y evitar el uso innecesario de ancho de banda?

Sí, podemos, y ahí es donde entra en juego el motor BLACKHOLE. En la misma computadora en la que se ejecuta el servidor maestro, ejecutamos un segundo proceso dummy mysqld , este aloja una base de datos BLACKHOLE. Configuramos este proceso ficticio para replicarlo desde el binlog del proceso maestro, con las mismas opciones de replicación que el esclavo real, y para producir un binlog propio. El binlog del proceso ficticio ahora solo contiene las declaraciones que necesita el esclavo real, y no ha realizado ningún trabajo real más allá de filtrar las declaraciones no deseadas del binlog (ya que utiliza el motor BLACKHOLE). Finalmente, configuramos el esclavo verdadero para que se replique desde el binlog del proceso ficticio, en lugar de hacerlo desde el binlog del proceso maestro original. Ahora hemos eliminado el innecesario tráfico de red entre las dos computadoras que albergan los servidores maestro y esclavo.

Esta configuración es lo que se describe e ilustra (mucho más tersamente) por este párrafo y diagrama de la documentación de BLACKHOLE :

Supongamos que su aplicación requiere reglas de filtrado del lado del esclavo, pero la transferencia de todos los datos de registro binarios al esclavo primero genera demasiado tráfico. En tal caso, es posible configurar en el host maestro un proceso esclavo "ficticio" cuyo motor de almacenamiento predeterminado es BLACKHOLE, como se muestra a continuación:

Además de filtrar, los documentos también sugieren crípticamente que el uso de un servidor BLACKHOLE con binlogging habilitado "puede ser útil como mecanismo de repetición ..." . Este caso de uso se materializa menos en los documentos, pero es posible imaginar un escenario en el que esto tendría sentido. Por ejemplo, suponga que tiene muchos servidores esclavos, todos en computadoras en una red local con conexiones locales rápidas entre sí, que todos necesitan replicar grandes cantidades de datos desde un esclavo remoto al que solo se puede conectar a través de Internet. No querrá que todos se repliquen directamente desde la caja maestra, ya que entonces obtendrá la misma información varias veces y usará un ancho de banda de Internet varias veces mayor que el necesario. Pero suponga que tampoco desea que solo uno de sus esclavos existentes se replique desde el maestro y los otros se repliquen fuera de ese esclavo, quizás porque sus esclavos se ejecutan en máquinas mucho menos confiables que el maestro, o ejecutan otros procesos. eso podría matar a la caja consumiendo toda su CPU o memoria, y no querrás arriesgarte a una falla de software o hardware en el esclavo intermedio que destruye toda tu red de esclavos. ¿Qué haces?

Un posible compromiso sería introducir una caja adicional en su red esclava para actuar como intermediario, optimizado para la confiabilidad y el rendimiento en lugar de para el almacenamiento. Déle una unidad SSD pequeña y confiable y no ejecute nada en ella, aparte de un proceso mysqld se replique desde el maestro remoto, y haga que produzca binlogs a los que los demás esclavos puedan suscribirse. Y, por supuesto, configura este esclavo intermedio para usar el motor BLACKHOLE, de modo que no necesite espacio de almacenamiento.

Tanto este como el esclavo de filtrado intermedio descritos en detalle en la documentación son casos de borde; la mayoría de los usuarios de MySQL nunca se encontrarán en situaciones en las que se beneficiarían del uso de cualquiera de estas estrategias, y mucho menos se beneficiarán lo suficiente como para justificar el trabajo para configurarlas realmente. Pero al menos en teoría, el motor BLACKHOLE se puede usar para crear un nodo intermedio en una red de esclavos en replicación como una estrategia de conservación de ancho de banda, sin necesidad de que ese nodo almacene realmente los datos en el disco.