Rubén Ortiz » MySql

Percona Server cotejamiento

Rubén Ortiz — Fri, 11 Nov 2011 11:55:32 +0000

Estos días trabajamos en Rsystem (ITnet Consulting) el lanzamiento de un proyecto (start-up). El proyecto requería una base de datos MySQL. De inicio montamos Percona Server e hicimos la importación de la base de datos suya de su entorno viejo al nuestro actual. Y es ahí donde nos avisaron del problema. Por defecto, el cotejamiento de Percona Servers es latin. Vamos a cambiarlo a utf para que los carácteres especiales se guarden bien.

Comprobamos que valores tenemos antes de todo

1
2
3
4
5

Como podemos ver, latin1 es el _set_server. Vamos a editar my.cnf.

1
2
3

# vim /etc/my.cnf
character_set_server = utf8
collation_server = utf8_general_ci

Sólo queda entonces rebotar el servicio y volver a comprobar

1
2
3
4
5
6
7
8
9

MySQL replicación Master a Slave

Rubén Ortiz — Fri, 08 Jul 2011 08:42:04 +0000

Uno de los motivos de implementar replicación de MySQL Master-Slave, puede ser por ejemplo el disponer de una instancia de MySQL Server de nuestra base de datos, que sólo sirva para el acceso a lecturas (SELECT) para diversos fines (estadísticas, backups, repartir lecturas y liberar de carga al MASTER). Vamos a ver como implementarlo en MySQL 5.0.

Metas y Límites de la replicación

Distribución de datos
Balanceo de carga
Backup
HA y failover
Testear upgrades de MySQL

Una instancia de MySQL SLAVE puede tener sólo un MySQL MASTER
Cada SLAVE debe tener un único ID server
Un MASTER puede manejar varios SLAVES
Un SLAVE puede propagar cambios desde su MASTER y ser a su vez el MASTER de otros SLAVES si habilitas log_slave_updates

Pasos (BREVE)

Configurar cuentas de replicación en ambos servidores
Configurar master y esclavo (editar my.cnf)
Configurar esclavo para conectar y replicar desde el master

Escenario

MASTER = 10.0.0.1, server id 100

SLAVE = 10.0.0.2, server id 101

Asumimos que partimos de un MASTER en servicio, es decir, el SLAVE y MASTER no parten ambos desde cero

1. Setup en MASTER

1.1 Creamos una cuenta de replicación con permisos en la BD master

1
2
3

# mysql -uroot -p
# mysql>; use mysql;
# mysql>; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@’10.0.0.1%’ IDENTIFIED BY ‘replpassword’;

1.2. Habilitar binary login and server ID (editar my.cnf)

1
2
3
4
5
6

# vim /etc/my.cnf

# Replication Master Server (default)
# binary logging is required for replication
log-bin=mysql-bin
server_id=100

1.3. Reiniciar MYSQL

1	service mysqld restart

1.4. Comprobar estado Master

1
2
3
4
5
6
7

Si obtenemos algo como esto es que el archivo de log binario se ha creado correctamente.

2. Setup SLAVE

2.1 Creamos una cuenta de replicación con permisos en la BD master

1
2
3

# mysql -uroot -p
# mysql> use mysql;
# mysql>; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@’10.0.0.2%’ IDENTIFIED BY ‘replpassword’;

*** NOTA: realmente, el usuario de replicación sólo necesita privilegios REPLICATION SLAVE en el MASTER y no necesita REPLICATION CLIENT, pero para este tutorial, seguiremos estos pasos

2.2. Editamos my.cnf

1
2
3
4
5
6
7

# vim /etc/my.cnf

log-bin=mysql-bin
server_id=101
relay_log=mysql-relay-bin
log_slave_updates=1
read_only=1

relay_log: precisa la ruta y nombre del fichero de log relay

read _only: evita las writes en el esclavo

log_slave_updates: guarda los eventos del esclavo en un log

2.3 Reiniciamos esclavo

1	service mysqld restart

