Re: [OFF-TOPIC] Percona sobre debian Wheezy
El día 5 de junio de 2015, 17:14, Camaleón <noelamac@gmail.com> escribió:
> El Wed, 03 Jun 2015 17:26:50 +0200, Maykel Franco escribió:
>
>> Hola buenas, al final migré desde galera a percona en 2 nodos por lo
>> pronto.
>
> Ah, pues muy bien :-P
>
>> Me ha funcionado todo bien, excepto que nos hemos vuelto locos con el
>> rendimiento sobre los SSDs, teniendo que cambiar la directiva:
>>
>> innodb_flush_log_at_trx_commit = 0 , ya que por defecto está en 1 y se
>> nos producían cuellos de botella... Aconsejan este valor además si no
>> tienes cache de escritura en la controladora. Que creo que tiene más que
>> ver con esto último que con los SSDs, ha sido cambiar eso y va como un
>> tiro. Sin cambiar esta directva, metiendo muchas querys se nos quedaban
>> las querys como "searching rows for update".
>
> Hum... bueno, lo que dice MySQL¹ es que:
>
> 1/ Recomiendan activar la descarga del registro a disco (1) para mayor
> seguridad en la recuperación de las transacciones aunque advierten de que
> no todos los sistemas operativos informan/ejecutan correctamente de la
> operación.
>
> 2/ Independientemente de la configuración de ese valor recomiendan el uso
> de un SAI o controladora de disco con batería para mayor fiabilidad en
> caso de apagón.
>
> Si lo desactivas simplemente es para ganar en rapidez pero nada más ;-)
>
>> El problema que tenemos ahora, que por eso recurro a ustedes, es que
>> "creo" que desde que cambie esa directiva empezó a crearme en un nodo
>> percona todos estos ficheros...que por lo visto no se pueden borrar.
>>
>>
>> 128M /var/lib/mysql/gcache.page.000000 128M
>
> (...)
>
>> http://www.severalnines.com/blog/understanding-gcache-galera
>>
>> Los writesets que se pierden los almacena en fichero y creo que penaliza
>> rendimiento a en /var/lib/mysql (directorio donde está montado los SSD
>> como raid1) que es donde se crean por defecto.
>>
>> Lo que sí que se puede hacer es hacer que se guarden en otro sitio,
>> para que no nos penalice el rendimiento. Y aumentar el tamaño:
>>
>> wsrep_provider_options="gcache.size = 5G; gcache.name =
>> /another_partition/galera.cache"
>>
>>
>> Alguien se ha peleado con esto? Como siga así nos quedamos sin espacio
>> más adelante y encima creo que no se pueden borrar...
>
> Podrás borrarlos pero entiendo que para eso se deben de dar las
> siguientes condiciones:
>
> 1/ Debería hacerlo percona/galera directamente para saber cuándo poder
> eliminarlos sin causar estragos. En caso de que no lo haga, podrás
> detener la aplicación y borrarlos manualmente.
>
> 2/ Tendría que haber algún parámetro que evitara la creación de los
> archivos pero entiendo que eso lo lleva la parte de la bdd, es decir,
> MySQL, mira a ver si tiene alguna opción para esto.
>
> 3/ Los datos contienen información relevante en caso de reconstrucción de
> las consultas, si los borras tienes que saber a lo que te expones.
>
> ¹http://dev.mysql.com/doc/refman/5.7/en/innodb-
> parameters.html#sysvar_innodb_flush_log_at_trx_commit
>
> Saludos,
>
> --
> Camaleón
Gracias Camaleón. Reiniciamos los servicios poco a poco de mysql en
los 3 percona que tenemos y cuando reiniciamos empezó el solito a
borrar esos ficheros, lo vimos además en el log, deleted page... Solo
pasaba esto en uno de los nodos...Curioso.
Por otro lado lo que hemos hecho es aumentar el tamaño del fichero
galera.cache, que es el que guarda las últimas transacciones usando un
buffer circular en fichero, de tal forma que lo va rellenando y
sobreescribiendo según van escribiéndose los últimos writesets. De tal
forma, que cuando un nodo se cae y se vuelve a levantar, intente hacer
un IST antes de hacer el SST. Para eso te aconsejan hacer una
operacion matemática sacando el tamaño necesario de galera.cache en
cuanto a tu tráfico se refiere entre los datos recibidos y los
replicados:
https://www.percona.com/blog/2014/09/08/calculate-correct-size-percona-xtradb-clusters-gcache/
También hemos cambiado la ubicación del fichero galera.cache, para que
no escriba en /var/lib/mysql, que es un raid aparte, y escriba en el
sistema /var/tmp/percona-gcache que es otro raid a parte y no ocupe
I/O de disco de datadir de mysql.
Ahora mola, porque cuando reinicias un nodo tarda nada en sincronizar,
mientras que el nodo no esté apagado más del tiempo establecido con el
tamaño del fichero galera.cache (no me sé explicar mejor), es decir,
si en los nodos activos se escribe más writesets de los que el fichero
galera.cache pueda contener, entonces el nodo caido cuando levante
tendrá que hacer un SST, copia completa de /var/lib/mysql usando
xtrabackup.
Lo que no entendía era el por qué la creación de esos
ficheros...gcache.page...Sigo sin entenderlo la verdad después de leer
eso...
>
>
> --
> To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] pan.2015.06.05.15.14.01@gmail.com">https://lists.debian.org/[🔎] pan.2015.06.05.15.14.01@gmail.com
>
Reply to: