¿Puedo ejecutar mysqld sobre glusterfs?

He estado jugando con glusterfs recientemente.

Lo que quiero probar es ejecutar mysqld sobre los glusterfs de una manera similar a la que es posible ejecutar MySQL sobre DRBD .

Estoy familiarizado con la replicación MySQL y las ventajas de usar eso en lugar de este enfoque y también conozco MongoDB y otras soluciones NoSQL.

Sin embargo, sería una solución fácil para algunos proyectos específicos que tengo por delante si pudiera dejar MySQL como está y replicar el sistema de archivos subyacente.

¿Es esto posible y, si es así, dónde puedo averiguar cómo?

Debido a un retraso razonablemente largo sin respuestas, lo descubrí por prueba y error.

La respuesta es: Sí, puedo ejecutar mysqld sobre glusterfs.

Configuré esto en Ubuntu y brevemente aquí están los pasos:

• Instalar Ubuntu
• Instalar y configurar glusterfs
• Instalar mysql-server
• Configure /etc/mysql/my.cnf para establecer datadir / mnt / glusterfs en lugar de / var / lib / mysql
• Configurar las bases de datos
• Configure AppAmor para permitir que lo anterior funcione (o deshabilite la apariencia)

El verdadero problema viene en cómo MySQL maneja las cerraduras.

Sin embargo, puede pasar todo esto a los glusterfs para que manejen de manera que muchos procesos mysqld (que se ejecutan en nodos separados) puedan acceder a los mismos archivos de base de datos en / mnt / glusterfs. Necesitas leer esto cuidadosamente .

• Deshabilite el caché de consultas, active el bloqueo externo y desactive los retrasos en la escritura .

Intenté esto en un clúster K8. MySQL se ejecuta dentro de un contenedor, GlusterFS instalado directamente en el nodo (no contenedorizado). El contenedor MySQL tenía un conjunto de afinidad para ejecutarse siempre en el mismo nodo que GFS, montando el volumen utilizando el controlador de volumen GFS nativo de K8.

Experimentado alta latencia aleatoria para sitios de WordPress, incluso con el almacenamiento en caché NGINX FastCGI (PHP-FPM) habilitado. Cambiado al volumen hostPath para el contenedor MySQL, los problemas de latencia desaparecieron.

No creo que sea posible. Richard, el enlace que proporcionaste está hablando de MyIsam y dicen que no se recomienda de todos modos. Leí en alguna parte (no recuerdo dónde) que usar archivos de innoDB compartidos por varios nodos conducirá a la corrupción de datos.

No sé por qué desea acceder a los mismos archivos DB desde diferentes procesos del servidor MySQL, pero si el motivo es el rendimiento, debería echar un vistazo a Galera.

http://www.codership.com/content/using-galera-cluster

Integrado en Maria DB y Percona XTRA DB Cluster

En teoría puedes. En la práctica y especialmente con respecto al rendimiento, el manual de Gluster sugiere que no está destinado a ser utilizado para replicar archivos DB u otros sistemas de E / S de grano fino.

Vea la descripción general oficial de Gluster aquí:

http://docs.gluster.org/en/latest/Install-Guide/Overview/#is-gluster-going-to-work-for-me-and-what-i-need-it-to-do

¿Gluster va a funcionar para mí y qué necesito que haga?

... Por otro lado, al agregar suficientes servidores Gluster a la mezcla, algunas personas han visto un mejor rendimiento con nosotros que otras soluciones debido a la naturaleza de escalamiento horizontal de la tecnología: Gluster no admite los llamados "datos estructurados", lo que significa en vivo , Bases de datos SQL. Por supuesto, usar Gluster para hacer una copia de seguridad y restaurar la base de datos estaría bien: Gluster es tradicionalmente mejor cuando se utilizan tamaños de archivo de al menos 16 KB (con un punto óptimo alrededor de 128 KB más o menos).

Una vez más, si desea tener la replicación MySQL, sugiero:

1. Utilice la replicación tradicional de MySQL Master / Slave https://dev.mysql.com/doc/refman/5.7/en/replication.html

2. Utilice el clúster Codership Galera que actualmente se implementa en todos los sabores de MySQL como Oracle MySQL o MariaDB