Intentando conectar a un MySQL me encontré con el siguiente error:

# mysql -h 192.168.157.97
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0

Haciendo un tcpdump veremos que la conexión TCP se establece y se cierra correctamente:

# tcpdump -nni any 'host 192.168.157.97'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
16:31:44.812893 IP 192.168.157.97.54337 > 192.168.157.121.3306: Flags [S], seq 4035808194, win 5840, options [mss 1460,sackOK,TS val 2347458047 ecr 0,nop,wscale 7], length 0
16:31:44.812937 IP 192.168.157.121.3306 > 192.168.157.97.54337: Flags [S.], seq 1534874692, ack 4035808195, win 5792, options [mss 1460,sackOK,TS val 2340675374 ecr 2347458047,nop,wscale 7], length 0
16:31:44.813560 IP …

No solo es importante tener los backups, también saber restaurarlos. Vamos a ver cómo restaurar un backup full hecho con xtrabackup

Primero deberemos asegurarnos que se trata de un backup, lo podemos ver mediante el fichero xtrabackup_checkpoints:

# cat FULL/xtrabackup_checkpoints 
backup_type = full-backuped
from_lsn = 0
to_lsn = 1862778
last_lsn = 1862778
compact = 0

A continuación deberemos aplicar los logs para hacer undo de transacciones no comiteadas o aplicar cambios pendientes de transacciones que ya esta comiteadas. Lo deberemos hacer mediante la opción –apply-log:

# innobackupex --apply-log /var/backups/xtrabackup/FULL/

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona LLC and/or its affiliates 2009-2013.  All Rights Reserved.

This software is …

Podemos utilizar xtrabackup mediante el wrapper innobackupex para realizar backups de MySQL sin la asistencia de LVM de una forma muy similar a hotbackup. Vamos a ver un ejemplo de cómo realizar un full backup, un incremental y otro incremental del incremental anterior

Para realizar un backup simplemente deberemos indicar dónde dejar el backup:

# innobackupex /var/backups/xtrabackup

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona LLC and/or its affiliates 2009-2013.  All Rights Reserved.

This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

Get the latest version of Percona XtraBackup, documentation, and help resources:

http://www.percona.com/xb/p

140824 19:04:44  innobackupex: Connecting to MySQL server with DSN …

Al montar un slave de MySQL resulta común evitar tener binlogs (si no es master de otro slave) para evitat el overhead de dicha escritura a disco

Pero si intentamos el mismo setup con GTID tendremos el siguiente error:

2014-08-25 19:39:19 1599 [ERROR] --gtid-mode=ON or UPGRADE_STEP_1 or UPGRADE_STEP_2 requires --log-bin and --log-slave-updates
2014-08-25 19:39:19 1599 [ERROR] Aborting

No es posible tener un slave con GTID sin los binlogs activos también en el slave.

Esto se debe a la forma que se aplican las transacciones en el slave con GTID:

Primero el slave comprueba que el GTID de la transacción no se ha usado en su propio binlog, si es así, aplica la transacción y el GTID y lo escribe en su binlog. Por esto necesitamos tanto los binlogs (opción …

A continuación vamos a ver cómo montar la replicación master-slave en MySQL 5.6 con GTID

Primero deberemos asegurarnos que el master tiene las siguientes opciones en su my.cnf:

gtid_mode=ON
log_bin=binlog
log_slave_updates=1
enforce_gtid_consistency
expire_logs_days=7
server_id=1         
binlog_format=ROW

Creamos el usuario para la replicación con un GRANT:

mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave'@'%' IDENTIFIED BY 'slavepassword';
Query OK, 0 rows affected (0.01 sec)

A continuación mediante un snapshot LVM, mysqldump, …

Por supuesto, esto sólo es un título para llamar la atención. Por lo que yo sé no todas las tablas de sistema se pueden convertir a InnoDB todavía (por ejemplo, las tablas de privilegios), lo cual convierte la cabecera en técnicamente falsa. MyISAM es un motor muy simple, y eso tiene algunas ventajas inherentes (no hay carga extra debido a las transacciones, más fácil de “editar” manualmente, normalmente ocupa menos espacio en disco), pero también algunas desventajas bastante importantes: no es seguro en el caso de un cuelgue general, no hay claves foráneas, sólo bloqueos a nivel de tabla, problemas de consistencia, bugs en tablas muy grandes,… La versión 5.7.5 “Milestone 15”, presentada hoy en el Oracle Open World tiene …

Al realizar queries podemos modificar lo que devolvemos usando la clausula CASE, vamos a ver un ejemplo:

Supongamos que tenemos una columna que nos devuelve 4 o 2:

mysql> show status like 'wsrep%';
(...)
| wsrep_local_state            | 4                                               |
| wsrep_local_state_comment    | Synced                                          |
(...)
mysql> show status like 'wsrep%';
(...)
| wsrep_local_state            | 2                                                           |
| wsrep_local_state_comment    | Donor/Desynced                                              |
(...)

Mediante CASE podemos transformar el 2 en un 1 y el 4 en un 0, mucho más fácil de tratar con, por ejemplo, checks de nagios. En este caso se trata de una query contra information_schema.GLOBAL_STATUS:

mysql> SELECT case VARIABLE_VALUE when 4 then …

En el caso que necesitemos hacer una actualización desde los paquetes community de MySQL nos encontraremos que no podemos simplemente actualizarlos. Vamos a ver los pasos:

Primero deberemos parar el MySQL limpiamente (evidentemente, necesitaremos backups por si algo sale mal):

/etc/init.d/mysql stop

Si intentamos hacer la actualización directamente veremos que no nos deja:

# ls
MySQL-client-5.5.37-1.rhel5.x86_64.rpm  MySQL-server-5.5.37-1.rhel5.x86_64.rpm  MySQL-shared-5.5.37-1.rhel5.x86_64.rpm
# rpm -Uvh MySQL-*
Preparing...                ########################################### [100%]
Repackaging...              
   1:MySQL-client-community #   1:MySQL-server-community ########################################### [ 33%]
   2:MySQL-shared-community ########################################### [ 67%]
Upgrading...                
   1:MySQL-client …

Al realizar un backup con mysqldump nos puede interesar conservar la posición de los binlogs para poder hacer recuperaciones en un punto en el tiempo en lugar del último backup

Para que el mysqldump guarde la posición deberemos usar la opción –master-data:

Si usamos –master-data=1 se guardará la posición mediante el comando CHANGE MASTER, esto es más adecuado si queremos importar los datos en un slave, pero en el master producirá un error:

(...)
--
-- Position to start replication or point-in-time recovery from
--

CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=107;
(...)

Si usamos –master-data=2 el CHANGE MASTER estará comentado, por lo que nos podrá valer tanto …

Vamos a ver cómo realizar una recuperación de datos de una base de datos MySQL en un determinado punto en el tiempo mediante backups con mysqldump y los binlogs activados

Primero vamos a preparar una base de datos de ejemplo:

mysql> create database jordidb;
Query OK, 1 row affected (0.00 sec)

mysql> use jordidb
Database changed
mysql> create table tbl(id int);
Query OK, 0 rows affected (0.03 sec)

mysql> insert into tbl values (1),(2),(3);
Query OK, 3 rows affected (0.01 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> select * from tbl;
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
+------+
3 rows in set (0.00 sec)

A continuación generamos un mysqldump con los datos de posición de los binlogs (opción …