Sei sulla pagina 1di 140

BD3: Dise˜no F´ısico - MySQL

Bases de Datos III Dise˜no F´ısico - MySQL Enxe˜nar´ıa Inform´atica Curso 2013/2014

Miguel R. Luaces Laboratorio de Bases de Datos Universidade da Coru˜na

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

Universidade da Coru˜na Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

Contenidos

1 Introducci´on a MySQL

2 Replicaci´on

3 Copia de seguridad y recuperaci´on

4 Medici´on de rendimiento y perfilado Medici´on del rendimiento Perfilado de aplicaciones

5 Optimizaci´on Optimizaci´on de esquemas e ´ındices Optimizaci´on de hw. y sw. Optimizaci´on del servidor

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

del servidor Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Contenidos

1

Introducci´on a MySQL

2

Replicaci´on

3

Copia de seguridad y recuperaci´on

4

Medici´on de rendimiento y perfilado Medici´on del rendimiento Perfilado de aplicaciones

5

Optimizaci´on Optimizaci´on de esquemas e ´ındices Optimizaci´on de hw. y sw. Optimizaci´on del servidor

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

del servidor Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

MySQL Community Server

Versi´on actual: 5.6.17

Documentaci´on: http://dev.mysql.com/doc/

Funciona sobre todas las plataformas: Mac OS X, Windows, GNU/Linux, Solaris, FreeBSD

Punto diferenciador: arquitectura diferente a otros SGBDs Orientado a entornos de gran demanda (ej.: aplicaciones web)

OLTP Aplicaciones incrustadas Data warehouse Indexado de contenido

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

Indexado de contenido Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

MariaDB

An enhanced, drop-in replacement for MySQL

Versi´on actual: 5.5.36

Documentaci´on: https://kb.askmonty.org/en/

Funciona sobre todas las plataformas: Mac OS X, Windows, GNU/Linux Mejoras sobre MySQL 5.5:

M´as motores de almacenamiento (ej.: No-SQL) Optimizaciones Extensiones (ej.: virtual columns) Completamente Open Source

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

Open Source Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Arquitectura de MySQL

Clientes

API del motor de

almacenamiento

Conexión / Control de subprocesos Caché de Analizador consultas sintáctico optimizador
Conexión / Control de subprocesos
Caché de
Analizador
consultas
sintáctico
optimizador

(“Iniciar transacción”,

“recuperar registro con

clave x”)

transacción”, “recuperar registro con clave x” ) Motores de almacenamiento Enxe˜nar´ıa Inform´atica

Motores de almacenamiento

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

de almacenamiento Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Arquitectura de MySQL

Cada consulta es atendida por un thread del pool servidor

La cach´e consultas almacena sentencias select junto con su resultado Si la consulta no est´a en cach´e, tras el an´alisis sint´actico, se realiza la optimizaci´on del plan de ejecuci´on

Reescritura de la consulta Determinaci´on del orden de acceso a las tablas Selecci´on de los ´ındices a utilizar Inclusi´on de las caracter´ısticas espec´ıficas de los motores de almacenamiento

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

de almacenamiento Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Arquitectura de MySQL

Caracter´ıstica unica:´

procesamiento de consultas, optimizaci´on) de tareas de almacenamiento y recuperaci´on de datos

Se puede elegir el motor de almacenamiento a nivel de tabla

Se pueden cargar motores de almacenamiento en tiempo de ejecuci´on Describiremos brevemente los siguientes aspectos de MySQL:

separaci´on de tareas de servidor (conexiones,

Control de concurrencia Gesti´on de transacciones Motores de almacenamiento Criterios de selecci´on

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

Criterios de selecci´on Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Control de concurrencia

Los bloqueos permiten evitar que un cliente lea un fragmento de datos mientras otro lo est´a cambiando

Hay dos tipos de bloqueos: compartidos (lectura) y exclusivos (escritura)

Los SGBD permiten distintas granularidades a los bloqueos (tabla, p´agina o fila)

Los bloqueos de fila minimizan la cantidad de datos por lo que aumenta la concurrencia

Los bloqueos de tabla minimizan el consumo de memoria por lo que aumenta el rendimiento

Cada motor de almacenamiento de MySQL define su propia pol´ıtica y granularidad. El servidor no es consciente de los bloqueos.

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

de los bloqueos. Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Control de concurrencia

MyISAM, Memory y Merge realizan bloqueos a nivel de tabla

Cada motor lo implementa a su modo con optimizaciones para mejorar el rendimiento Necesita muy poca memoria Ideal en el caso de que las lecturas sean mucho m´as frecuentes que las modificaciones Es eficiente en el caso de modificaciones simult´aneas en varias filas

InnoDB realiza bloqueos a nivel de fila

Permite la m´axima concurrencia a costa de mayor consumo de memoria Ideal en el caso de cambios frecuentes o transacciones largas Es muy eficiente en el caso de cancelaci´on de transacciones

El servidor de MySQL puede bloquear tablas independiente del motor para garantizar correcci´on de sentencias DDL como ALTER TABLE

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

DDL como ALTER TABLE Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Gesti´on de transacciones

MySQL incluye motores transaccionales (InnoDB) y no transaccionales (MyISAM, Memory) El est´andar SQL define cuatro niveles de aislamiento:

Read uncommited

Read commited

Repeatable read

Serializable

Las figuras de las siguientes diapositivas se extrajeron de aqu´ı:

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Gesti´on de transacciones

Read uncommited

No hay bloqueos, por lo que una transacci´on lee datos sin confirmar de otra transacci´on Permite lecturas sucias porque la segunda transacci´on podr´ıa ser cancelada

Enxe˜nar´ıa Inform´atica

podr´ıa ser cancelada Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

podr´ıa ser cancelada Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Gesti´on de transacciones

Read commited

Los bloqueos de escritura se mantienen hasta el fin de la transacci´on Los de lectura se liberan al finalizar la lectura Una transacci´on s´olo lee datos de transacciones confirmadas Permite lecturas no-repetibles porque los datos podr´ıan cambiar despu´es de leidos

Enxe˜nar´ıa Inform´atica

cambiar despu´es de leidos Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

despu´es de leidos Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Gesti´on de transacciones

Repeatable read

Todos los bloqueos se mantienen durante toda la transacci´on Cualquier fila que lea una transacci´on ser´a igual en sucesivas lecturas Como no hay bloqueo de rangos, permite lecturas fantasma Es la predeterminada en InnoDB

Enxe˜nar´ıa Inform´atica

Es la predeterminada en InnoDB Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

en InnoDB Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Gesti´on de transacciones

Serializable

Aislamiento completo de las transacciones usando bloqueos de rango. InnoDB permite el nivel de aislamiento serializable mediante Multiversion Concurrency Control (MVCC)

Mantiene instant´aneas de los datos tal y como exist´ıan en un determinado momento Diferentes transacciones ven simult´aneamente datos distintos en las mismas tablas Evita la necesidad de bloquear filas en modo lectura

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

filas en modo lectura Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Gesti´on de transacciones

Interbloqueos (Deadlocks)

El funcionamiento de los bloqueos es espec´ıfico del motor de almacenamiento Los interbloqueos son inevitables ya que ocurren por conflictos reales en las transacciones Los interbloqueos producen consultas lentas o que sobrepasan tiempo m´aximo La soluci´on consiste en reanudar alguna de las transacciones InnoDB detecta dependencias circulares y reanuda la transacci´on con los bloqueos de fila menos exclusivos

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

fila menos exclusivos Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Gesti´on de transacciones

Registro de transacciones (Write-ahead logging)

El almacenamiento inmediato de los cambios en los datos es lento Los cambios realizan en la copia en memoria de la p´agina de disco El almacenamiento en disco se realiza mediante un registro de transacciones usando escritura secuencial (y por tanto, r´apida) Los datos en disco se escriben cuando la p´agina se elimina de memoria En caso de fallo del servidor, los cambios se pueden recuperar

Uso de varios motores de almacenamiento en transacciones

Cada motor de almacenamiento gestiona el funcionamiento de las transacciones No se pueden combinar de forma fiable motores de almacenamiento diferentes en una transacci´on Por ejemplo, los cambios en tablas MyISAM no se pueden deshacer con un rollback MySQL no informa del error de ninguna manera

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

error de ninguna manera Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Motores de almacenamiento: MyISAM

Motor predeterminado para las tablas hasta MySQL 5.1

No soporta transacciones ni claves for´aneas, y s´olo permite bloqueos a nivel de tabla

El tama˜no m´aximo de una tabla es 256 TB

Cada tabla se almacena en un fichero del sistema operativo Variantes:

Tablas con filas de tama˜no fijo (est´aticas) y tama˜no variable (din´amicas) Tablas comprimidas y de s´olo lectura

El espacio usado en disco es m´ınimo

´

Optimo para soportes de s´olo lectura y/o lentos

Se construyen con la utilidad myisampack

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

la utilidad myisampack Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Motores de almacenamiento: InnoDB

Motor predeterminado para las tablas desde MySQL 5.5 Soporta transacciones, claves for´aneasy bloqueos a nivel de fila El tama˜no m´aximo de una tabla es 64 TB

Las tablas se almacenan en archivos de datos administrados por el

motor y que pueden utilizar particiones raw

´

Indices agrupados (clustered indexes)

Se crea un ´ındice para la clave principal de la tabla que se almacena en las mismas p´aginas que las filas Las b´usquedas por clave principal son r´apidas porque ahorran un acceso a disco Los ´ındices secundarios (todos los dem´as) siempre incluyen los atributos de la clave principal para usar el ´ındice agrupado en las b´usquedas

Inconvenientes:

Tiene problemas de escalabilidad debido al soporte transaccional Cambios en la estructura de las tablas implican copiar todos los datos y recrear los ´ındices

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

y recrear los ´ındices Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Motores de almacenamiento: Memory

Tablas que se guardan en la memoria del servidor y que no permiten la persistencia

No soportan transacciones ni claves for´aneas. Los bloqueos son a nivel de tabla

El tama˜no m´aximo de una tabla depende de la memoria del servidor

Permite un acceso muy r´apido a los datos (un orden de magnitud m´as r´apido que el motor MyISAM)

El espacio ocupado por una tabla s´olo se devuelve al borrar o recrear la tabla Ejemplos de posibles usos:

Tablas de b´usqueda r´apida (i.e. c´odigos postales) Guardar en cach´e datos agregados peri´odicamente Resultados intermedios de procesos MySQL lo usa para procesar consultas que necesitan tablas temporales

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

tablas temporales Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Motores de almacenamiento: otros

Motor Merge

Combinaci´on de varias tablas MyISAM en una unica´

Permite la partici´on de informaci´on en diferentes bloques Posibles usos: gesti´on de archivos de log, superar la limitaci´on de tama˜no de archivo del SO

tabla virtual

Motor Blackhole

No almacena datos. Todas las inserciones se descartan Mantiene un registro de operaciones realizadas Posibles usos: auditor´ıa, algunas configuraciones de replicaci´on

Motor CSV

Tablas creadas sobre archivos con valores separados por comas (comma-separated values) No admite ´ındices Posibles usos: intercambio de datos con aplicaciones externas

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

aplicaciones externas Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Motores de almacenamiento: selecci´on

Dado que podemos elegir el motor de almacenamiento para cada tabla, necesitamos conocer c´omo se va a utilizar cada tabla, c´omo funciona la aplicaci´on, y su evoluci´on potencial En funci´on del uso de transacciones:

Si la aplicaci´on requiere transacciones, la unica´

Si no requieren transacciones y las consultas son SELECT e INSERT, MyISAM es buena opci´on

opci´on es InnoDB

En funci´on de la concurrencia en las operaciones:

Depende de la carga de trabajo esperada Si s´olo hay inserciones y lecturas: MyISAM Si queremos una mezcla de operaciones concurrentes sin interferencia, necesitamos un motor con bloqueo a nivel de fila (InnoDB)

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

de fila ( InnoDB ) Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Motores de almacenamiento: selecci´on

En funci´on de las copias de seguridad:

Algunos motores (InnoDB) no permiten la copia de seguridad con el SGBD on-line Si se puede detener el servidor: cualquier motor. El uso de m´ultiples motores complica el proceso de copia de seguridad

En funci´on de la necesidad de operaciones especiales:

S´olo InnoDB incluye ´ındices agrupados y optimizaciones basadas en ellos

InnoDB s´olo permite b´usquedas de texto completo desde la versi´on

5.6.4

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

desde la versi´on 5.6.4 Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Motores de almacenamiento: cambios

M´etodos para el cambio de motor de almacenamiento de tablas

Mediante la sentencia ALTER TABLE Realizando una copia de seguridad, y editando el fichero de volcado Creando una nueva tabla e insertando los datos mediante una sentencia INSERT INTO

En todos los casos, las opciones espec´ıficas del motor de almacenamiento se pierden

Todos los m´etodos son lentos pues implican la copia de los datos

El m´etodo basado en ALTER TABLE implica un bloqueo de escritura en la tabla

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

de escritura en la tabla Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Motores de almacenamiento: ejemplos

Registro de llamadas de central telef´onica en tiempo real

La velocidad es el requisito principal. MyISAM impone una sobrecarga baja y permite miles de inserciones por segundo Si son necesarios informes de resumen, la recopilaci´on de datos ralentiza las inserciones Alternativas:

Realizar la recopilaci´on en horas de poca carga Replicar la base de datos en un segundo servidor esclavo en el que se har´an las consultas Particionar el registro de llamadas por mes, semana o d´ıa, y crear una tabla de tipo Merge para las consultas

Servicio de cotizaciones

Si es una herramienta de consumo interno con un n´umero limitado de usuarios, MyISAM Si es un servicio web con mucho tr´afico, miles de usuarios y alimentaci´on de cotizaciones en tiempo real, InnoDB

Una consulta no debe esperar Miles de usuarios intentando leer mientras simult´aneamente se actualizan filas requiere bloqueos a nivel de fila

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

a nivel de fila Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Introducci´on a MySQL
BD3: Dise˜no F´ısico - MySQL
Introducci´on a MySQL

Motores de almacenamiento: ejemplos

Boletines de anuncios y foros de discusi´on

Cientos de aplicaciones PHP y Perl que dan soporte a este tipo de sitios Web No suelen tener en cuenta la eficiencia de la BD

Ejecutan muchas consultas para cada solicitud que sirven Muchos usan tablas monol´ıticas con mucha actividad pesada de lectura y escritura La carga suele ser mediana o peque˜na, MyISAM no es imprescindible InnoDB no es capa de ejecutar r´apidamente esta consulta sin optimizaciones por parte del usuario

SELECT

COUNT(*)

FROM

TABLE

Aplicaciones distribuidas en DVD / USB

El motor MyISAM trabaja directamente sobre el sistema de ficheros Utilizando el formato comprimido se optimiza el acceso a disco, aunque la BD es de s´olo lectura

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD es de s´olo lectura Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Contenidos

1

Introducci´on a MySQL

2

Replicaci´on

3

Copia de seguridad y recuperaci´on

4

Medici´on de rendimiento y perfilado Medici´on del rendimiento Perfilado de aplicaciones

5

Optimizaci´on Optimizaci´on de esquemas e ´ındices Optimizaci´on de hw. y sw. Optimizaci´on del servidor

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

del servidor Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Definici´on de replicaci´on

Consiste en configurar uno o varios servidores como esclavos - o r´eplicas - de otro servidor

Problema a resolver: mantener los datos de los servidores sincronizados

Base para construir aplicaciones extensas y de alto rendimiento Admite diferentes topolog´ıas

Muchos esclavos pueden conectarse a un maestro Un esclavo puede, a su vez, actuar como maestro

Se puede replicar:

todo el servidor determinadas bases de datos s´olo algunas tablas

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

s´olo algunas tablas Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Problemas resueltos por la replicaci´on

Distribuci´on de datos

No exige un ancho de banda intensivo y funciona con una conexi´on intermitente

´

Util para mantener una copia de los datos en una ubicaci´on

geogr´aficamente distante

Balanceo de carga

Permite distribuir peticiones de datos entre varios servidores

Alta disponibilidad y failover

Los esclavos ayudan a reducir el tiempo de ca´ıda del servidor principal

Prueba de actualizaciones de MySQL

Configuramos un servidor esclavo con la nueva versi´on de MySQL, y la utilizamos para ver que las aplicaciones siguen funcionando

Copias de seguridad

La carga de la copia se realiza sobre el esclavo, no sobre el servidor original Un servidor replicado no es una copia de seguridad

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

una copia de seguridad Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Funcionamiento de la replicaci´on

El maestro registra todos sus cambios como eventos del registro binario (binary log) El esclavo copia los eventos del registro binario a su registro de repetici´on (relay log) El esclavo repite todos los eventos del registro de repetici´on sobre sus propios datos

eventos del registro de repetici´on sobre sus propios datos Enxe˜nar´ıa Inform´atica Miguel R. Luaces

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

sobre sus propios datos Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Funcionamiento de la replicaci´on

El registro binario de mySQL:

Registra todas las operaciones del servidor que modifican datos (o podr´ıan modificarlos, por ejemplo, un DELETE con filtro) con independencia de los motores de almacenamiento Est´a formado por una secuencia de eventos, cada de uno de ellos formado por:

La fecha y hora del evento (un timestamp) Identificador del servidor de origen (evita bucles infinitos) Byte de desplazamiento del evento siguiente Id del thread que ejecut´o el evento en el servidor de origen Tipo de evento (por ejemplo, Query) Detalles del evento

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

) Detalles del evento Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Funcionamiento de la replicaci´on

