Percona Live 17 Day Two Too Many Talks

• Web ¹
• PDF ²

Nuevamente si tenes Master-Slaves casi no hay problemas, si usas Multiples Masters es problematico y quedo claro porque un nodo de Galera/PXC ni bien detecta una inconsistencia deja de escribir y se suicida (kill -9) y la única manera de volver es de una copia completa (como agregar un nodo nuevo), aunque si es un slave y a tu aplicación no le molesta mucho la integridad podés ponerlo en modo read-only que siga devolviendo SELECT :)

• Web ³
• PDF ⁴

Un flaco de Dropbox contando que tenian 1000 MySQLs, que se creaban 1.200.000.000 de archivos por día y había mucha data por manejar y que en lugar de ponerse a tunear MySQL, se pusieron a ver como se comportaba el SO, dieron un par de tuneos simples y efectivos para GNU/Linux pero mostraron su laboratorio perfilando MySQL.

Primero vieron que TCPWrapper hace un montón de syscalls revisando /etc/hosts.deny y /etc/hosts.accept para comprorar si el host que se esta conectado tiene permiso para hacerlo, esto es un legacy y básicamente eliminaron eso del source de la lib y pusieron reglas de iptables, como tenían que compilar MySQL.

Empezaron a hacer tests con diferentes compiladores, cgolang y 2 versiones de gcc, resulto que la versión mas nueva de gcc era menos performante que la vieja, pero que no podían hacer un downgrade, asi que se pusieron a jugar con todos los parámetros de gcc para lograr una excelente performance, básicamente uso de instrucciones modernas para el hardware con el que contaban y unas optimizaciones locas, entre otras cosas reemplazaron el código de fastmutex del source de MySQL por algo mas performante y fast posta.

Y como todos estos tests son fabulosos con unit tests vieron como simular una carga real, para esto hablo uno de Percona mostrando una tool pt-query-playback, que básicamente lee un slow-query y lo ejecuta y con eso perfilaron y lo usaron de base para recompilar con gcc y lograr que sea casi el doble de rápido!

Estuve poco tiempo porque era muy bonito todo lo que contaban sobre la dificultad de tener replicación multi-continentes pero por lo que entendí es un SaaS (Software as a Service) y en otras charlas le pegaron varios palos porque ofrecen HA y contaban que no siempre funciona el HA :P

• Web ⁵
• PDF ⁶

• Web ⁷
• PDF ⁸

Un par de tanos que descubrieron que tokudb era más rápido que innodb si las tablas no tenían primary key, porque la aplicación genera un uuid y entonces sólo crean el campo id como index (no unique) y combinado con logran responder para un sitio de alto tráfico como lastminute.

• Web ⁹
• PDF ¹⁰

Vi apenas unos minutos, pero lo esencial sobre permisos en la DB.

• Web https://www.percona.com/live/17/sessions/zfs-linux-salesforce-real-world-example-why-pardot-salesforce-company-trusts-and-uses-zol

Llegué al final de esta, logré ver algunos tips de configuración de ZFS como filesystem de MySQL, la mala es que el speaker de Salesforce no tenía autorización para compartir los slides (menos mal que saque fotos)

• Web https://www.percona.com/live/17/sessions/bash-one-liners-and-other-tools-simplify-mysql-ops-scale

No podía faltar a esta, si bien de bash no vi casi nada nuevo, resultó muy útil algunos ejemplos para interactuar con mysql, era un developer de dropbox y tenían unos 450 MySQLs!

• https://www.percona.com/live/17/sessions/protecting-mysql-network-traffic

Como configurar TLS entre cliente y servidor, básicamente lento pero seguro

• https://www.percona.com/live/17/sessions/percona-xtradb-cluster-57-proxysql-your-high-availability-and-clustering-needs

Mas datos sobre ProxySQL + PXC en diferentes escenarios.

• Web https://www.percona.com/live/17/sessions/advance-sharding-solution-proxysql

Como construir reglas para reescribir queries on-the-fly para hacer sharding

• Web https://www.percona.com/live/17/sessions/myrocks-engineering-deploying-new-mysql-storage-engine-production-facebook

Como laburan en FaceBook haciendo replicas de InnoDB en MyRocks y en TokuDB para que todo funcione rapido y sin downtime

La última fue una de las mejores, no habia slides ni nada preparado, se trato de una charla entre Shlomi Noach ¹¹ desarrollador de Orchestrator ¹² y René Cannaò ¹³ desarrollador de ProxySQL ¹⁴ escuchando las sugerencias de la comunidad sobre como debían interactuar estas 2 aplicaciones y fue muy productiva, porque todos tenían diferentes escenarios y necesidades, pero se llego a la conclusión que debían haber 2 opciones: consistencia vs disponibilidad, debido a que ambas herramientas son utilizadas en entornos de alta disponibilidad pero que ante una falla hay que decidir si seguir operando posiblemente con problemas de consistencia o split-brain ¹⁵ (lo mas común en entornos multi-master) o pasar a un esquema single-master o incluso readonly hasta ver como resolverlo.

Post charlas fue la Community Dinner, donde básicamente le queme la cabeza a varios sobre our cooperative company model :P

Según charlé con uno de los sponsors, esta es la conferencia mas grande sobre open-source-databases y estimaban unos 500 attendees