DesenoFisico MySQL PDF

BD3: Diseno Fsico - MySQL
Bases de Datos III

Diseno Fsico - MySQL
Enxenara Informatica
Curso 2013/2014
Miguel R. Luaces
Laboratorio de Bases de Datos
Universidade da Coruna
Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Contenidos
1 Introduccion a MySQL
2 Replicacion
3 Copia de seguridad y recuperacion
4 Medicion de rendimiento y perfilado
Medicion del rendimiento
Perfilado de aplicaciones
5 Optimizacion
Optimizacion de esquemas e ndices
Optimizacion de hw. y sw.
Optimizacion del servidor

Introduccion a MySQL
Contenidos
2 Replicacion
5 Optimizacion

MySQL Community Server

Version actual: 5.6.17
Documentacion: 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
Version actual: 5.5.36
Documentacion: https://kb.askmonty.org/en/
Funciona sobre todas las plataformas: Mac OS X, Windows,
GNU/Linux
Mejoras sobre MySQL 5.5:
Mas motores de almacenamiento (ej.: No-SQL)
Optimizaciones
Extensiones (ej.: virtual columns)
Completamente Open Source

Arquitectura de MySQL
Clientes
Conexin / Control de subprocesos
Cach de Analizador
consultas sintctico
optimizador
API del motor de