El registro binario de mySQL permite tres tipos de replicaci´on:

Basada en sentencias (statement-based replication)

Se registra la instrucci´on que cambia los datos en el maestro La utilizada por defecto. Sencilla de implementar y compacta. Estable desde MySQL 3.23 Hay instrucciones que no se pueden replicar (detalles en el manual)

Basada en filas (row-based replication)

Se registran las filas cambiadas y el cambio realizado Permite la replicaci´on de cualquier instrucci´on El registro aumenta de tama˜no No es f´acil auditar los cambios realizados

Mixta (mixed-format replication)

MySQL decide en funci´on de la instrucci´on que se ejecuta si se usa replicaci´on basada en sentencias o en filas Se usa la replicaci´on basada en sentencias a no ser que la instrucci´on no sea segura Ver la descripci´on en el manual

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

en el manual Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Funcionamiento de la replicaci´on

El proceso para configurar la replicaci´on es el siguiente:

Configurar cuentas de replicaci´on en cada servidor

El thread E/S del esclavo hace una conexi´on TCP/IP al maestro para leer el registro binario. Por lo tanto, necesita una cuenta de usuario en el maestro con los permisos apropiados

Configurar maestro

Activar el registro binario y asignarle un id al servidor

Configurar esclavo

Asignarle un id al servidor y activar el registro de repetici´on Inidicar al esclavo como conectarse al maestro y desde qu´e punto del registro binario hay que replicar Opcionalmente, activar el registro binario y configurar su actualizaci´on

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

su actualizaci´on Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Funcionamiento de la replicaci´on

Es posible replicar s´olo parte de los eventos de un servidor, utilizando diferentes tipos de filtros

Filtros sobre el registro binario del maestro Filtros sobre el registro de repetici´on

del maestro Filtros sobre el registro de repetici´on Enxe˜nar´ıa Inform´atica Miguel R. Luaces

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

registro de repetici´on Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Topolog´ıas de replicaci´on

Las restricciones en la replicaci´on son las siguientes:

Cada esclavo s´olo puede tener un maestro Un maestro puede tener muchos esclavos Un esclavo puede actuar tambi´en como maestro

Estas restricciones permiten diferentes topolog´ıas con diferentes aplicaciones

Un maestro, m´ultiples esclavos Maestro-maestro en modo activo-activo Maestro-maestro en modo activo-pasivo Anillo

Maestro, maestro de distribuci´on, esclavos

´

Arbol o pir´amide

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

´ Arbol o pir´amide Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Topolog´ıas de replicaci´on

Un maestro, m´ultiples esclavos

de replicaci´on Un maestro, m´ultiples esclavos Enxe˜nar´ıa Inform´atica Miguel R. Luaces

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

m´ultiples esclavos Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Topolog´ıas de replicaci´on

Un maestro, m´ultiples esclavos

La topolog´ıa m´as sencilla y m´as com´un

Todas las escrituras se realizan en el maestro, las lecturas se pueden realizar en cualquier servidor

El n´umero de esclavos est´a limitado por la capacidad de procesamiento y el ancho de banda del maestro Variantes:

Usar cada esclavo para funciones diferentes (ej.: ´ındices diferentes, motores diferentes) Tener un esclavo en un centro remoto para recuperarse de un desastre Retrasar un esclavo en el tiempo para facilitar la recuperaci´on Utilizar un esclavo para copia de seguridad, para pruebas o para desarrollo

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

o para desarrollo Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Topolog´ıas de replicaci´on

Maestro-maestro en modo activo-activo

de replicaci´on Maestro-maestro en modo activo-activo Cada maestro es a su vez esclavo del otro Cualquier

Cada maestro es a su vez esclavo del otro Cualquier servidor se puede utilizar para cualquier operaci´on Posible uso: oficinas separadas geogr´aficamente, donde cada oficina necesita su copia local de los datos Problemas: cambios conflictivos

Actualizaci´on simult´anea de la misma fila en ambos servidores Inserciones simult´aneas con columnas AUTO INCREMENT

¿Y si la replicaci´on se detiene por un tiempo? ¿C´omo reenganchamos despu´es?

S´olo se recomienda si tenemos datos bien particionados y buen reparto de privilegios

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

reparto de privilegios Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Topolog´ıas de replicaci´on

Maestro-maestro en modo activo-pasivo

de replicaci´on Maestro-maestro en modo activo-pasivo Uno de los servidores es un servidor “pasivo” de s´olo

Uno de los servidores es un servidor “pasivo” de s´olo lectura Permite intercambiar los papeles de forma muy sencilla: las configuraciones son sim´etricas Mantenimiento, optimizaci´on de tablas, actualizaciones del sistema operativo no implican inactividad del sistema. Por ejemplo, ALTER TABLE bloquea toda la tabla, incluyendo lecturas y escrituras sobre la misma. Para no ralentizar el sistema:

Detenemos los hilos esclavos en el maestro activo Hacemos el cambio en el maestro pasivo Cambiamos los papeles de activo y pasivo Reiniciamos los hilos esclavos en el antiguo maestro activo

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

Enxe˜nar´ıa Inform´atica

antiguo maestro activo Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez Enxe˜nar´ıa Inform´atica
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Topolog´ıas de replicaci´on

Anillo

- MySQL Replicaci´on Topolog´ıas de replicaci´on Anillo Enxe˜nar´ıa Inform´atica Miguel R. Luaces

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

de replicaci´on Anillo Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Topolog´ıas de replicaci´on

