Hace un tiempo descubrí una característica (tal vez sea un bug) sobre los campos timestamp de MySQL. Es probable que este documentado en alguna parte que todavía no he leído:

Cuando se añade un campo timestamp a una tabla, MySQL agrega mágicamente algunas características al nuevo campo creado como un «trigger» y la fecha actual como valor por defecto.

Aquí esta el script donde se produce el caso:

-- CREANDO UNA TABLA CUALQUIERA E INSERTANDO DATOS 
mysql> create table t(
    -> id int not null primary key auto_increment,
    -> val varchar(50)
    -> );
Query OK, 0 rows affected (0.15 sec)

mysql> insert into t (val) values ("foo") ,("var");
Query OK, 2 rows affected (0.08 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> select * from t;
+----+------+
| id | val  |
+----+------+
|  1 | foo  |
|  2 | var  |
+----+------+
2 rows in set (0.00 sec)


-- AGREGANDO UN CAMPO TIMESTAMP Y MAS DATOS
mysql> alter …

Algunos datos que pueden ser interesantes mostrar en un gráfico son las queries en la cache y la memoria libre de la query cache:

mysql> show status like 'Qca%';
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| Qcache_free_blocks      | 2          |
| Qcache_free_memory      | 400954376  |
| Qcache_hits             | 1014709429 |
| Qcache_inserts          | 149894868  |
| Qcache_lowmem_prunes    | 1785432    |
| Qcache_not_cached       | 57337894   |
| Qcache_queries_in_cache | 26915      |
| Qcache_total_blocks     | 53982      |
+-------------------------+------------+
8 rows in set (0.00 sec)

Si mostramos las queries en cache en gráfico podemos obtener algo similar a:

Queries en cache

Para el caso …

En un post anterior comenté que no es suficiente mirar el Seconds_Behind_Master para saber si se esta replicando correctamente un MySQL, por lo que las herramientas de monitorización se deben adaptar a esto.

El siguiente script comprueba no sólo Seconds_Behind_Master, sino también Last_Errno para dar por buena la sincronización entre master y slave. Los dos únicos parámetros que debemos definir en el script son:

• SBMLIMIT: Número de segundos de retraso máximo que permitimos, no nos interesa que por una pequeña desincronización puntual nos este avisando
• AUTOSTARTSLAVE: Si debe intentar arrancar el slave en caso que se lo encuentre parado

Por otro lado, espera que el password de …

Cansado de tener que averiguar manualmente  cuanto espacio ocupan mis bases de datos, acabo de crear un procedimiento almacenado para tener una vista global de las bases de datos que tenemos en nuestro servidor MySQL.

En MySQL no hay disponible  un comando que nos permita tener una resumen global de las bases de datos, algo que se parezca a SHOW TABLE STATUS pero para todas las bases de datos. El comando SHOW DATABASES sólo lista las bases actuales pero no nos dice cuanto espacio ocupan o cuantas tablas hay, etc.

El procedimiento que escribí esta basado en la base de datos INFORMATION_SCHEMA, que contiene mucha información de todas las bases de datos existentes.

Ya antes en un post anterior mencioné que podemos tener todas estas «herramientas» en una base de datos llamada tools, es por eso que …

El MySQL a veces tiene comportamientos sorprendentes o acabas descubriendo porque stopped no es lo mismo que not running. Por ejemplo, comparando una cadena con un int puedes obtener resultados.

Vamos a suponer la siguiente tabla de ejemplo con datos:

mysql> create table test(id int, txt text);
Query OK, 0 rows affected (0.03 sec)

mysql> insert into test values(1,"uno");
Query OK, 1 row affected (0.00 sec)

mysql> insert into test values(2,"dos");
Query OK, 1 row affected (0.00 sec)

mysql> insert into test values(3,"tres");
Query OK, 1 row affected (0.00 sec)

Cualquier podría suponer que si comparamos el id con un string no obtendremos ningún resultado:

mysql> select * from test where id="asfsafsa";
Empty set, 1 warning (0.00 sec)

mysql> show warnings; …

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 …

En MySQL, para dar privilegios a un cierto rango de IPs, si es un /24 podemos hacerlo con el siguiente comando:

mysql> GRANT ALL PRIVILEGES ON `systemadmin_blog`.* 
       TO 'systemadmin_blog'@'192.168.100.%'  
       IDENTIFIED BY 'systemadmin.es';
Query OK, 0 rows affected (0.00 sec)

Pero si lo que queremos es restringirlo a un rango más pequeño (o uno más grande que tampoco sea redondo) no nos sirve este método.

En el manual de MySQL podemos encontrar que también se puede hacer por IP y máscara de red:

mysql> GRANT ALL PRIVILEGES ON `systemadmin_blog`.* 
       TO 'systemadmin_blog'@'192.168.100.128/255.255.255.240'  
       IDENTIFIED BY 'systemadmin.es';
Query OK, 0 rows affected (0.00 sec)

En la tabla de …

Para crecer en slaves de MySQL podemos apuntar el slave al master o bien utilizar el slave como master para el nuevo slave:

master <--> slave1 <--> slave2

En el caso que usemos el slave anterior como master para el nuevo slave deberemos tener en cuenta varias cosas. A parte de las opciones de configuración como slave:

# Replicacion
server-id               = 3
relay-log               = mysqld-relay-bin
max-relay-log-size      = 500M
relay_log_purge         = 1

Deberemos añadir las que usamos para el master, los binlogs:

log-bin                         = /var/mysql-extra/binlog/mysql-bin
sync_binlog                     = 1
max-binlog-size                 = 500M
expire_logs_days                = 4
innodb_flush_log_at_trx_commit  = 1

Pero también deberemos indicar que el slave que actua como …

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 …

Mediante snapshots LVM y mylvmbackup podemos realizar backups en caliente, pero en el caso que necesitemos mantener el snapshot sin realizar ninguna copia y a la vez conocer la posición del master para montar un slave de MySQL, deberemos parchear el script mylvmbackup.

En el caso que necesitemos crear un snapshot pero sin realizar ningún backup, en la sección misc del fichero de configuración deberemos definir las opciones backuptype y keep_snapshot:

(...)
[misc]
backuptype=none
(...)
keep_snapshot=1
(...)

El problema es que al realizar el backup de tipo none, …