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

Question

¿Por qué guardaría algo que no puede recuperar más adelante? ¿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 quiere que algunos nodos realmente almacenen el resultado. Se trata de un caso de uso dado en la documentación: http://dev.mysql.com/doc/refman/5.0/en/blackhole-storage-engine.html

Otros usos indicados en la documentación incluyen:

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

Answer 2

Suponga que tiene dos equipos, cada uno ejecutando un servidor MySQL. Una computadora alberga la base de datos primaria, y la segunda computadora alberga una replicating slave que utiliza como respaldo.

Supongamos además que su servidor primario contiene algunas bases de datos o tablas de las que no desea hacer una copia de seguridad. Quizás sean tablas de caché de alta rotación y no importa si pierdes su contenido. Por lo tanto, para ahorrar espacio en el disco y evitar el uso innecesario de la CPU, la memoria y el disco IO, use el replication options para configurar el esclavo a fin de que ignore las afirmaciones que afectan las tablas de las que no quiere hacer una copia de seguridad.

Pero ya que los filtros de replicación sólo se les aplicó en el servidor esclavo, los binlogs para todos instrucciones ejecutadas en el servidor maestro todavía necesitan ser transmitidos por la red. Aquí se desperdicia ancho de banda; el servidor maestro está enviando bitácoras para transacciones que el esclavo simplemente va a tirar al recibirlas. ¿Podemos hacerlo mejor y evitar el uso innecesario del ancho de banda?

Sí, podemos, y ahí es donde entra en el motor BLACKHOLE. En el mismo equipo que el servidor maestro se está ejecutando en, corremos un segundo proceso simulado, mysqld, este alojamiento una base de datos BLACKHOLE. Configuramos este proceso ficticio para replicar desde el binlog del proceso maestro, con las mismas opciones de replicación que el esclavo real, y para producir un bit log propio. El binlog del proceso ficticio ahora solo contiene las afirmaciones que el esclavo real necesita, y no ha hecho ningún trabajo real más allá de filtrar las declaraciones no deseadas del binlog (ya que está usando el motor BLACKHOLE). Finalmente, configuramos el esclavo verdadero para que se replique desde el binlog del proceso ficticio, en lugar de desde el binlog del proceso maestro original. Ahora hemos eliminado el innecesario tráfico de red entre las dos computadoras que alojan los servidores maestro y esclavo.

Esta configuración es lo que se describe e ilustra (mucho más concisamente) por este párrafo y el diagrama de the BLACKHOLE docs:

Supongamos que la aplicación requiere reglas de filtrado del lado del esclavo, pero la transferencia de todos los datos de registro binario a la primer esclavo resulta en demasiado tráfico.En tal caso, es posible configurar en el host maestro un proceso “ficticia” esclavo cuyo valor predeterminado de almacenamiento del motor es BLACKHOLE, representado como sigue:

Además de la filtración, los docs también crípticamente sugerencia de que el uso de un servidor BLACKHOLE con el borrado habilitado "puede ser útil como un mecanismo repetidor ...". Este caso de uso se desarrolla menos en los documentos, pero es posible imaginar un escenario en el que esto tenga sentido. Por ejemplo, supongamos 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ás que todos se repliquen directamente desde el cuadro maestro, ya que obtendrás los mismos datos varias veces y utilizarás varias veces más ancho de banda de Internet de lo necesario. Pero supongamos que también no desea que uno de sus esclavos existentes se replique desde el maestro y los otros se repliquen desde ese esclavo, quizás porque sus esclavos se ejecutan en máquinas mucho menos confiables que el maestro, o están ejecutando algunos otros procesos que pueden matar la caja al consumir toda su CPU o memoria, y no quiere arriesgarse a una falla de software o hardware en el esclavo intermedio que destruye toda su red esclava. ¿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 que se replica desde el maestro remoto, y haga que produzca bitácoras a las que los otros esclavos puedan suscribirse. Y, por supuesto, configure 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 detalladamente en la documentación son casos extremos; 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ían lo suficiente como para justificar el trabajo para configurarlas realmente. Pero al menos teóricamente, el motor BLACKHOLE puede usarse para crear un nodo intermedio en una red de esclavos replicantes como una estrategia de conservación del ancho de banda, sin necesidad de que ese nodo almacene realmente los datos en el disco.