DesenoFisico MySQL PDF

BD3: Diseño Fı́sico - MySQL
Bases de Datos III

Diseño Fı́sico - MySQL
Enxeñarı́a Informática
Curso 2013/2014
Miguel R. Luaces
Laboratorio de Bases de Datos
Universidade da Coruña
Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Contenidos
1 Introducción a MySQL
2 Replicación
3 Copia de seguridad y recuperación
4 Medición de rendimiento y perfilado
Medición del rendimiento
Perfilado de aplicaciones
5 Optimización
Optimización de esquemas e ı́ndices
Optimización de hw. y sw.
Optimización del servidor

Introducción a MySQL
Contenidos
2 Replicación
5 Optimización

MySQL Community Server

Versión actual: 5.6.17
Documentación: 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

MariaDB
An enhanced, drop-in replacement for MySQL
Versión actual: 5.5.36
Documentación: https://kb.askmonty.org/en/
Funciona sobre todas las plataformas: Mac OS X, Windows,
GNU/Linux
Mejoras sobre MySQL 5.5:
Más motores de almacenamiento (ej.: No-SQL)
Optimizaciones
Extensiones (ej.: virtual columns)
Completamente Open Source

Arquitectura de MySQL
Clientes
Conexión / Control de subprocesos
Caché de Analizador
consultas sintáctico
optimizador
API del motor de

almacenamiento
(“Iniciar transacción”,
“recuperar registro con
clave x”)
Motores de almacenamiento
Cada consulta es atendida por un thread del pool servidor
La caché consultas almacena sentencias select junto con su resultado
Si la consulta no está en caché, tras el análisis sintáctico, se realiza
la optimización del plan de ejecución
Reescritura de la consulta
Determinación del orden de acceso a las tablas
Selección de los ı́ndices a utilizar
Inclusión de las caracterı́sticas especı́ficas de los motores de
almacenamiento

Caracterı́stica única: separación de tareas de servidor (conexiones,
procesamiento de consultas, optimización) de tareas de
almacenamiento y recuperación de datos
Se puede elegir el motor de almacenamiento a nivel de tabla
Se pueden cargar motores de almacenamiento en tiempo de ejecución
Describiremos brevemente los siguientes aspectos de MySQL:
Control de concurrencia
Gestión de transacciones
Motores de almacenamiento
Criterios de selección