almacenamiento
(Iniciar transaccin,
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 analisis sintactico, se realiza
la optimizacion del plan de ejecucion
Reescritura de la consulta
Determinacion del orden de acceso a las tablas
Seleccion de los ndices a utilizar
Inclusion de las caractersticas especficas de los motores de
almacenamiento

Caracterstica unica: separacion de tareas de servidor (conexiones,
procesamiento de consultas, optimizacion) de tareas de
almacenamiento y recuperacion de datos
Se puede elegir el motor de almacenamiento a nivel de tabla
Se pueden cargar motores de almacenamiento en tiempo de ejecucion
Describiremos brevemente los siguientes aspectos de MySQL:
Control de concurrencia
Gestion de transacciones
Motores de almacenamiento
Criterios de seleccion

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,
pagina 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 poltica
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 mas frecuentes que
las modificaciones
Es eficiente en el caso de modificaciones simultaneas en varias filas
InnoDB realiza bloqueos a nivel de fila
Permite la maxima 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 cancelacion de transacciones
El servidor de MySQL puede bloquear tablas independiente del motor
para garantizar correccion de sentencias DDL como ALTER TABLE

MySQL incluye motores transaccionales (InnoDB) y no
transaccionales (MyISAM, Memory)
El estandar 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 transaccion lee datos sin confirmar
de otra transaccion
Permite lecturas sucias porque la segunda transaccion podra ser
cancelada

Read commited
Los bloqueos de escritura se mantienen hasta el fin de la transaccion
Los de lectura se liberan al finalizar la lectura
Una transaccion solo lee datos de transacciones confirmadas
Permite lecturas no-repetibles porque los datos podran cambiar
despues de leidos

Repeatable read
Todos los bloqueos se mantienen durante toda la transaccion
Cualquier fila que lea una transaccion 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 instantaneas de los datos tal y como existan en un
determinado momento
Diferentes transacciones ven simultaneamente datos distintos en las
mismas tablas
Evita la necesidad de bloquear filas en modo lectura

Interbloqueos (Deadlocks)
El funcionamiento de los bloqueos es especfico 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
maximo
La solucion consiste en reanudar alguna de las transacciones
InnoDB detecta dependencias circulares y reanuda la transaccion 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 pagina de disco
El almacenamiento en disco se realiza mediante un registro de
transacciones usando escritura secuencial (y por tanto, rapida)
Los datos en disco se escriben cuando la pagina 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 transaccion
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 foraneas, y solo permite bloqueos
a nivel de tabla
El tamano maximo de una tabla es 256 TB
Cada tabla se almacena en un fichero del sistema operativo
Variantes:
Tablas con filas de tamano fijo (estaticas) y tamano variable
(dinamicas)
Tablas comprimidas y de solo lectura
El espacio usado en disco es mnimo
Optimo para soportes de solo 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 foraneasy bloqueos a nivel de fila
El tamano maximo 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 paginas que las filas
Las busquedas por clave principal son rapidas porque ahorran un
acceso a disco
Los ndices secundarios (todos los demas) siempre incluyen los
atributos de la clave principal para usar el ndice agrupado en las
busquedas
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 foraneas. Los bloqueos son a
nivel de tabla
El tamano maximo de una tabla depende de la memoria del servidor
Permite un acceso muy rapido a los datos (un orden de magnitud
mas rapido que el motor MyISAM)
El espacio ocupado por una tabla solo se devuelve al borrar o recrear
la tabla
Ejemplos de posibles usos:
Tablas de busqueda rapida (i.e. codigos postales)
Guardar en cache datos agregados periodicamente
Resultados intermedios de procesos
MySQL lo usa para procesar consultas que necesitan tablas
temporales

Motores de almacenamiento: otros

Motor Merge
Combinacion de varias tablas MyISAM en una unica tabla virtual
Permite la particion de informacion en diferentes bloques
Posibles usos: gestion de archivos de log, superar la limitacion de
tamano de archivo del SO
Motor Blackhole
No almacena datos. Todas las inserciones se descartan
Mantiene un registro de operaciones realizadas
Posibles usos: auditora, algunas configuraciones de replicacion
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: seleccion

Dado que podemos elegir el motor de almacenamiento para cada
tabla, necesitamos conocer como se va a utilizar cada tabla, como
funciona la aplicacion, y su evolucion potencial
En funcion del uso de transacciones:
Si la aplicacion requiere transacciones, la unica opcion es InnoDB
Si no requieren transacciones y las consultas son SELECT e INSERT,
MyISAM es buena opcion
En funcion de la concurrencia en las operaciones:
Depende de la carga de trabajo esperada
Si solo 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: seleccion

En funcion 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 multiples motores complica el proceso de copia de
seguridad
En funcion de la necesidad de operaciones especiales:
Solo InnoDB incluye ndices agrupados y optimizaciones basadas en
ellos
InnoDB solo permite busquedas de texto completo desde la version
5.6.4

Motores de almacenamiento: cambios

Metodos 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 especficas del motor de
almacenamiento se pierden
Todos los metodos son lentos pues implican la copia de los datos
El metodo basado en ALTER TABLE implica un bloqueo de
escritura en la tabla

Motores de almacenamiento: ejemplos

Registro de llamadas de central telefonica 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 recopilacion de datos
ralentiza las inserciones
Alternativas:
Realizar la recopilacion en horas de poca carga
Replicar la base de datos en un segundo servidor esclavo en el que se
haran las consultas
Particionar el registro de llamadas por mes, semana o da, y crear una
tabla de tipo Merge para las consultas
Servicio de cotizaciones
Si es una herramienta de consumo interno con un numero limitado
de usuarios, MyISAM
Si es un servicio web con mucho trafico, miles de usuarios y
alimentacion de cotizaciones en tiempo real, InnoDB
Una consulta no debe esperar
Miles de usuarios intentando leer mientras simultaneamente se
actualizan filas requiere bloqueos a nivel de fila

Motores de almacenamiento: ejemplos

Boletines de anuncios y foros de discusion
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 monolticas con mucha actividad pesada de
lectura y escritura
La carga suele ser mediana o pequena, MyISAM no es imprescindible
InnoDB no es capa de ejecutar rapidamente 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 solo lectura

Replicacion
Contenidos
2 Replicacion
5 Optimizacion

Replicacion
Definicion de replicacion
Consiste en configurar uno o varios servidores como esclavos - o
replicas - de otro servidor
Problema a resolver: mantener los datos de los servidores
sincronizados
Base para construir aplicaciones extensas y de alto rendimiento
Admite diferentes topologas
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
solo algunas tablas

Replicacion
Problemas resueltos por la replicacion

Distribucion de datos
No exige un ancho de banda intensivo y funciona con una conexion
intermitente
Util para mantener una copia de los datos en una ubicacion
geograficamente distante
Balanceo de carga
Permite distribuir peticiones de datos entre varios servidores
Alta disponibilidad y failover
Los esclavos ayudan a reducir el tiempo de cada del servidor principal
Prueba de actualizaciones de MySQL
Configuramos un servidor esclavo con la nueva version 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

Replicacion
Funcionamiento de la replicacion
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
repeticion (relay log)
El esclavo repite todos los eventos del registro de repeticion sobre
sus propios datos

Replicacion
El registro binario de mySQL:
Registra todas las operaciones del servidor que modifican datos (o

podran 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

Replicacion
El registro binario de mySQL permite tres tipos de replicacion:
Basada en sentencias (statement-based replication)
Se registra la instruccion 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 replicacion de cualquier instruccion
El registro aumenta de tamano
No es facil auditar los cambios realizados
Mixta (mixed-format replication)
MySQL decide en funcion de la instruccion que se ejecuta si se usa
replicacion basada en sentencias o en filas
Se usa la replicacion basada en sentencias a no ser que la instruccion
no sea segura
Ver la descripcion en el manual
Replicacion
El proceso para configurar la replicacion es el siguiente:
Configurar cuentas de replicacion en cada servidor
El thread E/S del esclavo hace una conexion 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 repeticion
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
actualizacion

Replicacion
Es posible replicar solo parte de los eventos de un servidor,
utilizando diferentes tipos de filtros
Filtros sobre el registro binario del maestro
Filtros sobre el registro de repeticion

Replicacion
Topologas de replicacion
Las restricciones en la replicacion son las siguientes:
Cada esclavo solo puede tener un maestro
Un maestro puede tener muchos esclavos
Un esclavo puede actuar tambien como maestro
Estas restricciones permiten diferentes topologas con diferentes
aplicaciones
Un maestro, multiples esclavos
Maestro-maestro en modo activo-activo
Maestro-maestro en modo activo-pasivo
Anillo
Maestro, maestro de distribucion, esclavos
Arbol o piramide

Replicacion

Replicacion
La topologa mas sencilla y mas comun
Todas las escrituras se realizan en el maestro, las lecturas se pueden
realizar en cualquier servidor
El numero 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 recuperacion
Utilizar un esclavo para copia de seguridad, para pruebas o para
desarrollo

Replicacion
Maestro-maestro en modo activo-activo
Cada maestro es a su vez esclavo del otro

Cualquier servidor se puede utilizar para cualquier operacion
Posible uso: oficinas separadas geograficamente, donde cada oficina
necesita su copia local de los datos
Problemas: cambios conflictivos
Actualizacion simultanea de la misma fila en ambos servidores
Inserciones simultaneas con columnas AUTO INCREMENT
Y si la replicacion se detiene por un tiempo? Como reenganchamos
despues?
Solo se recomienda si tenemos datos bien particionados y buen
reparto de privilegios
Replicacion
Maestro-maestro en modo activo-pasivo
Uno de los servidores es un servidor pasivo de solo lectura

Permite intercambiar los papeles de forma muy sencilla: las
configuraciones son simetricas
Mantenimiento, optimizacion 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
Replicacion
Anillo

Replicacion
Anillo
Tres o mas maestros
Cada servidor es un esclavo del servidor que esta antes en el anillo, y
maestro del servidor que esta despues
Configuracion simetrica, failover facil.
Es una configuracion fragil:
Depende enormemente de que todos los nodos funcionen
correctamente
Difcil que esten todos sincronizados a la vez: detener algun nodo es
complicado
Si eliminamos un nodo sin tener cuidado, sus eventos pueden
propagarse de forma infinita por el anillo. El unico nodo que filtra un
evento es el que lo ha generado!

Replicacion

Replicacion
Similar a la topologa maestro-esclavos, pero no sobrecarga al
maestro principal
El maestro principal solo tiene un esclavo que a su vez actua como
maestro de distribucion
El maestro de distribucion usa el motor BlackHole que graba en el
registro binario pero no mantiene tablas ni datos

Replicacion
Arbol o piramide

Replicacion
Arbol o piramide
Si hay muchos esclavos, puede ser mas rentable un diseno en
piramide
Esto alivia la carga del maestro y la redistribuye por los diferentes
esclavos
Desventaja: fallos en niveles intermedios afectan a un gran numero
de servidores
Ademas, cuantos mas niveles intermedios, mas difcil y complicado
es manejar los fallos

Replicacion
Problemas en la replicacion
La replicacion 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 replicacion solo escala las lecturas, no las escrituras
La distribucion de la carga debe ser realizada por otro software
La complejidad de la replicacion se ve claramente en la longitud de
la seccion del manual

Copia de seguridad y recuperacion
Contenidos
2 Replicacion
5 Optimizacion

Introduccion
Recuperacion no es restauracion
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 configuracion
Calentar las caches del servidor
Utilidades de las copias de seguridad
Recuperacion ante desastres. Un error importante corrompe los datos
o el servidor
Recuperacion ante cambios no deseados. La gente cambia de idea, y
ocurre mas a menudo que los desastres
Auditoras. Necesidad de recuperar datos o esquema en algun
momento del pasado (ej. temas judiciales)
Pruebas. La manera mas facil de cargar un servidor de pruebas con
datos es usando una copia de seguridad
Introduccion
El mejor sistema de copias de seguridad no es suficiente. Un buen
plan de recuperacion es fundamental
El procedimiento de recuperacion es complejo. Es facil cometer
errores
Las copias de seguridad son rutinarias y no se realizan bajo
situaciones de presion extrema. La recuperacion se hace en medio de
una situacion de crisis
Una persona puede planear, disenar e implementar las copias de
seguridad, pero podra no estar disponible cuando se produzca el
desastre. Es necesario formar a personal cualificado para que se
encargue de la recuperacion
Alternativas que no son copias de seguridad
La replicacion no es una copia de seguridad
Usar discos en RAID
Como 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
Codigo: disparadores y procedimientos almacenados (estan en la BD
mysql)
Configuracion del servidor y de la replicacion
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 gua 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 mas nos permitamos perder, mas facil es hacer la copia
Las copias de seguridad en MySQL son mucho mas complicadas de
lo que parece

Tipos de copia de seguridad

Copias calientes, templadas o fras?
Calientes: sin detener el servidor ni bloquear las tablas
Templadas: sin detener el servidor pero bloqueando las tablas
Fras: deteniendo el servidor
Copias logicas o sin procesar?
Copia logica: en un formato que MySQL puede interpretar (SQL,
CSV)
Copia sin procesar: los archivos de mySQL tal y como estan
almacenados en disco


Inconvenientes de copias calientes
Buferes sucios en el grupo de buffers de InnoDB (u otras caches)
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 paginas sucias en grupo de buffers InnoDB requieren tiempo para
volcarse a disco
Reiniciar tambien requiere tiempo: abrir tablas, calentar caches, etc.
Inconvenientes de copias templadas
Tiempo de espera indeterminado debido al proceso de adquirir
bloqueos


Ventajas de las copias logicas
Archivos que se pueden manipular e inspeccionar con editores de
textos
Faciles de restaurar
Se pueden restaurar en una maquina diferente
Independientes del motor de almacenamiento
Se pueden retocar para exportar a otros SGBD
Desventajas de las copias logicas
El servidor debe hacer el trabajo de generarlas
Pueden llegar a ocupar mucho mas que los datos en algunos casos
La reconstruccion 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 restauracion puede ser sencillsima: para MyISAM, simplemente
copiar los archivos en su sitio; InnoDB, en cambio, obliga a detener
el servidor
La restauracion es mas rapida: no hay que ejecutar sentencias, ni
reconstruir ndices
Desventajas de las copias sin procesar
Suelen ocupar mucho mas espacio que las copias logicas (por
ejemplo, el espacio de tabla InnoDB incluye mucho espacio sin
utilizar)
No siempre se pueden mover a traves de las plataformas, SO y
versiones de SQL (mayusculas/minusculas, representacion punto
flotante)

Procedimiento de copia logica

Copia
Realizar un volcado SQL con mysqldump o CSV con SELECT *
INTO OUTFILE
Restauracion
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 podran
abrirlos)

Procedimiento de copia logica

Hay que asegurar que los datos son consistentes en un punto de
tiempo determinado (por ejemplo, en una BD de comercio
electronico debe haber una factura por cada pago). Es complicado
en copias calientes
En motores transaccionales: realizar la copia en una transaccion
En motores no transaccionales, bloquear todas las tablas que se
deben copiar juntas
Esto no nos protege de una aplicacion mal disenada (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 tecnicas de gestion de ficheros del
SO (por ejemplo, LVM)
Restauracion:
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
Restauracion:
Restaurar la copia completa y ejecutar todos los registro binarios
Restauracion a un punto concreto del tiempo
Localizar el punto de tiempo en los registros binarios y ejecutar hasta
esa posicion
Eliminar el resultado de una instruccion
Localizar la instruccion y ejecutar el registro binario hasta esa
posicion y desde despues de esa posicion

Medicion de rendimiento y perfilado
Contenidos
2 Replicacion
5 Optimizacion

Medicion del rendimiento y perfilado

El objetivo de la optimizacion es aumentar el rendimiento de MySQL
Los elementos a optimizar son muchos. Ej: esquemas, ndices,
consultas, configuracion del servidor, hardware, software, aplicaciones
Necesitamos dos practicas basicas:
Medicion del rendimiento. Responde a Como se ejecuta?
Permiten evaluar el desempeno del SGBD
Permiten determinar la capacidad maxima del sistema
Permiten discriminar los cambios que importan de los que no
Muestran como se ejecuta la aplicacion 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 mas tiempo
Lugares donde se consumen mas recursos

Contenidos
2 Replicacion
5 Optimizacion

Objetivos de las medidas

Las medidas de rendimiento permiten realizar las siguientes tareas:
Medir rendimiento actual de nuestra aplicacion
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 adaptacion a entornos cambiantes
Picos esporadicos, configuraciones diferentes de servidores
Probar configuraciones diferentes de hw., sw. y so.
RAID5 o RAID10? nucleo 2.4 o 2.6 de Linux? escala bien con
doble de memoria?

Estrategias para medir

Existen dos estrategias en la medida de rendimiento:
Aplicacion como un todo
La preocupacion ultima es el rendimiento de toda la aplicacion
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 aplicacion. Es mas difcil si
solo probamos una parte de ella
Aislar mySQL (SGBD, en general)
Es difcil aislar puntos de referencia y de configuracion de la
aplicacion
Acercamiento paulatino: empezar por mySQL
Interesan medidas de rendimiento cortas, con tiempo de ciclo mas
corto
Facil aislar consultas tpicas y repetirlas muchas veces

Ejemplos de medidas de rendimiento

Transacciones por unidad de tiempo (clasica)
Se ajusta bien a aplicaciones interactivas de multiples usuarios, OLTP
Unidad tpica: transacciones por segundo
Tiempo de respuesta (latencia)
Mide tiempo total requerido por una tarea (ej: milesimas, minutos)
La ejecucion repetida permite derivar tiempos de respuesta mnimo,
maximo o medio
Los tiempos mnimos y maximos no son muy utiles porque no son
repetibles, cuanto mas tiempo se ejecute la medida, mas extremos
seran, y varan 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 aplicacion bajo diferentes niveles de
concurrencia
Un ejemplo de medida: numero 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 solo es un resultado, tambien 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):
El tamano de la base datos
El numero de conexiones concurrentes
El hw. disponible

Errores comunes en las medidas

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

Utilizar datos sinteticos distribuidos uniformemente
Definir un escenario con un solo usuario
Medir en un solo servidor el rendimiento de una aplicacion distribuida
Fallo en imitar el comportamiento del usuario: clics en vnculos uno
tras otro sin parar, en una aplicacion web
Ejecutar consultas identicas en un bucle, olvidando posibles perdidas
en cache
No detectar los errores en el proceso de medida (ej: que una
operacion lenta se agilice mucho puede ser debido a un error de
sintaxis en SQL)
Olvidar tener en cuenta latencia del servidor despues de reinicio

Planificacion de medidas de rendimiento

Proceso de planificacion 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 estandar o una prueba de diseno
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
Documentacion de los parametros
Almacenamiento de los resultados

Planificacion de medidas de rendimiento

Proceso de planificacion 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 instantanea de los datos, usando el servidor en caliente)
Debemos tener cuidado con la carga externa y con las tareas periodicas
Cambiar la menor cantidad de parametros posible en cada prueba (los
independientes)
Es recomendable automatizar las ejecuciones de las pruebas (scripts,
makefiles)
El numero de repeticiones depende del grado de certeza que se quiera
alcanzar. Comunmente:
Ejecutar varias veces y eliminar los resultados discrepantes
Ejecutar hasta que los resultados no varen demasiado (reducir la varianza)
Utilizar tecnicas estadsticas
Analizar los resultados
Los resultados agregados permiten dar una idea general de la medida
Los resultados detallados permiten detectar picos ocultos por la
agregacion