3. Iniciar replicación

Necesitamos tres cosas para sincronizar un SLAVE con su MASTER:

Un snapshot de los datos del maestro en algún punto concreto de tiempo
El archivo de log actual del master y el byte offset con el log en el punto de tiempo exacto en el que tomaste el snapshot. Nos referiremos a estos dos valores como coordenadas del archivo log porque juntas identifican la posición del archivo de log binario. Puedes encontrar las coordenadas del archivo log del master con el comando SHOW MASTER STATUS.
Los archivos logs binarios del master desde ese momento hasta el presente.

Hay muchas formas de aplicar la copia de los datos: cold copy, warm copy, mysqldump, lvm snapshot, etc. En este tutorial cubriremos esta:

Coldcopy: parar el master, hacer un trasvase de los archivos físicos del master hacia el slave. Levantar el MASTER otra vez, lo que comenzará un nuevo archivo de log binario y utilizar CHANGE MASTER TO para iniciar el SLAVE al principio del archivo de log binario.

Esta forma tiene un inconveniente MUY CLARO, hay que parar el MASTER en algún momento. Siguiendo la info de http://dev.mysql.com/doc/refman/5.1/en/replication-howto-masterstatus.html tenemos explicado lo mismo de otra forma, vamos a seguir estos pasos:

3.1 Parada de servicio en MASTER y copia de datos
Inicia el cliente de MySQL y haz flush de todas las tablas bloqueando los writes ejecutando. No abandonar la consola de MySQL:

1	mysql>FLUSH TABLES WITH READ LOCK;

Las tablas INNODB también bloquean las operaciones de COMMIT.

Warning: Leave the client from which you issued the FLUSH TABLES statement
running so that the read lock remains in effect. If you exit the client, the lock is released.

A continuación, en la misma consola, obtenemos la posición de nuestro MASTER después del bloqueo de las tablas:

1
2
3
4
5
6

La columna FILE muestra el nombre del archivo de log y la posición muestra el offset del archivo. En este ejemplo, el archivo de log binario es mysql-bin.003 y el offset es el 73. Graba esos valores. Tu necesitarás esto más tarde cuando configures el slave. Esto representa las coordenadas del archivo log en las cuales el slave comenzara a procesar las nuevas actualizaciones desde el master.

En otra sesión, empeazamos el volcado de datos a un archivo físico con mysqldump

1	shell> mysqldump --all-databases --lock-all-tables > dbdump.sql

Cuando el proceso finaliza, desbloqueamos las tablas en la primera sesión abierta en los pasos anteriores

1	mysql>UNLOCK TABLES;

De nuevo en el SLAVE, deberemos importar y configurar

1	shell> mysql -uuser -ppassword < dbdump.sql

Una vez hecho esto, configuramos el SLAVE y comenzamos la replicación. Recuperamos los datos que guardamos previamente en el MASTER cuando hicimos el SHOW MASTER STATUS (punto 3).

1 2	mysql> CHANGE MASTER TO MASTER_HOST='10.0.0.1', MASTER_USER='repl', MASTER_PASSWORD='replpassword', MASTER_LOG_FILE='mysql-bin.000001 ', MASTER_LOG_POS='103874 '; mysql> START SLAVE;

Actualización 30/8/2011: en la parte de esta query, MASTER_LOG_POS=nnnnn, no se ponen comillas, si las ponemos nos devuelve un error

Revisamos el estado de nuestro SLAVE

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host:10.0.0.1
Master_User: slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 951
Relay_Log_File: mysqld-relay-bin.000001
Relay_Log_Pos: 251
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 951
Relay_Log_Space: 407
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 382
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
1 row in set (0.00 sec)

A partir de este momento, los “Second Behind Master” disminuirán progresivamenet hasta 0.

Links

MySQL 5.5

Rubén Ortiz — Tue, 24 May 2011 11:56:58 +0000

