El documento describe los diferentes métodos para instalar MySQL, incluyendo código fuente, binarios y paquetes. Explica los pasos para instalar MySQL desde código fuente o binarios, como compilar, crear usuarios y directorios, y configurar el servicio. También cubre la instalación a través de paquetes en Debian.
3. Irontec – Administración de MySQL
Instalación
● La instalación puede realizarse de las siguientes formas:
– Código fuente
– Binarios
– Sistema de paquetes de tu distribución
● Cada uno tiene sus ventajas e inconvenientes
– Código fuente es laborioso, pero te permite definir
mejor las carácterísticas de tu servidor, activando y
desactivando a tu gusto
– Los binarios vienen compilados y son más fáciles de
actualizar. Si están compilados con icc se puede casi
doblar el rendimiento
– Sistema de paquetes, facil de instalar y de actualizar
3
4. Irontec – Administración de MySQL
Instalación
http://downloads.mysql.com/archives.php
● Para compilar en debian es necesario como mínimo:
– aptget install buildessential libncurses5dev
● Como siempre ./configure && make && make install
– ./configure –help
– ./configure –prefix=/usr/local/mysql
– ./configure –withoutplugininnodb
● Tenemos que crear los usuarios:
– # groupadd mysql
– # useradd g mysql mysql
● Creamos las bases de datos necesarias para funcionar
– # cd scripts
– # ./mysql_install_db
4
5. Irontec – Administración de MySQL
Instalación
● Damos permisos a la carpeta:
– # chown R root /usr/local/mysql
– # chown R mysql /usr/local/mysql/var
– # chgrp R mysql /usr/local/mysq
● Copiamos el fichero de configuración y lo editamos en
caso de que sea necesario:
– # cp supportfiles/mymedium.cnf /etc/my.cnf
● Arrancamos MySQL :)
– # /usr/local/mysql/bin/mysqld_safe –user=mysql
5
6. Irontec – Administración de MySQL
Instalación
● Los binarios podemos descargarlos de:
http://dev.mysql.com/downloads/mysql/
# groupadd mysql
# useradd g mysql mysql
# cd /usr/local
# tar xzf mysqlVERSIONOS.tar.gz
# cd mysql
# chown R mysql .
# chgrp R mysql .
# scripts/mysql_install_db user=mysql
# chown R root .
# chown R mysql data
# bin/mysqld_safe user=mysql &
6
7. Irontec – Administración de MySQL
Instalación
● En Debian podemos hacer la instalación con apt-get :)
● ¡En cualquiera de los tres modos de instalación es
necesario dar una contraseña a root!
7
8. Irontec – Administración de MySQL
SandBox
● Para crear una laboratorio de pruebas podemos:
– Montar equipos físicos e instalarlos (de locos).
– Montar máquinas virtuales.
– Usar ¡sandbox!
8
9. Irontec – Administración de MySQL
SandBox
● SandBox nos permite:
– Montar sistemas de replicación
– Probar versiones nuevas de MySQL facilmente
– Manejar múltiples instancias de MySQL desde un único
punto.
– Te olvidas de rmps, sources, debs... ¡tar.gz binario!
– Testear
– Testear
– Testear...
9
10. Irontec – Administración de MySQL
SandBox
● No es un producto oficial de MySQL.
● Está escrito el perl (puag!) y aún así funciona bien.
http://mysqlsandbox.net/
● Tendremos que descargar un paquete tar.gz de MySQL
y Sandbox.
10
11. Irontec – Administración de MySQL
Instalación
● ¡Como root!
root@shyris:~# tar xzf MySQLSandbox3.0.05.tar.gz
root@shyris:~# cd MySQLSandbox3.0.05/
root@shyris:~/MySQLSandbox3.0.05# perl Makefile.PL
root@shyris:~/MySQLSandbox3.0.05# make
root@shyris:~/MySQLSandbox3.0.05# make test
root@shyris:~/MySQLSandbox3.0.05# make install
root@shyris:/usr/local/bin# ls
low_level_make_sandbox make_multiple_sandbox make_sandbox
make_sandbox_from_source sb test_sandbox
make_multiple_custom_sandbox make_replication_sandbox
make_sandbox_from_installed msandbox sbtool
11
12. Irontec – Administración de MySQL
Uso de SandBox
● Crear un sandbox con una única instancia de MySQL
punisher@shyris:~$ make_sandbox /home/punisher/MySQL/mysql
5.0.86perconahighperfb19.tar.gz
unpacking /home/punisher/MySQL/mysql5.0.86percona
highperfb19.tar.gz
Executing low_level_make_sandbox
basedir=/home/punisher/MySQL/5.0.86
sandbox_directory=msb_5_0_86
install_version=5.0
sandbox_port=5086
no_ver_after_name
my_clause=logerror=msandbox.err
12
13. Irontec – Administración de MySQL
Uso de SandBox
● Parar sandbox:
– stop
● Arrancar sandbox:
– start
● Utilizar sandbox:
– use
● Reiniciar sandbox:
– restart
● Limpiar el sandbox:
– clean
13
14. Irontec – Administración de MySQL
Clientes
● Existen distintos clientes para conectarse a la BBDD
● Clientes de consola
– Mysql
– Mysqldump
– Mysqladmin
– Mysqlimport
● Gráficos
– Mysql Administrator
– Mysql Query Browser
– MySQL Workbench
● etc.
14
15. Irontec – Administración de MySQL
Clientes
● Mysql: el típico, nos permite conectarse tanto de
forma local como remota y ejecutar sentencias SQL
● Mysqldump: permite hacer backups
● Mysqladmin: crear/borrar bases de datos, cambiar
contraseñas, ver el estado, variables, parar slaves, etc.
● Mysqlimport “frontend” para “LOAD DATA INFILE”
Vienen ya incluidos en MySQL
15
20. Irontec – Administración de MySQL
Ficheros de configuración
● Algunos parámetros de configuración se pueden pasar
directamente al mysqld
– mysqld –basedir /usr/local/mysql
● Otros parámetros que se pueden especificar:
– Habilitar/deshabilitar engines
– Opciones de rendimiento
– Logs
– …
● Es más cómodo especificarlo en los ficheros de
configuración
20
21. Irontec – Administración de MySQL
Ficheros de configuración
● Por defecto busca los ficheros en las siguientes
ubicaciones:
– /etc/my.cnf
– $MYSQL_HOME/my.cnf
– ~/.my.cnf
● Se puede añadir un fichero de configuración en el
arranque con:
– defaultsextrafile
21
22. Irontec – Administración de MySQL
Ficheros de configuración
● El fichero se encuentra dividido en distintas secciones,
por ejemplo [mysqld], [mysql], [mysqldump]
● Cada opción dentro de una categoría se aplica
únicamente a dicha aplicación
[mysql]
prompt='mysql [h] {u} (d) > '
[mysqld]
user = punisher
port = 5140
socket =
/tmp/mysql_sandbox5140.sock
[mysqldump]
quick
quotenames
max_allowed_packet = 100M
22
24. Irontec – Administración de MySQL
Engines
● MySQL es modular, permite elegir entre diferentes
engines para el almacenamiento de datos
● Los engines se aplican a tablas, no a bases de datos
● Puedes tener una base de datos con diferentes engines,
dependiendo del tipo de datos o consultas que se
hagan
24
25. Irontec – Administración de MySQL
Tablas
● Todas las tablas de MySQL tienen ciertas similitudes
● Las tablas tienen .frm como formato. Este fichero
guarda la estructura de la tabla
● Independientemente del engine, tendremos un .frm
● A parte, podemos tener otros ficheros acompañando
al .frm
25
26. Irontec – Administración de MySQL
Engines
● Al crear una tabla se puede indicar el engine:
create table t (i INT) ENGINE = MyISAM;
● Una vez que está creada, se puede cambiar el engine:
alter table t ENGINE = MyISAM;
● También podemos saber con que engine se ha creado
una tabla
Show create table t;
26
27. Irontec – Administración de MySQL
Engines
● ¿De que engines tenemos soporte?
show enginesG
mysql [localhost] {msandbox} (mysql) >
*************************** 1. row ***************************
Engine: InnoDB
Support: YES
Comment: Supports transactions, rowlevel locking, and foreign keys
Transactions: YES
XA: YES
Savepoints: YES
*************************** 2. row ***************************
Engine: MRG_MYISAM
Support: YES
Comment: Collection of identical MyISAM tables
Transactions: NO
XA: NO
Savepoints: NO
*************************** 3. row ***************************
Engine: BLACKHOLE
Support: YES
Comment: /dev/null storage engine (anything you write to it disappears)
Transactions: NO
XA: NO
Savepoints: NO
[...]
27
28. Irontec – Administración de MySQL
MyISAM
● MyISAM es el engine por defecto en MySQL
● Si no se indica lo contrario, todas las tablas se crearán
con este engine
● Es obligatorio tener soporte para el engine en MySQL,
ya que todas las tablas de la BBDD son MyISAM
● La tabla viene definida por tres ficheros:
– mitabla.frm
– mitabla.MYD
– mitabla.MYI
28
29. Irontec – Administración de MySQL
MyISAM
● Antes de usar MyISAM hay que conocer bien
sus virtudes y defectos :)
● Soporta busquedas FULLTEXT
● Al escribir se hace uso de bloqueo de tabla
● Se puede usar para generar tablas MERGE
● No soporta, transacciones, integridad referencial o
claves externas
● Suele ser el más rápido en lecturas
● No tiene cacheo de datos
● Se pueden comprimir tablas para ahorrar espacio
http://dev.mysql.com/doc/refman/5.1/en/myisam-storage-engine.html
29
30. Irontec – Administración de MySQL
MyISAM
● El bloque en MyISAM se hace a nivel de tabla
● No pueden ocurrir deadlocks (dos procesos se quedan
esperando a que termine el otro)
● Soporta inserciones concurrentes siempre y cuando la
tabla no tenga “agujeros” causados por el borrado de
datos (optimize table)
● Las escrituras tienen prioridad sobre las lecturas
● El servidor intenta hacer las escrituras en el orden en
que las recibe
30
31. Irontec – Administración de MySQL
MyISAM
● Si una tabla se está leyendo y llega una petición de
escritura, al escritura tiene que esperar
● Si una tabla se está escribiendo y llega una petición de
lectura, la lectura tiene que esperar
● Si hay escrituras pendientes, las lecturas que lleguén
tendrán que ponerse a la cola
31
32. Irontec – Administración de MySQL
MyISAM
● Las prioridades pueden moficiarse haciendo useo de
los schedulers:
– LOW PRIORITY: para las querys que escriben datos. La
escritura se queda esperando a que terminen todas las
lecturas, incluso las que llegan después. Se escribirá
cuando no exista ninguna lectura pendiente.
– HIGH PRIORITY: para las querys de lectura. Las querys
con este modificador se mueven al principio de la cola,
por delante de otras escrituras y lecturas
– DELAYED: para querys INSERT y REPLACE. El servidor
mete en buffer las filas y lo inserta cuando no se esté
usando la tabla. Las delayed se insertan en bloques en
lugar de una a una aumentando el rendimiento
32
33. Irontec – Administración de MySQL
MyISAM
● MyISAM puede almacenar las filas en tres formatos,
fixed, dynamic y compressed.
● FIXED
– Todas las filas tienen el mismo tamaño
– Ocupan más espacio
– Se encuentran más rápido
● DYNAMIC
– Usa un tamaño variable de datos (menos que fixed)
– Las filas no se encuentran tan eficientemente
– Puede haber más fragmentación
● COMPRESSED
– Ocupan mucho menos espacio
– Optimizado para consultas rápidas
– Solo lectura
33
34. Irontec – Administración de MySQL
MyISAM
● Para conocer el formato en el que se encuetran las filas
de una tabla:
SHOW TABLE STATUS LIKE 't'G
● Crear tabla FIXED:
CREATE TABLE t (c CHAR(50)) ROW_FORMAT= FIXED;
● Crear tabla DYNAMIC:
CREATE TABLE t (c CHAR(50)) ROW_FORMAT= DYNAMIC;
34
35. Irontec – Administración de MySQL
MyISAM
● Una tabla MyISAM, fixed o dynamic, puede convertirse
en tabla comprimida
● Se suelen comprimir aquellas que se usan para datos
históricos y que nunca van a ser modificadas
● Son de solo lectura
● Se comprimen con la utilidad myisampack
● Se debe parar el servidor antes de comprimir
los datos
● Se descomprimen con myisamchk --unpack
35
36. Irontec – Administración de MySQL
MyISAM
$ myisampack departments employees
departments is too small to compress
Compressing employees.MYD: (300024 records)
Calculating statistics
Compressing file
47.12%
Remember to run myisamchk rq on compressed tables
$ myisamchk rq departments employees
check record deletechain
recovering (with sort) MyISAMtable 'departments'
Data records: 9
Fixing index 1
Fixing index 2
check record deletechain
recovering (with sort) MyISAMtable 'employees'
Data records: 300024
Fixing index 1
36
37. Irontec – Administración de MySQL
Merge
● Una tabla merge es una colección de distintas tablas
con la misma estructura
● Una query en la tabla merge se ejecuta en todas las
tablas que la componen
● Puede ayudarnos a superar el tamaño máximo de una
tabla MyISAM (256TB)
● Es mas lento, ya que tiene que leer múltiples tablas
● Aumenta el número de descriptores de ficheros
abiertos requeridos
37
38. Irontec – Administración de MySQL
Merge
● Se suele utilizar para borrar millones de datos en un
instante. Gracias a merge podemos borrar la tabla que
lo compone en lugar de ir eliminando una a una cada
fila
mysql> CREATE TABLE A (name varchar(100))
ENGINE=MyISAM; Query OK, 0 rows affected (0.00 sec)
mysql> CREATE TABLE B (name varchar(100))
ENGINE=MyISAM; Query OK, 0 rows affected (0.00 sec)
mysql> CREATE TABLE TOTAL (name varchar(100))
ENGINE=MERGE UNION=(A,B) INSERT_METHOD=LAST;
Query OK, 0 rows affected (0.01 sec)
38
39. Irontec – Administración de MySQL
Merge
● El problema de bloqueo se acentúa más con Merge
● Cuando se bloquea para escritura, se bloquean todas
las tablas que contiene
● Cuando se bloquea para lectura, se bloquean todas las
tablas que contiene
● Añadir un registro en Merge puede traer como
consecuencia el bloqueo de cientos de tablas
● Contra más tablas y mas datos, mas problemas de
rendimiento y bloqueos
39
40. Irontec – Administración de MySQL
Memory
● Es una tabla en memoria, lo cual ya nos da sus
pros y contras solo con el nombre
– Es muy muy rápida
– Los datos no se guardan después del reinicio del servidor
– Usan la memoria RAM, por lo que no debe usarse para
tablas grandes
– Usa bloqueo a nivel de tablas
– No puede tener columnas TEXT o BLOB
40
41. Irontec – Administración de MySQL
Memory
● Soporta dos típos de índices, HASH y BTREE:
– HASH: memory las usa por defecto. El algoritmo es muy
rápido para comparaciones que usen índices únicos.
Pero solo se puede usar para comparaciones = o <=>
– BTREE: es preferible para índices que se usarán con
comparaciones disintas a las anteriores. Por ejemplo:
id<1024 or id BETWEEN 4000 and 5000
CREATE TABLE T (i int) ENGINE=MEMORY;
41
42. Irontec – Administración de MySQL
Federated
● Te permite usar tablas de otro servidores MySQL
remotos
● De esta forma el cliente no debe conectarse a otros
servidores para acceder a los datos
● Al estar en un servidor remoto, las federated no
soportan el bloqueo de tablas
CREATE TABLE federated_table (
id INT(20) NOT NULL AUTO_INCREMENT,
name VARCHAR(32) NOT NULL DEFAULT '',
other INT(20) NOT NULL DEFAULT '0',
PRIMARY KEY (id),
INDEX name (name),
INDEX other_key (other)
)
ENGINE=FEDERATED
DEFAULT CHARSET=latin1
CONNECTION='mysql://fed_user@remote_host:9306/federated/tes
t_table';
42
43. Irontec – Administración de MySQL
Federated
● Los engines que se conectan a un servidor externo para
coger datos (como FEDERATED, NDB o SPIDER) tienen
un funcionamiento poco optimo cuando las querys
tienen condiciones
● En estos engines, la condición no se envia junto con la
petición, por lo tanto el servidor remoto nos transmite
TODAS las filas de la tabla para que nuestro MySQL
local haga la búsqueda
● Para solucionarlo se debe implementar “CONDITION
PUSHDOWN” ya sea mediante un parche o plugin
● Dependiendo del engine tendremos diferentes
soluciones (o en algunos casos ninguna)
43
44. Irontec – Administración de MySQL
InnoDB
● InnoDB nos ofrece todo aquello de lo que MyISAM
carece
– Claves externas
– Integridad referencial
– Bloqueo de filas en lugar de tablas
– Auto recuperación ante errores
– Transacciones y rollbacks
– Cacheo de índices y datos
– Etc...
http://dev.mysql.com/doc/refman/5.1/en/innodb.html
44
45. Irontec – Administración de MySQL
InnoDB
● ¿Y que perdemos al pasarnos a InnoDB?
– Capacides de busqueda FULLTEXT
– La posibilidad de comprimir las tablas
– No poder hacer uso de Merge
– “Sólo” 64 TB de datos por tabla
45
46. Irontec – Administración de MySQL
InnoDB
● InnoDB es un engine que cumple las características
ACID:
– Atomic: O todas las sentencias se ejectuan correctamente
o se cancelan.
– Consistent: Es consistente cuando una transacción que
comienza la deja en estado consistente al terminar.
– Isolated: Una transacción no afecta a las demás.
– Durable: Todos los cambios efectuados por una
transacción se graban. No se pierden datos.
46
47. Irontec – Administración de MySQL
InnoDB
● Cuando se producen múltiples transacciones que
afectan a los mismos datos, pueden darse los siguientes
problemas:
– Dirty read: es una lectura de una transacción de datos no
commiteados realizados por otra. ¡Si finalmente esta
última no hace el commit, lo que hemos leido no sirve!
– Non-repeatable: ocurre cuando una transacción realiza
la misma petición de datos dos veces recibiendo
resultados distintos
– Phantom: ocurre cuando aparece una fila que no era
visible en la query, ya que otra transacción la ha incluido
durante el proceso de lectura
47
48. Irontec – Administración de MySQL
InnoDB
● InnoDB dispone de 4 niveles de aislamiento:
– READ UNCOMMITED: permite a una transacción ver
los datos sin commitear de otra. Se pueden dar non-
repeatable reads, phantoms y dirty reads
– READ COMMITED: permite ver cambios de otras
transacciones solo si están commiteados. Se pueden dar
non-repeatable reads y phantoms
– REPETABLE READ: asegura que la misma SELECT
ejecutada dos veces de los mismos valores. Las filas
modificadas por una transacción no puden ser
modificadas por otras. Se pueden dar phantoms
– SERIALIZE: separa completamente los efectos de unas
transacciones sobre otras con la restricción de que las
filas seleccionadas por una transacción no pueden ser
accedidas por otras
48
49. Irontec – Administración de MySQL
InnoDB
● Por defecto InnoDB utiliza REPEATABLE READ para ser
full ACID
● Para cambiar de uno a otro aislamiento de:
[mysqld]
Transactionisolation = READCOMMITED
49
50. Irontec – Administración de MySQL
InnoDB
● InnoDB implementa la concurrencia en las
transacciones siguiendo el modelo MVCC (multiversion
concurrency control)
● Permite que cada transacción tenga una visión única de
los datos (un snapshot) para tener una vista consistente
con el paso del tiempo, sin tener en cuenta las
modificaciones de otras transacciones
● Esto puede permitir que distintas transacciones vean
datos diferentes de la misma tabla en un mismo
momento
● Gracias a esto evitamos tener que bloquear siempre las
filas. Menos overhead y más operaciones concurrentes
● En lecturas casi nunca se bloquearán las filas
50
51. Irontec – Administración de MySQL
InnoDB
● MVCC funciona añadiendo a cada fila dos valores
adicionales que indican cuando fué creada y cuando
fué eliminada
● Con esto InnoDB se asegura que al iniciar una
transacción...
– La fila existía antes de iniciar la transacción
– La fila no fué eliminada antes de iniciar la transacción
● Con cada actualización de la fila, la transacción
actualiza los valores asociados
● El multiversioning se utiliza con:
– REPETABLE READ
– READ COMMITED
51
52. Irontec – Administración de MySQL
InnoDB
● Por defecto InnoDB viene habilitado con autocommit,
cada query se commitea al instante
● Esto no nos permite hacer rollback ni agrupar querys en
batch para mejorar el rendimiento
● ¿Y como desactivo el autocommit?
– SET AUTOCOMIT = 0;
– START TRANSACTION; COMMIT;
● Para habilitar el rollback podemos añadir un
SAVEPOINT
– SAVEPOINT nombre;
– ROLLBACK TO SAVEPOINT nombre;
52
54. Irontec – Administración de MySQL
Mantenimiento de tablas
● Existen una serie de comandos que nos ayudar al
mantenimiento de las tablas
● Algunos son tienen utilidad en unos engines pero no en
otros
● Podemos:
– Chequear
– Reparar
– Analizar
– Optimizar
54
55. Irontec – Administración de MySQL
Mantenimiento de tablas
● CHECK TABLE
– Realizar un chequeo de integridad tanto de la estructura
como del contenido de los datos
– Funciona tanto en MyISAM como InnoDB
– En MyISAM además actualiza las estadísticas de los índices
● Su uso es el siguiente:
mysql > check table A;
+++++
| Table | Op | Msg_type | Msg_text |
+++++
| pruebas.A | check | status | OK |
+++++
1 row in set (0.00 sec)
55
56. Irontec – Administración de MySQL
Mantenimiento de tablas
● REPAIR TABLE
– Repara los errores que se puedan encontrar en una tabla
– Solo funciona con MyISAM
– Se puede habilitar el auto-reparado de tablas
[mysqld]
myisamrecover=[Opciones]
Default: opciones por defecto
Backup: hace backup de las tablas que tenga que
cambiar
Force: fuerza la reparación aunque se puedan
perder datos
Quick: las tablas no fragmentadas se evitan
56
57. Irontec – Administración de MySQL
Mantenimiento de tablas
● Reparación en caliente
mysql > repair table A;
+++++
| Table | Op | Msg_type | Msg_text |
+++++
| pruebas.A | repair| status | OK |
+++++
1 row in set (0.00 sec)
57
58. Irontec – Administración de MySQL
Mantenimiento de tablas
● ANALYZE TABLE
– Actualiza las tablas con información acerca de la
distribución de los valores de las claves en la tabla
– Esta información la usa el optimizador para elegir el mejor
plan de ejecución
– Solo funciona en MyISAM
mysql > analyze table A;
+++++
| Table | Op | Msg_type | Msg_text |
+++++
| pruebas.A |analyze| status | OK |
+++++
1 row in set (0.00 sec)
58
59. Irontec – Administración de MySQL
Mantenimiento de tablas
● OPTIMIZE TABLE
– Desfragmenta las tablas MyISAM, eliminando los huecos
generados por múltiples updates y deletes
– Actualiza las estadísticas de los índices
– Se puede utilizar en InnoDB, pero no desfragmenta (ya
que InnoDB no se fragmenta) Actualiza las estadísticas
de índices y libera espacio relacionado con índices
mysql > optimize table A;
+++++
| Table | Op | Msg_type | Msg_text |
+++++
| pruebas.A |optimize| status | OK |
+++++
1 row in set (0.00 sec)
59
60. Irontec – Administración de MySQL
Mantenimiento de tablas
● Existen herramientas externas de consola que también
nos pueden ayudar con el mantenimiento
– mysqlcheck
– myisamchk
● Mysqlcheck envía las sentencias SQL necesarias para
el mantenimiento. Por lo tanto, mysqld debe estár en
funcionamiento
● Myisamchk no necesita de un servidor en
funcionamiento, puede actuar directamente contra las
tablas en el sistema de ficheros
60
61. Irontec – Administración de MySQL
Mantenimiento de tablas
● Mysqlcheck nos ofrece alguna ventaja al uso de las
sentencias SQL directamente
– Podemos indicarle una BBDD para que haga operaciones
de mantenimiento en todas sus tablas en lugar de indicar
una a una
– Al ser un comando de consola, se puede crear una tarea
programada
● Ejemplo:
– Mysqlcheck test (chequea BBDD test)
– Mysqlcheck test A (chequea tabla A de la BBDD test)
– Mysqlcheck –all-databases (chequea todo)
– --check, --repair, --analyze, --optimize
61
62. Irontec – Administración de MySQL
Mantenimiento de tablas
● Myisamchk permite realizar las mismas tareas que
mysqlcheck
● Se debe hacer offline, con mysqld apagado
● Actua directamente sobre las tablas
● Es el último recurso cuando ni siquiera el servidor
arranca (por ejemplo, tablas en la BBDD mysql
corruptas)
● Como el propio nombre indica, solo funciona con
tablas MyISAM
62
64. Irontec – Administración de MySQL
Usuarios y permisos
● MySQL permite definir usuarios y decidir que pueden
hacer
● Los usuarios siguen el siguiente formato:
– 'usuario'@'host'
● No es lo mismo irontec@localhost que
irontec@10.10.0.210
● La primera parte es el nombre de usuario con el que
haremos login, mientras que la segunda será la IP desde
la cual nos conectamos
64
65. Irontec – Administración de MySQL
Usuarios y permisos
● Se puede crear un usuario que se conecta desde
cualquier ubicación:
– 'irontec'@'%'
● Los usuarios y permisos se guardan dentro de las tablas
user y grant de la BBDD mysql
● Es posible insertar datos directamente mediante la
consola de mysql, pero también es más lioso
● ¡No debe existir nunca un 'root'@'%', por seguridad!
65
66. Irontec – Administración de MySQL
Usuarios y permisos
● Para ver todos los permisos disponibles y una
descripción:
mysql > show privileges;
● Nos muestra tres columnas:
– Privilege: es el nombre del permiso
– Context: contexto en el cual es posible aplicar el permiso
– Comment: breve explicación
66
67. Irontec – Administración de MySQL
Usuarios y permisos
● Permisos especiales:
– ALL y ALL PRIVILEGES da todos los permisos excepto
GRANT OPTION
– USAGE no da ningún privilegio excepto el de conexión
67
68. Irontec – Administración de MySQL
Usuarios y permisos
● Los permisos pueden aplicarse en diferentes contextos:
– Server
– Databases
– Tables
– Functions
– Procedures
– Indexes
– File Access
● Por ejemplo, no puedes dar permisos FILE a un usuario
sobre una tabla, es un permiso global o CREATE
ROUTINE a nivel de índice
● Todos pueden aplicarse globalmente
68
69. Irontec – Administración de MySQL
Usuarios y permisos
● Para crear un usuario se debe indicar tanto el usuario
como el host y su contraseña (no obligatorio):
mysql > create user 'irontec'@'localhost'
IDENTIFIED BY '1234';
● Borrar un usuario:
mysql > drop user 'irontec'@'localhost';
● Renombrar un usuario:
mysql > rename user 'irontec'@'localhost' TO
'miguelangel'@'localhost';
69
70. Irontec – Administración de MySQL
Usuarios y permisos
● Para cambiar una contraseña hay distintas formas:
– Para un usuario en particular:
mysql > SET PASSWORD for 'miguel'@'localhost' =
PASSWORD('nueva');
– Para tu usuario:
mysql > SET PASSWORD = PASSWORD('nueva');
– Mediante GRANT:
mysql > GRANT USAGE ON *.* TO
'miguel'@'localhost' IDENTIFIED BY 'nueva';
70
71. Irontec – Administración de MySQL
Usuarios y permisos
● Para dar permisos se usa GRANT
● Importante: si el usuario al que damos permisos no
existe, lo crea
mysql > GRANT SELECT ON mysql.* TO
'miguel'@'localhost' IDENTIFIED BY 'test';
● Se pueden indicar múltiples permisos separándolos por
comas
● Para aplicar a distintos contextos:
– ON *.*
– ON db.*
– ON db.table
– ON db.routine
71
72. Irontec – Administración de MySQL
Usuarios y permisos
● Para eliminar un permiso haremos uso de REVOKE:
mysql > REVOKE SELECT ON mysql.* FROM
'miguel'@'localhost';
● El usuario seguirá existiendo, pero sin el permiso
indicado
mysql > show grants for 'miguel'@'localhost';
● Si le borramos el último permiso, USAGE, no se podrá
conectar
72
74. Irontec – Administración de MySQL
Optimización de querys
● Hay que tener especial cuidado con las querys que se
lanzan a una base de datos
● Si está mal construida puede degradar el rendimiento
del servicio
● Es necesario detectar estas querys y reescribirlas
completamente
● EXPLAIN nos ayudará a saber como se comportar
internamente una query y cuales son sus deficiencias
74
75. Irontec – Administración de MySQL
Optimización de querys
● En primer lugar debemos detectar cuales son esas
querys
● Para ello nos ayudaremos del log-slow
● En este log se irán escribiendo las sentencias SQL que
tarden un tiempo superior al que le indiquemos
● Su activación no afecta al rendimiento como otros logs
– logslowqueries=/var/log/mysql/slowquerys.log
– long_query_time=5
– Logqueriesnotusingindexes
● Log de querys lentas (superior a 5 segundos) así como
querys sin índices :)
75
76. Irontec – Administración de MySQL
Optimización de querys
● El log puede crecer con el tiempo y leerlo con un editor
de textos convertirse en un infierno
● No es necesario hacerte tu propio script, ya existen
utilidades para dumpearlo
/var/log/mysql# mysqldumpslow mysqlslow.log
● Nos resumirá las querys lentas
76
77. Irontec – Administración de MySQL
Optimización de querys
● ¿Cómo se ve en el log?
/var/log/mysql# cat mysqlslow.log
# Query_time: 4.00s Lock_time: 0 Rows_sent: 0
Rows_examined: 1380
SELECT * FROM foobar WHERE id="foo";
# Query_time: 2.50s Lock_time: 0 Rows_sent: 0
Rows_examined: 1380
SELECT * FROM foobar WHERE id="bar";
77
78. Irontec – Administración de MySQL
Optimización de querys
● Ejemplo de mysqldumpslow:
/var/log/mysql# mysqldumpslow mysqlslow.log
Count: 2 Time=4s (6.50s) Lock=0.00s (0s)
Rows=1380 (2760)
SELECT * FROM foobar WHERE id='S';
78
79. Irontec – Administración de MySQL
Optimización de querys
● Ya tenemos identificadas las querys lentas, ahora es
necesario estudiarlas
– Mysql > explain [extended] SELECT [opciones]
● Basicamente nos mostrará información del plan de
ejecución del optimizador
● Sólo funciona con SELECT
79
80. Irontec – Administración de MySQL
Optimización de querys
● Problema:
explain SELECT * from City where
CountryCode='ESP'G
*************************** 1. row
***************************
id: 1
select_type: SIMPLE
table: City
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4079
Extra: Using where
1 row in set (0.00 sec)
80
81. Irontec – Administración de MySQL
Optimización de querys
● ID: identificador de la query, en caso de tener
subquerys
● select_type: el tipo de select. Simple, primary,
derived, union, subquery
● table: indica el nombre de la tabla utilizada
● type: tipo de acceso para la query. system/const,
eq_ref, ref, ref_or_null, index_merge, range, index,
ALL
● possible_keys: lista de índices disponibles para usar
● key: índice utilizado
● key_len: número de bytes utilizados del índice
● rows: número de filas a leer
● extra: información extra de la query
81
82. Irontec – Administración de MySQL
Optimización de querys
● Type:
– system: la tabla tiene una única fila
– const: la tabla tiene una única fila coincidente con la
query
– eq_ref: la busqueda por índices da una única fila
– ref: similar a eq_ref pero puede devolver más de una fila
– ref_or_null: igual que los anteriores, pero también busca
valores NULL
– index_merge: el único tipo de acceso que usa dos
índices
– range: busqueda por rango
– index: busqueda completa por la tabla, pero de índices
en lugar de los datos
– ALL: escaneo completo de la tabla. MAL
82
83. Irontec – Administración de MySQL
Optimización de querys
● Extra:
– Using index: se está usando un index, cogiendo el dato
del índice en lugar de la tabla
– Using filesort: se ordenan las filas de forma manual en
lugar de usar índices
– Using temporary: se ha usado una tabla temporal (en
RAM o disco) para realizar la consulta
– Using where: el filtrado se hace fuera del engine
83
84. Irontec – Administración de MySQL
Optimización de querys
● Volvemos al problema :)
explain SELECT * from City where
CountryCode='ESP'G
*************************** 1. row
***************************
id: 1
select_type: SIMPLE
table: City
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4079
Extra: Using where
1 row in set (0.00 sec)
84
85. Irontec – Administración de MySQL
Optimización de querys
● El optimizador no encuentra índices
● Al no encontrar... no puede usar
● Como no hay índices, el tipo de búsqueda es ALL, se
lee todas las filas
● ¿Como podríamos mejorarlo?
– Añadiendo índices
– Optimizar la query añadiendo más detalles
● Después de cada cambio hay que comprobar si existe
mejora
85
86. Irontec – Administración de MySQL
Optimización de querys
● Añadiendo un índice:
– Mysql>alter table City add index(CountryCode);
Query OK, 4079 rows affected (0.02 sec)
Records: 4079 Duplicates: 0 Warnings: 0
● Ejecutamos de nuevo la query con explain:
id: 1
select_type: SIMPLE
table: City
type: ref
possible_keys: CountryCode
key: CountryCode
key_len: 3
ref: const
rows: 58
Extra: Using where
1 row in set (0.00 sec)
86
87. Irontec – Administración de MySQL
Optimización de querys
● Modificamos la query añadiendo más datos, haciéndola
más concisa:
– explain SELECT * from City where
CountryCode='ESP' and District='Madrid';
– alter table City add index(District);
id: 1
select_type: SIMPLE
table: City
type: index_merge
possible_keys: CountryCode,District
key: District,CountryCode
key_len: 20,3
ref: NULL
rows: 1
Extra: Using intersect(District,CountryCode);
Using where
1 row in set (0.00 sec)
87
89. Irontec – Administración de MySQL
Optimización de la base de datos
● Cuando nos referimos a optimizar la base de datos,
esto implica en primer lugar optimizar el servidor
– RAM: contra más RAM, más índices y datos en memoria,
por lo tanto más velocidad de respuesta
– CPU: nunca sobra la CPU y los cores ;)
– Disco duro: contra más rápido mejor. Últimamente se
estan empezando a usar disco SSD para bases de datos
● Una vez que tenemos el mejor equipo que podamos
comprar, tocará optimizar la base de datos de acuerdo
a dicho hardware
89
90. Irontec – Administración de MySQL
Optimización de la base de datos
● ¿32 o 64 bits?
● Siempre que sea posible es recomendable 64 bits
● En sistemas GNU/Linux y Solaris de 32 bits, un solo
proceso no puede usar más de 2GB. Por lo tanto da
igual que tengamos 4, MySQL usará la mitad
● En algunos sistemas, según un parámetro de
configuración del kernel, puede disponer de 3 GB,
pero puede ser insuficiente
● En 64 bits no existe esa limitación
● Si tienes 32 bits, no configures MySQL para que use
mas de 2GB, tendrás errores de falta de memoria
memory=key_buffer+(sort_buffer_size+read_buffer_size)*max_connections
90
91. Irontec – Administración de MySQL
Optimización de la base de datos
● Las optimizaciones también dependerán mucho del
tipo de querys que ejecutemos
● Para tener una estadística
mysql> show status like 'Com%';
91
92. Irontec – Administración de MySQL
Optimización de la base de datos
● Número máximo de conexiones (max_connections)
– Son el número máximo de conexiones simultaneas que
soportará el servidor
– Cada conexión en espera consume memoria
– Se debe ajustar a un número no muy superior a la media
de nuestro servidor
mysql> show status like '%connections%';
+++
| Variable_name | Value |
+++
| Connections | 4651724 |
| Max_used_connections | 41 |
+++
2 rows in set (0.01 sec)
92
93. Irontec – Administración de MySQL
Optimización de la base de datos
● Cache de tablas (table_cache)
– Cada vez que mysql abre una tabla mantiene en cache
información sobre ella para evitar reabrirlas
– Si se abren muchas y un usuario necesita abrir otra nueva,
una de las ya abiertas debe cerrarse
– No vale poner millones y millones, estamos limitados por
los descriptores del sistema operativo
● Si Open_tables está cercano a Table_cache y
Opened_tables no para de aumentar, toca subir el
table_cache mysql> show status like 'Open%tables%';
+++
| Variable_name | Value |
+++
| Open_tables | 1551 |
| Opened_tables | 0 |
+++
2 rows in set (0.02 sec)
93
94. Irontec – Administración de MySQL
Optimización de la base de datos
● Cacheo de índices en MyISAM (key_buffer_size)
– Cachea los índices que lee de una tabla MyISAM
– Permite reutilizar los índices en lugar de leerlos
continuamente, más rendimiento
– Para calcularlo:
Ratio de fallo: Key_reads / Key_read_requests
Eficiencia: 1 – (Key_reads / Key_read_requests)
– Los fallos tienen que estar lo más cerca posible de 0 y
eficiencia de 1
mysql> show status like 'Key_read%';
+++
| Variable_name | Value |
+++
| Key_read_requests | 150683856 |
| Key_reads | 325197 |
+++
2 rows in set (0.01 sec)
94
95. Irontec – Administración de MySQL
Optimización de la base de datos
● Buffer de InnoDB (innodb_buffer_pool_size)
– Cache tanto los índices como los datos de una tabla
InnoDB
– El valor por defecto es 8 megas, pero se recomienda entre
el 50% y 80% de la memoria total del sistema
mysql> show variables like
'innodb_buffer_pool_size';
+++
| Variable_name | Value |
+++
| innodb_buffer_pool_size | 838860800 |
+++
1 row in set (0.00 sec)
95
96. Irontec – Administración de MySQL
Optimización de la base de datos
● Cacheo de querys (query_cache_size)
– Nos permite almacenar en cache el resultado de una query
select
– La cache solo se mantiene mientras los datos de la tabla no
se modifiquen
● query_cache_type: OFF desactivado, ON activado,
DEMAND solo para SELECT SQL_CACHE
● query_cache_size: 0 es desactivado
● query_cache_limit: el tamaño máximo de una query
que se puede almacenar
96
97. Irontec – Administración de MySQL
Optimización de la base de datos
● Midiendo la efectividad de la cache:
– Qcache_hits: numero de querys que no se han
ejecutado por estar en cache
– Qcache_inserts: el número total de querys guardadas en
la cache
– Qcache_lowmem_prunes: número de caches
eliminadas por falta de memoria
● Si hits es bajo e inserts alto... hay que aumentar la
caché
97
98. Irontec – Administración de MySQL
Optimización de la base de datos
● Otros valores:
– read_buffer_size: cuando se lee una tabla lo leerá en
bloques del tamaño que aquí indiquemos. Contra mas
grande, más rápido la leerá
– read_rnd_buffer_size: por defecto coge el valor del
anterior. Se usa para lecturas no secuenciales (como las
requeridas por ORDER BY)
– sort_buffer_size: para las operaciones con ORDER o
GROUP BY
– join_buffer_size: para querys con joins
98
100. Irontec – Administración de MySQL
Optimización de tablas
● Si las tablas aumentan mucho puede llegar un
momento en el que los índices ocupen más que la
propia RAM del sistema
ÍNDICES
RAM
100
102. Irontec – Administración de MySQL
Optimización de tablas
● Si no queremos comprar más RAM, los índices se
vuelven lentos
● Particionar se vuelve más rápido que los índices
● Será nuestra salvación cuando:
– Nos quedemos sin RAM
– Tenemos muchísimos datos
– Guardamos datos históricos
– Rotamos datos
– Datos crecientes
Es transparente, no tendremos que modificar las
aplicaciones
102
103. Irontec – Administración de MySQL
Optimización de tablas
● Cosas a tener en cuenta antes de particionar:
– La columna que utilicemos para definir el rango de las
particiones debe ser un INT, no se acepta cualquier otro
valor
– Si tenemos una clave única o una primary key, esta debe
usarse para particionar
– Como máximo se permiten 1024 particiones
– No se permiten claves externas
– No se permiten búsquedas FULL TEXT
103
104. Irontec – Administración de MySQL
Optimización de tablas
● El particionado se puede hacer:
– Por rango: es el más sencillo, se divide en base a rangos
– Por listas: se divide en particiones en base a una lista de
posibles valores
– Por hash: nos permite dividir los datos de forma
equitativa entre todas las particiones. La expresión por la
que separar los datos debe devolver un entero
– Por key: similar a hash. En lugar de indicar nosotros el
valor del hash, lo hace el propio MySQL con md5 y
password(). Pueden usarse columnas que no sean entero
104
105. Irontec – Administración de MySQL
Optimización de tablas
CREATE TABLE employees (
id INT NOT NULL,
fname VARCHAR(30),
lname VARCHAR(30),
hired DATE NOT NULL DEFAULT '19700101',
separated DATE NOT NULL DEFAULT '999912
31',
job_code INT NOT NULL,
store_id INT NOT NULL
)
PARTITION BY RANGE (store_id) (
PARTITION p0 VALUES LESS THAN (6),
PARTITION p1 VALUES LESS THAN (11),
PARTITION p2 VALUES LESS THAN (16),
PARTITION p3 VALUES LESS THAN (21),
PARTITION p3 VALUES LESS THAN MAXVALUE
);
105
106. Irontec – Administración de MySQL
Optimización de tablas
CREATE TABLE employees (
id INT NOT NULL,
fname VARCHAR(30),
lname VARCHAR(30),
hired DATE NOT NULL DEFAULT '19700101',
separated DATE NOT NULL DEFAULT '999912
31',
job_code INT,
store_id INT
)
PARTITION BY LIST(store_id) (
PARTITION pNorth VALUES IN (3,5,6,9,17),
PARTITION pEast VALUES IN
(1,2,10,11,19,20),
PARTITION pWest VALUES IN
(4,12,13,14,18),
PARTITION pCentral VALUES IN (7,8,15,16)
);
106
107. Irontec – Administración de MySQL
Optimización de tablas
CREATE TABLE employees (
id INT NOT NULL,
fname VARCHAR(30),
lname VARCHAR(30),
hired DATE NOT NULL DEFAULT '197001
01',
separated DATE NOT NULL DEFAULT
'99991231',
job_code INT,
store_id INT
)
PARTITION BY HASH( YEAR(hired) )
PARTITIONS 4;
107
108. Irontec – Administración de MySQL
Optimización de tablas
CREATE TABLE Employee (
emp_id INT,
fname VARCHAR(50),
lname VARCHAR(50),
store_id TINYINT
) ENGINE=MyISAM
PARTITION BY KEY (lname)
PARTITIONS 4;
108
109. Irontec – Administración de MySQL
Optimización de tablas
● Existe un script que nos permite crearnos la query de
creación de particiones
http://forge.mysql.com/wiki/Partition_Helper
./partitions_helper table=mytable column=d
interval=year start=20040101 –end=20090101
./partitions_helper table=mytable column=d
interval=month start=20080101 end=20090101
./partitions_helper table=mytable –column=prod_id
interval=1000 start=1 –end=10000
109
110. Irontec – Administración de MySQL
Optimización de tablas
● Para comprobar si las particiones funcionan y en que
partición se encuentran nuestros datos:
mysql [localhost] {msandbox} (employees) > explain
partitions select count(*) from salaries
where from_date between '20000101' and '20001231'G
*************************** 1. row
***************************
id: 1
select_type: SIMPLE
table: salaries
partitions: p016
type: index
possible_keys: NULL
key: emp_no
key_len: 4
ref: NULL
rows: 2830488
Extra: Using where; Using index
1 row in set (0.00 sec)
110
111. Irontec – Administración de MySQL
Optimización de tablas
● Mantenimiento de tablas RANGE y LIST
– Se pueden añadir más particiones
ALTER TABLE gente ADD PARTITION (PARTITION p4 VALUES
LESS THAN (2010));
– Se pueden eliminar particiones (borra datos)
ALTER TABLE gente DROP PARTITION p4
– Se reorganizar particiones
ALTER TABLE gente REORGANIZE PARTITION p0 INTO (
PARTITION s0 VALUES LESS THAN (1960),
PARTITION s1 VALUES LESS THAN (1970)
);
111
112. Irontec – Administración de MySQL
Optimización de tablas
● Mantenimiento de tablas HASH y KEY
– Se pueden añadir más particiones
ALTER TABLE gente ADD PARTITION PARTITIONS 2;
– Se pueden reducir el número de particiones, DROP no
funciona
ALTER TABLE gente COALESCALE PARTITION 2;
● Las particiones HASH o KEY se auto reorganizan según
añadamos o eliminemos particiones
112
113. Irontec – Administración de MySQL
Optimización de tablas
● Reconstruir partición:
– Borrar los datos de la partición para volver a insertarlos. De
esta forma solucionas el problema de fragmentado
● Optimizar partición:
– Otra forma de solucionar la fragmentación. Reclama el
espacio libre y reorganiza los datos
● Analizar partición:
– Lee y almacena la distribución de índices
● Reparar partición:
– Repara particiones corruptas
● Chequear partición:
– Chequea una partición en busca de errores
113
114. Irontec – Administración de MySQL
Optimización de tablas
ALTER TABLE gente REBUILD PARTITION p1;
ALTER TABLE gente OPTIMIZE PARTITION p1;
ALTER TABLE gente ANALYZE PARTITION p1;
ALTER TABLE gente REPAIR PARTITION p1;
ALTER TABLE gente CHECK PARTITION p1;
114
116. Irontec – Administración de MySQL
Logs
● En MySQL tenemos 3 tipos de logs
– Slow: guardan las querys lentas
– Sql: guarda todas las querys que se ha recibido el servidor
– Binlog: guarda únicamente las querys que modifican
datos
● ¿Para que nos pueden servir?
– Arreglar querys lentas o sin índices
– Debuggear a nivel SQL nuestra aplicación
– Replicación o recuperación de backup
116
118. Irontec – Administración de MySQL
Logs
● SQL log almacena todas las querys que llegan a
nuestro servidor
● Se puede usar para debuggear nuestra aplicación antes
de pasarla a producción
● En producción no es recomendable tenerlo habilitado,
consume muchos recusos tanto de CPU como de disco
duro
● Si este log está activado, el logrotate debe estar
habilitado
log=/var/log/mysql/mysql.log
118
119. Irontec – Administración de MySQL
Logs
● Los logs binarios almacenan los cambios que se realizan
en la BBDD (update, insert, delete, alter, etc.)
● Nos sirven para:
– Recuperación de backup
– Replicación
● Es recomendable tenerlos habilitados, no consumen
mucho y nos pueden salvar la vida
● En caso de replicación es obligatorio tenerlos
habilitados
119
120. Irontec – Administración de MySQL
Logs
● Otras opciones:
– max_binlog_size (por defecto y máximo 1 GB)
– expire_logs_days
– sync_binlog (>0)
– replicate-do-db
– replicate-ignore-db
– binlog-do-db
– binlog-ignore-db
– replicate-do-table
– replicate-wild-do-table
– replicate-ignore-table
– replicate-wild-ignore-table
120
122. Irontec – Administración de MySQL
Logs
● El diagrama para el logeo de tablas es demasiado
grande y no entra ;)
http://dev.mysql.com/doc/refman/5.0/en/replication-rules-table-options.html
● Para rellenar la diapositiva pondré un dibujo:
No se quien es el autor :(
122
124. Irontec – Administración de MySQL
Arquitecturas de replicación
● Tenemos varias formas de montar una arquitectura de
replicación.
– Maestro-Maestro
– Maestro-Esclavo
– Circular
● Según lo que se necesite, se monta una u otra.
124
125. Irontec – Administración de MySQL
Limitaciones
● Un esclavo solo puede tener un maestro. Por el
contrario, un maestro múltiples esclavos.
● No es recomendable montar una replicación por WAN.
La replicación es asíncrona y sensible a latencias.
● En un servidor esclavo esta prohibido escribir datos,
solo se usarán selects.
125
126. Irontec – Administración de MySQL
Maestro-Esclavo
● Un maestro, múltiples esclavos.
● En el maestro se escribe, en el esclavo se lee.
126
127. Irontec – Administración de MySQL
Maestro-Esclavo
● Primero debemos configurar el maestro.
Imprescindible:
– Habilitar los logs binarios.
– Crear un usuario que permita conectarse a los esclavos.
– Habilitar sync_binlog.
– Elegir un server-id.
logbin=mysqlbin
serverid=1
sync_binlog=1
127
128. Irontec – Administración de MySQL
Maestro-Esclavo
● Dar permisos de conexión a los eslavos y dumpeamos
la BD:
mysqldump BD masterdata=2 > dump_file;
mysql> grant replication slave on *.* to
'replication'@10.10.10.1 identified by 'slave';
mysql> grant replication slave on *.* to
'replication'@10.10.10.2 identified by 'slave';
128
129. Irontec – Administración de MySQL
Maestro-Esclavo
● Configuramos el eslavo:
– Seleccionamos un ID diferente para cada uno.
– Importamos la BD.
– Nos configuramos como esclavo de un maestro.
$mysql u root p < dump
serverid=101
mysql> CHANGE MASTER TO MASTER_HOST = ‘10.10.10.100’,
MASTER_USER = ‘replication’, MASTER_PASSWORD = ‘slave’,
MASTER_LOG_FILE = ‘master_log_file’, MASTER_LOG_POS =
master_log_pos;
129
130. Irontec – Administración de MySQL
Maestro-Esclavo
● Master_log_pos y Master_log_file indican al esclavo
desde que posición del log binario deben leer, de
forma que no se repliquen datos que ya tenemos.
● Podemos sacarlo con un dump como ya hemos visto o
con el comando show master status;
● El log binario debe estár habilitado :)
130
131. Irontec – Administración de MySQL
Maestro-Esclavo
● No se debe dejar al servidor la elección de cuando
escribir los datos al disco duro.
● Si el servidor se cae sin que algunos datos se escriban
en el log, es posible que estos se pierdan (dependerá
del sistema de ficheros).
● sync_binlog por defecto es 0, que deja que el servidor
decida cuando realizar la escritura al disco.
● Se recomienda un valor de 1, para que se fuerce la
escritura.
● Esto también es lento, dependerá de los discos duros
instalados.
● Si el servidor se cae, como mucho perderemos una
transacción. 131
132. Irontec – Administración de MySQL
Maestro-Esclavo
● Para comprobar si la replicación es correcta tenemos el
comando show slave status.
● Este nos tiene que mostrar lo siguiente:
[...]
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
[...]
Seconds_Behind_Master: 0
Slave_IO_Running: Se encarga de conectarse al
maestro para comprobar cambios
Slave_SQL_Running: Se encarga de escribir las
sentencias SQL.
Seconds_Behind_Master: El lag en segundos entre
el maestro y el esclavo.
132
133. Irontec – Administración de MySQL
Maestro-Maestro
● Lo que se escribe en uno se replica en el otro.
● Se puede escribir en los dos.
133
134. Irontec – Administración de MySQL
Maestro-Maestro
● La arquitectura maestro-maestro es igual a la maestro
esclavo.
● Aquí los hosts realizan las dos tareas, maestro y esclavo
al mismo tiempo.
● Esta arquitectura soporta como máximo dos hosts, ya
que un esclavo solo puede tener como máximo un
maestro.
A es maestro de B. B es maestro de A.
A es esclavo de B. B es esclavo de A.
134
135. Irontec – Administración de MySQL
Maestro-Maestro
● Se debe tener en cuenta, al igual que antes, lo
siguiente:
– Habilitar el log binario.
– Seleccionar un server-id.
– Establecer el valor de sync_binlog.
– Crear los usuarios para la replicación.
● El funcionamiento, opciones, monitorización, etc. es
todo igual.
135
136. Irontec – Administración de MySQL
Maestro-Maestro
● Los auto-incrementales son el gran problema de este
tipo de arquitectura. Si se realizan dos insert al mismo
tiempo que incluya un campo autoincremental,
podemos tener un problema de ID duplicado.
● A envía a B un artículo cuyo ID autoincremental es
3000, B envía un artículo diferente a A cuyo
autoincremental es 3000 también. La replicación se
rompe.
– auto_increment_increment = 2
– auto_increment_offset = 1
● ¿Cómo sería para el server B?
136
137. Irontec – Administración de MySQL
Circular
● Lo que se escribe en uno se replica en el siguiente, este
en el siguiente, este en... A → B → C → D → A
● Es la menos recomendable. En realidad está casi
prohibida también ;)
137
138. Irontec – Administración de MySQL
Circular
● Es una forma de disponer de más de dos servidores en
arquitectura maestro-maestro.
● Contra más sean los hosts implicados, mayor el caos de
su administración.
A→B→C→D→E→A
● Si el host C se cae (por ejemplo) la replicación se
rompe. Lo escrito en B no se replica, lo escrito en D se
replica en todos menos en C, etc.
● Si se cae por ejemplo B y D, el caos es infinito. La
solución es salir corriendo.
● A no ser que no exista otra solución, no se
recomienda.
138
139. Irontec – Administración de MySQL
Circular
● Los logs que reciben los esclavos, deben logearlos en el
log binario para enviarselo al siguiente en la cadena.
Esto no es el funcionamiento por defecto, los que se
recibe como esclavo no se logea. Para cambiarlo:
– logslaveupdates
● En algún momento de la cadena nos llegarán nuestros
propios logs. Para evitar formar un bucle:
– Replicatesameserverid=0
● También habrá que tener cuidado con los auto-
incrementales:
– auto_increment_increment=4
– auto_increment_offset=1
139
141. Irontec – Administración de MySQL
Replicación rota
● Es recomendable tener el error-log habilitado, ahí se
guardará, entre otras cosas, cualquier error relacionado
con la replicación.
● ¡EJEMPLO!
Sep 11 11:13:16 test2 mysqld[6776]: 090911 11:13:16
[ERROR] Slave: Error 'Table 't' already exists' on
query. Default database: 'mysql'. Query: 'CREATE
TABLE t (c CHAR(20) CHARACTER SET utf8 COLLATE
utf8_bin)', Error_code: 1050
Sep 11 11:13:16 test2 mysqld[6776]: 090911 11:13:16
[ERROR] Error running query, slave SQL thread
aborted. Fix the problem, and restart the slave SQL
thread with "SLAVE START". We stopped at log 'mysql
bin.000003' position 421
141
142. Irontec – Administración de MySQL
Replicación rota
● Forma rápida y no tan buena de solucionarlo:
● Decirle al esclavo que ignore esa query y continue con
la replicación:
mysql> stop slave; Query OK, 0 rows affected (0.00
sec)
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; Query
OK, 0 rows affected (0.00 sec)
mysql> start slave;
142
143. Irontec – Administración de MySQL
Replicación rota
● Forma buena de solucionarlo:
http://www.maatkit.org/
● Maatkit makes MySQL easier to manage.
● Lo de “easier” ponedlo entre muchas comillas.
● Son una colección de herramientas que nos puede
ayudar en la administración de nuestro servidores, y en
este caso en particular, en rescatar una replicación.
● Todas las utilidades:
http://www.maatkit.org/doc/
143
144. Irontec – Administración de MySQL
Replicación rota
● Para saber si dos tables están sincronizadas, podemos
sacar un checksum de estas y comparar:
– mktablechecksum
● Para sincronizar los datos de dos tablas:
– mktablesync
$ mktablechecksum h=host1,u=user,p=password h=host2
$ mktablesync –execute
u=user,p=pass,h=host1,D=db,t=tbl host2
144
145. Irontec – Administración de MySQL
MMM
● Cuando ya sabemos que queremos y lo montamos,
llega el mantenimiento.
● Si tenemos un cluster de, por ejemplo, 2 maestros y 50
esclavos, comprobar el correcto funcionamiento es
complicado.
● ¿Y si deseamos parar algún esclavo?
● ¿Y si deseamos parar algún maestro?
● Es necesario reducir el tiempo de parada de
servicio al mínimo.
145
147. Irontec – Administración de MySQL
MMM
● También el Perl. El mundo se ha vuelto loco...
● Características:
– Monitorización de la replicación
– Monitorización de los hosts
– Gestión del failover
– Balanceo de IPs entre nodos
– Gestión de grupos de escritura/lectura
147
148. Irontec – Administración de MySQL
MMM
● La alta disponibilidad se hace mediante el balanceo de
Ips virtuales que saltarán de un servidor a otro en caso
de ser necesario.
– Exclusivo: Una única IP para muchos hosts. Si el host que
la tiene se cae se balancea a otro. Generalmente se usa
en los nodos de escritura.
– Balanceado: Una IP por cada host. Si uno de los hosts se
cae la IP se balancea a cualquier otro, pasando a tener
dos IPs virtuales. Se usa para nodos en lectura.
148
149. Irontec – Administración de MySQL
MMM
● Se pueden meter los servidores dentro de dos roles,
escritura y lectura. Escritura es obligatorio, mientras que
el de lectura no tiene porque definirse.
● La diferencia es lógica:
– Nodos de escritura son aquellos en los que los datos se
escribirán.
– Nodos de lectura son aquellos de los cuales se leerán
datos.
● Escritura (maestro) – Lectura (esclavo)
149
150. Irontec – Administración de MySQL
MMM
http://mysql-mmm.org/
● En el sistema de control se instalará:
– mysql-mmm-common_2.0.10-1_all.deb
– mysql-mmm-monitor_2.0.10-1_all.deb
● En los nodos:
– mysql-mmm-common_2.0.10-1_all.deb
– mysql-mmm-agent_2.0.10-1_all.deb
● ¡Junto con todas las dependencias!
150
151. Irontec – Administración de MySQL
MMM
● Los ficheros de configuración se guardan en /etc/mysql-
mmm
● Todos tendrán un fichero llamado
mmm_common.conf que será exactamente igual.
● El nodo de control mmm_mon.conf
● Los servidores de MySQL mmm_agent.conf
151
152. Irontec – Administración de MySQL
MMM
● mmm_common.conf
● Incluye la configuración de:
– Los Hosts
– Sus Ips
– Los roles
– Usuario/Contraseña del agente
– Usuario/Contraseña para la replicación
– La interfaz de red en la que se trabaja
152
153. Irontec – Administración de MySQL
MMM
● mmm_mon.conf
● Incluye la configuración de:
– Usuario/Contraseña para la monitorización
– Ips a las que pingar
– Ruta de los binarios
– Ruta del PID
– Nivel de debug
153
154. Irontec – Administración de MySQL
MMM
● mmm_agent
● Incluye la configuración de:
– El nombre de este servidor
– Todo el mmm_common.conf
– Y nada más :P
154
155. Irontec – Administración de MySQL
MMM
● Como hemos visto, hay varios usuarios y contraseñas
definidos. Hay que crerlos en MySQL.
GRANT REPLICATION CLIENT ON *.* TO 'mmm_monitor'@'10.100.1.%'
IDENTIFIED BY 'RepMonitor';
GRANT SUPER, REPLICATION CLIENT, PROCESS ON *.* TO
'mmm_agent'@'10.100.1.%' IDENTIFIED BY 'RepAgent';
GRANT REPLICATION SLAVE ON *.* TO 'replication'@'10.100.1.%'
IDENTIFIED BY 'slave';
– El usuario monitor se usa para comprobar el estado de los
servidores Mysql.
– El usuario agent se usa para cambiar el read only mode,
poner offline un equipo, ejecutar un change_master, etc.
– El usuario replication slave... para replicación ;)
155
156. Irontec – Administración de MySQL
MMM
● Una vez puesto en marcha los servicios, se deben
poner online los servidores desde el comando de
control.
MMM:~# mmm_control show
db1(10.100.1.1) master/AWAITING_RECOVERY. Roles:
db2(10.100.1.2) master/AWAITING_RECOVERY. Roles:
db3(10.100.1.3) slave/AWAITING_RECOVERY. Roles:
db4(10.100.1.4) slave/AWAITING_RECOVERY. Roles:
MMM:~# mmm_control set_online db1
OK: State of 'db1' changed to ONLINE. Now you can wait
some time and check its new roles!
MMM:~# mmm_control set_online db2
OK: State of 'db2' changed to ONLINE. Now you can wait
some time and check its new roles!
MMM:~# mmm_control set_online db3
OK: State of 'db3' changed to ONLINE. Now you can wait
some time and check its new roles!
MMM:~# mmm_control set_online db4
OK: State of 'db4' changed to ONLINE. Now you can wait
some time and check its new roles!
156
157. Irontec – Administración de MySQL
MMM
● ¡Ejemplo! Parando un servidor en producción:
MMM:~# mmm_control set_offline db1
OK: State of 'db1' changed to ADMIN_OFFLINE. Now you can
wait some time and check all roles!
MMM:~# mmm_control show
db1(10.100.1.1) master/ADMIN_OFFLINE. Roles:
db2(10.100.1.2) master/ONLINE. Roles:
writer(10.100.1.10)
db3(10.100.1.3) slave/ONLINE. Roles: reader(10.100.1.12)
db4(10.100.1.4) slave/ONLINE. Roles: reader(10.100.1.11)
157
159. Irontec – Administración de MySQL
MySQL Proxy
● El balanceo de carga se puede hacer bien por hardware
como por software.
● Existe un software creado para MySQL que nos puede
“ayudar”.
● Para que te ayude debes saber LUA.
http://forge.mysql.com/wiki/MySQL_Proxy
● Es un proxy que se pone entre el cliente y los servidores
de MySQL.
159
160. Irontec – Administración de MySQL
MySQL Proxy
● Trae scripts de ejemplo, que entre otras cosas te
permite:
– Reescribir queries.
– Balanceo de carga.
– Loggeo avanzado.
– Failover.
– Análisis de queries.
160
161. Irontec – Administración de MySQL
MySQL Proxy
● La instalación es sencilla, descargamos de:
– http://dev.mysql.com/downloads/mysql-proxy/
● Descomprimimos en:
– /usr/local/mysql-proxy
● Tenemos el binario en bin
● Tenemos scripts de ejemplo en share/doc/mysql-proxy/
161