Anillo

Tres o m´as maestros

Cada servidor es un esclavo del servidor que est´a antes en el anillo, y maestro del servidor que est´a despu´es

Configuraci´on sim´etrica, failover f´acil. Es una configuraci´on fr´agil:

Depende enormemente de que todos los nodos funcionen correctamente Dif´ıcil que est´en todos sincronizados a la vez: detener alg´un nodo es complicado Si eliminamos un nodo sin tener cuidado, sus eventos pueden

propagarse de forma infinita por el anillo. ¡El unico´ evento es el que lo ha generado!

nodo que filtra un

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

nodo que filtra un Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Topolog´ıas de replicaci´on

Maestro, maestro de distribuci´on, esclavos

replicaci´on Maestro, maestro de distribuci´on, esclavos Enxe˜nar´ıa Inform´atica Miguel R. Luaces

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

distribuci´on, esclavos Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Topolog´ıas de replicaci´on

Maestro, maestro de distribuci´on, esclavos

Similar a la topolog´ıa maestro-esclavos, pero no sobrecarga al maestro principal

El maestro principal s´olo tiene un esclavo que a su vez act´ua como maestro de distribuci´on

El maestro de distribuci´on usa el motor BlackHole que graba en el registro binario pero no mantiene tablas ni datos

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

mantiene tablas ni datos Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Topolog´ıas de replicaci´on

´

Arbol o pir´amide

Topolog´ıas de replicaci´on ´ Arbol o pir´amide Enxe˜nar´ıa Inform´atica Miguel R. Luaces

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

´ Arbol o pir´amide Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Topolog´ıas de replicaci´on

´

Arbol o pir´amide

Si hay muchos esclavos, puede ser mas rentable un dise˜no en pir´amide

Esto alivia la carga del maestro y la redistribuye por los diferentes esclavos

Desventaja: fallos en niveles intermedios afectan a un gran n´umero de servidores

Adem´as, cuantos m´as niveles intermedios, m´as dif´ıcil y complicado es manejar los fallos

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

es manejar los fallos Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Replicaci´on
BD3: Dise˜no F´ısico - MySQL
Replicaci´on

Problemas en la replicaci´on

La replicaci´on implica varias tareas complejas:

Medir el desfase de los esclavos para saber en que estado se encuentran

Determinar la consistencia de los esclavos con respecto al maestro

Resincronizar un esclavo con el maestro

Intercambiar un esclavo por un maestro

La replicaci´on s´olo escala las lecturas, no las escrituras

La distribuci´on de la carga debe ser realizada por otro software

La complejidad de la replicaci´on se ve claramente en la longitud de la secci´on del manual

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

la secci´on del manual Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Copia de seguridad y recuperaci´on
BD3: Dise˜no F´ısico - MySQL
Copia de seguridad y recuperaci´on

Contenidos

1

Introducci´on a MySQL

2

Replicaci´on

3

Copia de seguridad y recuperaci´on

4

Medici´on de rendimiento y perfilado Medici´on del rendimiento Perfilado de aplicaciones

5

Optimizaci´on Optimizaci´on de esquemas e ´ındices Optimizaci´on de hw. y sw. Optimizaci´on del servidor

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

del servidor Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Copia de seguridad y recuperaci´on
BD3: Dise˜no F´ısico - MySQL
Copia de seguridad y recuperaci´on

Introducci´on

Recuperaci´on no es restauraci´on

Restaurar: recuperar datos desde una copia de seguridad y cargarlos en una base de datos Recuperar: todo el proceso de rescatar un sistema o parte de ´el. Incluye todos los pasos para lograr que un servidor vuelva a ser completamente funcional y operativo:

Restaurar copia de seguridad Reiniciar servidor Cambiar configuraci´on Calentar las cach´es del servidor

Utilidades de las copias de seguridad

Recuperaci´on ante desastres. Un error importante corrompe los datos o el servidor Recuperaci´on ante cambios no deseados. La gente cambia de idea, y ocurre m´as a menudo que los desastres Auditor´ıas. Necesidad de recuperar datos o esquema en alg´un momento del pasado (ej. temas judiciales) Pruebas. La manera m´as f´acil de cargar un servidor de pruebas con datos es usando una copia de seguridad

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

una copia de seguridad Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Copia de seguridad y recuperaci´on
BD3: Dise˜no F´ısico - MySQL
Copia de seguridad y recuperaci´on

Introducci´on

El mejor sistema de copias de seguridad no es suficiente. Un buen plan de recuperaci´on es fundamental

El procedimiento de recuperaci´on es complejo. Es f´acil cometer errores Las copias de seguridad son rutinarias y no se realizan bajo situaciones de presi´on extrema. La recuperaci´on se hace en medio de una situaci´on de crisis Una persona puede planear, dise˜nar e implementar las copias de seguridad, pero podr´ıa no estar disponible cuando se produzca el desastre. Es necesario formar a personal cualificado para que se encargue de la recuperaci´on

Alternativas que no son copias de seguridad

La replicaci´on no es una copia de seguridad Usar discos en RAID ¿C´omo nos recuperamos en estos casos de un DROP DATABASE?

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

de un DROP DATABASE? Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Copia de seguridad y recuperaci´on
BD3: Dise˜no F´ısico - MySQL
Copia de seguridad y recuperaci´on

Estrategia para la copia de seguridad

No olvidar realizar copias de seguridad de recursos no obvios

Registro binario y registro de transacciones de InnoDB C´odigo: disparadores y procedimientos almacenados (est´an en la BD mysql) Configuraci´on del servidor y de la replicaci´on Ficheros seleccionados del SO (trabajos cron, configuraciones de usuario y de grupo, scripts administrativos, reglas sud0, etc)

¿Qu´e podemos permitirnos perder?

La respuesta a esa pregunta gu´ıa la estrategia de copia de seguridad

¿Basta con la copia de la noche anterior y podemos perder el trabajo de hoy? ¿Necesitamos retroceder a un instante de tiempo predeterminado?

Cuanto m´as nos permitamos perder, m´as f´acil es hacer la copia Las copias de seguridad en MySQL son mucho m´as complicadas de lo que parece

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

de lo que parece Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Copia de seguridad y recuperaci´on
BD3: Dise˜no F´ısico - MySQL
Copia de seguridad y recuperaci´on

Tipos de copia de seguridad

¿Copias calientes, templadas o fr´ıas?

Calientes: sin detener el servidor ni bloquear las tablas Templadas: sin detener el servidor pero bloqueando las tablas Fr´ıas: deteniendo el servidor

¿Copias l´ogicas o sin procesar?

Copia l´ogica: en un formato que MySQL puede interpretar (SQL, CSV) Copia sin procesar: los archivos de mySQL tal y como est´an almacenados en disco

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

almacenados en disco Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Copia de seguridad y recuperaci´on
BD3: Dise˜no F´ısico - MySQL
Copia de seguridad y recuperaci´on

Tipos de copia de seguridad

Inconvenientes de copias calientes

B´uferes sucios en el grupo de buffers de InnoDB (u otras cach´es) Datos modificados mientras se est´a haciendo la copia

Inconvenientes de copias frias

Desconectar servidor es costoso, aun si se minimiza el tiempo de copia de seguridad Las p´aginas sucias en grupo de buffers InnoDB requieren tiempo para volcarse a disco Reiniciar tambi´en requiere tiempo: abrir tablas, calentar cach´es, etc.

Inconvenientes de copias templadas

Tiempo de espera indeterminado debido al proceso de adquirir bloqueos

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

de adquirir bloqueos Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Copia de seguridad y recuperaci´on
BD3: Dise˜no F´ısico - MySQL
Copia de seguridad y recuperaci´on

Tipos de copia de seguridad

Ventajas de las copias l´ogicas

Archivos que se pueden manipular e inspeccionar con editores de textos F´aciles de restaurar Se pueden restaurar en una m´aquina diferente Independientes del motor de almacenamiento Se pueden retocar para exportar a otros SGBD

Desventajas de las copias l´ogicas

El servidor debe hacer el trabajo de generarlas Pueden llegar a ocupar mucho m´as que los datos en algunos casos La reconstrucci´on implica volver a ejecutar todas las sentencias y regenerar todos los ´ındices.

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

todos los ´ındices. Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Copia de seguridad y recuperaci´on
BD3: Dise˜no F´ısico - MySQL
Copia de seguridad y recuperaci´on

Tipos de copia de seguridad

Ventajas de las copias sin procesar

No hay trabajo adicional: se copian los archivos tal cual La restauraci´on puede ser sencill´ısima: para MyISAM, simplemente copiar los archivos en su sitio; InnoDB, en cambio, obliga a detener el servidor La restauraci´on es m´as r´apida: no hay que ejecutar sentencias, ni reconstruir ´ındices

Desventajas de las copias sin procesar

Suelen ocupar mucho m´as espacio que las copias l´ogicas (por ejemplo, el espacio de tabla InnoDB incluye mucho espacio sin utilizar) No siempre se pueden mover a trav´es de las plataformas, SO y versiones de SQL (may´usculas/min´usculas, representaci´on punto flotante)

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

punto flotante) Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Copia de seguridad y recuperaci´on
BD3: Dise˜no F´ısico - MySQL
Copia de seguridad y recuperaci´on

Procedimiento de copia l´ogica

Copia

Realizar un volcado SQL con mysqldump o CSV con SELECT * INTO OUTFILE

Restauraci´on

Ejecutar el script SQL o importar el CSV con LOAD DATA INFILE INTO TABLE

Problemas:

En el volcado SQL los esquemas y datos almacenados juntos, en el volcado CSV no hay esquemas Los archivos pueden ser enormes (y los editores de texto no podr´an abrirlos)

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

no podr´an abrirlos) Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Copia de seguridad y recuperaci´on
BD3: Dise˜no F´ısico - MySQL
Copia de seguridad y recuperaci´on

Procedimiento de copia l´ogica

Hay que asegurar que los datos son consistentes en un punto de tiempo determinado (por ejemplo, en una BD de comercio electr´onico debe haber una factura por cada pago). Es complicado en copias calientes

En motores transaccionales: realizar la copia en una transacci´on En motores no transaccionales, bloquear todas las tablas que se deben copiar juntas Esto no nos protege de una aplicaci´on mal dise˜nada (por ejemplo, si el pago y la factura se registran en dos transacciones distintas)

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

transacciones distintas) Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Copia de seguridad y recuperaci´on
BD3: Dise˜no F´ısico - MySQL
Copia de seguridad y recuperaci´on

Procedimiento de copia sin procesar

Copia

MyISAM: bloquear las tablas y copiar los archivos de datos InnoDB:

Bloquear las tablas no es suficiente porque los cambios se reflejan en el registro de transacciones y no en el espacio de tablas Alternativa: parar el servidor o usar t´ecnicas de gesti´on de ficheros del SO (por ejemplo, LVM)

Restauraci´on:

MyISAM: bloquear las tablas y copiar los archivos de datos InnoDB: parar el servidor y sustituir los archivos

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

y sustituir los archivos Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Copia de seguridad y recuperaci´on
BD3: Dise˜no F´ısico - MySQL
Copia de seguridad y recuperaci´on

Procedimiento de copias de seguridad incrementales

Activar el registro binario de mySQL Copia:

Realizar copias completas con los procedimientos anteriores Realizar copias incrementales del registro binario

Restauraci´on:

Restaurar la copia completa y ejecutar todos los registro binarios

Restauraci´on a un punto concreto del tiempo