En otro post, trataremos la instalación de MySQL 5.5 en CentOS, que por cierto, la primera vez no es sencilla. MySQL 5.5 se convirtió en estable el 15 de diciembre de 2010. Ahora descubro que GA es Generally Available , vaya tela… En definitiva, algunos patchs de google incorporados a la suite 5.5, hacen más que probable que 5.5 tenga un rendimiento bastante superior a otras versiones. Lo digo sin todavía haber hecho los pertinentes test. Pero tiene buenta pinta.

Características principales

El lanzamiento de MySQL 5.5 aporta mejoras en la personalización y escalabilidad.

Escalabilidad y mejora del rendimiento: MySQL Database y motor de almacenamiento InnoDB han sido mejorados para aportar un óptimo rendimiento y escalabilidad para aprovechar los últimos avances en plataformas multi-CPU y multi-core (SMP).

En los entornos que soporten esta característica, se utilizan instrucciones atómicas de la CPU para mejorar el rendimiento de los RW-locks(mutex que permite múltiples lectores). Hay una variable de estado de MySQL que permite conocer si esta característica se soporta en nuestro sistema o instalación.

1
2
3
4
5
6
7

Nuevas variables a configurar para mejorar el rendimiento en base a múltiples threads de lectura y de escritura

1
2
3
4
5
6
7
8

Disponemos de innodb_io_capacity, otro patch de google, que permite configurar el número de operaciones de entrada/salida por segundos. Anteriormente, limitada por defecto a 100, ahora aumentada a 200.

1
2
3
4
5
6
7

mysql>

InnoDB motor por defecto: Ahora, desde la versión MySQL 5.5, InnoDB es el motor de almacenamiento por defecto de la base de datos MySQL, entrega de transacciones ACID, integridad referencial y sistema de recuperación de desastres.

Alta-Disponibilidad: nueva replicación semi-sincrona, se supone que el sistema de replicación es ahora más eficaz y consistente

Usabilidad mejorada: índices mejorados y particionamiento de tablas, soporte SIGNAL/RESIGNAL y diagnósticos mejorados, incluyendo un nuevo PERFORMANCE_SCHEMA, mejorada la administración de MySQL 5.5.

Mejoras en el rendimiento
Teóricamente, la suite MySQL 5.5 ofrece mejoras en el rendimiento versus la suite 5.1. Hasta un 360 % de ganancia en operaciones Read/Write y hasta 200 % de mejoras sólo en Read Only.

Links

MySQL – optimizar base de datos

Rubén Ortiz — Tue, 19 Oct 2010 11:24:23 +0000

Pequeño ejemplo para optimizar las tablas. El ejemplo es válido para instalaciones con Plesk pero vendría a ser algo así.

Si encuentra tablas corruptas las reparará.

1
2
3
4
5

#!/bin/sh
MYSQLCHECK="$(which mysqlcheck)"
USER="admin"
PASSWORD="$(cat /etc/psa/.psa.shadow)"
$MYSQLCHECK -Aao --auto-repair -u$USER -p$PASSWORD

MySQL – Backup y restore III

Rubén Ortiz — Tue, 19 Oct 2010 09:59:20 +0000

Script para backup sencillo de motor de base de datos mysql

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

#!/bin/bash
# Ruta en la que se guarda el log de la operacion de backup.
logfile="/var/log/mysql.log"
# Ruta en la que guardar los backups
backup_dir="/root/backup/mysql"
# Usuario
username=""
password=""
# Creamos un nuevo log del proceso de backup
rm -rf $logfile
touch $logfile
# Mediante esta instruccion, generamos un nombre de fichero con el dia y la hor
timeslot=`date +%Y%m%d_%H%M`
timeslot2=`date +%d-%m-%y`
cd $backup_dir
mkdir $backup_dir/$timeslot2
cd $timeslot2
# Iteramos a traves de la lista de bases de datos a la que el usuario tiene acceso.
for BBDD in $( mysql -u $username --password=$password -h
localhost -Bse 'show databases' ); do
echo "Creando copia de seguridad de $BBDD"
# Volcamos la base de datos en un fichero temporal
mysqldump --user=$username --password=$password $BBDD > datos.sql
# Y lo comprimimos en un tar.bz2 para ocupar lo mmnimo.
#Util en bases de datos grandes.
tar cvjf mysql-$BBDD-$timeslot.tar.bz2 *.sql
# El nombre del fichero resultante contiene el nombre de
la base de datos y la fecha de la copia.
# De esta manera, cuando sea necesaria su restauracion
sera mas sencillo de localizar.
echo "Backup completo en la base de datos: $BBDD (mysql-$BBDD-$timeslot.tar.bz2)"
>> $logfile
# Borramos el fichero temporal
rm datos.sql
done

