The Information Systems and Computer Applications examination covers material that is usually taught in an introductory college-level business information systems course.

Posts tagged “SQL

Cambio en los Senconds_Behind_Master en MySQL 5.6 by Jordi Prats

En los cambios de MySQL 5.5 a MySQL 5.6 podemos encontrar el siguiente comentario que puede sonar raro:

Important Change: Replication: Formerly, the value of the Seconds_Behind_Master column in the output of SHOW SLAVE STATUS was always set to NULL whenever the SQL thread or the I/O thread was stopped. Now, this column is set to NULL only if the SQL thread is not running, or if the I/O thread is not running following a check to determine whether or not the SQL thread has processed all of the relay log. (If the SQL thread has finished processing and the I/O thread is running, Seconds_Behind_Master is 0.) (Bug #12946333)

Suena raro que se diferencie entre “stopped” y “not running”, pero tiene su explicación.

 

Podemos encontrarnos que los Seconds_Behind_Master vayan creciendo linealmente:

SBM creciendo linealmenteSBM creciendo linealmente

Revisando los logs nos encontraremos con el siguiente error:

121122 17:20:41 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL
thread with "SLAVE START". We stopped at log 'binlog.000050' position 877769220

Lo que esta pasando es que por el bug anteriormente comentado (#12946333) el thread esta corriendo pero no esta actualizando, por lo que como que no esta “stopped” el Seconds_Behind_Master no esta a NULL.

Por lo que lo que nos encontramos en versiones de MySQL 5.5 y anteriores es que aparece un error en los camposLast_Error y Last_Errno. Por suerte no ocurre con todos los errores de replicación sino algunos.

Por lo tanto, para comprobar si se ha roto la replicación en MySQL 5.5 en lugar de mirar si elSeconds_Behind_Master esta a NULL, deberemos mirar si el Last_Errno no esta a 0

Tags: 

Relacionados

 

Enhanced by Zemanta

Ficheros temporales de MySQL by Jordi Prats

En MySQL existe la directiva tmpdir que indicamos el directorio que debe usar para crear ficheros temporales. Aún así, existen otros ficheros temporales que no se crean el dicho directorio.

 

Si definimos la directiva tmpdir veremos que allí crea ficheros con los datos de queries que no le caben en memoria (HEAP) y hace la operación (por ejemplo un sort) en disco:

# grep tmp /etc/my.cnf
tmpdir				= /var/mysql/tmp
# ls /var/mysql/tmp
#sql_22c8_0.MYD  #sql_22c8_0.MYI  #sql_22c8_1.MYD  #sql_22c8_1.MYI

Pero en el datadir también podemos ver en alguna ocasión ficheros temporales que ignoran la directiva tmpdir. En el caso de MyISAM ficheros TMM:

-rw-rw---- 1 mysql mysql 7684096 Nov 16 08:56 xbt_announce_log#P#p48.MYI
-rw-rw---- 1 mysql mysql    1024 Nov 16 08:56 xbt_announce_log#P#p52.TMM
-rw-rw---- 1 mysql mysql 7733248 Nov 16 08:56 xbt_announce_log#P#p51.MYI
-rw-rw---- 1 mysql mysql 7702528 Nov 16 08:56 xbt_announce_log#P#p50.MYI

O en el caso de InnoDB se forman con un identificador de la query:

-rw-rw---- 1 mysql mysql      13632 Nov 16 08:59 #sql-4731_a5b2.frm
-rw-rw---- 1 mysql mysql   28311552 Nov 16 08:59 #sql-4731_a5b2.ibd

Estos ficheros temporales en el datadir se producen cuando realizamos un OPTIMIZE sobre la tabla. Se tratan de ficheros temporales muy diferentes de los que nos referimos con la directiva tmpdir.

Con tmpdir indicamos los ficheros que corresponden a operaciones con los datos. Mientras que los ficheros temporales que se crean en el datadir son las propias tablas que se están recreando.

Tags: 

Relacionados

 

Enhanced by Zemanta