Localizar el punto de tiempo en los registros binarios y ejecutar hasta esa posici´on

Eliminar el resultado de una instrucci´on

Localizar la instrucci´on y ejecutar el registro binario hasta esa posici´on y desde despu´es de esa posici´on

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

de esa posici´on Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Contenidos 1 Introducci´on a MySQL 2

Medici´on de rendimiento y perfilado

Contenidos

1

Introducci´on a MySQL

2

Replicaci´on

3

Copia de seguridad y recuperaci´on

4

Medici´on de rendimiento y perfilado Medici´on del rendimiento Perfilado de aplicaciones

5

Optimizaci´on Optimizaci´on de esquemas e ´ındices Optimizaci´on de hw. y sw. Optimizaci´on del servidor

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

del servidor Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Medici´on del rendimiento y perfilado El

Medici´on de rendimiento y perfilado

Medici´on del rendimiento y perfilado

El objetivo de la optimizaci´on es aumentar el rendimiento de MySQL

Los elementos a optimizar son muchos. Ej: esquemas, ´ındices, consultas, configuraci´on del servidor, hardware, software, aplicaciones Necesitamos dos pr´acticas b´asicas:

Medici´on del rendimiento. Responde a ¿C´omo se ejecuta?

Permiten evaluar el desempe˜no del SGBD Permiten determinar la capacidad m´axima del sistema Permiten discriminar los cambios que importan de los que no Muestran c´omo se ejecuta la aplicaci´on con datos diferentes

Perfilado. Responde a ¿Por qu´e se ejecuta as´ı?

Indica cuanto contribuye cada elemento de un sistema al coste de producir el resultado Lugares donde se pierde m´as tiempo Lugares donde se consumen m´as recursos

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

consumen m´as recursos Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Medici´on del rendimiento
BD3: Dise˜no F´ısico - MySQL
Medici´on de rendimiento y perfilado
Medici´on del rendimiento

Contenidos

1

Introducci´on a MySQL

2

Replicaci´on

3

Copia de seguridad y recuperaci´on

4

Medici´on de rendimiento y perfilado

Medici´on del rendimiento

Perfilado de aplicaciones

5

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Optimizaci´on de hw. y sw.

Optimizaci´on del servidor

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

del servidor Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Medici´on del rendimiento
BD3: Dise˜no F´ısico - MySQL
Medici´on de rendimiento y perfilado
Medici´on del rendimiento

Objetivos de las medidas

Las medidas de rendimiento permiten realizar las siguientes tareas:

Medir rendimiento actual de nuestra aplicaci´on

Necesario para poder comparar efecto de cambios Diagnosticar problemas no previstos

Validar la escalabilidad del sistema

Pruebas comparativas con cargas masivas

Planificar el crecimiento

Estimar hw., capacidad de red y otros recursos para la carga futura prevista

Probar la capacidad de adaptaci´on a entornos cambiantes

Picos espor´adicos, configuraciones diferentes de servidores

Probar configuraciones diferentes de hw., sw. y so.

¿RAID5 o RAID10? ¿n´ucleo 2.4 o 2.6 de Linux? ¿escala bien con doble de memoria?

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

con doble de memoria? Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Medici´on del rendimiento
BD3: Dise˜no F´ısico - MySQL
Medici´on de rendimiento y perfilado
Medici´on del rendimiento

Estrategias para medir

Existen dos estrategias en la medida de rendimiento:

Aplicaci´on como un todo

La preocupaci´on ultima´

MySQL no es siempre el cuello de botella. Una prueba de pila completa pude revelarlo Los puntos de referencia para medir rendimiento son buenos si reflejan el comportamiento real de toda la aplicaci´on. Es m´as dif´ıcil si s´olo probamos una parte de ella

es el rendimiento de toda la aplicaci´on

Aislar mySQL (SGBD, en general)

Es dif´ıcil aislar puntos de referencia y de configuraci´on de la aplicaci´on Acercamiento paulatino: empezar por mySQL Interesan medidas de rendimiento cortas, con “tiempo de ciclo m´as corto” F´acil aislar consultas t´ıpicas y repetirlas muchas veces

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

repetirlas muchas veces Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Medici´on del rendimiento
BD3: Dise˜no F´ısico - MySQL
Medici´on de rendimiento y perfilado
Medici´on del rendimiento

Ejemplos de medidas de rendimiento

Transacciones por unidad de tiempo (cl´asica)

Se ajusta bien a aplicaciones interactivas de m´ultiples usuarios, OLTP Unidad t´ıpica: transacciones por segundo

Tiempo de respuesta (latencia)

Mide tiempo total requerido por una tarea (ej: mil´esimas, minutos) La ejecuci´on repetida permite derivar tiempos de respuesta m´ınimo, m´aximo o medio

Los tiempos m´ınimos y m´aximos no son muy utiles´

repetibles, cuanto m´as tiempo se ejecute la medida, m´as extremos ser´an, y var´ıan mucho entre diferentes ejecuciones En general es mejor agregar utilizando percentiles (ej: el 95 % de las respuestas se responden en menos de 5 ms)

porque no son

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

de 5 ms) porque no son Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez
BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Medici´on del rendimiento
BD3: Dise˜no F´ısico - MySQL
Medici´on de rendimiento y perfilado
Medici´on del rendimiento

Ejemplos de medidas de rendimiento

Concurrencia

Medimos el rendimiento de la aplicaci´on bajo diferentes niveles de concurrencia Un ejemplo de medida: n´umero solicitudes atendidas respecto a las solicitadas en un segundo Es importante mediar las consultas que se realizan, no las conexiones establecidas, ya que los servidores y los clientes actuales incluyen un pool de conexiones No s´olo es un resultado, tambi´en es una propiedad que debemos configurar en nuestras pruebas

Escalabilidad

´

Util en sistemas que tienen que mantener un rendimiento estable bajo carga de trabajo cambiante Generalmente se utilizan medidas de tiempo de respuesta probando con diferentes intensidades de carga La intensidad de carga se varia cambiando (entre otros):

Enxe˜nar´ıa Inform´atica

El tama˜no de la base datos El n´umero de conexiones concurrentes El hw. disponible

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

n´umero de conexiones concurrentes El hw. disponible Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Medici´on del rendimiento
BD3: Dise˜no F´ısico - MySQL
Medici´on de rendimiento y perfilado
Medici´on del rendimiento

Errores comunes en las medidas

Algunos errores comunes en la definici´on de medidas de rendimiento:

Usar un subconjunto no representativo de los datos

Utilizar datos sint´eticos distribuidos uniformemente

Definir un escenario con un solo usuario

Medir en un solo servidor el rendimiento de una aplicaci´on distribuida

Fallo en imitar el comportamiento del usuario: clics en v´ınculos uno tras otro sin parar, en una aplicaci´on web

Ejecutar consultas id´enticas en un bucle, olvidando posibles p´erdidas en cach´e

No detectar los errores en el proceso de medida (ej: que una operaci´on lenta se agilice mucho puede ser debido a un error de sintaxis en SQL)

Olvidar tener en cuenta latencia del servidor despu´es de reinicio

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

despu´es de reinicio Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Medici´on del rendimiento
BD3: Dise˜no F´ısico - MySQL
Medici´on de rendimiento y perfilado
Medici´on del rendimiento

Planificaci´on de medidas de rendimiento

Proceso de planificaci´on de una medida de rendimiento

Identificar el objetivo de la medida y definir indicadores para evaluarlo

Un objetivo mal definido: “El nuevo ´ındice agiliza las consultas” Un objetivo bien definido: “El nuevo ´ındice reduce el tiempo de respuesta de la consulta en un 10 %”

Decidir si usaremos una prueba est´andar o una prueba de dise˜no propio Definir un plan de toma de medidas porque tendremos que repetir la prueba varias veces y necesitamos reproducirla exactamente

Datos de partida de la prueba Pasos seguidos para configurar sistema Plan de calentamiento Documentaci´on de los par´ametros Almacenamiento de los resultados

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

de los resultados Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Medici´on del rendimiento
BD3: Dise˜no F´ısico - MySQL
Medici´on de rendimiento y perfilado
Medici´on del rendimiento

Planificaci´on de medidas de rendimiento

Proceso de planificaci´on de una medida de rendimiento Realizar la toma de medidas

Usar diferentes intervalos de tiempo para cubrir todas las actividades del sistema Debemos asegurar que la prueba es significativa y repetible (ej: usando una instant´anea de los datos, usando el servidor en caliente) Debemos tener cuidado con la carga externa y con las tareas peri´odicas Cambiar la menor cantidad de par´ametros posible en cada prueba (los independientes) Es recomendable automatizar las ejecuciones de las pruebas (scripts, makefiles) El n´umero de repeticiones depende del grado de certeza que se quiera alcanzar. Com´unmente:

Ejecutar varias veces y eliminar los resultados discrepantes Ejecutar hasta que los resultados no var´ıen demasiado (reducir la varianza) Utilizar t´ecnicas estad´ısticas

Analizar los resultados

Los resultados agregados permiten dar una idea general de la medida Los resultados detallados permiten detectar picos ocultos por la agregaci´on

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

por la agregaci´on Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Medici´on del rendimiento
BD3: Dise˜no F´ısico - MySQL
Medici´on de rendimiento y perfilado
Medici´on del rendimiento

Herramientas para medidas de rendimiento

Herramientas espec´ıficas de mySQL mysqlslap

Incluido desde la version 5.1 con mySQL Simula carga en el servidor e informa sobre el tiempo Muy configurable, ej: n´umero de conexiones concurrentes Permite una instrucci´on SQL en l´ınea de comandos o un archivo con instrucciones SQL

MySQL Benchmark suite