Los bloqueos permiten evitar que un cliente lea un fragmento de
datos mientras otro lo está cambiando
Hay dos tipos de bloqueos: compartidos (lectura) y exclusivos
(escritura)
Los SGBD permiten distintas granularidades a los bloqueos (tabla,
página 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.

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 más frecuentes que
las modificaciones
Es eficiente en el caso de modificaciones simultáneas en varias filas
InnoDB realiza bloqueos a nivel de fila
Permite la máxima 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 cancelación de transacciones
El servidor de MySQL puede bloquear tablas independiente del motor
para garantizar corrección de sentencias DDL como ALTER TABLE

MySQL incluye motores transaccionales (InnoDB) y no
transaccionales (MyISAM, Memory)
El estándar SQL define cuatro niveles de aislamiento:
Read uncommited
Read commited
Repeatable read
Serializable
Las figuras de las siguientes diapositivas se extrajeron de aquı́:
http://www.byteslounge.com/tutorials/spring-transaction-isolation-tutorial

Read uncommited
No hay bloqueos, por lo que una transacción lee datos sin confirmar
de otra transacción
Permite lecturas sucias porque la segunda transacción podrı́a ser
cancelada

Read commited
Los bloqueos de escritura se mantienen hasta el fin de la transacción
Los de lectura se liberan al finalizar la lectura
Una transacción sólo lee datos de transacciones confirmadas
Permite lecturas no-repetibles porque los datos podrı́an cambiar
después de leidos

Repeatable read
Todos los bloqueos se mantienen durante toda la transacción
Cualquier fila que lea una transacción será igual en sucesivas lecturas
Como no hay bloqueo de rangos, permite lecturas fantasma
Es la predeterminada en InnoDB

Serializable
Aislamiento completo de las transacciones usando bloqueos de rango.
InnoDB permite el nivel de aislamiento serializable mediante
Multiversion Concurrency Control (MVCC)
Mantiene instantáneas de los datos tal y como existı́an en un
determinado momento
Diferentes transacciones ven simultáneamente datos distintos en las
mismas tablas
Evita la necesidad de bloquear filas en modo lectura

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
máximo
La solución consiste en reanudar alguna de las transacciones
InnoDB detecta dependencias circulares y reanuda la transacción con
los bloqueos de fila menos exclusivos

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 página de disco
El almacenamiento en disco se realiza mediante un registro de
transacciones usando escritura secuencial (y por tanto, rápida)
Los datos en disco se escriben cuando la página 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 transacción
Por ejemplo, los cambios en tablas MyISAM no se pueden deshacer
con un rollback
MySQL no informa del error de ninguna manera

Motores de almacenamiento: MyISAM

Motor predeterminado para las tablas hasta MySQL 5.1
No soporta transacciones ni claves foráneas, y sólo permite bloqueos
a nivel de tabla
El tamaño máximo de una tabla es 256 TB
Cada tabla se almacena en un fichero del sistema operativo
Variantes:
Tablas con filas de tamaño fijo (estáticas) y tamaño variable
(dinámicas)
Tablas comprimidas y de sólo lectura
El espacio usado en disco es mı́nimo
Óptimo para soportes de sólo lectura y/o lentos
Se construyen con la utilidad myisampack

Motores de almacenamiento: InnoDB

Motor predeterminado para las tablas desde MySQL 5.5
Soporta transacciones, claves foráneasy bloqueos a nivel de fila
El tamaño máximo de una tabla es 64 TB
Las tablas se almacenan en archivos de datos administrados por el
motor y que pueden utilizar particiones raw
Índices agrupados (clustered indexes)
Se crea un ı́ndice para la clave principal de la tabla que se almacena
en las mismas páginas que las filas
Las búsquedas por clave principal son rápidas porque ahorran un
acceso a disco
Los ı́ndices secundarios (todos los demás) siempre incluyen los
atributos de la clave principal para usar el ı́ndice agrupado en las
búsquedas
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
Motores de almacenamiento: Memory

Tablas que se guardan en la memoria del servidor y que no permiten
la persistencia
No soportan transacciones ni claves foráneas. Los bloqueos son a
nivel de tabla
El tamaño máximo de una tabla depende de la memoria del servidor
Permite un acceso muy rápido a los datos (un orden de magnitud
más rápido que el motor MyISAM)
El espacio ocupado por una tabla sólo se devuelve al borrar o recrear
la tabla
Ejemplos de posibles usos:
Tablas de búsqueda rápida (i.e. códigos postales)
Guardar en caché datos agregados periódicamente
Resultados intermedios de procesos
MySQL lo usa para procesar consultas que necesitan tablas
temporales

Motores de almacenamiento: otros

Motor Merge
Combinación de varias tablas MyISAM en una única tabla virtual
Permite la partición de información en diferentes bloques
Posibles usos: gestión de archivos de log, superar la limitación de
tamaño de archivo del SO
Motor Blackhole
No almacena datos. Todas las inserciones se descartan
Mantiene un registro de operaciones realizadas
Posibles usos: auditorı́a, algunas configuraciones de replicación
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

Motores de almacenamiento: selección

Dado que podemos elegir el motor de almacenamiento para cada
tabla, necesitamos conocer cómo se va a utilizar cada tabla, cómo
funciona la aplicación, y su evolución potencial
En función del uso de transacciones:
Si la aplicación requiere transacciones, la única opción es InnoDB
Si no requieren transacciones y las consultas son SELECT e INSERT,
MyISAM es buena opción
En función de la concurrencia en las operaciones:
Depende de la carga de trabajo esperada
Si sólo hay inserciones y lecturas: MyISAM
Si queremos una mezcla de operaciones concurrentes sin
interferencia, necesitamos un motor con bloqueo a nivel de fila
(InnoDB)

Motores de almacenamiento: selección

En función 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 múltiples motores complica el proceso de copia de
seguridad
En función de la necesidad de operaciones especiales:
Sólo InnoDB incluye ı́ndices agrupados y optimizaciones basadas en
ellos
InnoDB sólo permite búsquedas de texto completo desde la versión
5.6.4

Motores de almacenamiento: cambios

Métodos 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 métodos son lentos pues implican la copia de los datos
El método basado en ALTER TABLE implica un bloqueo de
escritura en la tabla

Motores de almacenamiento: ejemplos

Registro de llamadas de central telefónica 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 recopilación de datos
ralentiza las inserciones
Alternativas:
Realizar la recopilación en horas de poca carga
Replicar la base de datos en un segundo servidor esclavo en el que se
harán 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 número limitado
de usuarios, MyISAM
Si es un servicio web con mucho tráfico, miles de usuarios y
alimentación de cotizaciones en tiempo real, InnoDB
Una consulta no debe esperar
Miles de usuarios intentando leer mientras simultáneamente se
actualizan filas requiere bloqueos a nivel de fila

Motores de almacenamiento: ejemplos

Boletines de anuncios y foros de discusión
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 pequeña, MyISAM no es imprescindible
InnoDB no es capa de ejecutar rápidamente 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 sólo lectura

Replicación
Contenidos
2 Replicación
5 Optimización

Replicación
Definición de replicación
Consiste en configurar uno o varios servidores como esclavos - o
réplicas - 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
sólo algunas tablas

Replicación
Problemas resueltos por la replicación

Distribución de datos
No exige un ancho de banda intensivo y funciona con una conexión
intermitente
Útil para mantener una copia de los datos en una ubicación
geográficamente 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 versión 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

Replicación
Funcionamiento de la replicación
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
repetición (relay log)
El esclavo repite todos los eventos del registro de repetición sobre
sus propios datos

Replicación
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
Está 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 ejecutó el evento en el servidor de origen
Tipo de evento (por ejemplo, Query)
Detalles del evento

Replicación
El registro binario de mySQL permite tres tipos de replicación:
Basada en sentencias (statement-based replication)
Se registra la instrucción 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 replicación de cualquier instrucción
El registro aumenta de tamaño
No es fácil auditar los cambios realizados
Mixta (mixed-format replication)
MySQL decide en función de la instrucción que se ejecuta si se usa
replicación basada en sentencias o en filas
Se usa la replicación basada en sentencias a no ser que la instrucción
no sea segura
Ver la descripción en el manual
Replicación
El proceso para configurar la replicación es el siguiente:
Configurar cuentas de replicación en cada servidor
El thread E/S del esclavo hace una conexión 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 repetición
Inidicar al esclavo como conectarse al maestro y desde qué punto del
registro binario hay que replicar
Opcionalmente, activar el registro binario y configurar su
actualización

Replicación
Es posible replicar sólo parte de los eventos de un servidor,
utilizando diferentes tipos de filtros
Filtros sobre el registro binario del maestro
Filtros sobre el registro de repetición

Replicación
Topologı́as de replicación
Las restricciones en la replicación son las siguientes:
Cada esclavo sólo puede tener un maestro
Un maestro puede tener muchos esclavos
Un esclavo puede actuar también como maestro
Estas restricciones permiten diferentes topologı́as con diferentes
aplicaciones
Un maestro, múltiples esclavos
Maestro-maestro en modo activo-activo
Maestro-maestro en modo activo-pasivo
Anillo
Maestro, maestro de distribución, esclavos
Árbol o pirámide

Replicación

Replicación
La topologı́a más sencilla y más común
Todas las escrituras se realizan en el maestro, las lecturas se pueden
realizar en cualquier servidor
El número de esclavos está 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 recuperación
Utilizar un esclavo para copia de seguridad, para pruebas o para
desarrollo

Replicación
Maestro-maestro en modo activo-activo
Cada maestro es a su vez esclavo del otro

Cualquier servidor se puede utilizar para cualquier operación
Posible uso: oficinas separadas geográficamente, donde cada oficina
necesita su copia local de los datos
Problemas: cambios conflictivos
Actualización simultánea de la misma fila en ambos servidores
Inserciones simultáneas con columnas AUTO INCREMENT
¿Y si la replicación se detiene por un tiempo? ¿Cómo reenganchamos
después?
Sólo se recomienda si tenemos datos bien particionados y buen
reparto de privilegios
Replicación
Maestro-maestro en modo activo-pasivo
Uno de los servidores es un servidor “pasivo” de sólo lectura

Permite intercambiar los papeles de forma muy sencilla: las
configuraciones son simétricas
Mantenimiento, optimización 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
Replicación
Anillo

Replicación
Anillo
Tres o más maestros
Cada servidor es un esclavo del servidor que está antes en el anillo, y
maestro del servidor que está después
Configuración simétrica, failover fácil.
Es una configuración frágil:
Depende enormemente de que todos los nodos funcionen
correctamente
Difı́cil que estén todos sincronizados a la vez: detener algún nodo es
complicado
Si eliminamos un nodo sin tener cuidado, sus eventos pueden
propagarse de forma infinita por el anillo. ¡El único nodo que filtra un
evento es el que lo ha generado!

Replicación

Replicación
Similar a la topologı́a maestro-esclavos, pero no sobrecarga al
maestro principal
El maestro principal sólo tiene un esclavo que a su vez actúa como
maestro de distribución
El maestro de distribución usa el motor BlackHole que graba en el
registro binario pero no mantiene tablas ni datos

Replicación

Replicación
Si hay muchos esclavos, puede ser mas rentable un diseño en
pirámide
Esto alivia la carga del maestro y la redistribuye por los diferentes
esclavos
Desventaja: fallos en niveles intermedios afectan a un gran número
de servidores
Además, cuantos más niveles intermedios, más difı́cil y complicado
es manejar los fallos

Replicación
Problemas en la replicación
La replicación 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 replicación sólo escala las lecturas, no las escrituras
La distribución de la carga debe ser realizada por otro software
La complejidad de la replicación se ve claramente en la longitud de
la sección del manual

Copia de seguridad y recuperación
Contenidos
2 Replicación
5 Optimización

Introducción
Recuperación no es restauración
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 él.
Incluye todos los pasos para lograr que un servidor vuelva a ser
completamente funcional y operativo:
Restaurar copia de seguridad
Reiniciar servidor
Cambiar configuración
Calentar las cachés del servidor
Utilidades de las copias de seguridad
Recuperación ante desastres. Un error importante corrompe los datos
o el servidor
Recuperación ante cambios no deseados. La gente cambia de idea, y
ocurre más a menudo que los desastres
Auditorı́as. Necesidad de recuperar datos o esquema en algún
momento del pasado (ej. temas judiciales)
Pruebas. La manera más fácil de cargar un servidor de pruebas con
datos es usando una copia de seguridad
Introducción
El mejor sistema de copias de seguridad no es suficiente. Un buen
plan de recuperación es fundamental
El procedimiento de recuperación es complejo. Es fácil cometer
errores
Las copias de seguridad son rutinarias y no se realizan bajo
situaciones de presión extrema. La recuperación se hace en medio de
una situación de crisis
Una persona puede planear, diseñar 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 recuperación
Alternativas que no son copias de seguridad
La replicación no es una copia de seguridad
Usar discos en RAID
¿Cómo nos recuperamos en estos casos de un DROP DATABASE?

Estrategia para la copia de seguridad

No olvidar realizar copias de seguridad de recursos no obvios
Registro binario y registro de transacciones de InnoDB
Código: disparadores y procedimientos almacenados (están en la BD
mysql)
Configuración del servidor y de la replicación
Ficheros seleccionados del SO (trabajos cron, configuraciones de
usuario y de grupo, scripts administrativos, reglas sud0, etc)
¿Qué 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 más nos permitamos perder, más fácil es hacer la copia
Las copias de seguridad en MySQL son mucho más complicadas de
lo que parece

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 lógicas o sin procesar?
Copia lógica: en un formato que MySQL puede interpretar (SQL,
CSV)
Copia sin procesar: los archivos de mySQL tal y como están
almacenados en disco


Inconvenientes de copias calientes
Búferes sucios en el grupo de buffers de InnoDB (u otras cachés)
Datos modificados mientras se está haciendo la copia
Inconvenientes de copias frias
Desconectar servidor es costoso, aun si se minimiza el tiempo de
copia de seguridad
Las páginas sucias en grupo de buffers InnoDB requieren tiempo para
volcarse a disco
Reiniciar también requiere tiempo: abrir tablas, calentar cachés, etc.
Inconvenientes de copias templadas
Tiempo de espera indeterminado debido al proceso de adquirir
bloqueos


Ventajas de las copias lógicas
Archivos que se pueden manipular e inspeccionar con editores de
textos
Fáciles de restaurar
Se pueden restaurar en una máquina diferente
Independientes del motor de almacenamiento
Se pueden retocar para exportar a otros SGBD
Desventajas de las copias lógicas
El servidor debe hacer el trabajo de generarlas
Pueden llegar a ocupar mucho más que los datos en algunos casos
La reconstrucción implica volver a ejecutar todas las sentencias y
regenerar todos los ı́ndices.


Ventajas de las copias sin procesar
No hay trabajo adicional: se copian los archivos tal cual
La restauración puede ser sencillı́sima: para MyISAM, simplemente
copiar los archivos en su sitio; InnoDB, en cambio, obliga a detener
el servidor
La restauración es más rápida: no hay que ejecutar sentencias, ni
reconstruir ı́ndices
Desventajas de las copias sin procesar
Suelen ocupar mucho más espacio que las copias lógicas (por
ejemplo, el espacio de tabla InnoDB incluye mucho espacio sin
utilizar)
No siempre se pueden mover a través de las plataformas, SO y
versiones de SQL (mayúsculas/minúsculas, representación punto
flotante)

Procedimiento de copia lógica

Copia
Realizar un volcado SQL con mysqldump o CSV con SELECT *
INTO OUTFILE
Restauración
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 podrán
abrirlos)