Herramientas para medidas de rendimiento

Herramientas especficas de mySQL
mysqlslap
Incluido desde la version 5.1 con mySQL
Simula carga en el servidor e informa sobre el tiempo
Muy configurable, ej: numero de conexiones concurrentes
Permite una instruccion SQL en lnea de comandos o un archivo con
instrucciones SQL
MySQL Benchmark suite
Incluido desde la version 5.0 con mySQL
Mide lo rapido que ejecuta el servidor las consultas
Muchas pruebas predefinidas, que permiten comparar diferentes
motores de almacenamiento y configuraciones
Mejorable (un solo usuario, el conjunto de datos es pequeno, y usa
un solo proceso (no multiples CPU)


Herramientas especficas 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 comparacion OLTP
Desarrollo parado
Super Smack
Pruebas de comparacion + Prueba de estres + Herramienta de
generacion de carga para MySQL y PostgreSQL
Multiples 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 numero de solicitudes que puede servir por segundo
Solo prueba una URL todo lo rapido que pueda
httpload
Utiliza un archivo de entrada con muchas URLs de las que elige
aleatoriamente
Prueba lo mas rapido que pueda, o segun una velocidad establecida
(-rate)
Tambien simula usuarios concurrentes (-parallel)
JMeter
Aplicacion Java para medir el rendimiento de otros programas
Simula usuarios reales (tiempo de escalada configurable)
Interfaz grafica que permite reproducir prueba fuera de lnea

Contenidos
2 Replicacion
5 Optimizacion

Objetivos del perfilado

El perfilado de un sistema nos indica cuanto contribuye cada
elemento al coste total de produccion 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 informacion
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 estadsticas 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 codigo de perfilado en las aplicaciones que tome
mediciones de:
Tiempo total de ejecucion de la pagina
Tiempo de ejecucion de las consultas
Tiempo de llamadas a recursos externos (servicios web)
Es una sobrecarga al sistema, por lo que es necesario aplicar tacticas
como
Solo realizar el perfilado en un porcentaje pequeno 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 conexion y desconexion
Sin tiempos de ejecucion: de poco interes para el perfilado
El registro de consultas lentas
Registra las consultas ejecutadas que sobrepasan un determinado
tiempo
Se puede configurar para registrar tambien las consultas que no
utilizan ndices
Guarda tiempos de ejecucion: permite perfilado
Es difcil de utilizar:
Una consulta es lenta porque tarda mas de lo esperado, no porque
tarda mas que un umbral de tiempo
Hay consultas que no tienen que usar el ndice de ningun modo

Perfilado en MySQL
Desde la version 5.1.28, MySQL permite realizar perfilado de los
recursos usados en una sesion
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 sesion
La estrategia de analisis de resultados puede ser:
Comprobar que consultas tienen mas impacto
Comprobar el plan de ejecucion de esas consultas con EXPLAIN
Realizar los ajustes necesarios
Repetir el analisis

Optimizacion
Contenidos
2 Replicacion
5 Optimizacion

Optimizacion

Optimizar esquema mal disenado 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 mas lentas
Las tablas de resumen y los contadores agilizan consultas, pero el
mantenimiento es mas costoso
Los cambios requieren conocer todo el sistema y cada elemento
afectado
Describiremos estas tecnicas:
Eleccion de tipos de datos optimos y seleccion de clave primaria
Distintos tipos de ndices: B+, Hash y agrupados
Estrategias de indexado
Indices para ordenacion
Tablas de cache y de resumen
Tablas de contadores
Desnormalizacion

Optimizacion
Eleccion de tipos de datos optimos

Elegir adecuadamente el tamano es importante
Usar el tipo de datos mas pequeno posible
Menos espacio en disco, memoria y CPU
Cuanto mas 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 vaca, . . .
Proceso:
Paso 1: Determinar tipo de datos: numerico, cadena, temporal
Paso 2: Elegir tipo especfico

Optimizacion

DATETIME vs. TIMESTAMP
Datetime: Entero empaquetado (YYYMMDDHHMMSS) de 8 bytes.
Mayor rango de valores (1001-9999, con precision de 1 segundo).
Timestamp: Entero de 4 bytes. Numero 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 mas adelante
(fragmentacion, reasignacion de espacio)
Vale la pena cuando la longitud maxima de columna es mucho mayor
que la media y hay pocas actualizaciones, o cuando el cjto. caracteres
complejo, codificacion variable (UTF-8).
Optimizacion

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 tamano fijo a la memoria
Tabla temporal para ordenacion: reservara espacio para el maximo
tamano posible (motor Memory necesita filas de tamano fijo)
Mejor reservar el tamano justo
BLOB y TEXT
Guardan grandes cantidades de datos (binarios y de cadena)
Cada motor, diferente gestion
Evitar usarlos en el ORDER BY ya que el motor Memory no permite
campos TEXT ni BLOB, as que habra que usar myISAM para la
tabla temporal de ordenacion)
Truco (longitud lo bastante corta para que la tabla no sobrepase
tmp table size) ORDER BY SUBSTRING(columna text, longitud)

