MySQL InnoDB sobre un dispositivo sin formato en una topología activa/pasiva

Question

Tenemos una topología Activa/Pasiva donde hay dos complejos x86 con un almacenamiento sin procesar compartido, donde solo uno de los nodos en un momento dado tiene acceso al almacenamiento compartido (también conocido como el nodo activo).En caso de una conmutación por error en el nodo activo, el nodo pasivo inicia una toma de control y se convierte en el nodo activo con acceso al almacenamiento compartido.Cada nodo tiene su propio dispositivo de almacenamiento de arranque con un sistema de archivos.Sin embargo, el almacenamiento compartido no puede tener un sistema de archivos montado.

Estamos interesados ​​en instalar MySQL en ambos nodos, donde sus datos residen en el almacenamiento compartido y solo el nodo activo ejecuta el servidor.

MySQL con InnoDB es capaz de ejecutarse en un dispositivo sin formato, y también hay una guía sobre cómo ejecutar MySQL sobre un cluster similar a nuestra topología.Sin embargo, en el segundo ejemplo, tienen un sistema de archivos montado en el almacenamiento compartido.El problema del sistema de archivos genera una gran preocupación:

ib_logfile* todavía requiere un sistema de archivos.Por lo tanto, la función MySQL sin formato no es exactamente completamente sin formato.Por favor corríjame si me equivoco.¿Existe alguna solución para almacenar esos archivos en el almacenamiento sin formato?Podemos guardar los registros de rehacer (ib_logfile0, ib_logfile1) en el dispositivo de arranque del nodo y siempre elimine esos archivos antes de que se inicie el servidor (para que no tengamos archivos de registro antiguos en caso de múltiples conmutaciones por error).Sin embargo, esto podría llevar a que una transacción no comprometida se comprometa parcialmente en caso de una falla en medio de una transacción, contradiciendo así toda la idea de transacciones.

¿Hay más archivos/características que puedan afectar el comportamiento de MySQL en esta topología?

Answer 1

Vale la pena señalar que el registro de escritura de Innodb (WAL), el IB_LOGFILE *, no es lo único que necesitará un sistema de archivos. Tienes:

1. Tablas del sistema en el esquema MySQL que probablemente use el motor de almacenamiento MYISAM (.FRM, .MYD, .MYI por mesa) (la mayoría ahora está utilizando InnoDB en 5.7)
2. . FRMES FRM para cada tabla Innodb, incluso cuando se usa el espacio de tabla del sistema compartido (metadatos de la tabla que se requiere)
3. MySQL Log Archivos (registro de errores, registro general, registro binario)
4. artefactos SSL
5. auto.cnf (donde se genera la instancia de MySQL UUID y se almacena automáticamente)
6. archivo db.opt para cada esquema (en /<datadir>/<schema>/)
7. .par archivo si crea una tabla particionada (ido en 5.7)
8. .trn y .trg archivos si crea desencadenantes
9. InnoDB TMP TableSpace (5.6 +)
10. Mapa de la página Piscina de amortiguamiento persistió (ib_buffer_pool, 5.6 +)

Todas las anteriores son típicamente dentro de la directorio de datos , así que, siempre y cuando tenga datadir=/some/valid/fs/path, que también se replica (por ejemplo, DRBD) o compartido (por ejemplo, NFS, GFS, OCFS) entre los dos nodos, entonces estará bien.

Vale la pena señalar que los archivos .FRM, .PAR, .TRN, .TRG y .OPT desaparecerán con el Nuevo diccionario de datos .

¡Manténgase sintonizado para algunos anuncios grandes allí en los próximos meses! :)

¡No está claro por qué estás usando el dispositivo RAW? Estoy seguro de que tienes tus razones sin embargo. :)

¡Buena suerte!

Answer 2

La técnica de almacenamiento sin formato solo es buena para ibdata1 con innodb_file_per_table desactivado.

He mencionado configurar esto un par de veces.

• Jul 25, 2012 : Diseño de bases de datos: creación de varias bases de datos para evitar el dolor de cabeza de limitar el tamaño de la tabla
• Feb 26, 2013 : Mantenimiento en MYSQL cuando innodb_file_per_table está deshabilitado

Nota sobre la arquitectura InnoDB (imagen del CTO de Percona, Vadim Tkachenko)

Con innodb_file_per_table deshabilitado, los datos y los índices de todas las tablas InnoDB aterrizarían dentro del almacenamiento sin procesar junto con el búfer de escritura doble, el búfer de inserción, el diccionario de datos, los segmentos de reversión y el espacio para deshacer.

Con respecto a los registros de rehacer, debería considerar tener un pequeño dispositivo de bloqueo DRBD solo para mantener /var/lib/mysql, con ib_logfile0 y ib_logfile1 en esa carpeta.Por lo tanto, la conmutación por error sería la siguiente

• Romper DRBD entre los dos servidores
• Establezca el estado DRBD del nuevo servidor en Primary/Unknown
• Monte DRBD en /var/lib/mysql
• Montar dispositivo sin formato con la información de ibdata1
• service mysql start
• Sincronizar dispositivos DRBD
• Configuración Marcapasos/ucarp servicios para prepararse para la próxima conmutación por error

Preferí DRBD/ucarp para configuraciones de conmutación por error. Ver mis publicaciones antiguas sobre ellos.

ACTUALIZACIÓN 2015-10-14 11:30EDT

Como ya mencioné, los registros de rehacer deben estar en el dispositivo de bloque DRBD montado en /var/lib/mysql.Con respecto a otros archivos esenciales como

• registros binarios
• registros de retransmisión
• registro de errores
• registro lento
• registro general

todos estos archivos deben estar en /var/lib/mysql también.De esa manera, las conmutaciones por error llevarán todo lo relacionado con MySQL (menos los datos sin procesar que están en su propio disco).

ADVERTENCIA :Esta configuración no es para tablas MyISAM.Si se produce una conmutación por error, todas las tablas MyISAM abiertas antes del fallo o la conmutación por error se marcarán como corruptas y será necesario ejecutarlas. REPAIR TABLE en todos afectan las tablas MyISAM.

Si todas sus tablas son InnoDB, ignore esta advertencia.Si convierte las tablas MyISAM restantes a InnoDB, puede ignorar esta advertencia.(NO CONVIERTA NINGUNA TABLA MyISAM EN EL mysql ESQUEMA EN InnoDB).