Procedimiento de copia lógica

Hay que asegurar que los datos son consistentes en un punto de
tiempo determinado (por ejemplo, en una BD de comercio
electrónico debe haber una factura por cada pago). Es complicado
en copias calientes
En motores transaccionales: realizar la copia en una transacción
En motores no transaccionales, bloquear todas las tablas que se
deben copiar juntas
Esto no nos protege de una aplicación mal diseñada (por ejemplo, si
el pago y la factura se registran en dos transacciones distintas)

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 técnicas de gestión de ficheros del
SO (por ejemplo, LVM)
Restauración:
MyISAM: bloquear las tablas y copiar los archivos de datos
InnoDB: parar el servidor y sustituir los archivos

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
Restauración:
Restaurar la copia completa y ejecutar todos los registro binarios
Restauración a un punto concreto del tiempo
Localizar el punto de tiempo en los registros binarios y ejecutar hasta
esa posición
Eliminar el resultado de una instrucción
Localizar la instrucción y ejecutar el registro binario hasta esa
posición y desde después de esa posición

Medición de rendimiento y perfilado
Contenidos
2 Replicación
5 Optimización

Medición del rendimiento y perfilado

El objetivo de la optimización es aumentar el rendimiento de MySQL
Los elementos a optimizar son muchos. Ej: esquemas, ı́ndices,
consultas, configuración del servidor, hardware, software, aplicaciones
Necesitamos dos prácticas básicas:
Medición del rendimiento. Responde a ¿Cómo se ejecuta?
Permiten evaluar el desempeño del SGBD
Permiten determinar la capacidad máxima del sistema
Permiten discriminar los cambios que importan de los que no
Muestran cómo se ejecuta la aplicación con datos diferentes
Perfilado. Responde a ¿Por qué se ejecuta ası́?
Indica cuanto contribuye cada elemento de un sistema al coste de
producir el resultado
Lugares donde se pierde más tiempo
Lugares donde se consumen más recursos