Optimizacion

ENUM en lugar de cadenas
Ahorro de espacio
Es solucion solo para listas fijas de cadenas. Ampliarla: ALTER
TABLE
Ademas: sobrecarga de conversion de valores (por ejemplo, al
concatenar o al comparar)
Usar solo si la lista de cadenas no va a cambiar en el futuro

Optimizacion
Seleccion 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 foraneas si no hay coincidencia exacta
Conversiones de tipo implcitas pueden provocar errores difciles de
detectar
Elegir tamano mas pequeno necesario dejando espacio para
crecimiento futuro
Por ejemplo: un entero (4 bytes) para codigos de provincias implica
mucho espacio en claves externas
Las cadenas de caracteres son una mala eleccion porque ocupan
mucho espacio y son mas lentas que los enteros
Las cadenas de caracteres aleatorias (estilo UUID) implican:
ralentizacion de los INSERT ya que el valor se inserta en una posicion
aleatoria del ndice que puede crear fragmentacion de paginas
mal rendimiento de las caches ya que se elimina la localidad
ralentizacion de los SELECT porque filas adyacentes en el resultado
quedan dispersas en disco y memoria si las filas se almacenan
ordenadas por clave
Optimizacion
Revision de los esquemas generados automaticamente

Proceso tradicional: Modelado conceptual, logico y fsico
Proceso de mapeado objeto-relacional: anotacion de clases y
creacion de esquemas
Proceso model-driven engineering: modelado conceptual y creacion
automatica de esquemas
Posibles problemas
Uso reiterado de tipos VARCHAR sin lmite
Tipos de datos en columnas de combinacion 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

