Blog de Ibercivis

Estamos ampliando el sistema con dos nodos nuevos, uno en el CSIC y otro en RedIris, que complementan a los del Bifi y el Ceta. Ya hemos puesto el primero en el circulo de la base de datos -asi que ahora es un triangulo- y nos queda por poner el segundo, dentro de un par de dias.

De momento las nuevas maquinas estan descargando a las antiguas de algunos trabajos de mantenimiento y backup, pero asumiran tanto el respaldo en averias y picos puntuales como la creación de trabajos de los nuevos proyectos.

Entretanto, ayer tuvimos un incremento de visitas, sospecho que por parte de la alianza francófona pero no lo he verificado en los logs. El caso es que por primera vez el sistema de recepcion estuvo un buen rato colgado en el tope de procesos de apache. Hoy estamos mandando trabajos de proyectos mas largos, y la cosa esta mas suave.

Ya se han publicado online los pdf y videos del cuarto encuentro pangalactico de plataformas BOINC.

http://boinc.berkeley.edu/trac/wiki/WS08/WorkshopProceedings

O como un avión. El hecho de que incluso en esta fase de apenas unas millares de CPUS hayamos tenido que marcar tasas de creacion de unidades de 2 y 3 por segundo me lleva a pensar que tal se comportan las bases de datos en otros negocios. La mayor parte de los webs se basa en mysql pero en el fondo son de muchas lecturas y pocas escrituras. En nuestro caso la vida de una ficha incluye mas escrituras que lecturas, y ademas creamos muchas. Una situacion equivalente que he encontrado, en cuanto a escala, son las bases de datos de las reservas de viajes:

A dos viajeros por segundo, en un año gestionariamos 63 millones de viajeros.

Renfe factura en media y larga distancia entre 30 y 40 millones de viajeros al año.

Ryanair afirma tener 50 millones de pasajeros; Iberia unos 27, y el record europeo lo marca Lufthansa con unos 75 millones. Las alianzas suman pasajeros hasta por ejemplo los 400 millones que declara Star Alliance, pero no tengo claro que impliquen una unificación real de las bases de datos.

Naturalmente, estamos lejos de la banca: las tarjetas de credito inglesas, en Diciembre, promedian las 250 transacciones por segundo. Y desde luego en USA los ordenes de magnitud de las operaciones bancarias son mucho mas gordos. Hay un Top de ordenadores de banca:
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
que se mide en transacciones por minuto; los ordenadores mas brutos superan el millon de transacciones por minuto con maquinas de 32 o 64 cores y, esto es importante, otros tantos terminales enviando datos. Si nos ponemos a hilar fino y contamos cada acceso atomico, nosotros podriamos hablar de entre unas 1600 y 2000 por minuto ahora, con un par de cores. Aunque la creación de datos es mas compleja en nuestro caso, pues no la hacen los terminales sino que cuesta tiempo de CPU en el core.

PS: lo que me esta resultando mas dificil de encontrar son los datos del numero de llamadas telefonicas anuales de distintas compañias. Lyman y Varian hicieron en el año 2000 una estimación muy citada sobre el volumen total de información intercambiada en el mundo, pero sin entrar es este detalle fino del "numero de fichas".

Un truco interesante de mysql, que aun no hemos implementado pero que lo vamos a pensar.

Ahora mismo, ya lo he dicho antes, el esqueleto de ibercivis son seis maquinas: cuatro de ellas forman un circulo mysql db0, db1, db2, db3 y vuelta a db0 en cuanto a actualizaciones de la base de datos; y otras dos forman una rama dbweb y dbusers donde se copian los datos que son de solo lectura en las consultas via web. La rama sale de una de las del circulo, digamos db0.

Una de las maquinas del circulo no esta propiamente en los centros de los investigadores sino en instalaciones de rediris. De hecho nos pillo el apagon de Telvent el lunes pasado. Al estar lejos de la tentacion de los investigadores es pues un buen candidato para todas las tareas de gestion: backup de la base de datos, purgado de workunits antiguas y esas cosas. El problema es que estas tareas crean Locks en la base de datos y por tanto retrasan la propagacion a traves del circulo; por ello nuestra solucion y supongo que la de casi todo el mundo es repartirse estas tareas entre todas las maquinas dbN.

Pues bien, resulta que ya va para dos años que se sabe una forma de tener dos masters con un solo esclavo en MySql. Tan solo he encontrado en la web un documento que lo explica: http://www.shinguz.ch/MySQL/mm-single-slave-repl.pdf El truco esta en que en la maquina esclavo deben correr dos esclavos: el de verdad, que apunta al master que mas trafico tenga, y el secundario, que apunta al otro master y ¡no tiene tablas propias, sino federadas!

El resto del truco es tan trivial que ya ni lo dicen: tan solo uno de los masters, el que va al esclavo principal, debe tener activado el log-slave-updates, pues de lo contrario al volver a unirse los flujos se duplicarian todos los updates que vienen del aguas arriba. Tambien hay que tener en cuenta el server_id y sospecho que otros detallitos por investigar. Pero la solucion es interesante. El "circulo" final tendria las replicaciones:

y podriamos hacer consultas "bloqueantes" en db3 sin que se interrumpiera la propagacion de cambios. No asi en db0’, pues no es mas que un acceso disfrazado a db0.

¿por qué no se explica esto en el manual? Supongo que no es porque no funcione, sino porque la posibilidad de paradas de la circulación aumenta mucho: db3 podria escribir sobre fichas que luego no existen en db0 porque ya ha llegado alli una señal de borrado que en db3 estaba atascada, o cosas asi. En tal caso, la replicacion se para y el sysadmin se gana el sueldo. Pero si uno tiene claro que db3 solo va a escribir o borrar cosas que no van a desaparecer por culpa de otro nodo, (o al menos no en las proximas horas), este tipo de operacion "en el anden auxiliar" es posible. Otro problema es que, como dicen en el articulo,  "there isn't the safety net", aunque en el ejemplo nuestro sí que la hay, en el sentido de que todo esta en algun log y puede repetirse si ha fallado.

Otro uso creativo que le veo, mas que la replicacion síncrona, es la replicacion todos a todos. Sin pasarse, digamos para tres nodos: En cada nodo corren dos mysqld en federacion, dbN y dbN', los dos con el "log-slave-updates" quitado, y cada uno se hace esclavo de uno de los otros dos nodos. Resultado: tres nodos replicados sin que el bloqueo de uno fastidie a los otros dos. ¿alguien tiene esto montado? ¿le funciona?

Etiquetas: arivero, toquiteos, mysql

Hola,

Este fin de semana ha sido especialmente desastroso. Una configuracion que en las pruebas andaba justo en los limites de lo posible ha resultado estar más alla del limite. Y como esta semana, a la espera de docking, solo esta saliendo materiales, lo habeis sufrido al 100%.

La perdida de CPU bueno, es parte del juego de la investigación. Al menos no es un fallo que te retrasa cuatro meses el experimento. Pero en cuanto a la perdida de creditos, supongo que podemos dar una compensacion a los que se han bajado unidades durante todo el fin de semana pero han fallado. Digo "supongo" porque no sé como lo veis los diferentes equipos, desde el punto de vista de etiqueta de BOINC. Lo que sea, hay que decidirlo en 24 horas, antes de que la gente desaparezca de la base de datos hacia el backup xml.