Contenidos
2 Replicación
5 Optimización

Objetivos de las medidas

Las medidas de rendimiento permiten realizar las siguientes tareas:
Medir rendimiento actual de nuestra aplicación
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 adaptación a entornos cambiantes
Picos esporádicos, configuraciones diferentes de servidores
Probar configuraciones diferentes de hw., sw. y so.
¿RAID5 o RAID10? ¿núcleo 2.4 o 2.6 de Linux? ¿escala bien con
doble de memoria?

Estrategias para medir

Existen dos estrategias en la medida de rendimiento:
Aplicación como un todo
La preocupación última es el rendimiento de toda la aplicación
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 aplicación. Es más difı́cil si
sólo probamos una parte de ella
Aislar mySQL (SGBD, en general)
Es difı́cil aislar puntos de referencia y de configuración de la
aplicación
Acercamiento paulatino: empezar por mySQL
Interesan medidas de rendimiento cortas, con “tiempo de ciclo más
corto”
Fácil aislar consultas tı́picas y repetirlas muchas veces

Ejemplos de medidas de rendimiento

Transacciones por unidad de tiempo (clásica)
Se ajusta bien a aplicaciones interactivas de múltiples usuarios, OLTP
Unidad tı́pica: transacciones por segundo
Tiempo de respuesta (latencia)
Mide tiempo total requerido por una tarea (ej: milésimas, minutos)
La ejecución repetida permite derivar tiempos de respuesta mı́nimo,
máximo o medio
Los tiempos mı́nimos y máximos no son muy útiles porque no son
repetibles, cuanto más tiempo se ejecute la medida, más extremos
serán, 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)

Ejemplos de medidas de rendimiento

Concurrencia
Medimos el rendimiento de la aplicación bajo diferentes niveles de
concurrencia
Un ejemplo de medida: número 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 sólo es un resultado, también es una propiedad que debemos
configurar en nuestras pruebas
Escalabilidad
Útil 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):
El tamaño de la base datos
El número de conexiones concurrentes
El hw. disponible

Errores comunes en las medidas

Algunos errores comunes en la definición de medidas de rendimiento:
Usar un subconjunto no representativo de los datos

Utilizar datos sintéticos distribuidos uniformemente
Definir un escenario con un solo usuario
Medir en un solo servidor el rendimiento de una aplicación distribuida
Fallo en imitar el comportamiento del usuario: clics en vı́nculos uno
tras otro sin parar, en una aplicación web
Ejecutar consultas idénticas en un bucle, olvidando posibles pérdidas
en caché
No detectar los errores en el proceso de medida (ej: que una
operación lenta se agilice mucho puede ser debido a un error de
sintaxis en SQL)
Olvidar tener en cuenta latencia del servidor después de reinicio

Planificación de medidas de rendimiento

Proceso de planificación 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 estándar o una prueba de diseño
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
Documentación de los parámetros
Almacenamiento de los resultados

Planificación de medidas de rendimiento

