MySQL y su anillo
En los ultimos dias habreis notado paradas y rearranques de las bases de datos, o de ibercivis completamente, en pequeños lapsos mitad simulacro de emergencias, mitad prueba de parametros. Lo cierto es que no tuvimos Zivis a este nivel de usuarios durante mucho tiempo, asi que tenemos que aprender sobre la marcha. Tambien por eso los tecnicos estamos comodos con este nivel inicial de un par de miles de participantes asiduos.
MySQL es fascinante. Su modo cluster no es aconsejable mas que si de verdad tienes necesidades brutales, pues exige tener toda la base de datos en RAM, y no solo las caches de los indices. Pero entre la base aislada y el cluster tiene unas etapas intermedias muy interesantes. Basicamente, el sistema de copias Maestro->Esclavo puede no solo expandirse en arbol sino tambien cerrarse en circulo, de forma que un "cluster" de baja velocidad se puede formar mediante un circulo de nodos que aceptan escrituras junto con ramificaciones a nodos que solo aceptan lectura.
A la espera de que se pongan de pie las maquinas de nuestros socio, el "circulo" lo forman dos nodos, uno en subida y otro en bajada/registro, y la ramificacion es una copia que sale hacia www y de ahi a modulos.
Un primer descubrimiento, tan obvio que no sale en los manuales, ha sido el que no habia obligacion de tener los mismos indices en cada copia de la tabla. Lo que sí que sale en el manual es que podemos escoger que tablas copiamos a cada rama, pero eso era de esperar 
. Total, que resulta que podemos optimizar las copias a las ramas quitando indices que no van a utilizar y añadiendo indices que sí que pueden necesitar. Es de esta manera como conseguimos listar en menos de cinco minutos las actividades de los ultimos cinco minutos 
. Otro dia os contare por qué no conseguimos listar las coordenadas de los usarios a la misma velocidad.
Otro descubrimiento, asociado a este, es que las tareas de escritura se repiten en cada nodo. Usease, que realmente el anillo alivia las lecturas, pero las escrituras se las tienen que comer todos como si fuera una base de datos unica. Y obviamente el anillo va a ser tan lento como lo sea su nodo mas debil. Asi que, tirando de ganglia, iostat y lo que se os ocurra, estamos haciendo malabarismos con la cpy, la memoria y los RAID para ver como optimizarlos, y segun vayamos creciendo habra que ir dejando discos y maquinas completas en exclusiva para el mysql.
Es tambien un poco molesto ver que esta diferencia entre lectura y escritura se entendio a medias del desarrollo de BOINC y hay mucho legacy frenandote. Asi, el php tiene una flag para dar un nodo de lectura diferente que el de escritura pero en realidad no lo usa de forma correcta en todos los db_init y ni siquiera esta documentada. La cosa es grave porque hemos observado, o creido observar, que las oleadas de lecturas bloquean la creacion o borrado de tablas.
3 comentarios
engimesex -
Deuvedé -
Ygrámul -
Os quería lanzar una pregunta: por ahora las tareas vienen con deadlines muy cortos; uno de mis ordenadores no está encendido siempre, y se me han quedado algunas tareas por computar que debería haber entregado hace un par de días. La pregunta es: ¿es útil que siga adelante con ellas o ya no sirve para nada? Los créditos me dan más o menos igual, pero tampoco es cosa de perder tiempo de computación en algo que ya no interesa... ¿debería preguntarles a la gente del proyecto? Su blog parece un poquitín muerto...
Gracias!