Optimizacion
Indices
Mas 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 solo busca
eficientemente el prefijo en la parte mas 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

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

Optimizacion
Arbol B y B+

Optimizacion
Arbol B y B+
Tipos de consulta que pueden usar ndice de un arbol 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 mas a la izquierda
apellidos = Allen and nombre like C %
Coincidencia con rango de valores
apellidos >= Allen % and apellidos <= Barrimore %
Clausulas ORDER BY por los campos del ndice

Optimizacion
Arbol B y B+
Limitaciones. No son utiles en:
Busquedas que no empiezan en la parte mas 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
condicion de rango. Por ejemplo:
apellidos = Allen AND nombre >= J AND fnac = 23-12-1976

Optimizacion
Indices Hash
Solo soportado por el motor Memory (el indice por defecto)
Para cada fila se crea un codigo hash con las columnas indizadas
El ndice es una tabla hash con apuntadores de fila (muy compactos)
Las colisiones de la funcion hash se almacenan con una lista enlazada
Util solo para busquedas 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 solo se almacena un punto
al registro
Solo permite comparaciones de igualdad (=, IN) pero no consultas
de rangos (>100)
Las colisiones de la funcion hash ralentizan el acceso y el
mantenimiento
Es posible simular ndice hash con una columna extra, un arbol B+ y
triggers
Optimizacion
Indices agrupados
Las filas de las tablas se guardan en las paginas 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 mas 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 implcito con la clave primaria, con un ndice unico
sin valores NULL, o con una clave interna oculta
Inconvenientes:
Solo ahorra E/S si los datos no caben en memoria
La velocidad de insercion depende del orden de insercion (lo mejor,
en el orden de la clave primaria)
La actualizacion es costosa debido a la reubicacion de paginas
Paginas mas sujetas a fragmentacion al insertar filas nuevas
Pueden ser mas lentas para escaneos completos
Optimizacion
Otros ndices
Indices espaciales (arbol R)
Solo en motor MyISAM
Solo para los tipos de datos y operaciones de geometra espacial
(GEOMETRY)
El soporte espacial de MySQL no es muy completo
Indices de texto completo
Solo en el motor MyISAM
Permite busquedas de palabras clave en textos y calculo de
relevancias
Soporta conceptos de recuperacion de informacion (stopwords,
lematizacion, busqueda booleana)