Proceso de planificación 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 instantánea de los datos, usando el servidor en caliente)
Debemos tener cuidado con la carga externa y con las tareas periódicas
Cambiar la menor cantidad de parámetros posible en cada prueba (los
independientes)
Es recomendable automatizar las ejecuciones de las pruebas (scripts,
makefiles)
El número de repeticiones depende del grado de certeza que se quiera
alcanzar. Comúnmente:
Ejecutar varias veces y eliminar los resultados discrepantes
Ejecutar hasta que los resultados no varı́en demasiado (reducir la varianza)
Utilizar técnicas 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
agregación

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: número de conexiones concurrentes
Permite una instrucción 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 rápido que ejecuta el servidor las consultas
Muchas pruebas predefinidas, que permiten comparar diferentes
motores de almacenamiento y configuraciones
Mejorable (un sólo usuario, el conjunto de datos es pequeño, y usa
un solo proceso (no multiples CPU)


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 comparación OLTP
Desarrollo parado
Super Smack
Pruebas de comparación + Prueba de estrés + Herramienta de
generación de carga para MySQL y PostgreSQL
Múltiples usuarios, carga datos de prueba (aleatorios)
Lenguaje neutro (smack) para definir clientes, tablas, consultas, etc.
Desarrollo parado


Herramientas de pila completa
Ab
Incluida con el servidor HTTP Apache
Calcula el número de solicitudes que puede servir por segundo
Sólo prueba una URL todo lo rápido que pueda
httpload
Utiliza un archivo de entrada con muchas URLs de las que elige
aleatoriamente
Prueba lo más rápido que pueda, o según una velocidad establecida
(-rate)
También simula usuarios concurrentes (-parallel)
JMeter
Aplicación Java para medir el rendimiento de otros programas
Simula usuarios reales (tiempo de escalada configurable)
Interfaz gráfica que permite reproducir prueba fuera de lı́nea

Contenidos
2 Replicación
5 Optimización

Objetivos del perfilado

El perfilado de un sistema nos indica cuanto contribuye cada
elemento al coste total de producción de un resultado
Permite entender por qué 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 información
Procesamiento de resultados en memoria
Llamadas a recursos externos
Algoritmos poco óptimos
Si nos limitamos a medir tiempo de respuesta del servidor web
No tenemos estadı́sticas del sistema que permitan determinar qué
esfuerzo permite una mayor mejora
El cuello de botella puede estar en otra parte.

Proceso de perfilado
Es necesario incluir código de perfilado en las aplicaciones que tome
mediciones de:
Tiempo total de ejecución de la página
Tiempo de ejecución de las consultas
Tiempo de llamadas a recursos externos (servicios web)
Es una sobrecarga al sistema, por lo que es necesario aplicar tácticas
como
Sólo realizar el perfilado en un porcentaje pequeño de las peticiones
Guardar los datos en memoria y hacerlos persistentes en bloque

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 conexión y desconexión
Sin tiempos de ejecución: de poco interés para el perfilado
El registro de consultas lentas
Registra las consultas ejecutadas que sobrepasan un determinado
tiempo
Se puede configurar para registrar también las consultas que no
utilizan ı́ndices
Guarda tiempos de ejecución: permite perfilado
Es difı́cil de utilizar:
Una consulta es lenta porque tarda más de lo esperado, no porque
tarda más que un umbral de tiempo
Hay consultas que no tienen que usar el ı́ndice de ningún modo

Perfilado en MySQL
Desde la versión 5.1.28, MySQL permite realizar perfilado de los
recursos usados en una sesión
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 sesión
La estrategia de análisis de resultados puede ser:
Comprobar qué consultas tienen más impacto
Comprobar el plan de ejecución de esas consultas con EXPLAIN
Realizar los ajustes necesarios
Repetir el análisis

Optimización
Contenidos
2 Replicación
5 Optimización

Optimización

Optimizar esquema mal diseñado o mal indizado mejora del
rendimiento en órdenes de magnitud
Sin embargo, hay que tener cuidado con los efectos secundarios
Un nuevo ı́ndice INSERT y UPDATE más lentas
Las tablas de resumen y los contadores agilizan consultas, pero el
mantenimiento es más costoso
Los cambios requieren conocer todo el sistema y cada elemento
afectado
Describiremos estas técnicas:
Elección de tipos de datos óptimos y selección de clave primaria
Distintos tipos de ı́ndices: B+, Hash y agrupados
Estrategias de indexado
Índices para ordenación
Tablas de cache y de resumen
Tablas de contadores
Desnormalización

Optimización
Elección de tipos de datos óptimos

Elegir adecuadamente el tamaño es importante
Usar el tipo de datos más pequeño posible
Menos espacio en disco, memoria y CPU
Cuanto más 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: numérico, cadena, temporal
Paso 2: Elegir tipo especı́fico

Optimización

DATETIME vs. TIMESTAMP
Datetime: Entero empaquetado (YYYMMDDHHMMSS) de 8 bytes.
Mayor rango de valores (1001-9999, con precisión de 1 segundo).
Timestamp: Entero de 4 bytes. Número 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 más adelante
(fragmentación, reasignación de espacio)
Vale la pena cuando la longitud máxima de columna es mucho mayor
que la media y hay pocas actualizaciones, o cuando el cjto. caracteres
complejo, codificación variable (UTF-8).
Optimización

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 tamaño fijo a la memoria
Tabla temporal para ordenación: reservarı́a espacio para el máximo
tamaño posible (motor Memory necesita filas de tamaño fijo)
Mejor reservar el tamaño justo
BLOB y TEXT
Guardan grandes cantidades de datos (binarios y de cadena)
Cada motor, diferente gestión
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 ordenación)
Truco (longitud lo bastante corta para que la tabla no sobrepase
tmp table size) ORDER BY SUBSTRING(columna text, longitud)

Optimización

ENUM en lugar de cadenas
Ahorro de espacio
Es solución sólo para listas fijas de cadenas. Ampliarla: ALTER
TABLE
Además: sobrecarga de conversión de valores (por ejemplo, al
concatenar o al comparar)
Usar sólo si la lista de cadenas no va a cambiar en el futuro

Optimización
Selección 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 foráneas si no hay coincidencia exacta
Conversiones de tipo implı́citas pueden provocar errores difı́ciles de
detectar
Elegir tamaño mas pequeño necesario dejando espacio para
crecimiento futuro
Por ejemplo: un entero (4 bytes) para códigos de provincias implica
mucho espacio en claves externas
Las cadenas de caracteres son una mala elección porque ocupan
mucho espacio y son más lentas que los enteros
Las cadenas de caracteres aleatorias (estilo UUID) implican:
ralentización de los INSERT ya que el valor se inserta en una posición
aleatoria del ı́ndice que puede crear fragmentación de páginas
mal rendimiento de las caches ya que se elimina la localidad
ralentización de los SELECT porque filas adyacentes en el resultado
quedan dispersas en disco y memoria si las filas se almacenan
ordenadas por clave
Optimización
Revisión de los esquemas generados automáticamente

Proceso tradicional: Modelado conceptual, lógico y fı́sico
Proceso de mapeado objeto-relacional: anotación de clases y
creación de esquemas
Proceso model-driven engineering: modelado conceptual y creación
automática de esquemas
Posibles problemas
Uso reiterado de tipos VARCHAR sin lı́mite
Tipos de datos en columnas de combinación 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

Optimización
Índices
Más 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 sólo busca
eficientemente el prefijo en la parte más 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

Optimización
Árbol B y B+
Admitido por todos los motores (menos Archive)
Cada motor lo implementa a su modo. Por ejemplo, MyISAM usa
compresión mientras que InnoDB no usa compresión
Idea general: todos los valores se almacenan en orden y se accede
mediante un árbol en el que cada hoja está a la misma distancia de
la raı́z y las páginas 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.

Optimización
Árbol B y B+

Optimización
Árbol B y B+
Tipos de consulta que pueden usar ı́ndice de un árbol B
Coincidencia con valor completo.
apellidos = ’Allen’ and nombre = ’Cuba’ and fnac = ’01-01-1960’
Coincidencia parcial con prefijo de columna
apellidos like ’A %’
Coincidencia parcial con prefijo más a la izquierda
apellidos = ’Allen’ and nombre like ’C %’
Coincidencia con rango de valores
apellidos >= ’Allen %’ and apellidos <= ’Barrimore %’
Cláusulas ORDER BY por los campos del ı́ndice

Optimización
Árbol B y B+
Limitaciones. No son útiles en:
Búsquedas que no empiezan en la parte más 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
condición de rango. Por ejemplo:
apellidos = ’Allen’ AND nombre >= ’J’ AND fnac = ’23-12-1976’