Incluido desde la version 5.0 con mySQL Mide lo r´apido que ejecuta el servidor las consultas Muchas pruebas predefinidas, que permiten comparar diferentes motores de almacenamiento y configuraciones Mejorable (un s´olo usuario, el conjunto de datos es peque˜no, y usa un solo proceso (no multiples CPU)

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

(no multiples CPU) Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Medici´on del rendimiento
BD3: Dise˜no F´ısico - MySQL
Medici´on de rendimiento y perfilado
Medici´on del rendimiento

Herramientas para medidas de rendimiento

Herramientas espec´ıficas de mySQL sysbench

Tests predefinidos para medir rendimiento de servidor y SGBD Pruebas de rendimiento de CPU, memoria, threads, etc. Pruebas de rendimiento de la E/S de archivos: comparar discos duros, tarjetas RAID, modos RAID, etc. Pruebas de comparaci´on OLTP Desarrollo parado

Super Smack

Pruebas de comparaci´on + Prueba de estr´es + Herramienta de generaci´on de carga para MySQL y PostgreSQL M´ultiples usuarios, carga datos de prueba (aleatorios) Lenguaje neutro (smack) para definir clientes, tablas, consultas, etc. Desarrollo parado

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

etc. Desarrollo parado Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Medici´on del rendimiento
BD3: Dise˜no F´ısico - MySQL
Medici´on de rendimiento y perfilado
Medici´on del rendimiento

Herramientas para medidas de rendimiento

Herramientas de pila completa Ab

Incluida con el servidor HTTP Apache Calcula el n´umero de solicitudes que puede servir por segundo S´olo prueba una URL todo lo r´apido que pueda

httpload

Utiliza un archivo de entrada con muchas URLs de las que elige aleatoriamente Prueba lo m´as r´apido que pueda, o seg´un una velocidad establecida (-rate) Tambi´en simula usuarios concurrentes (-parallel)

JMeter

Aplicaci´on Java para medir el rendimiento de otros programas Simula usuarios reales (tiempo de escalada configurable) Interfaz gr´afica que permite reproducir prueba fuera de l´ınea

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

prueba fuera de l´ınea Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Perfilado de aplicaciones
BD3: Dise˜no F´ısico - MySQL
Medici´on de rendimiento y perfilado
Perfilado de aplicaciones

Contenidos

1

Introducci´on a MySQL

2

Replicaci´on

3

Copia de seguridad y recuperaci´on

4

Medici´on de rendimiento y perfilado

Medici´on del rendimiento

Perfilado de aplicaciones

5

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Optimizaci´on de hw. y sw.

Optimizaci´on del servidor

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

del servidor Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Perfilado de aplicaciones
BD3: Dise˜no F´ısico - MySQL
Medici´on de rendimiento y perfilado
Perfilado de aplicaciones

Objetivos del perfilado

El perfilado de un sistema nos indica cuanto contribuye cada elemento al coste total de producci´on de un resultado

Permite entender por qu´e un sistema se ejecuta como lo hace Es necesesario considerar el sistema completo porque:

Si nos centramos en ejecutar, analizar, y optimizar consultas perdemos mucha informaci´on

Procesamiento de resultados en memoria Llamadas a recursos externos Algoritmos poco optimos´

Si nos limitamos a medir tiempo de respuesta del servidor web

No tenemos estad´ısticas del sistema que permitan determinar qu´e esfuerzo permite una mayor mejora

El cuello de botella puede estar en otra parte.

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

estar en otra parte. Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Perfilado de aplicaciones
BD3: Dise˜no F´ısico - MySQL
Medici´on de rendimiento y perfilado
Perfilado de aplicaciones

Proceso de perfilado

Es necesario incluir c´odigo de perfilado en las aplicaciones que tome mediciones de:

Tiempo total de ejecuci´on de la p´agina Tiempo de ejecuci´on de las consultas Tiempo de llamadas a recursos externos (servicios web)

Es una sobrecarga al sistema, por lo que es necesario aplicar t´acticas como

S´olo realizar el perfilado en un porcentaje peque˜no de las peticiones Guardar los datos en memoria y hacerlos persistentes en bloque

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

persistentes en bloque Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Perfilado de aplicaciones
BD3: Dise˜no F´ısico - MySQL
Medici´on de rendimiento y perfilado
Perfilado de aplicaciones

Perfilado en MySQL

MySQL mantiene dos registros de consultas: el registro general y el registro de consultas lentas El registro general

Se guardan todas las consultas que se reciben aunque por error no se terminen ejecutando Se guardan los eventos de conexi´on y desconexi´on Sin tiempos de ejecuci´on: de poco inter´es para el perfilado

El registro de consultas lentas

Registra las consultas ejecutadas que sobrepasan un determinado tiempo Se puede configurar para registrar tambi´en las consultas que no utilizan ´ındices Guarda tiempos de ejecuci´on: permite perfilado Es dif´ıcil de utilizar:

Una consulta es lenta porque tarda m´as de lo esperado, no porque tarda m´as que un umbral de tiempo Hay consultas que no tienen que usar el ´ındice de ning´un modo

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

de ning´un modo Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Medici´on de rendimiento y perfilado Perfilado de aplicaciones
BD3: Dise˜no F´ısico - MySQL
Medici´on de rendimiento y perfilado
Perfilado de aplicaciones

Perfilado en MySQL

Desde la versi´on 5.1.28, MySQL permite realizar perfilado de los recursos usados en una sesi´on

Se activa mediante la variable profiling Se consulta mediante SHOW PROFILES y SHOW PROFILE [FOR QUERY n] Registra multitud de variables para cada uno de los estados de todas las consultas ejecutadas Los datos se pueden consultar agregados o a nivel de consulta individual Los datos se guardan en memoria mientras dure la sesi´on

La estrategia de an´alisis de resultados puede ser:

Comprobar qu´e consultas tienen m´as impacto Comprobar el plan de ejecuci´on de esas consultas con EXPLAIN Realizar los ajustes necesarios Repetir el an´alisis

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

Repetir el an´alisis Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Contenidos 1 Introducci´on a

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Contenidos

1

Introducci´on a MySQL

2

Replicaci´on

3

Copia de seguridad y recuperaci´on

4

Medici´on de rendimiento y perfilado

5

Medici´on del rendimiento Perfilado de aplicaciones Optimizaci´on Optimizaci´on de esquemas e ´ındices Optimizaci´on de hw. y sw. Optimizaci´on del servidor

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

del servidor Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Optimizaci´on de esquemas e

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Optimizaci´on de esquemas e ´ındices

Optimizar esquema mal dise˜nado o mal indizado mejora del rendimiento en ´ordenes de magnitud Sin embargo, hay que tener cuidado con los efectos secundarios

Un nuevo ´ındice INSERT y UPDATE m´as lentas Las tablas de resumen y los contadores agilizan consultas, pero el mantenimiento es m´as costoso Los cambios requieren conocer todo el sistema y cada elemento afectado

Describiremos estas t´ecnicas:

Elecci´on de tipos de datos optimos´

Distintos tipos de ´ındices: B+, Hash y agrupados

Estrategias de indexado

´

Indices para ordenaci´on Tablas de cache y de resumen

Tablas de contadores Desnormalizaci´on

y selecci´on de clave primaria

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

de clave primaria Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Elecci´on de tipos de datos

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Elecci´on de tipos de datos ´optimos

Elegir adecuadamente el tama˜no es importante Usar el tipo de datos m´as peque˜no posible

Menos espacio en disco, memoria y CPU

Cuanto m´as sencillos mejor

Tipos de datos simples, menos ciclos de CPU. Por ejemplo, enteros para IPs, y no cadenas (una IP es un entero de 32 bits sin signo): INET ATON(), INET NTOA()

Evitar valores NULL. Indicar NOT NULL siempre que sea posible

Complicado optimizar si hay columnas con valores NULL Columnas NULL usan mas espacio de almacenamiento y requieren procesamiento especial. (i.e. byte adicional en ´ındice) A ser posible, usar cero, valor especial, cadena vac´ıa,

Proceso:

Paso 1: Determinar tipo de datos: num´erico, cadena, temporal Paso 2: Elegir tipo espec´ıfico

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

tipo espec´ıfico Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Elecci´on de tipos de datos

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Elecci´on de tipos de datos ´optimos

DATETIME vs. TIMESTAMP

Datetime: Entero empaquetado (YYYMMDDHHMMSS) de 8 bytes. Mayor rango de valores (1001-9999, con precisi´on de 1 segundo). Timestamp: Entero de 4 bytes. N´umero de segundos desde 0:00 del 1/1/1970 en meridiano Greenwich. Mitad de espacio y utiliza zona horaria.

CHAR vs. VARCHAR

CHAR

Longitud fija Vale la pena para valores muy cortos o cuando todos los valores tienen aprox. la misma longitud.

VARCHAR

Menos espacio por ser longitud variable 1 o 2 bytes adicionales para almacenar longitud (varchar(10): hasta 11 bytes; varchar(1000): hasta 1002 bytes) Filas ocupan menos, pero pueden crecer m´as adelante (fragmentaci´on, reasignaci´on de espacio) Vale la pena cuando la longitud m´axima de columna es mucho mayor que la media y hay pocas actualizaciones, o cuando el cjto. caracteres complejo, codificaci´on variable (UTF-8).

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

variable (UTF-8). Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Elecci´on de tipos de datos

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Elecci´on de tipos de datos ´optimos

VARCHAR(5) vs. VARCHAR(200)

Un texto de cuatro caracteres ocupa lo mismo en ambos casos, no hay diferencia en almacenamiento secundario MySQL asigna fragmentos de tama˜no fijo a la memoria Tabla temporal para ordenaci´on: reservar´ıa espacio para el m´aximo tama˜no posible (motor Memory necesita filas de tama˜no fijo) Mejor reservar el tama˜no justo

BLOB y TEXT

Guardan grandes cantidades de datos (binarios y de cadena) Cada motor, diferente gesti´on Evitar usarlos en el ORDER BY ya que el motor Memory no permite campos TEXT ni BLOB, as´ı que habr´ıa que usar myISAM para la tabla temporal de ordenaci´on) Truco (longitud lo bastante corta para que la tabla no sobrepase tmp table size) ORDER BY SUBSTRING(columna text, longitud)

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

text, longitud) Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Elecci´on de tipos de datos

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Elecci´on de tipos de datos ´optimos

ENUM en lugar de cadenas

Ahorro de espacio Es soluci´on s´olo para listas fijas de cadenas. Ampliarla: ALTER TABLE Adem´as: sobrecarga de conversi´on de valores (por ejemplo, al concatenar o al comparar) Usar s´olo si la lista de cadenas no va a cambiar en el futuro

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

Enxe˜nar´ıa Inform´atica

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Selecci´on de clave primaria Debe

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Selecci´on de clave primaria

Debe ser el mismo tipo en todas las tablas relacionadas ya que tipos distintos afectan al rendimiento debido a las conversiones

InnoDB no permite claves for´aneas si no hay coincidencia exacta Conversiones de tipo impl´ıcitas pueden provocar errores dif´ıciles de detectar

Elegir tama˜no mas peque˜no necesario dejando espacio para crecimiento futuro

Por ejemplo: un entero (4 bytes) para c´odigos de provincias implica mucho espacio en claves externas

Las cadenas de caracteres son una mala elecci´on porque ocupan mucho espacio y son m´as lentas que los enteros Las cadenas de caracteres aleatorias (estilo UUID) implican:

ralentizaci´on de los INSERT ya que el valor se inserta en una posici´on aleatoria del ´ındice que puede crear fragmentaci´on de p´aginas mal rendimiento de las caches ya que se elimina la localidad ralentizaci´on de los SELECT porque filas adyacentes en el resultado quedan dispersas en disco y memoria si las filas se almacenan ordenadas por clave

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

ordenadas por clave Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Revisi´on de los esquemas

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Revisi´on de los esquemas generados autom´aticamente

Proceso tradicional: Modelado conceptual, l´ogico y f´ısico

Proceso de mapeado objeto-relacional: anotaci´on de clases y creaci´on de esquemas

Proceso model-driven engineering: modelado conceptual y creaci´on autom´atica de esquemas Posibles problemas

Uso reiterado de tipos VARCHAR sin l´ımite Tipos de datos en columnas de combinaci´on que no coinciden El objetivo principal es que cualquier clase puede ser almacenada en cualquier SGBD, lo que puede provocar:

Tablas con cada propiedad de un objeto en una fila Versiones de cada propiedad usando timestamps

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

usando timestamps Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices ´ Indices M´as importantes a

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

´

Indices

M´as importantes a medida que nuestros datos crecen

Por ejemplo, en una consulta como

SELECT

first_name

FROM

actor

where

actor_id=5;

Si hay ´ındice sobre actor id se busca sobre el ´ındice y se recuperan punteros a las filas en la tabla

Si se define el ´ındice sobre varias columnas el orden en el que se indican las columnas es muy importante ya que MySQL s´olo busca eficientemente el prefijo en la parte m´as a la izquierda del ´ındice

Crear un ´ındice sobre dos columnas no es lo mismo que crear dos ´ındices de una sola columna independientes

Los ´ındices se implementan a nivel de motor de almacenamiento (no en capa de servidor), por lo que no todos los motores admiten todos los tipos de ´ındices

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

los tipos de ´ındices Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

Optimizaci´on Optimizaci´on de esquemas e ´ındices ´
Optimizaci´on
Optimizaci´on de esquemas e ´ındices
´

Arbol B y B+

Admitido por todos los motores (menos Archive) Cada motor lo implementa a su modo. Por ejemplo, MyISAM usa compresi´on mientras que InnoDB no usa compresi´on Idea general: todos los valores se almacenan en orden y se accede mediante un ´arbol en el que cada hoja est´a a la misma distancia de la ra´ız y las p´aginas de hojas contienen punteros a los registros de la tabla. Agiliza acceso a los datos. Se realiza un acceso al nodo ra´ız y e va descendiendo por las ramas escogiendo punteros adecuados hasta llegar al valor correcto.

punteros adecuados hasta llegar al valor correcto. Enxe˜nar´ıa Inform´atica Miguel R. Luaces

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

al valor correcto. Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

Optimizaci´on Optimizaci´on de esquemas e ´ındices ´
Optimizaci´on
Optimizaci´on de esquemas e ´ındices
´

Arbol B y B+

Optimizaci´on de esquemas e ´ındices ´ Arbol B y B+ Enxe˜nar´ıa Inform´atica Miguel R. Luaces
Optimizaci´on de esquemas e ´ındices ´ Arbol B y B+ Enxe˜nar´ıa Inform´atica Miguel R. Luaces

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

´ Arbol B y B+ Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

Optimizaci´on Optimizaci´on de esquemas e ´ındices ´
Optimizaci´on
Optimizaci´on de esquemas e ´ındices
´

Arbol B y B+

Tipos de consulta que pueden usar ´ındice de un ´arbol B

Coincidencia con valor completo. =

Coincidencia parcial con prefijo de columna

apellidos

=

’Allen’

and

nombre

’Cuba’

and

apellidos

like

’A %’

fnac

=

’01-01-1960’

Coincidencia parcial con prefijo m´as a la izquierda

apellidos

=

’Allen’

and

nombre

Coincidencia con rango de valores

apellidos

>=

’Allen %’

and

apellidos

like

’C %’

<=

’Barrimore %’

Cl´ausulas ORDER BY por los campos del ´ındice

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

los campos del ´ındice Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

Optimizaci´on Optimizaci´on de esquemas e ´ındices ´
Optimizaci´on
Optimizaci´on de esquemas e ´ındices
´

Arbol B y B+

Limitaciones. No son utiles´

en:

B´usquedas que no empiezan en la parte m´as izquierda de las columnas indizadas. Ejemplos:

nombre

=

’Cuba’

and

fnac

=

’01-01-1960’

 

apellidos

like

’ %Z’

No permiten saltar columnas del ´ındice. Ejemplo:

apellidos

=

’Allen’

and

fnac

=

’01-01-1960’

No se optimiza el acceso a columnas a la derecha de la primera condici´on de rango. Por ejemplo:

apellidos

=

Enxe˜nar´ıa Inform´atica

’Allen’

AND

nombre

>=

’J’

AND

fnac

=

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

’23-12-1976’

AND nombre >= ’J’ AND fnac = Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices ´ Indices Hash S´olo soportado

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

´

Indices Hash

S´olo soportado por el motor Memory (el indice por defecto) Para cada fila se crea un c´odigo hash con las columnas indizadas El ´ındice es una tabla hash con apuntadores de fila (muy compactos)

Las colisiones de la funci´on hash se almacenan con una lista enlazada

´

Util s´olo para b´usquedas que usan todas las columnas del ´ındice. No

admiten coincidencia parcial de clave Problemas

No se pueden usar los ´ındices para ordenar ya que el ´ındice ordena por hash, no por el valor original. No evita leer las filas ya que en el ´ındice s´olo se almacena un punto al registro S´olo permite comparaciones de igualdad (=, IN) pero no consultas de rangos (>100) Las colisiones de la funci´on hash ralentizan el acceso y el mantenimiento

Es posible simular ´ındice hash con una columna extra, un ´arbol B+ y triggers

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

un ´arbol B+ y triggers Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices ´ Indices agrupados Las filas

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

´

Indices agrupados

Las filas de las tablas se guardan en las p´aginas hoja del ´ındice Las filas con valores de clave adyacentes se guardan juntas Ahorra operaciones de E/S en consultas con datos relacionados Los ´ındices tradicionales pueden ocupar m´as espacio del esperado ya que en vez de punteros a registros almacenan valores de clave primaria No todos los motores los admiten InnoDB lo hace impl´ıcito con la clave primaria, con un ´ındice unico´ sin valores NULL, o con una clave interna oculta Inconvenientes:

S´olo ahorra E/S si los datos no caben en memoria La velocidad de inserci´on depende del orden de inserci´on (lo mejor, en el orden de la clave primaria) La actualizaci´on es costosa debido a la reubicaci´on de p´aginas P´aginas m´as sujetas a fragmentaci´on al insertar filas nuevas Pueden ser m´as lentas para escaneos completos

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

para escaneos completos Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Otros ´ındices ´ Indices

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Otros ´ındices

´

Indices espaciales (´arbol R)

S´olo en motor MyISAM S´olo para los tipos de datos y operaciones de geometr´ıa espacial (GEOMETRY) El soporte espacial de MySQL no es muy completo

´

Indices de texto completo

S´olo en el motor MyISAM Permite b´usquedas de palabras clave en textos y c´alculo de relevancias Soporta conceptos de recuperaci´on de informaci´on (stopwords, lematizaci´on, b´usqueda booleana)

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

b´usqueda booleana) Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Estrategias de indexado: aislar

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Estrategias de indexado: aislar columnas

Aislar la columna en las consultas para que no forme parte de una expresi´on ni sea argumento de funciones

Ejemplos que no usan el ´ındice:

 

SELECT

actor_id

FROM

actor

WHERE

actor_id+1=5;

SELECT

WHERE

TO_DAYS(CURRENT_DATE)

-

TO_DAYS(date_col)

<=

10;

Ejemplos que usan el ´ındice:

 
 

SELECT

actor_id

FROM

actor

WHERE

actor_id=4;

SELECT

WHERE

date_col

>=

DATE_SUB(CURRENT_DATE,

INTERVAL

10

Enxe˜nar´ıa Inform´atica

DAY);

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

INTERVAL 10 Enxe˜nar´ıa Inform´atica DAY); Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Estrategias de indexado: Construir

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Estrategias de indexado: Construir ´ındices sobre prefijos

Permite indexar columnas de caracteres largas

Indexar solo los primeros caracteres en lugar de todo el valor Es necesario buscar el tama˜no id´oneo que mantiene el ´ındice altamente selectivo

Selectividad = Valores diferentes indexados / Valores totales Bastante largo para proporcionar buena selectividad Bastante corto como para ahorrar espacio

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

para ahorrar espacio Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Estrategias de indexado: Construir

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Estrategias de indexado: Construir ´ındices sobre prefijos

Distribuci´on de los valores diferentes

sobre prefijos Distribuci´on de los valores diferentes Enxe˜nar´ıa Inform´atica Miguel R. Luaces

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

los valores diferentes Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Estrategias de indexado: Construir

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Estrategias de indexado: Construir ´ındices sobre prefijos

Calculo de las selectividades

´ındices sobre prefijos Calculo de las selectividades Enxe˜nar´ıa Inform´atica Miguel R. Luaces

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

de las selectividades Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Estrategias de indexado: Construir

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Estrategias de indexado: Construir ´ındices sobre prefijos

Distribuci´on con prefijo de 3 caracteres

sobre prefijos Distribuci´on con prefijo de 3 caracteres Enxe˜nar´ıa Inform´atica Miguel R. Luaces

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

prefijo de 3 caracteres Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Estrategias de indexado: Construir

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Estrategias de indexado: Construir ´ındices sobre prefijos

Distribuci´on con prefijo de 4 caracteres

sobre prefijos Distribuci´on con prefijo de 4 caracteres Enxe˜nar´ıa Inform´atica Miguel R. Luaces

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

prefijo de 4 caracteres Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Estrategias de indexado: Construir

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Estrategias de indexado: Construir ´ındices sobre prefijos

Distribuci´on con prefijo de 7 caracteres

sobre prefijos Distribuci´on con prefijo de 7 caracteres Enxe˜nar´ıa Inform´atica Miguel R. Luaces

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

prefijo de 7 caracteres Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Estrategias de indexado: ´ Indices

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Estrategias de indexado:

´

Indices de cobertura

Inclu´ır en el ´ındice todas las columnas necesarios para resolver una consulta MySQL puede utilizar ´ındices para recuperar valores de una columna sin tener que acceder para nada a la fila Ventajas:

Como las entradas del ´ındice son m´as peque˜nas que el tama˜no total de la fila encajan mejor en memoria y caben en cach´e de los motores de almacenamiento Como los ´ındices se ordenan por valor los accesos de rango requieren menos E/S Se evitan bloqueos porque si no accedemos a la fila, no hace falta bloquearla

porque si no accedemos a la fila, no hace falta bloquearla Enxe˜nar´ıa Inform´atica Miguel R. Luaces

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

no hace falta bloquearla Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Usar ´ındices para ordenaci´on

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Usar ´ındices para ordenaci´on

MySQL ordena los resultados usando dos m´etodos: escaneando un ´ındice en orden (r´apido) o mediante ordenaci´on de archivos (lento)

El escaneado del ´ındice s´olo se puede hacer si cubre el where y el order by (las condiciones y columnas forman un prefijo del ´ındice) Ejemplos en los que no lo cubre:

Se ordena de forma descendente (el ´ındice ordena de forma ascendente) Se usa en el order by una columna que no est´a en el ´ındice

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

est´a en el ´ındice Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Tablas de cach´e y resumen

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Tablas de cach´e y resumen

Crear tablas de resumen o de cache independientes de los datos de partida

Tablas de resumen: Resultados obtenidos con GROUP BY (datos plegados) Tablas de cach´e: Datos que se recuperan frecuentemente del esquema

Funciona si podemos tolerar datos ligeramente desactualizados

Debemos decidir si se actualizan las tablas en tiempo real o de forma peri´odica

La reconstrucci´on debe hacerse usando tablas sombreadas para poder seguir usando las tablas resumen antiguas

Cuando tenemos lista la nueva tabla resumen, cambiamos el nombre

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

cambiamos el nombre Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Tablas de contadores Se aconseja

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Tablas de contadores

Se aconseja que las tablas de contadores sean independientes

Resulta en tablas r´apidas y peque˜nas

Un contador es esencialmente un sem´aforo que crea problemas de concurrencia

CREATE

TABLE

hit_counter

(cnt

int

unsigned

not

null);

UPDATE

hit_counter

SET

cnt=cnt+1;

Se recomienda paralelizar mediante contadores parciales:

CREATE

TABLE

hit_counter

(slot

tinyint

unsigned

not

null

primary

key,

cnt

int

unsigned

not

null);

UPDATE

hit_counter

SET

cnt=cnt+1

WHERE

slot=RAND()*100;

Enxe˜nar´ıa Inform´atica

SELECT

SUM(cnt)

FROM

hit_counter;

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

Inform´atica SELECT SUM(cnt) FROM hit_counter; Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

BD3: Dise˜no F´ısico - MySQL

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de esquemas e ´ındices Desnormalizaci´on Las

Optimizaci´on

Optimizaci´on de esquemas e ´ındices

Desnormalizaci´on

Las actualizaciones normalizadas son m´as r´apidas que las no normalizadas

En los datos normalizados no hay redundancia por lo que hay menos datos que modificar