Optimizacion
Estrategias de indexado: aislar columnas

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

Optimizacion
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 tamano idoneo que mantiene el ndice
altamente selectivo
Selectividad = Valores diferentes indexados / Valores totales
Bastante largo para proporcionar buena selectividad
Bastante corto como para ahorrar espacio

Optimizacion

Distribucion de los valores diferentes

Optimizacion

Calculo de las selectividades

Optimizacion

Distribucion con prefijo de 3 caracteres

Optimizacion


Optimizacion


Optimizacion
Estrategias de indexado: Indices de cobertura

Inclur 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 mas pequenas que el tamano 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

Optimizacion
Usar ndices para ordenacion

MySQL ordena los resultados usando dos metodos: escaneando un
ndice en orden (rapido) o mediante ordenacion de archivos (lento)
El escaneado del ndice solo 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

Optimizacion
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
periodica
La reconstruccion debe hacerse usando tablas sombreadas para
poder seguir usando las tablas resumen antiguas
Cuando tenemos lista la nueva tabla resumen, cambiamos el nombre

Optimizacion
Tablas de contadores
Se aconseja que las tablas de contadores sean independientes
Resulta en tablas rapidas y pequenas
Un contador es esencialmente un semaforo 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;

Optimizacion
Desnormalizacion
Las actualizaciones normalizadas son mas rapidas 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 mas pequenas por lo que encajan mejor
en memoria
Sin embargo, en un esquema normalizado las recuperaciones
implican combinaciones que son costosas

Optimizacion
Contenidos
2 Replicacion
5 Optimizacion

Optimizacion
Introduccion
El hardware y el software sobre los que se ejecuta SGBD determinan
la eficiencia de MySQL (tamano de disco, memoria disponible,
recursos de CPU, red . . . )
Se necesitan directrices para resolver cuellos de botella del hardware
y del sistema operativo
Prestaremos atencion a los siguientes aspectos
Seleccion de CPU
Equilibrar recursos de memoria y disco
Elegir discos (RAID, NAS)
Configuracion de red

Optimizacion
Introduccion
Cuellos de botella comunes:
Saturacion de CPU. Comun cuando MySQL trabaja con datos que
caben en memoria o pueden ser ledos de disco tan rapido como sea
necesario. Ejemplos: ops. criptograficas intensivas, combinaciones sin
ndices
Saturacion E/S. Se trabaja con mas datos de los que caben en
memoria. Se vaca cache para traer mas datos, y al rato los datos
vaciados se tienen que volver a cargar
Posibles errores de interpretacion:
Escasez de memoria se puede interpretar como falta de capacidad
E/S
Bus de memoria saturado se puede interpretar como problema de la
CPU

Optimizacion
Seleccion de la CPU
CPU rapida o muchas CPUs no tan rapidas?
MySQL aprovecha mal el paralelismo ya que asigna una operacion a
una CPU. Problemas de escala con muchas CPU
En funcion del tipos de rendimiento deseable:
Baja latencia
Tiempo de respuesta rapido para cada consulta.
Mejor CPUs rapidas porque cada peticion solo aprovecha una CPU.
Alto rendimiento:
Muchas peticiones simultaneas.
Mejor muchas CPUs, pero como MySQL escala mal no funciona el
cuantas mas mejor.
Al final: meter mas CPUs hasta que deje de compensar y llegados a
ese punto: intentar que sean lo mas rapidas posible.

Optimizacion
Seleccion de la CPU
Cuando compensan muchas CPUs?
MySQL puede aprovechar CPUs secundarias para tareas en segundo
plano (ops. de red, limpieza de buferes InnoDB)
Esas tareas son menores en comparacion con la ejecucion 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 mas importante que el tiempo de
respuesta de una peticion particular

Optimizacion
Equilibrar recursos memoria / disco

Disponer de mucha memoria evita E/S del disco
Es necesario encontrar un equilibrio entre el tamano 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 mas rapidos en memoria que en disco
Accesos secuenciales: 5 veces mas rapidos en memoria que en disco
Se ahorra mucho mas trabajo almacenando lecturas aleatorias en
cache
Anadir memoria es la solucion para solucionar problemas de E/S
Enxenara Informaticaaleatoria Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez
Optimizacion

Cache de las BDs (ej. grupo de buferes InnoDB) funciona mejor que
cache de SO (generalista)
Mas conocimiento sobre los datos que necesita
Logica para fines especiales
No necesita llamadas al sistema
Aspectos a tener en cuenta al considerar el tamano de la cache
Conjunto de trabajo
Datos que la aplicacion necesita en la cache en memoria
Incluye datos e ndices
Unidad de cache
Unidad de datos mas pequena con la que puede trabajar el motor de
almacenamiento
InnoDB: 16KB
Fila 100 Bytes puede necesitar cargar 32 KB en cache (datos e ndice)

Optimizacion