Optimización
Índices Hash
Sólo soportado por el motor Memory (el indice por defecto)
Para cada fila se crea un código hash con las columnas indizadas
El ı́ndice es una tabla hash con apuntadores de fila (muy compactos)
Las colisiones de la función hash se almacenan con una lista enlazada
Útil sólo para búsquedas 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 sólo se almacena un punto
al registro
Sólo permite comparaciones de igualdad (=, IN) pero no consultas
de rangos (>100)
Las colisiones de la función hash ralentizan el acceso y el
mantenimiento
Es posible simular ı́ndice hash con una columna extra, un árbol B+ y
triggers
Optimización
Índices agrupados
Las filas de las tablas se guardan en las páginas 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 más 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 único
sin valores NULL, o con una clave interna oculta
Inconvenientes:
Sólo ahorra E/S si los datos no caben en memoria
La velocidad de inserción depende del orden de inserción (lo mejor,
en el orden de la clave primaria)
La actualización es costosa debido a la reubicación de páginas
Páginas más sujetas a fragmentación al insertar filas nuevas
Pueden ser más lentas para escaneos completos
Optimización
Otros ı́ndices
Índices espaciales (árbol R)
Sólo en motor MyISAM
Sólo para los tipos de datos y operaciones de geometrı́a espacial
(GEOMETRY)
El soporte espacial de MySQL no es muy completo
Índices de texto completo
Sólo en el motor MyISAM
Permite búsquedas de palabras clave en textos y cálculo de
relevancias
Soporta conceptos de recuperación de información (stopwords,
lematización, búsqueda booleana)

Optimización
Estrategias de indexado: aislar columnas

Aislar la columna en las consultas para que no forme parte de una
expresión 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
DAY);

Optimización
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 tamaño idóneo que mantiene el ı́ndice
altamente selectivo
Selectividad = Valores diferentes indexados / Valores totales
Bastante largo para proporcionar buena selectividad
Bastante corto como para ahorrar espacio

Optimización

Distribución de los valores diferentes

Optimización

Calculo de las selectividades

Optimización

Distribución con prefijo de 3 caracteres

Optimización


Optimización


Optimización
Estrategias de indexado: Índices 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 más pequeñas que el tamaño total
de la fila encajan mejor en memoria y caben en caché 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

Optimización
Usar ı́ndices para ordenación

MySQL ordena los resultados usando dos métodos: escaneando un
ı́ndice en orden (rápido) o mediante ordenación de archivos (lento)
El escaneado del ı́ndice sólo 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 está en el ı́ndice

Optimización
Tablas de caché 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 caché: 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
periódica
La reconstrucción debe hacerse usando tablas sombreadas para
poder seguir usando las tablas resumen antiguas
Cuando tenemos lista la nueva tabla resumen, cambiamos el nombre

Optimización
Tablas de contadores
Se aconseja que las tablas de contadores sean independientes
Resulta en tablas rápidas y pequeñas
Un contador es esencialmente un semáforo 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;
SELECT SUM(cnt) FROM hit_counter;

Optimización
Desnormalización
Las actualizaciones normalizadas son más rápidas 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 más pequeñas por lo que encajan mejor
en memoria
Sin embargo, en un esquema normalizado las recuperaciones
implican combinaciones que son costosas

Optimización
Contenidos
2 Replicación
5 Optimización

Optimización
Introducción
El hardware y el software sobre los que se ejecuta SGBD determinan
la eficiencia de MySQL (tamaño de disco, memoria disponible,
recursos de CPU, red . . . )
Se necesitan directrices para resolver cuellos de botella del hardware
y del sistema operativo
Prestaremos atención a los siguientes aspectos
Selección de CPU
Equilibrar recursos de memoria y disco
Elegir discos (RAID, NAS)
Configuración de red

Optimización
Introducción
Cuellos de botella comunes:
Saturación de CPU. Común cuando MySQL trabaja con datos que
caben en memoria o pueden ser leı́dos de disco tan rápido como sea
necesario. Ejemplos: ops. criptográficas intensivas, combinaciones sin
ı́ndices
Saturación E/S. Se trabaja con más datos de los que caben en
memoria. Se vacı́a caché para traer más datos, y al rato los datos
vaciados se tienen que volver a cargar
Posibles errores de interpretación:
Escasez de memoria se puede interpretar como falta de capacidad
E/S
Bus de memoria saturado se puede interpretar como problema de la
CPU

Optimización
Selección de la CPU
¿CPU rápida o muchas CPUs no tan rápidas?
MySQL aprovecha mal el paralelismo ya que asigna una operación a
una CPU. Problemas de escala con muchas CPU
En función del tipos de rendimiento deseable:
Baja latencia
Tiempo de respuesta rápido para cada consulta.
Mejor CPUs rápidas porque cada petición sólo aprovecha una CPU.
Alto rendimiento:
Muchas peticiones simultáneas.
Mejor muchas CPUs, pero como MySQL escala mal no funciona el
“cuantas más mejor”.
Al final: meter más CPUs hasta que deje de compensar y llegados a
ese punto: intentar que sean lo más rápidas posible.

Optimización
Selección de la CPU
¿Cuándo compensan muchas CPUs?
MySQL puede aprovechar CPUs “secundarias” para tareas en segundo
plano (ops. de red, limpieza de búferes InnoDB)
Esas tareas son “menores” en comparación con la ejecución 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 más importante que el tiempo de
respuesta de una petición particular

Optimización
Equilibrar recursos memoria / disco

Disponer de mucha memoria evita E/S del disco
Es necesario encontrar un equilibrio entre el tamaño 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 más rápidos en memoria que en disco
Accesos secuenciales: 5 veces más rápidos en memoria que en disco
Se ahorra mucho más trabajo almacenando lecturas aleatorias en
caché
Añadir memoria es la solución para solucionar problemas de E/S
Enxeñarı́a Informáticaaleatoria Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez
Optimización

Caché de las BDs (ej. grupo de búferes InnoDB) funciona mejor que
caché de SO (generalista)
Más conocimiento sobre los datos que necesita
Lógica para fines especiales
No necesita llamadas al sistema
Aspectos a tener en cuenta al considerar el tamaño de la cache
Conjunto de trabajo
Datos que la aplicación necesita en la caché en memoria
Incluye datos e ı́ndices
Unidad de caché
Unidad de datos más pequeña con la que puede trabajar el motor de
almacenamiento
InnoDB: 16KB
Fila 100 Bytes puede necesitar cargar 32 KB en caché (datos e ı́ndice)

Optimización

Pérdida de caché: datos no en caché, hay que ir a buscarlos a disco
Forma fácil de medirla: por el uso CPU (90 % tiempo CPU, 10 %
E/S -> proporción pérdida caché buena)
Buscar proporción de pérdida aceptable
No se arregla simplemente añadiendo más memoria (ej., deficiencias
por tamaño de unidad de caché)
Ejemplo:
Sistema con 10 GB de memoria con 10 % pérdida
Si fuese lineal: 11 % más de memoria (11,1 GB) nos darı́a 0 % de
pérdida
En realidad, bajar a 1 % podrı́a requerir 500 GB de memoria
La escalibilidad la determina el eslabón más débil
Ejemplo:
sistema con 16 GB memoria, 20 GB datos y mucho disco libre que
funciona bien
Algunos componentes pueden estar a más del 50 % de su capacidad
máxima (ej. 80 % de número máximo 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!!
Optimización
Selección de discos
Factores a tener en cuenta:
Capacidad de almacenamiento
No suele ser un problema (tamaño actual de los discos más que
suficiente)
Práctica estándar: combinar discos pequeños y RAID
Ventajoso tener más 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 búsquedas
aleatorias
Tamaño fı́sico: discos más pequeños son más rápidos y ocupan
menos (fı́sicamente)
El aprovechamiento depende del motor. InnoDB escala bien entre 10
y 20 discos

Optimización
Selección de RAID

Optimización
Múltiples volúmenes ¿Dónde 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 único directorio
InnoDB:
datos e ı́ndices en un único conjunto de archivos
Sólo los archivos de definición de tablas van aparte, en el directorio
de cada base de datos

Optimización
Múltiples volúmenes
Usar múltiples volúmenes puede ayudarnos a gestionar E/S pesada
Regla clásica: registros transaccionales y archivos de datos en
volúmenes diferentes
E/S secuencial de tx. no interfiere con E/S aleatoria de datos
En realidad, no es tal ventaja
Escrituras en registro son pequeñas
Cachés 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 más seguro tenerlos separados
Si se pierden los datos: se pueden recuperar usando el registro
Recuperación point-in-time

Optimización
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 caché del disco hace todo el trabajo)
10 discos duros: 2 para datos, 2 para registros transaccionales
Proporcionalmente menos caro
Configuración tı́pica:
SO, swap y registros binarios en RAID 1
Resto: un único volumen en RAID 5 o RAID 10

Optimización
Configuración de red
El mayor problema es la latencia
En una aplicación tı́pica hay muchas transferencias pequeñas y se
suman los retrasos de cada transmisión
La causa principal es la pérdida de paquetes, 1 % de pérdida produce
degradación significativa
Optimizaciones:
Pocas conexiones, peticiones o resultados grandes: aumentar el
tamaño del buffer TCP
Aumenta el número de paquetes que se pueden mandar “de una
tacada”
Modificable en origen y destino
Sólo conexiones locales: acortar timeout de cierre de conexión (por
defecto, un minuto)
Otras: Eliminar latencia resolución DNS: skip name resolve

Optimización
Contenidos
2 Replicación
5 Optimización

Optimización
Introducción
No existe el archivo de configuración óptimo.
Cada servidor necesita una configuración diferente, dependiendo de:
hardware
tamaño datos,
tipos de consultas
Requisitos del sistema (tiempo de respuesta, duración tx,
consistencia, . . . )
La configuración de MySQL predeterminada está pensada para no
utilizar muchos recursos.
No da por hecho máquina dedicada.
Reserva recursos suficientes para iniciar MySQL y ejecutar consultas
sobre pocos datos
Para definir configuración a medida:
Partir de alguno de los ficheros de configuración de ejemplo.
No esperar muchas mejoras con cada cambio
Inicialmente, cambios que duplican o triplican rendimiento
Después, mejoras incrementales
Optimización
Introducción
La configuración permanente MySQL se almacena fichero my.cnf
Se configura mediante la asignación de valores a variables
Es posible ejecutar múltiples instancias desde una sola configuración
con secciones independientes.
Ámbitos de las variables:
Global (se aplican al servidor y a cada conexión)
Sesión (se aplican a una conexión especı́fica)
Especı́ficas para un objeto
Valores demasiado altos generan problemas (i.e. quedarnos sin
memoria)

Optimización
Introducción
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 supervisión para medir si cambio mejora o
empeora rendimiento
Cambiar una o dos variables, un poco, cada vez, y hacer prueba de
medición
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 más, y el
rendimiento cae en picado

Optimización
Introducción
No comenzar a ajustar configuración sin un esquema y consultas
estables
Todos los ı́ndices creados
Si modificamos esquema después de ajustar configuración: volver a
empezar
Describiremos estos aspectos
Ajuste de uso de memoria
Ajustes de cachés
Ajustes E/S
Concurrencia

Optimización

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 conexión (buffer ordenación,
tablas temporales)
Usar el resto memoria para las cachés de MySQL

Optimización

Lı́mite superior de memoria
Inicial: memoria fı́sica del servidor
Kernel Linux limita tamaño máximo memoria para un proceso (en
general, parámetros especı́ficos del SO como el tamaño de pilas . . . )
Librerı́as (glibc) también pueden fijar sus propios lı́mites
Memoria para el SO
Necesario reservar memoria para que el SO haga su trabajo
Mejor indicador de asignación correcta: poco intercambio de
memoria virtual
Normalmente: 1-2 GB (incluso en máquinas con mucha memoria
fı́sica)
Asignar siempre algo de memoria adicional (para tareas periódicas
que consuman mucha memoria, copias de seguridad . . . )
No tener en cuenta memoria para cachés (esa la tratamos aparte)

Optimización

Necesidades de memoria por conexión
Cada conexión, pequeña cantidad de memoria para mantenerse
abierta
También, pequeña 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 simultáneas
Fijamos tamaño máximo buffer ordenación (uno por conexión) en 256
MB
Peor caso: pico de carga supondrı́a 25 GB (Muy poco probable)
Buena solución: observar servidor con carga de trabajo real y
comprobar cuánta memoria utiliza

Optimización

Toda la memoria que no se use: dedicada a cachés
MySQL necesita más memoria para cachés que para el resto de
elementos
Caché del SO trabaja para MySQL
. . . pero MySQL necesita mucha memoria para sı́ mismo
Cachés más importantes:
Caché de claves MyISAM
Grupo de búferes InnoDB
Caché de subprocesos
Existen otras cachés, pero no requieren mucha memoria
Más fácil ajustar servidor que usa un único motor de almacenamiento
Mezcla de motores: difı́cil encontrar equilibrio

Optimización

Para almacenar ı́ndices (no datos, MyISAM lo delega en el sistema
operativo)
Si sólo usamos MyISAM: dedicar mucha memoria a esta caché
Si se usa también InnoDB: ajustar al 25-30 % de la cantidad de
memoria reservada para las cachés
Una predeterminada, pero se pueden crear más
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;

Optimización

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
aplicación
El número de fallos por segundo es el más 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
Optimización

El tamaño de bloque de la caché de claves MyISAM es configurable
a partir de MySQL 5.1
Debe ser el mismo tamaño 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 caché y entrega bloque de
1KB a MyISAM
SO libera caché 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

Optimización
Conjunto de búferes InnoDB

Si usamos tablas InnoDB el conjunto de búferes necesitará más
memoria que cualquier otra opción
Almacenan ı́ndices, datos de filas, buffer de inserciones, bloqueos,
otras estructuras internas
Habitual: reservar 80 % de la memoria fı́sica de la máquina
Cuando el % de páginas sucias excede el umbral establecido un
proceso automático inicia el volcado a disco
Valor predeterminado del % de páginas sucias es el 90 %
Si subimos el umbral tolera mejor picos de actualizaciones
Si bajamos umbral: tarda menos en cerrarse (se acumulan menos
páginas que grabar)
Si el tamaño demasiado grande se ralentiza el arranque y la parada
del servidor

Optimización
Caché de subprocesos
Pool de procesos libres preparada para conexiones nuevas
Entra conexión: se le asigna proceso de la caché
Conexión se cierra: proceso vuelve a estar disponible en la caché
Si no hay sitio: el proceso se destruye
Número máximo de subprocesos en cache: thread_cache_size
Monitorización:
Intentar mantener threads_created entre 1-10 por segundo
Revisar threads_connected para configurar el tamaño de la cache
de forma que sea capaz de contener la fluctuación tı́pica de la carga
de trabajo

Optimización
Caché de tablas MyISAM

Guarda objetos que representan tablas
Necesita poca memoria, ayuda a conservar recursos
Dos partes:
Caché de definición de tablas (table_definition_cache)
Contenido del archivo .frm analizado sintácticamente
A poder ser, fijar tamaño para que quepan todas las definiciones de
nuestras tablas
Caché 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 está
incrementando: aumentar caché
Aumentar número de archivos que pueden permanecer abiertos:
open_files_limit

Optimización
Ajuste E/S: MyISAM

Cada escritura en caché 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
dañado
Si se retrasan muchas escrituras, las tablas tardan más en cerrarse
Demasiados bloques sucios en cache: no dejan espacio para nuevos:
consultas pueden retrasarse

Optimización
Ajuste E/S de InnoDB: Registro de transacciones

Para ahorrar E/S aleatorias en páginas de datos se graba
secuencialmente las ops. en el registro (de transacciones
Transacciones persistentes aún sin haber volcado datos a disco
Proceso de vaciado en segundo plano convierte registro de tx en ops
de volcado de datos secuenciales más eficientes
Tamaño del archivo de log: vital para rendimiento de la escritura
Dividido en varios archivos. Registro circular único.
Tamaño total: suma del tamaño de los archivos
Predeterminado: dos archivos de 5 MB (10 MB totales)
Lı́mite superior: 4 GB
Tamaño tı́pico para alto rendimiento: 256 MB

Optimización
Ajuste E/S de InnoDB: Registro de transacciones

Tamaño ideal registro, valorar:
Carga actualizaciones rutinarias de datos
Tiempo de recuperación requerido en caso de caı́da del sistema
Si registro demasiado pequeño: InnoDB realizará más 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
Supervisión del rendimiento:
Anotar valor máximo de variable innodb_os_log_written a
intervalos de 10-100 segundos
Usarlo para determinar tamaño del registro y del buffer del registro
Máximo 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

Optimización
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 transacción
Una vez por segundo
Tamaño 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 máximo 1 segundo de transacciones

Optimización
Ajuste E/S de InnoDB: Buffer de doble escritura

Para evitar daños con escritura de disco parcial de datos de tablas
Buffer de doble escritura: estructura en caché de tablas InnoDB
Tamaño suficiente para contener bloque contiguo de 100 páginas de
disco
Cuando se vuelca grupo de páginas a disco:
Se vuelcan primero a buffer doble
Después, se vuelcan a disco
Si error en InnoDB, cuando se recupere puede detectar escrituras
parciales en disco o en doble buffer

Optimización
Concurrencia
InnoDB antes de MySQL 5.1 responde mal a situaciones de alta
concurrencia
Única solución: limitar concurrencia
(innodb_thread_concurrency)
Formula útil (en la práctica, puede ser mejor usar valor más
pequeño):
concurrencia = num CPUs * num discos * 2
Antes, InnoDB tenı́a muchos semáforos MUTEX
Ahora la concurrencia es mucho mejor en InnoDB, pero la mejora de
la caché de threads quedó la rama abandonada de MySQL 6.0 y se
ha recuperado en MariaDB

Optimización
Bases de Datos III

Diseño Fı́sico - MySQL
Enxeñarı́a Informática
Curso 2013/2014
Miguel R. Luaces
Laboratorio de Bases de Datos
Universidade da Coruña

DesenoFisico MySQL PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

DesenoFisico MySQL PDF

Cargado por

Copyright:

Formatos disponibles

BD3: Diseño Fı́sico - MySQL

Bases de Datos III

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

MySQL Community Server

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Conexión / Control de subprocesos

API del motor de

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Motores de almacenamiento: MyISAM

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Motores de almacenamiento: InnoDB

Motores de almacenamiento: Memory

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Motores de almacenamiento: otros

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Motores de almacenamiento: selección

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Motores de almacenamiento: selección

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Motores de almacenamiento: cambios

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Motores de almacenamiento: ejemplos

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Motores de almacenamiento: ejemplos

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Problemas resueltos por la replicación

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Registra todas las operaciones del servidor que modifican datos (o

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Cada maestro es a su vez esclavo del otro

Uno de los servidores es un servidor “pasivo” de sólo lectura

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

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

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Enxeñarı́a Informática Miguel R. Luaces (luaces@udc.es) - Juan Ramón López Rodrı́guez

Estrategia para la copia de seguridad