MySQL – Innodb motor engine

Rubén Ortiz — Thu, 26 Aug 2010 13:39:06 +0000

Me ha pasado una cosa curiosa. Entiendo que es más debido a un procedimiento que yo no conocía que a un bug, pero en todo caso, lo comento.

Tenemos una instalación nueva, de MySQL, versión 5.077 en un CentOS 5, por ejemplo. Por defecto en la mayoría de instalaciones el motor de base de datos será MyISAM. El caso es que importo una base de datos en las que las tablas son Innodb. Pero al entrar vía phpmyadmin veo que el motor que sale es MyISAM. Me sorprende porque no tenía puesto el

skip-innodb

en la configuración de MySQL. Otra pista, el phpmyadmin, en el link que te muestra los motores de almacenamiento me muestra 3, pero ninguno es Innodb. Muy raro porque si entro por consola y ejecuto

1 2	mysql> show engines; \| InnoDB \| YES \| Supports transactions, row-level locking, and foreign keys

me devuelve que si que está habilitado. La solución la encontré de chiripa porque no tenía ni idea de que estaba pasando. Para arreglarlo tuve que renombrar los ficheros de log innodb, de la siguiente forma.

1
2
3
4

# service mysqld stop
# mv /var/lib/mysql/ib_logfile0 /var/lib/mysql/ib_logfile0.bak
# mv /var/lib/mysql/ib_logfile1 /var/lib/mysql/ib_logfile1.bak
# service mysqld start

En el mismo link donde un colega posteó la solución, otro tipo plantea la solución al dilema:

I did a little research on why your solution works and it seems that though InnoDB is enabled by default, MySQL seems to disable it automatically if your InnoDB log files get corrupted. When you remove them, they are recreated, allowing InnoDB to start again.

Links

http://www.turnkeylinux.org

MySQL – Configurar password root

Rubén Ortiz — Wed, 09 Jun 2010 09:08:28 +0000

1	# mysqladmin -u root password NEWPASSWORD

MySQL – Script optimización tablas

Rubén Ortiz — Wed, 14 Apr 2010 13:52:54 +0000

Buen script que chequea todas las bbdds en busca de tablas MyISAM o INNODB y las optimiza.

MySQLFragFinder.sh

Links

http://www.dufault.info/blog/a-script-to-optimize-fragmented-tables-in-mysql/

MySQL – Copiar tabla

Rubén Ortiz — Wed, 14 Apr 2010 10:36:59 +0000

1 2	CREATE TABLE pruebas LIKE produccion; INSERT pruebas SELECT * FROM produccion;

El primer comando crea una tabla como la que queremos copiar, el segundo, añade todo lo de la tabla objeto de copia a la nueva tabla creada en el primer comando.

MYSQL – Backup de procedures

Rubén Ortiz — Mon, 01 Feb 2010 12:20:42 +0000

Cuando hacemos uso de mysqldump, para hacer backup de nuestras bases de datos, por defecto, se incluyen los triggers pero no las procedures.

Para hacer backup completo de las bases de datos y añadir las procedures, hemos de añadir el parámetro “- -routines”

# mysqldump –routines > datos.sql

Para hacer backup SÓLO de las procedures:

# mysqldump –no-create-info –no-data –no-create-db –skip-opt –routines > datos.sql