Perdida de cache: datos no en cache, hay que ir a buscarlos a disco
Forma facil de medirla: por el uso CPU (90 % tiempo CPU, 10 %
E/S -> proporcion perdida cache buena)
Buscar proporcion de perdida aceptable
No se arregla simplemente anadiendo mas memoria (ej., deficiencias
por tamano de unidad de cache)
Ejemplo:
Sistema con 10 GB de memoria con 10 % perdida
Si fuese lineal: 11 % mas de memoria (11,1 GB) nos dara 0 % de
perdida
En realidad, bajar a 1 % podra requerir 500 GB de memoria
La escalibilidad la determina el eslabon mas debil
Ejemplo:
sistema con 16 GB memoria, 20 GB datos y mucho disco libre que
funciona bien
Algunos componentes pueden estar a mas del 50 % de su capacidad
maxima (ej. 80 % de numero maximo 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!!
Optimizacion
Seleccion de discos
Factores a tener en cuenta:
Capacidad de almacenamiento
No suele ser un problema (tamano actual de los discos mas que
suficiente)
Practica estandar: combinar discos pequenos y RAID
Ventajoso tener mas 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 busquedas
aleatorias
Tamano fsico: discos mas pequenos son mas rapidos y ocupan
menos (fsicamente)
El aprovechamiento depende del motor. InnoDB escala bien entre 10
y 20 discos

Optimizacion
Seleccion de discos
Seleccion de RAID

Optimizacion
Seleccion de discos
Multiples volumenes Donde 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 directorio
InnoDB:
datos e ndices en un unico conjunto de archivos
Solo los archivos de definicion de tablas van aparte, en el directorio
de cada base de datos

Optimizacion
Seleccion de discos
Multiples volumenes
Usar multiples volumenes puede ayudarnos a gestionar E/S pesada
Regla clasica: registros transaccionales y archivos de datos en
volumenes diferentes
E/S secuencial de tx. no interfiere con E/S aleatoria de datos
En realidad, no es tal ventaja
Escrituras en registro son pequenas
Caches 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 mas seguro tenerlos separados
Si se pierden los datos: se pueden recuperar usando el registro
Recuperacion point-in-time

Optimizacion
Seleccion 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 cache del disco hace todo el trabajo)
10 discos duros: 2 para datos, 2 para registros transaccionales
Proporcionalmente menos caro
Configuracion tpica:
SO, swap y registros binarios en RAID 1
Resto: un unico volumen en RAID 5 o RAID 10

Optimizacion
Configuracion de red
El mayor problema es la latencia
En una aplicacion tpica hay muchas transferencias pequenas y se
suman los retrasos de cada transmision
La causa principal es la perdida de paquetes, 1 % de perdida produce
degradacion significativa
Optimizaciones:
Pocas conexiones, peticiones o resultados grandes: aumentar el
tamano del buffer TCP
Aumenta el numero de paquetes que se pueden mandar de una
tacada
Modificable en origen y destino
Solo conexiones locales: acortar timeout de cierre de conexion (por
defecto, un minuto)
Otras: Eliminar latencia resolucion DNS: skip name resolve

Optimizacion
Contenidos
2 Replicacion
5 Optimizacion

Optimizacion
Introduccion
No existe el archivo de configuracion optimo.
Cada servidor necesita una configuracion diferente, dependiendo de:
hardware
tamano datos,
tipos de consultas
Requisitos del sistema (tiempo de respuesta, duracion tx,
consistencia, . . . )
La configuracion de MySQL predeterminada esta pensada para no
utilizar muchos recursos.
No da por hecho maquina dedicada.
Reserva recursos suficientes para iniciar MySQL y ejecutar consultas
sobre pocos datos
Para definir configuracion a medida:
Partir de alguno de los ficheros de configuracion de ejemplo.
No esperar muchas mejoras con cada cambio
Inicialmente, cambios que duplican o triplican rendimiento
Despues, mejoras incrementales
Optimizacion
Introduccion
La configuracion permanente MySQL se almacena fichero my.cnf
Se configura mediante la asignacion de valores a variables
Es posible ejecutar multiples instancias desde una sola configuracion
con secciones independientes.
Ambitos de las variables:
Global (se aplican al servidor y a cada conexion)
Sesion (se aplican a una conexion especfica)
Especficas para un objeto
Valores demasiado altos generan problemas (i.e. quedarnos sin
memoria)

Optimizacion
Introduccion
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 supervision para medir si cambio mejora o
empeora rendimiento
Cambiar una o dos variables, un poco, cada vez, y hacer prueba de
medicion
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 tpicos: incrementamos variable un poco y
mejora rendimiento; la incrementamos un poco mas, y el
rendimiento cae en picado

Optimizacion
Introduccion
No comenzar a ajustar configuracion sin un esquema y consultas
estables
Todos los ndices creados
Si modificamos esquema despues de ajustar configuracion: volver a
empezar
Describiremos estos aspectos
Ajuste de uso de memoria
Ajustes de caches
Ajustes E/S
Concurrencia

Optimizacion

Comenzar con el lmite superior de memoria disponible para MySQL
Restar la memoria que necesita SO para ejecutarse bien
Restar la memoria necesaria para cada conexion (buffer ordenacion,
tablas temporales)
Usar el resto memoria para las caches de MySQL

Optimizacion

Lmite superior de memoria
Inicial: memoria fsica del servidor
Kernel Linux limita tamano maximo memoria para un proceso (en
general, parametros especficos del SO como el tamano de pilas . . . )
Libreras (glibc) tambien pueden fijar sus propios lmites
Memoria para el SO
Necesario reservar memoria para que el SO haga su trabajo
Mejor indicador de asignacion correcta: poco intercambio de
memoria virtual
Normalmente: 1-2 GB (incluso en maquinas con mucha memoria
fsica)
Asignar siempre algo de memoria adicional (para tareas periodicas
que consuman mucha memoria, copias de seguridad . . . )
No tener en cuenta memoria para caches (esa la tratamos aparte)

Optimizacion

Necesidades de memoria por conexion
Cada conexion, pequena cantidad de memoria para mantenerse
abierta
Tambien, pequena cantidad para ejecutar una consulta dada
Necesitamos memoria suficiente para momentos de picos de carga
Difcil de predecir. No es necesario suponer peor caso. Ejemplo:
Configurar para 100 conexiones simultaneas
Fijamos tamano maximo buffer ordenacion (uno por conexion) en 256
MB
Peor caso: pico de carga supondra 25 GB (Muy poco probable)
Buena solucion: observar servidor con carga de trabajo real y
comprobar cuanta memoria utiliza

Optimizacion