No tener redundancia implica un menor uso de DISTINCT o GROUP BY

Las tablas normalizadas son m´as peque˜nas por lo que encajan mejor en memoria

Sin embargo, en un esquema normalizado las recuperaciones implican combinaciones que son costosas

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

que son costosas Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de hw. y sw.
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on de hw. y sw.

Contenidos

1

Introducci´on a MySQL

2

Replicaci´on

3

Copia de seguridad y recuperaci´on

4

Medici´on de rendimiento y perfilado

5

Medici´on del rendimiento Perfilado de aplicaciones Optimizaci´on Optimizaci´on de esquemas e ´ındices Optimizaci´on de hw. y sw. Optimizaci´on del servidor

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

del servidor Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de hw. y sw.
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on de hw. y sw.

Introducci´on

El hardware y el software sobre los que se ejecuta SGBD determinan la eficiencia de MySQL (tama˜no de disco, memoria disponible,

recursos de CPU, red

Se necesitan directrices para resolver cuellos de botella del hardware y del sistema operativo Prestaremos atenci´on a los siguientes aspectos

)

Selecci´on de CPU Equilibrar recursos de memoria y disco Elegir discos (RAID, NAS) Configuraci´on de red

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

Configuraci´on de red Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de hw. y sw.
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on de hw. y sw.

Introducci´on

Cuellos de botella comunes:

Saturaci´on de CPU. Com´un cuando MySQL trabaja con datos que caben en memoria o pueden ser le´ıdos de disco tan r´apido como sea necesario. Ejemplos: ops. criptogr´aficas intensivas, combinaciones sin ´ındices Saturaci´on E/S. Se trabaja con m´as datos de los que caben en memoria. Se vac´ıa cach´e para traer m´as datos, y al rato los datos vaciados se tienen que volver a cargar

Posibles errores de interpretaci´on:

Escasez de memoria se puede interpretar como falta de capacidad E/S Bus de memoria saturado se puede interpretar como problema de la CPU

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

como problema de la CPU Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de hw. y sw.
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on de hw. y sw.

Selecci´on de la CPU

¿CPU r´apida o muchas CPUs no tan r´apidas?

MySQL aprovecha mal el paralelismo ya que asigna una operaci´on a una CPU. Problemas de escala con muchas CPU En funci´on del tipos de rendimiento deseable:

Baja latencia

Tiempo de respuesta r´apido para cada consulta. Mejor CPUs r´apidas porque cada petici´on s´olo aprovecha una CPU.

Alto rendimiento:

Muchas peticiones simult´aneas. Mejor muchas CPUs, pero como MySQL escala mal no funciona el “cuantas m´as mejor”. Al final: meter m´as CPUs hasta que deje de compensar y llegados a ese punto: intentar que sean lo m´as r´apidas posible.

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

m´as r´apidas posible. Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de hw. y sw.
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on de hw. y sw.

Selecci´on de la CPU

¿Cu´ando compensan muchas CPUs?

MySQL puede aprovechar CPUs “secundarias” para tareas en segundo plano (ops. de red, limpieza de b´uferes InnoDB) Esas tareas son “menores” en comparaci´on con la ejecuci´on de peticiones de los usuarios Muchas CPUs compensan realmente si:

Muchas conexiones que acceden a tablas diferentes (no compiten por bloqueos) Rendimiento total del servidor m´as importante que el tiempo de respuesta de una petici´on particular

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

petici´on particular Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de hw. y sw.
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on de hw. y sw.

Equilibrar recursos memoria / disco

Disponer de mucha memoria evita E/S del disco Es necesario encontrar un equilibrio entre el tama˜no de memoria y disco teniendo en cuenta rendimiento y coste Ejemplo: Lecturas aleatorias o secuenciales

Discos actuales: 200 operaciones E/S por segundo, 200 MB/segundo de forma secuencial Memoria actual: 1.300 millones de operaciones E/S por segundo, 10.000 MB/segundo de forma secuencial Acceso aleatorio: 200 filas/segundo de disco, 100.000 filas/segundo de memoria Acceso secuencial: 2 millones de filas/segundo de disco, 10 millones de filas/segundo de memoria

Resultado: Lecturas aleatorias o secuenciales

Accesos aleatorios: 500 veces m´as r´apidos en memoria que en disco Accesos secuenciales: 5 veces m´as r´apidos en memoria que en disco Se ahorra mucho m´as trabajo almacenando lecturas aleatorias en cach´e A˜nadir memoria es la soluci´on para solucionar problemas de E/S aleatoria

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

de E/S aleatoria Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez Enxe˜nar´ıa Inform´atica

Enxe˜nar´ıa Inform´atica

BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de hw. y sw.
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on de hw. y sw.

Equilibrar recursos memoria / disco

Cach´e de las BDs (ej. grupo de b´uferes InnoDB) funciona mejor que cach´e de SO (generalista)

M´as conocimiento sobre los datos que necesita L´ogica para fines especiales No necesita llamadas al sistema

Aspectos a tener en cuenta al considerar el tama˜no de la cache

Conjunto de trabajo

Datos que la aplicaci´on necesita en la cach´e en memoria Incluye datos e ´ındices

Unidad de cach´e

Unidad de datos m´as peque˜na con la que puede trabajar el motor de almacenamiento InnoDB: 16KB Fila 100 Bytes puede necesitar cargar 32 KB en cach´e (datos e ´ındice)

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

(datos e ´ındice) Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de hw. y sw.
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on de hw. y sw.

Equilibrar recursos memoria / disco

P´erdida de cach´e: datos no en cach´e, hay que ir a buscarlos a disco Forma f´acil de medirla: por el uso CPU (90 % tiempo CPU, 10 % E/S -> proporci´on p´erdida cach´e buena) Buscar proporci´on de p´erdida aceptable

No se arregla simplemente a˜nadiendo m´as memoria (ej., deficiencias por tama˜no de unidad de cach´e) Ejemplo:

Sistema con 10 GB de memoria con 10 % p´erdida Si fuese lineal: 11 % m´as de memoria (11,1 GB) nos dar´ıa 0 % de p´erdida En realidad, bajar a 1 % podr´ıa requerir 500 GB de memoria

La escalibilidad la determina el eslab´on m´as d´ebil Ejemplo:

sistema con 16 GB memoria, 20 GB datos y mucho disco libre que funciona bien Algunos componentes pueden estar a m´as del 50 % de su capacidad m´axima (ej. 80 % de n´umero m´aximo de operaciones de E/S) Aumentar a 40 GB datos (doble) no se puede soportar aumentando simplemente la memoria: la velocidad de transferencia del disco funciona a tope!!

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

disco funciona a tope!! Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de hw. y sw.
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on de hw. y sw.

Selecci´on de discos

Factores a tener en cuenta:

Capacidad de almacenamiento

No suele ser un problema (tama˜no actual de los discos m´as que suficiente) Pr´actica est´andar: combinar discos peque˜nos y RAID Ventajoso tener m´as capacidad de la necesaria: aumenta la localidad de los datos

Velocidad de transferencia: no suele ser un factor que limite las aplicaciones online Tiempo de acceso: es el factor determinante para agilizar b´usquedas aleatorias Tama˜no f´ısico: discos m´as peque˜nos son m´as r´apidos y ocupan menos (f´ısicamente) El aprovechamiento depende del motor. InnoDB escala bien entre 10 y 20 discos

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

entre 10 y 20 discos Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de hw. y sw.
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on de hw. y sw.

Selecci´on de discos

Selecci´on de RAID

de hw. y sw. Selecci´on de discos Selecci´on de RAID Enxe˜nar´ıa Inform´atica Miguel R. Luaces

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

Selecci´on de RAID Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de hw. y sw.
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on de hw. y sw.

Selecci´on de discos

M´ultiples vol´umenes ¿D´onde colocamos los archivos?

Archivos de datos e ´ındice Archivos de registros transaccionales

Archivos de registros binarios Archivos de registro general (registros de errores, registro de

peticiones, registro de consultas lentas, Archivos y tablas temporales

)

Por defecto, todos los archivos en un unico´ InnoDB:

directorio

datos e ´ındices en un unico´

S´olo los archivos de definici´on de tablas van aparte, en el directorio

de cada base de datos

conjunto de archivos

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

conjunto de archivos Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de hw. y sw.
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on de hw. y sw.

Selecci´on de discos

M´ultiples vol´umenes

Usar m´ultiples vol´umenes puede ayudarnos a gestionar E/S pesada Regla cl´asica: registros transaccionales y archivos de datos en vol´umenes diferentes

E/S secuencial de tx. no interfiere con E/S aleatoria de datos

En realidad, no es tal ventaja

Escrituras en registro son peque˜nas Cach´es RAID agrupan escrituras: se convierten en muchas menos escrituras por segundo No interfieren con E/S de datos

Ventaja real:

En caso de fallo, mucho m´as seguro tenerlos separados Si se pierden los datos: se pueden recuperar usando el registro Recuperaci´on point-in-time

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

point-in-time Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de hw. y sw.
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on de hw. y sw.

Selecci´on de discos

Dedicar discos a registros transaccionales depende del coste, no del rendimiento Ejemplo:

4 discos duros: 2 para datos, 2 para registros transaccionales

1/2 del disco perdido para datos 1 disco para un trabajo trivial (la cach´e del disco hace todo el trabajo)

10 discos duros: 2 para datos, 2 para registros transaccionales

Proporcionalmente menos caro

Configuraci´on t´ıpica:

SO, swap y registros binarios en RAID 1

Resto: un unico´

volumen en RAID 5 o RAID 10

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

en RAID 5 o RAID 10 Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on de hw. y sw.
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on de hw. y sw.

Configuraci´on de red

El mayor problema es la latencia

En una aplicaci´on t´ıpica hay muchas transferencias peque˜nas y se suman los retrasos de cada transmisi´on

La causa principal es la p´erdida de paquetes, 1 % de p´erdida produce degradaci´on significativa Optimizaciones:

Pocas conexiones, peticiones o resultados grandes: aumentar el tama˜no del buffer TCP

Aumenta el n´umero de paquetes que se pueden mandar “de una tacada” Modificable en origen y destino

S´olo conexiones locales: acortar timeout de cierre de conexi´on (por defecto, un minuto) Otras: Eliminar latencia resoluci´on DNS: skip name resolve

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

DNS: skip name resolve Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Contenidos

1

Introducci´on a MySQL

2

Replicaci´on

3

Copia de seguridad y recuperaci´on

4

Medici´on de rendimiento y perfilado

5

Medici´on del rendimiento Perfilado de aplicaciones Optimizaci´on Optimizaci´on de esquemas e ´ındices Optimizaci´on de hw. y sw. Optimizaci´on del servidor

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

del servidor Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Introducci´on

No existe el archivo de configuraci´on ´optimo. Cada servidor necesita una configuraci´on diferente, dependiendo de:

hardware

tama˜no datos,

tipos de consultas Requisitos del sistema (tiempo de respuesta, duraci´on tx,

consistencia,

)

La configuraci´on de MySQL predeterminada est´a pensada para no utilizar muchos recursos.

No da por hecho m´aquina dedicada. Reserva recursos suficientes para iniciar MySQL y ejecutar consultas sobre pocos datos

Para definir configuraci´on a medida:

Partir de alguno de los ficheros de configuraci´on de ejemplo. No esperar muchas mejoras con cada cambio Inicialmente, cambios que duplican o triplican rendimiento Despu´es, mejoras incrementales

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

mejoras incrementales Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Introducci´on