Toda la memoria que no se use: dedicada a caches
MySQL necesita mas memoria para caches que para el resto de
elementos
Cache del SO trabaja para MySQL
. . . pero MySQL necesita mucha memoria para s mismo
Caches mas importantes:
Cache de claves MyISAM
Grupo de buferes InnoDB
Cache de subprocesos
Existen otras caches, pero no requieren mucha memoria
Mas facil ajustar servidor que usa un unico motor de almacenamiento
Mezcla de motores: difcil encontrar equilibrio

Optimizacion

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

Optimizacion

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
aplicacion
El numero de fallos por segundo es el mas 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
Optimizacion

El tamano de bloque de la cache de claves MyISAM es configurable
a partir de MySQL 5.1
Debe ser el mismo tamano 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

Optimizacion
Conjunto de buferes InnoDB

Si usamos tablas InnoDB el conjunto de buferes necesitara mas
memoria que cualquier otra opcion
Almacenan ndices, datos de filas, buffer de inserciones, bloqueos,
otras estructuras internas
Habitual: reservar 80 % de la memoria fsica de la maquina
Cuando el % de paginas sucias excede el umbral establecido un
proceso automatico inicia el volcado a disco
Valor predeterminado del % de paginas sucias es el 90 %
Si subimos el umbral tolera mejor picos de actualizaciones
Si bajamos umbral: tarda menos en cerrarse (se acumulan menos
paginas que grabar)
Si el tamano demasiado grande se ralentiza el arranque y la parada
del servidor

Optimizacion
Cache de subprocesos
Pool de procesos libres preparada para conexiones nuevas
Entra conexion: se le asigna proceso de la cache
Conexion se cierra: proceso vuelve a estar disponible en la cache
Si no hay sitio: el proceso se destruye
Numero maximo de subprocesos en cache: thread_cache_size
Monitorizacion:
Intentar mantener threads_created entre 1-10 por segundo
Revisar threads_connected para configurar el tamano de la cache
de forma que sea capaz de contener la fluctuacion tpica de la carga
de trabajo

Optimizacion
Cache de tablas MyISAM

Guarda objetos que representan tablas
Necesita poca memoria, ayuda a conservar recursos
Dos partes:
Cache de definicion de tablas (table_definition_cache)
Contenido del archivo .frm analizado sintacticamente
A poder ser, fijar tamano 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 numero de archivos que pueden permanecer abiertos:
open_files_limit

Optimizacion
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
danado
Si se retrasan muchas escrituras, las tablas tardan mas en cerrarse
Demasiados bloques sucios en cache: no dejan espacio para nuevos:
consultas pueden retrasarse

Optimizacion
Ajuste E/S de InnoDB: Registro de transacciones

Para ahorrar E/S aleatorias en paginas de datos se graba
secuencialmente las ops. en el registro (de transacciones
Transacciones persistentes aun sin haber volcado datos a disco
Proceso de vaciado en segundo plano convierte registro de tx en ops
de volcado de datos secuenciales mas eficientes
Tamano del archivo de log: vital para rendimiento de la escritura
Dividido en varios archivos. Registro circular unico.
Tamano total: suma del tamano de los archivos
Predeterminado: dos archivos de 5 MB (10 MB totales)
Lmite superior: 4 GB
Tamano tpico para alto rendimiento: 256 MB

Optimizacion
Ajuste E/S de InnoDB: Registro de transacciones

Tamano ideal registro, valorar:
Carga actualizaciones rutinarias de datos
Tiempo de recuperacion requerido en caso de cada del sistema
Si registro demasiado pequeno: InnoDB realizara mas 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
Supervision del rendimiento:
Anotar valor maximo de variable innodb_os_log_written a
intervalos de 10-100 segundos
Usarlo para determinar tamano del registro y del buffer del registro
Maximo 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

Optimizacion
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 transaccion
Una vez por segundo
Tamano 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 maximo 1 segundo de transacciones

Optimizacion
Ajuste E/S de InnoDB: Buffer de doble escritura

Para evitar danos con escritura de disco parcial de datos de tablas
Buffer de doble escritura: estructura en cache de tablas InnoDB
Tamano suficiente para contener bloque contiguo de 100 paginas de
disco
Cuando se vuelca grupo de paginas a disco:
Se vuelcan primero a buffer doble
Despues, se vuelcan a disco
Si error en InnoDB, cuando se recupere puede detectar escrituras
parciales en disco o en doble buffer

Optimizacion
Concurrencia
InnoDB antes de MySQL 5.1 responde mal a situaciones de alta
concurrencia
Unica solucion: limitar concurrencia
(innodb_thread_concurrency)
Formula util (en la practica, puede ser mejor usar valor mas
pequeno):
concurrencia = num CPUs * num discos * 2
Antes, InnoDB tena muchos semaforos 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

Optimizacion
Bases de Datos III

Diseno Fsico - MySQL
Enxenara Informatica
Curso 2013/2014
Miguel R. Luaces
Laboratorio de Bases de Datos
Universidade da Coruna

DesenoFisico MySQL PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DesenoFisico MySQL PDF

Uploaded by

Copyright:

Available Formats

BD3: Diseno Fsico - MySQL

Bases de Datos III

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

MySQL Community Server

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Conexin / Control de subprocesos

API del motor de

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Motores de almacenamiento: MyISAM

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Motores de almacenamiento: InnoDB

Motores de almacenamiento: Memory

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Motores de almacenamiento: otros

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Motores de almacenamiento: seleccion

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Motores de almacenamiento: seleccion

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Motores de almacenamiento: cambios

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Motores de almacenamiento: ejemplos

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Motores de almacenamiento: ejemplos

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Problemas resueltos por la replicacion

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Registra todas las operaciones del servidor que modifican datos (o

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Cada maestro es a su vez esclavo del otro

Uno de los servidores es un servidor pasivo de solo lectura

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

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

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Enxenara Informatica Miguel R. Luaces (luaces@udc.es) - Juan Ramon Lopez Rodrguez

Estrategia para la copia de seguridad