La configuraci´on permanente MySQL se almacena fichero my.cnf

Se configura mediante la asignaci´on de valores a variables

Es posible ejecutar m´ultiples instancias desde una sola configuraci´on con secciones independientes.

´

Ambitos de las variables:

Global (se aplican al servidor y a cada conexi´on) Sesi´on (se aplican a una conexi´on espec´ıfica) Espec´ıficas para un objeto

Valores demasiado altos generan problemas (i.e. quedarnos sin memoria)

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

quedarnos sin memoria) Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Introducci´on

El proceso debe ser el siguiente:

Preparar y realizar mediciones de prueba antes de empezar a ajustar servidor

Pruebas que representen carga de trabajo real Incluir consultas complejas

Definir un sistema de supervisi´on para medir si cambio mejora o empeora rendimiento Cambiar una o dos variables, un poco, cada vez, y hacer prueba de medici´on Ajustar hasta que todo funciona “bastante bien” No insistir a menos que creamos que podemos obtener mejora significativa (el esfuerzo no compensa)

Los “acantilados” son t´ıpicos: incrementamos variable un poco y mejora rendimiento; la incrementamos un poco m´as, y el rendimiento cae en picado

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

cae en picado Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Introducci´on

No comenzar a ajustar configuraci´on sin un esquema y consultas estables

Todos los ´ındices creados Si modificamos esquema despu´es de ajustar configuraci´on: volver a empezar

Describiremos estos aspectos

Ajuste de uso de memoria Ajustes de cach´es Ajustes E/S Concurrencia

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

Ajustes E/S Concurrencia Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Ajuste de uso de memoria

Comenzar con el l´ımite superior de memoria disponible para MySQL

Restar la memoria que necesita SO para ejecutarse bien

Restar la memoria necesaria para cada conexi´on (buffer ordenaci´on, tablas temporales)

Usar el resto memoria para las cach´es de MySQL

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

las cach´es de MySQL Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Ajuste de uso de memoria

L´ımite superior de memoria

Inicial: memoria f´ısica del servidor Kernel Linux limita tama˜no m´aximo memoria para un proceso (en general, par´ametros espec´ıficos del SO como el tama˜no de pilas Librer´ıas (glibc) tambi´en pueden fijar sus propios l´ımites

Memoria para el SO

Necesario reservar memoria para que el SO haga su trabajo Mejor indicador de asignaci´on correcta: poco intercambio de memoria virtual Normalmente: 1-2 GB (incluso en m´aquinas con mucha memoria f´ısica)

Asignar siempre algo de memoria adicional (para tareas peri´odicas

que consuman mucha memoria, copias de seguridad

No tener en cuenta memoria para cach´es (esa la tratamos aparte)

)

)

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

la tratamos aparte) ) ) Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Ajuste de uso de memoria

Necesidades de memoria por conexi´on

Cada conexi´on, peque˜na cantidad de memoria para mantenerse abierta Tambi´en, peque˜na cantidad para ejecutar una consulta dada Necesitamos memoria suficiente para momentos de picos de carga Dif´ıcil de predecir. No es necesario suponer peor caso. Ejemplo:

Configurar para 100 conexiones simult´aneas Fijamos tama˜no m´aximo buffer ordenaci´on (uno por conexi´on) en 256 MB Peor caso: pico de carga supondr´ıa 25 GB (Muy poco probable)

Buena soluci´on: observar servidor con carga de trabajo real y comprobar cu´anta memoria utiliza

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

cu´anta memoria utiliza Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Ajuste de uso de memoria

Toda la memoria que no se use: dedicada a cach´es MySQL necesita m´as memoria para cach´es que para el resto de elementos

Cach´e del SO trabaja para MySQL pero MySQL necesita mucha memoria para s´ı mismo

Cach´es m´as importantes:

Cach´e de claves MyISAM Grupo de b´uferes InnoDB Cach´e de subprocesos

Existen otras cach´es, pero no requieren mucha memoria

M´as f´acil ajustar servidor que usa un unico´

Mezcla de motores: dif´ıcil encontrar equilibrio

motor de almacenamiento

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

motor de almacenamiento Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Cach´e de claves MyISAM

Para almacenar ´ındices (no datos, MyISAM lo delega en el sistema operativo)

Si s´olo usamos MyISAM: dedicar mucha memoria a esta cach´e

Si se usa tambi´en InnoDB: ajustar al 25-30 % de la cantidad de memoria reservada para las cach´es

Una predeterminada, pero se pueden crear m´as

key_buffer_1.key_buffer_size=1G

key_buffer_2.key_buffer_size=1G

Para asignar ´ındices a un buffer:

CACHE

INDEX

t1,

t2

in

key_buffer_1;

LOAD

INDEX

INTO

CACHE

t1,t2;

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

INTO CACHE t1,t2; Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Cach´e de claves MyISAM

Supervisar rendimiento buffer:

% buffer en uso

100-

((key_blocks_unused*key_cache_block_size)*100/key_buffer_size)

% de aciertos:

100-((key_reads*100)/key_read_requests)

Fallos por segundo:

key_reads/uptime

El % aciertos es el menos significativo porque depende mucho de la aplicaci´on El n´umero de fallos por segundo es el m´as significativo El % buffer en uso permite conocer si hemos reservado demasiado espacio Aunque no se usen tablas MyISAM hay que reservar espacio a la cache porque MySQL las usa para ciertas operaciones

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

para ciertas operaciones Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Cach´e de claves MyISAM

El tama˜no de bloque de la cach´e de claves MyISAM es configurable a partir de MySQL 5.1

Debe ser el mismo tama˜no que el bloque del SO para ahorrar lecturas Ejemplo: bloque MyISAM 1 KB, SO 4 KB

MyISAM solicita bloque de claves de 1KB del disco SO recupera 4KB del disco, guarda en cach´e y entrega bloque de 1KB a MyISAM SO libera cach´e al cargar nuevos datos MyISAM modifica bloque de 1KB y pide al SO que escriba en disco SO vuelve a leer mismos 4KB, modifica bloque 1 KB y graba en disco 4KB Si bloque MyISAM fuese de 4KB: ahorramos la lectura del paso anterior

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

del paso anterior Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Conjunto de b´uferes InnoDB

Si usamos tablas InnoDB el conjunto de b´uferes necesitar´a m´as memoria que cualquier otra opci´on

Almacenan ´ındices, datos de filas, buffer de inserciones, bloqueos, otras estructuras internas

Habitual: reservar 80 % de la memoria f´ısica de la m´aquina

Cuando el % de p´aginas sucias excede el umbral establecido un proceso autom´atico inicia el volcado a disco

Valor predeterminado del % de p´aginas sucias es el 90 %

Si subimos el umbral tolera mejor picos de actualizaciones

Si bajamos umbral: tarda menos en cerrarse (se acumulan menos p´aginas que grabar)

Si el tama˜no demasiado grande se ralentiza el arranque y la parada del servidor

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

y la parada del servidor Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Cach´e de subprocesos

Pool de procesos libres preparada para conexiones nuevas

Entra conexi´on: se le asigna proceso de la cach´e Conexi´on se cierra: proceso vuelve a estar disponible en la cach´e Si no hay sitio: el proceso se destruye

N´umero m´aximo de subprocesos en cache: thread_cache_size Monitorizaci´on:

Intentar mantener threads_created entre 1-10 por segundo Revisar threads_connected para configurar el tama˜no de la cache de forma que sea capaz de contener la fluctuaci´on t´ıpica de la carga de trabajo

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

de la carga de trabajo Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Cach´e de tablas MyISAM

Guarda objetos que representan tablas

Necesita poca memoria, ayuda a conservar recursos Dos partes:

Cach´e de definici´on de tablas (table_definition_cache)

Contenido del archivo .frm analizado sint´acticamente A poder ser, fijar tama˜no para que quepan todas las definiciones de nuestras tablas

Cach´e de tablas abiertas (table_open_cache)

Descriptores de archivos (datos, ´ındices)

Si un proceso necesita acceso a una tabla puede obtener descriptor desde la cache

Si la variable opened_tables demasiado grande, o est´a incrementando: aumentar cach´e

Aumentar n´umero de archivos que pueden permanecer abiertos:

open_files_limit

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

open_files_limit Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Ajuste E/S: MyISAM

Cada escritura en cach´e de claves (´ındices), por defecto, se graba inmediatamente a disco Es posible retrasar escrituras para realizarlas por lotes (variable delay_key_write)

OFF: bloques se graban inmediatamente a disco (en cuando tabla quede desbloqueada) ON: se retrasan escrituras hasta cierre de tabla (si es una tabla marcada con DELAY KEY WRITE) ALL: todas las tablas tienen escritura retardada

Problemas:

Si servidor se detiene y los bloques no se han volcado, ´ındice queda da˜nado Si se retrasan muchas escrituras, las tablas tardan m´as en cerrarse Demasiados bloques sucios en cache: no dejan espacio para nuevos:

consultas pueden retrasarse

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

pueden retrasarse Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Ajuste E/S de InnoDB: Registro de transacciones

Para ahorrar E/S aleatorias en p´aginas de datos se graba secuencialmente las ops. en el registro (de transacciones

Transacciones persistentes a´un sin haber volcado datos a disco

Proceso de vaciado en segundo plano convierte registro de tx en ops de volcado de datos secuenciales m´as eficientes

Tama˜no del archivo de log: vital para rendimiento de la escritura

Dividido en varios archivos. Registro circular unico.´

Tama˜no total: suma del tama˜no de los archivos

Predeterminado: dos archivos de 5 MB (10 MB totales)

L´ımite superior: 4 GB

Tama˜no t´ıpico para alto rendimiento: 256 MB

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

alto rendimiento: 256 MB Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Ajuste E/S de InnoDB: Registro de transacciones

Tama˜no ideal registro, valorar:

Carga actualizaciones rutinarias de datos Tiempo de recuperaci´on requerido en caso de ca´ıda del sistema

Si registro demasiado peque˜no: InnoDB realizar´a m´as vaciados Si registro demasiado grande: mucho trabajo para InnoDB cuando se tenga que recuperar

Escaneo del registro Examinar archivos de datos Aplicar cambios a los archivos de datos

Supervisi´on del rendimiento:

Anotar valor m´aximo de variable innodb_os_log_written a intervalos de 10-100 segundos Usarlo para determinar tama˜no del registro y del buffer del registro M´aximo 100 KB/s : buffer de registros de 1 MB lleno en 10 seg Archivos de registro de 256 MB: 2.560 segundos de entradas en el registro

Enxe˜nar´ıa Inform´atica

Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez

entradas en el registro Enxe˜nar´ıa Inform´atica Miguel R. Luaces (luaces@udc.es) - Juan Ram´on L´opez Rodr´ıguez
BD3: Dise˜no F´ısico - MySQL Optimizaci´on Optimizaci´on del servidor
BD3: Dise˜no F´ısico - MySQL
Optimizaci´on
Optimizaci´on del servidor

Ajuste E/S de InnoDB: Buffer del registro de transacciones

Se guarda registro de los cambios en un buffer en memoria El buffer se vuelca a disco (a los archivos del registro de transacciones):

Cuando buffer de registros se llena Cuando se confirma una transacci´on Una vez por segundo

Tama˜no buffer: por defecto, 1 MB

Rango recomendado: 1-8 MB

Al volcar buffer a archivos de log: se vuelcan estos a almacenamiento duradero

Podemos perder como m´aximo 1 segundo de transacciones

Enxe˜nar´ıa Inform´atica