1

Nombre de la asignatura

Administracin de Bases de Datos

Crditos Acadmicos

3 Crditos

Nmero y Nombre del Modulo

Mdulo 3: Optimizacin del Manejador
de Bases de Datos

Autor

Hctor Julio Melo Ocampo

Competencias de la asignatura

Conocer los conceptos relacionados con indexacin y aprender a gestionar ndices.

Aprender a optimizar consultas.
Conocer herramientas para el monitoreo del DBMS.
Aprender a optimizar y parametrizar el funcionamiento del servidor.

Competencias previas

Conocer las bases del lenguaje SQL para desarrollar consultas, insercin, borrado y
actualizacin de datos.
Conocer las bases de modelo relacional para el diseo de bases de datos.
Tener bases de lgica booleana y de programacin.
Seleccionar, conocer y usar adecuadamente diferentes sistemas operativos comerciales y de
distribucin libre.

Estructura temtica

Competencias de la asignatura ................................................................................................ 1

Competencias previas ................................................................................................................. 1

Estructura temtica ............................................................................................................................. 2

Ideograma ................................................................................................................................................ 3
3

Optimizacin del Manejador de Bases de Datos ................................................................ 4

3.1
ndices .............................................................................................................................................. 5
3.2
Estructuras de datos de los ndices .................................................................................................. 7
3.3
Algunas consideraciones acerca de los ndices................................................................................ 8
3.4
Optimizar sentencias SELECT y otras consultas ............................................................................. 10
Hay un factor determinante que afecta a todas las sentencias y es la configuracin de los permisos,
entre ms compleja sea sta mayor ser la carga para el servidor de bases de datos. ............................. 10
3.5
Herramientas para realizar pruebas de rendimiento .................................................................... 11

Bases de datos distribuidas .................................................................................................... 25

Fragmentacin ............................................................................................................................................ 27
Replicacin .................................................................................................................................................. 30
Las 12 reglas de Edgar Codd sobre los Sistemas de Gestin de Bases de Datos Distribuidas: ................... 30

Bibliografa: .................................................................................................................................. 37

Ideograma

Tipos de
DBMS

Conceptos

Gestin
de DBMS

Introduccin a
los DBMS
Procedimient
os
almacenados

Seguridad

Procedimientos
almacenados y
triggers

Triggers

Optimizacin

Optimiza
cin del
DBMS

Monitoreo
del DBMS

Bases de
datos
distribuid
as

4
3

Optimizacin del Manejador de Bases de Datos

Una de las principales funciones del Administrador de Bases de datos es velar por la eficiencia del
Sistema Gestor de Bases de Datos, para esto es necesario conocer herramientas y estrategias para
solucionar problemas de rendimiento, identificar cuellos de botella y determinar el origen de los
problemas.
La optimizacin es una tarea que requiere un amplio conocimiento del sistema a optimizar. En este
captulo exploraremos alternativas para la optimizacin de MySQL y revisaremos algunos
ejemplos que sern de utilidad para entender los conceptos.

Uno de los elementos fundamentales para lograr la optimizacin del DBMS radica en su diseo
bsico. As mismo es importante conocer sus procesos y probables cuellos de botella, que
principalmente dependen de los siguientes elementos segn el Manual de Referencia de MySQL:
Bsqueda en Disco. El disco necesita cierto tiempo para encontrar un paquete de datos.
Con discos modernos, el tiempo medio para esto es usualmente menor a 10ms, as que en
teora se pueden hacer 100 bsquedas por segundo. Este tiempo mejora lentamente con los
discos nuevos y es muy difcil optimizarlo para una sola tabla. La manera de optimizar el
tiempo de bsqueda es distribuir los datos dentro de ms de un disco.
Lectura y escritura en disco. Cuando el disco se encuentra en la posicin correcta,
necesitamos leer los datos. Los discos modernos transfieren al menos 10-20MB/s. Esto es
mucho ms fcil de optimizar que las bsquedas, puesto que podemos leer en paralelo
desde mltiples discos.
Ciclos de CPU. Cuando tenemos datos en la memoria principal, necesitamos procesarlos
para obtener algn resultado. Tener tablas pequeas en comparacin con la cantidad de
memoria es el factor ms comn de limitacin. Pero con tablas pequeas, la rapidez no es
usualmente el problema.

5
Ancho de banda de Memoria. Cuando el CPU necesita ms datos de los que puede
almacenar en la cache de la CPU, el ancho principal de la memoria se convierte en un cuello
de botella. Es poco comn en la mayora de casos, pero debe tenerse en cuenta.
En la presente seccin se revisarn algunas de las medidas y herramientas ms importantes para
solucionar problemas de rendimiento que afectan al servidor de Bases de Datos.
3.1

ndices

Un ndice de una base de datos es una estructura de datos que mejora la velocidad de las
operaciones realizadas, permitiendo un acceso ms rpido a los registros de una tabla. Por su
utilidad y la mejora en la eficiencia que permiten los ndices se suelen crear sobre los campos que
se hacen consultas de manera frecuente.
Para entender el funcionamiento de los ndices revisemos el siguiente ejemplo, supongamos que
tenemos una base de datos de las facturas del servicio de telefona. Si quisiramos averiguar los
datos concretos con el nmero de identificacin de un usuario la consulta de MySQL debera de
recorrer uno a uno todos los registros de la tabla hasta encontrar el nmero de identificacin
solicitado. Si consideramos que esta tabla puede tener millones de registros podremos entender
que este trabajo es poco eficiente, que se podra optimizar si tuviramos ordenados los registros
por el nmero de identificacin del usuario, con lo cual el acceso sera mucho ms rpido. Para
esto se crean los ndices, y funcionan como el ndice de un libro, permitiendo localizar rpidamente
lo que se est buscando.
Los ndices se crean sobre una o mltiples columnas. Cualquier tipo de columna puede ser sujeta
de tener un ndice, sin embargo para lograr una optimizacin de las consultas es importante
realizar un anlisis sobre cules son las columnas ms relevantes de ser indexadas.
Los ndices se pueden crear desde la misma creacin de la tabla como podemos ver en el siguiente
ejemplo:

CREATE TABLE usuarios (

id INT NOT NULL,

6
nombre VARCHAR(50) NOT NULL,
apellidos VARCHAR(50) NOT NULL,
PRIMARY KEY (id),
INDEX(id));

As mismo podemos crear ndices sobre tablas ya creadas, por ejemplo, si quisiramos agregar un
ndice sobre la anterior tabla que pueda realizar bsquedas sobre columnas mltiples lo podemos
realizar de la siguiente manera:

ALTER TABLE usuarios ADD INDEX nombre_completo(nombre, apellidos);

Este ltimo tipo de ndices es bastante til cuando se realizan consultas sobre las columnas
utilizadas incluyendo la clusula WHERE.
Una clave primaria es un ndice sobre uno o ms campos donde cada valor es nico y ninguno de
los valores es NULL.

La siguiente es la sintaxis para la creacin de ndices a travs de la clausula CREATE INDEX

CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name
[USING index_type]
ON nombre_tabla (index_nombre_columna,...)
index_nombre_columna: nombre_columna [(length)] [ASC | DESC]

La forma de eliminar un ndice se realiza de la siguiente manera:

DROP INDEX nombreIndice ON nombreTabla;

Para poder verificar los ndices que existen en la tabla se puede ejecutar el siguiente comando:

7
SHOW INDEX FROM nombre_tabla;

Con el cual obtendremos la informacin almacenada en la base de datos sobre los ndices creados.

3.2

Estructuras de datos de los ndices

Los ndices son estructuras de datos que facilitan el acceso a la informacin almacenada,
comprender a profundidad estas estructuras requiere un trabajo bastante extenso que sobrepasa el
alcance de este curso, son embargo a continuacin se har una breve explicacin de las estructuras
de datos soportadas por MySQL para el manejo de ndices:

Arboles B (B-Tree): Es una de las estructuras de datos ms usadas en los DBMS, est
conformado por un conjunto de nodos que contienen los valores de ndice ordenados que
apuntan a registros en el disco. Los rboles B tienen nodos internos con un nmero variable
de nodos hijo dentro de un rango predefinido. Cuando se insertan o eliminan datos de la
estructura la cantidad de nodos hijo, para esto se juntan o se parten los nodos para que se
mantenga el nmero de nodos dentro del rango establecido. Dentro de las ventajas que
tienen los Arboles B es que no requieren balancearse frecuentemente, de otro lado pueden
ocupar memoria de forma innecesaria debido a que algunos de los nodos no permanecen
ocupados en todo momento. Son muy tiles para consultas de rangos de datos, por ejemplo
los que usan la clusula BETWEEN.

Arboles R (R-Tree): Este tipo de rboles permite indexar tipos de datos espaciales o ndimencionales, como lo son los tipos de datos geometry, point, linestring o poligon,
haciendo uso de las coordenadas x, y, z de un objeto.

HASH: Las tablas de hash permiten obtener un valor de clave numrico a travs de una
funcin de Hash, permitiendo asociar a cada valor de clave que permite localizar el registro
correspondiente. Es un mtodo altamente efectivo y rpido, aunque no es tan til en
consultas que tengan que ver con rangos de valores.

8
3.3

Algunas consideraciones acerca de los ndices

Cuando se crean ndices en MySQL se puede establecer qu tipo de estructura pueden tener, (Hash,
b-tree, etc.) adems se cuenta con una serie de opciones que pueden ser utilizadas segn los
requerimientos y necesidades especficas. A continuacin mostramos algunas de las opciones que
pueden ser utilizadas.

UNIQUE: Indica que los campos de ste ndice no se repiten en la tabla.

PRIMARY: Son ndices creados sobre la clave principal de la tabla, es preferible que este
tipo de ndices sean numricos.

SPATIAL: Son ndices utilizados para tipos especiales como LINE o CURVE.

full-text: Se usa especialmente para bsqueda de cadenas dentro de columnas de gran

tamao.

Adems de los ndices, para la optimizacin del DBMS es importante conocer los tipos de tablas
y los motores de almacenamiento en MySQL, ya que cada uno de ellos tiene caractersticas propias
en cuanto al manejo de los ndices, por lo tanto un conocimiento acerca de sus ventajas o falencias
nos permitir generar estrategias mucho ms ptimas para el manejo de los datos.
MySQL tiene bsicamente dos motores de almacenamiento: MyISAM e InnoDB, La principal
diferencia entre los dos motores es que InnoDB es transaccional mientras que MyISAM no lo es.
Esto en la prctica significa que con InnoDB se puede hacer uso de las clusulas COMMIT que
permite confirmar la ejecucin de una serie o conjunto de sentencias SQL lo que permite asegurar
la integridad de la transaccin y coherencia entre los datos, y de la sentencia ROLLBACK que
permite deshacer la transaccin si en su ejecucin no se pudieron realizar todas las acciones
estipuladas. InnoDB es el motor por defecto de MySQL y es un motor ideal para sistemas con
modificaciones multiples y lecturas concurrentes.

Por otro lado MyISAM no es transaccional esto implica que aunque puede ser menos seguro en
cuanto el aseguramiento de las operaciones sobre los datos, es mucho ms rpido y no requiere de

9
tanta memoria y almacenamiento cono los motores transaccionales, lo que lo hace un motor ideal
para bases de datos que requieran de un nivel alto en cuanto a consultas de datos y bsquedas, y
que no requieran de muchas actualizaciones y transacciones.

Con esta informacin revisaremos las caractersticas ms importantes a tener en cuenta acerca de
los ndices sobre estos dos tipos de motores.

ndices en el motor InnoDB

Este tipo de tablas utilizan las denominadas tablespaces para el almacenamiento de datos e ndices.
Por defecto cuando creamos tablas sobre este motor, se crean en el directorio de datos dos archivos
de datos auto-extensibles de 10mb llamados ibdata1 y los archivos ib_logfile0 e ib_logfile1 donde
se almacenarn los registros.

Los ndices son almacenados junto con los datos dentro de esos archivos de datos y la estructura
que utilizan es de b-tree. Para el caso de las claves primarias (PRIMARY KEY) si el administrador
del sistema no las asigna, el sistema las establece internamente.

ndices en el motor MyISAM

Con este tipo de motor cuando creamos una tabla se crean tres archivos con el mismo nombre y
los siguientes tipos de extensin: .frm para la estructura de la tabla, .myd para los datos y .myi para
los ndices. Se usan ndices tipo b-tree como estructura de datos para los ndices.

10
3.4

Optimizar sentencias SELECT y otras consultas

Hay un factor determinante que afecta a todas las sentencias y es la configuracin de los permisos,
entre ms compleja sea sta mayor ser la carga para el servidor de bases de datos.
Usar permisos simples permite a MySQL reducir la carga en la verificacin de permisos cuando
los clientes ejecutan sentencias. El manual de referencia de MySQL dice por ejemplo, que si no se
conceden (GRANT) privilegios a nivel de tabla o de columna, el servidor no necesita verificar el
contenido de las tablas tables_priv y columns_priv, lo que reduce el tiempo y mejora la eficiencia.
Similarmente, si no se establecen lmites de recursos sobre ninguna cuenta, el servidor no tiene
que realizar conteos de recursos. Por lo tanto para reducir la carga de verificacin es importante
utilizar una estructura de permisos simplificada cuando se tiene un alto volumen de consultas.

Segn Hueso (2012) Para optimizar las consultas es necesario tener en cuenta los siguientes
elementos:
1. Como se ejecuta la consulta: Para ejecutar una consulta cada fila de la primera tabla de la
consulta se compara con cada fila de las tablas subsiguientes en una subconsulta, o con la
siguiente tabla en una combinacin.
2. Qu ndices existen: Si se ha creado ms de un ndice sobre un mismo campo el servidor
debe elegir el ms ptimo para lo cual se basar en su nmero de registros.
3. Cmo se almacenan los ndices: los ndices como se ha visto, en general son archivos
ordenados, que tienen registros de las columnas indexadas junto con la direccin fsica del
registro con los datos de la tabla a la que corresponde. Si el ndice contiene varias columnas
el orden es segn las columnas ms a la izquierda en la definicin del ndice.
Es por esto que la forma de mejorar el rendimiento de las consultas radique en crear ndices en los
campos ms utilizados en las consultas. Es de resaltar que crear muchos ndices tambin implica
un derroche de espacio, lo que puede perjudicar tambin el rendimiento del DBMS, al tener que
buscar los ndices adecuados para cada consulta a realizar y mantenerlos sincronizados con los
datos.

11
Si una consulta afecta solamente a campos indexados, no es necesario acceder a los datos de la
tabla sino que podemos usar directamente el archivo de ndices para obtener el resultado, en esto
radica la clave de la optimizacin de consultas.
Los ndices son fundamentales para las siguientes operaciones:

Consultas con clusulas WHERE que contienen columnas indexadas.

En combinaciones de tablas (JOIN) cuando existe un ndice en los campos comunes.

Para ordenar o agrupar campos indexados de tablas siempre y cuando se haga sobre la parte
ms a la izquierda del ndice.

Para casos en los que solo se requieren columnas indexadas no es necesario acceder a los
campos de la tabla.

3.5

Herramientas para realizar pruebas de rendimiento

My SQL cuenta con un algunas herramientas que permiten hacer pruebas de rendimiento para
visualizar qu operaciones se realizan bien y cules se hacen de forma ineficiente. Estas pruebas
de rendimiento miden el tiempo mnimo para las operaciones realizadas.

Una alternativa sencilla para determinar si una expresin o funcin especfica de MySQL presenta
problemas en una consulta es utilizar la funcin BENCHMARK(). Esta funcin siempre devuelve
cero, lo interesante es que muestra el tiempo que dur en ejecutarse la sentencia. Veamos un
ejemplo:

SELECT BENCHMARK(1000000,1+1);
BENCHMARK(1000000,1+1)
0
1 row(s) returned

0.047 sec

Este resultado se obtuvo en un sistema Intel CORE i7 2.8 GHz. Muestra que MySQL puede
ejecutar 1,000,000 de expresiones simples de suma en 0.32 segundos sobre ese sistema.

12
Otra forma de conocer el rendimiento es a travs de la sentencia EXPLAIN, puede utilizarse como
un sinnimo de DESCRIBE o tambin como una manera para obtener informacin acerca de cmo
MySQL ejecuta una sentencia SELECT. La sintaxis de la sentencia es la siguiente:

EXPLAIN [EXTENDED | PARTITIONS] SELECT consulta

Cuando se precede una sentencia SELECT con la palabra EXPLAIN, MySQL muestra
informacin del plan de ejecucin de la sentencia. En otras palabras MySQL explica cmo
procesara el SELECT.

EXPLAIN es una ayuda para decidir qu ndices agregar a las tablas, con el fin de que las
sentencias SELECT encuentren registros ms rpidamente. EXPLAIN puede utilizarse tambin
para verificar si el optimizador une (join) las tablas en el orden ptimo. Si no fuera as, se puede
forzar al optimizador a unir las tablas en el orden en el que se especifican en la sentencia SELECT
empezando la sentencia con SELECT STRAIGHT_JOIN en vez de simplemente SELECT.

EXPLAIN es una de las herramientas ms usadas para la optimizacin de consultas. El uso de

EXPLAIN permite detectar cuando un ndice se usa o no, si se usa correctamente o ver si las
consultas se ejecutan de forma ptima. De este modo el administrador tiene informacin de gran
utilidad para tomar decisiones y corregir u optimizar las consultas. Por ejemplo veamos el uso de
la clusula EXPLAIN en nuestra tabla usuarios:
EXPLAIN EXTENDED SELECT *
FROM usuarios
WHERE nombre = 'PEDRO'
AND apellidos = 'GOMEZ';
La anterior es una consulta sencilla que busca un nombre y un apellido en la tabla usuarios que
tiene un ndice compuesto por nombre y apellidos, as que MySQL buscar la primera coincidencia
en el ndice, acceder a la fila correspondiente y devolver el resultado.

13
Para nuestro ejemplo este es el resultado obtenido en Workbench:

Explicando los resultados de la consulta tenemos que:

id: Es el nmero de tabla en la consulta, en este caso solo hay una.

select_type: SIMPLE: para consultas que no son uniones.

table: la tabla de la que obtendrn los registros.

type: indica que tipo de valores se usan en la consulta, pueden ser de tipo const para datos
constantes, ref, index, range y ALL.

14

posible_keys: posibles ndices que pueden usarse para buscar registros.

Key: el nombre del ndice que MySQL ha decidido usar entre todos los posibles.

Ref: son los valores o columnas que se usan para hacer coincidir con la clave.

Rows: indica el nmero de filas que MySQL piensa que tendr que revisar antes de
devolver los resultados. Este valor es una estimacin, que no necesariamente coincide con
el nmero de filas devueltas.

Extra: Es para informacin adicional, como el uso de ciertas clusulas o el uso de ndices
para obtener el resultado de la consulta, sin necesidad de acceder a los registros de la tabla,
y por lo tanto mucho ms rpido.

A continuacin veremos algunas alternativas muy tiles que nos permitirn optimizar distintos
tipos de consultas utilizando el comando EXPLAIN.

Forzar ndices

MySQL puede tomar la decisin de no usar ndices si no lo considera apropiado, o en casos en los
que las tablas son muy pequeas. Para forzar el uso de los ndices en clusulas SELECT podemos
utilizar algunas de las siguientes alternativas despus del FROM y dar al optimizador pistas acerca
de cmo escoger los ndices haciendo uso de las clausulas USE INDEX, IGNORE INDEX,
FORCE INDEX como se describe a continuacin:
USE | FORCE | IGNORE { INDEX | KEY}
[ { FOR { JOIN | ORDER BY | GROUP BY }] ([index_list])

Con el comando USE indicamos a MySQL que use nicamente el ndice especificado, si usamos
IGNORE se evita el uso del ndice, mientras que FORCE indica que se debe hacer uso del ndice
siempre que se pueda para resolver la consulta, debido a que acceder a la tabla en disco implica un
costo muy alto en tiempo. El uso de FOR indica que se use el ndice solo en casos de unin,
ordenacin o agrupacin.

15
Para los siguientes ejemplos usaremos los scripts adjuntos para la creacin de las tablas de
departamentos y municipios de Colombia que son de gran utilidad y sobre los cuales podremos
hacer varias pruebas de inters sobre la optimizacin de consultas.
El script para la creacin de la tabla de departamentos tendra la siguiente estructura:

DROP TABLE IF EXISTS departamentos;

CREATE table departamentos(
id_departamento INT NOT NULL,
nombre_departamento VARCHAR (100) NOT NULL,
PRIMARY KEY (id_departamento)
);
CREATE INDEX nombre_departamento ON departamentos (nombre_departamento);
En este caso al finalizar la creacin de la tabla establecemos un ndice sobre el nombre del
departamento, lo que permitir realizar bsqueda de una manera muy eficiente cuando se busquen
departamentos por el nombre.
El script para la creacin de la tabla de municipios tendra la siguiente estructura:

DROP TABLE IF EXISTS municipios;

CREATE table municipios(
id_municipio INT NOT NULL,
id_departamento INT NOT NULL,
nombre_municipio VARCHAR (100) NOT NULL,
PRIMARY KEY (id_municipio),
FOREIGN KEY (id_departamento) REFERENCES departamentos(id_departamento)
);
Aunque el script es muy similar en este caso establecemos una restriccin, con el fin de referenciar
la tabla departamentos con el comando FOREIGN KEY, con lo cual las tablas quedarn enlazadas,
permitiendo que podamos tener una relacin entre los municipios y el departamento al que
pertenecen.

16
En el script se crea un ndice sobre el nombre de los municipios, lo que permitir realizar bsqueda
de una manera muy eficiente cuando se busquen municipios por el nombre, de la siguiente manera:

CREATE INDEX nombre_municipios ON municipios (nombre_municipio);

La forma de realizar la optimizacin para las bsquedas la vamos a realizar con el comando
FORCE INDEX, por ejemplo en una consulta que realice una bsqueda sobre la tabla de
municipios, con el fin de mostrar todos los municipios en orden alfabtico vamos a utilizar esta
tcnica para forzar el uso del ndice sobre los nombres de los municipios, lo que permitir que se
realice de una forma muy eficiente. A continuacin se encuentra el script que realiza esta tarea:
SELECT municipios.nombre_municipio
FROM municipios
FORCE INDEX (nombre_municipios)
ORDER BY municipios.nombre_municipio;
Optimizacin de consultas que incluyen la clusula WHERE
Para consultas con la clusula WHERE el servidor hace uso del tipo range indicando que la
consulta requiere un cierto nmero de registros resultado, dados por las condiciones que se hagan
sobre los campos. Si los campos son indexados el valor de range aparecer al utilizar la clusula
EXPLAIN. Por ejemplo la siguiente consulta, que busca un intervalo de municipios en orden si no
tuviramos ndices tendra que recorrer toda la tabla:
SELECT municipios.nombre_municipio
FROM municipios
WHERE municipios.nombre_municipio BETWEEN 'Abejorral' AND 'Curuman';
El siguiente es el resultado de realizar la sentencia EXPLAIN sobre la consulta sin ndices:

17

Como podemos ver la consulta en type muestra que tiene que recorrer toda la tabla (ALL) para
obtener el resultado revisando las 1102 filas (rows). Lo que la hace ineficiente.

Si le agregamos el ndice sobre el nombre de los municipios y ejecutamos de nuevo la sentencia

podremos ver en la siguiente grfica en la columna type que se realizar una revisin por rango
(range) y solo revisarn las filas necesarias, en este caso 278 filas (rows) que corresponden a los
registros que se encuentran en el rango solicitado. Este ejemplo sencillo nos muestra lo importante
que puede ser esta herramienta para realizar consultas mucho ms efectivas y que permitan
optimizar el consumo de nuestro DBMS. Si tenemos en cuenta que consultas de este estilo se
realizan concurrentemente y constantemente veremos que cada optimizacin realizada ser de
utilidad frente a la eficiencia de las aplicaciones que realicen consultas sobre las bases de datos.

18

Optimizacin de consultas con ms de una tabla

La siguiente consulta por ejemplo nos muestra el funcionamiento de los ndices en una consulta
que se realiza sobre dos tablas, la de departamentos y de municipios, sobre las cuales hay ndices.

EXPLAIN SELECT municipios.nombre_municipio,

departamentos.nombre_departamento
FROM departamentos, municipios
WHERE departamentos.id_departamento = municipios.id_departamento
AND departamentos.nombre_departamento
BETWEEN 'ANTIOQUIA' AND 'CALDAS'
ORDER BY municipios.nombre_municipio;

19

En este caso al ejecutar la sentencia EXPLAIN obtenemos el siguiente resultado:

Cuando hay consultas que involucran ms de una tabla es importante considerar, entre otros el
campo type en la salida de EXPLAIN. Como nos dice Hueso (2011) los valores posibles que se
pueden obtener son los siguientes:

eq_ref: se da cuando la clave ajena de la tabla secundaria es nica, en cuyo caso cada fila
de la tabla principal se combina con una nica fila de la secundaria.

ref: Es el caso contrario, la clave ajena no tiene que ser nica de forma que cada fila de la
tabla principal se combina con cada coincidencia de la secundaria.

unique subquery: se usa cuando la subconsulta se basa solo en campos clave de una tabla
de forma que es una funcin la que hace el clculo sin necesidad de acceder a la tabla
original.

index_subquery: similar al anterior pero permitiendo ndices no nicos.

20
Tambin es necesario entender el funcionamiento de este tipo de consultas desde el punto de vista
del servidor. En general para una consulta de combinacin de dos o ms tablas el proceso es el
siguiente:
1. El servidor lee la primera fila de la primera tabla.
2. A continuacin compara dicha fila con cada fila de la segunda tabla segn las condiciones
establecidas en la clusula WHERE.
3. Para cada coincidencia repite el proceso con la tercera tabla. El proceso se repite para cada
fila de la segunda tabla con la tercera y as sucesivamente hasta recorrer todas las tablas.
Segn EXPLAIN cada fila (row) de una tabla es usada para encontrar coincidencias en la segunda
y as sucesivamente.
Como vemos en la grfica anterior podemos ver que el plan de la consulta que obtenemos con
EXPLAIN nos muestra que primero realizar una consulta sobre la tabla de departamentos, como
la consulta tiene una clausula BETWEEN realizar una revisin en el rango (range) establecido
que es lo que podemos ver en la columna type. Posteriormente combina los resultados encontrados
de la primera tabla, la tabla de departamentos, con cada coincidencia de la segunda tabla, la tabla
de municipios, por esto encontramos ref en type.

Si no contramos con ndices la consulta sera mucho ms ineficiente, ya que por cada registro en
la tabla departamentos lo comparara con cada registro de la tabla municipios, es decir recorrer 32
* 1102 filas en disco, lo que implica un alto costo en tiempo y uso de recursos, si pensamos en
tablas de mayor tamao podemos ver que la diferencia puede ser inmensamente grande.

Optimizacin de consultas con sentencias ORDER BY y GROUP BY

La clusula ORDER BY permite devolver una consulta ordenada sobre uno o ms campos, este
proceso es muy costoso y hay que evitarlo en lo posible para evitar sobrecargas. En la consulta
anterior realizamos una ordenacin para obtener por orden alfabtico los municipios. Si miramos
con detenimiento la imagen de la consulta anterior podemos ver que en el campo Extra, toma el

21
valor using filesort. Cuando los campos a ser ordenados se encuentran indexados la consulta se
realiza de una manera mucho ms eficiente.

Cuando adicionalmente se cuenta con clusulas GROUP BY es posible que el DBMS requiera de
la creacin de tablas temporales, esto se reflejar con el valor Using Temporaly en el campo extra.

Consultas con ms de un ndice

Si una consulta puede usar dos ndices distintos MySQL intentar ejecutar la que requiera el uso
de menos filas, a menos que indiquemos lo contrario. Para ver la informacin de las filas
involucradas podemos ejecutar la siguiente sentencia:

SHOW INDEX FROM nombre_tabla

Optimizacin de consultas INSERT, UPDATE, DELETE

La insercin de una fila requiere de los siguientes pasos segn Hueso (2011):
1. Conectar a la base de datos.
2. Enviar el comando INSERT al servidor.
3. Parsear o traducir el comando.
4. Insertar el registro.
5. Insertar los ndices.
6. Cerrar la conexin.
Hueso nos habla que dada la cantidad de operaciones involucradas y el costo que involucra en
tiempo cuando est llena la tabla se pueden tener en cuenta las siguientes estrategias para su
optimizacin:

Usar comandos INSERT con valores mltiples.

22

Ajustar las variables bulk_insert_buffer_size y key_buffer_size para las tablas MyISAM as

como comandos INSERT y LOAD DATA INFILE que es muy recomendado para
inserciones masivas.

Para casos en los cuales se encuentran varios clientes realizando inserciones de forma
simultnea se puede utilizar la opcin DELAYED del comando INSERT.

Para tablas MyISAM en las que hay inserciones concurrentes as como lecturas de manera
simultnea podemos poner la variable current_insert a 1 de forma que se permiten
inserciones concurrentes siempre que no haya huecos en la tabla producto de la eliminacin
de filas. Para evitar esto podemos darle el valor de 2. Si esta variable est en 0
deshabilitamos esta opcin.

Para tablas no transaccionales es conveniente bloquearlas para escritura antes de realiar

inserciones. Para ello utilizaremos LOCK TABLES nombre_tabla WRITE y UNLOCK
TABLES para desbloquear. En el caso de tablas transaccionales se usan los comandos
START TRANSACTION y COMMIT

Para las clusulas de actualizacin UPDATE la optimizacin est relacionada con la necesidad de
actualizar los ndices as como a las condiciones que se realicen en la clusula WHERE, para lo
cual se ver afectada de la misma manera que la clusula SELECT.

Es recomendable, en el caso de tener que realizar una gran cantidad de actualizaciones lo mejor es
realizarlas todas, si es posible realizar la acumulacin de las mismas para ejecutarlas en un
momento establecido.

Para el caso de tablas MyISAM que usan tamao dinmico de fila (dynamic row format) es
importante usar el comando OPTIMIZE TABLE sobre el que se profundizar ms adelante.
Por ltimo para las sentencias de eliminacin DELETE el tiempo que demoran es proporcional al
nmero de ndices. Para acelerar el proceso es necesario incrementar el valor de la variable
key_buffer_size.

23
Es importante mencionar que si lo que se necesita hacer es un borrado de todos los elementos de
una tabla es preferible el uso de la sentencia TRUNCATE TABLE, aunque hay que tener en cuenta
las referencias a las que se haga relacin, para evitar que se generen errores si hay transacciones
en curso.

Mantenimiento de Tablas
MySQL cuenta con una serie de comandos que facilitan la optimizacin de sentencias SQL. A
continuacin revisaremos el uso de las sentencias ANALIZE, OPTIMIZE, REPAIR, CHECK y
CHECKSUM.

ANALIZE TABLE
Este comando analiza y almacena la distribucin de claves de una tabla. Funciona con tablas
MyISAM, BDB, e InnoDB.
La sintaxis es la siguiente:

ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...

Este comando analiza y almacena la distribucin de clave para una tabla. Durante el anlisis, la
tabla se bloquea con un bloqueo de lectura. Funciona en tablas MyISAM, BDB, y InnoDB.
MySQL usa la distribucin de claves almacenada para decidir el orden en que las tablas deben
hacer los joins cuando realiza uno en algo que no sea una constante.

REPAIR TABLE

Su funcin es reparar tablas daadas o corruptas. Normalmente no debe de usarse a menos que
haya un error grave en el sistema. Su sintaxis es como sigue:

24
REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE
tbl_name [, tbl_name] ... [QUICK] [EXTENDED] [USE_FRM]

REPAIR TABLE repara una tabla posiblemente corrupta, funciona slo en tablas MyISAM. Si
hay un desastre, REPAIR TABLE puede recuperar todos los datos de una tabla MyISAM . Si sus
tablas se corrompen a menudo, debe intentar encontrar la razn de lo que lo causa, para eliminar
la necesidad de usar REPAIR TABLE.

BACKUP TABLE
BACKUP TABLE copia al directorio de base de datos el mnimo nmero de ficheros de tablas
necesarias para restaurar la tabla. El comando funciona slo para tablas MyISAM. Copia los
ficheros de definicin .frm y de datos .MYD. El fichero ndice .MYI puede reconstruirse desde
estos otros. El directorio debe especificarse con la ruta entera. La sintaxis es la siguiente:
BACKUP TABLE tbl_name [, tbl_name] ... TO '/path/to/backup/directory'

RESTORE TABLE
Restaura la tabla o tablas de una copia de seguridad que se hizo con BACKUP TABLE. Las tablas
existentes no se sobreescriben; si trata restaurar una tabla existente, obtiene un error. Pero como
BACKUP TABLE, RESTORE TABLE actualmente funciona slo para tablas MyISAM . El
directorio debe especificarse como una ruta completa
RESTORE TABLE tbl_name [, tbl_name] ... FROM '/path/to/backup/directory'

25

Bases de datos distribuidas

Existen varias definiciones sobre qu es un sistema distribuido pero hay divergencias entre ellas,
una de las ms sencillas es la de zsu (1991) que expresa que un sistema distribuido es una
coleccin de computadoras independientes interconectadas entre s que aparecen ante los usuarios
del sistema como una nica computadora

Segn Ceri, (1984) una Base de Datos Distribuida (BDD) es una coleccin de datos que pertenece
lgicamente al mismo sistema pero que se encuentra almacenado en diferentes nodos de
una red de computadoras. Cada sitio de la red es autnomo, puede ejecutar aplicaciones locales y
al menos una aplicacin global, lo cual requiere el acceso a datos, ubicados en varios sitios, usando
un subsistema de comunicacin. Para el diseo de una BDD se han definido dos
grandes estrategias, en primer lugar el enfoque Top-Down o de arriba a abajo en el que se comienza
con el diseo del esquema global, y luego se realiza la fragmentacin de la BD y la localizacin
de los fragmentos en los sitios. Se completa ejecutando, en cada sitio, el diseo fsico de los datos.
Por otro lado el enfoque Bottom-Up o de abajo a arriba, se basa en la integracin de esquemas ya
creados en un esquema global a partir de las bases de datos existentes.

Los

Sistemas

de Bases

de Datos

Distribuidas

BDD se ajustan mucho

ms a

la estructura descentralizada de las organizaciones, y aumentan la disponibilidad de los datos, a

la vez que reducen el transporte de comunicacin y en el escenario actual donde los costos de los
equipos de infraestructura han disminuido son una alternativa viable. Dentro de las ventajas de los
Sistemas de Bases de Datos Distribuidas se encuentran los siguientes:

26

Mejora de Rendimiento: Se reduce la congestin debido a que las transacciones se

dispersan en varios sitios. As mismo las transacciones pueden realizarse en paralelo
cuando se requiere acceso a ms de un sitio, lo que reduce el tiempo de respuesta.

Disponibilidad y fiabilidad: Al ser distribuido aumenta la probabilidad de que el sistema

es encuentre activo la mayor parte del tiempo de manera continuada, ya que si falla algn
sitio es poco probable que esto pueda afectar la mayora de transacciones.

Aplicaciones: Existen aplicaciones marcadamente distribuidas, ya que cuentan con

componentes dispersos en distintos sitios, para este tipo de aplicaciones es ideal el uso de
bases de datos distribuidas ya que permite que se pueda acceder a sitos y datos locales de
una forma ms eficiente.

Dentro de las desventajas se puede mencionar que un sistema de bases de datos distribuido puede
ser ms complejo de disear, implementar y gestionar, por lo cual el DBMS debe tener
funcionalidades que permitan tener acceso a sitios remotos e intercambiar informacin para
realizar consultas y transacciones. As mismo contar con un diccionario con metadatos que pueda
dar cuenta acerca de cmo se encuentran distribuidos y replicados los datos del sistema, y la
capacidad de optimizar consultas y transacciones que se encuentren en ms de un sitio, a
continuacin se destacan otros elementos a tener en cuenta con las bases de datos distribuidas:

Es ms complicado el control y la manipulacin de los datos

Es ms difcil el aseguramiento de la integridad (consistencia, validez y exactitud de

la informacin de la informacin) en presencia de fallas no predecibles tanto de
componentes de hardware como de software.

El control de la concurrencia y los mecanismos de recuperacin son mucho ms

complejos que en un sistema centralizado dado que los datos pueden estar replicados.

27
El diseo de las Bases de Datos Distribuidas posee las fases del diseo centralizado pero
adicionalmente se tienen que tener en cuenta dos nuevos problemas que caracterizan
el proceso de distribucin de datos, e incluyen la determinacin de: cmo dividir la base de datos
en componentes para localizarlos en diferentes sitios, qu cantidad de datos debe ser replicados y
cmo deben los fragmentos replicados ser localizados.

Consideraciones para el diseo de bases de datos distribuidas

El elemento que diferencia el diseo de una base de dato centralizada y una distribuida consiste en
la fragmentacin que se refiere al como se dividir la Base de datos, y cual sern sus partes y la
asignacin, que se refiere al donde quedar ubicada cada parte y a la replicacin de datos. A
continuacin revisaremos con ms detalle estos dos conceptos.
Fragmentacin
Segn el artculo Bases de datos Distribuidas de

Vivian Romero1 el objetivo de la

fragmentacin consiste en dividir la relacin en un conjunto de relaciones ms pequeas tal que

algunas de las aplicaciones de usuario slo hagan uso de un fragmento. Sobre este marco, una
fragmentacin ideal es aquella que genera un esquema de divisin que minimiza el tiempo de
ejecucin de las aplicaciones que emplean esos fragmentos. La unidad de fragmentacin entonces
no es la tabla sino una subdivisin de sta, esto es debido a los siguientes elementos:

Las aplicaciones usan vistas definidas sobre varias relaciones, es decir, se forman a partir de
"trozos" de varias tablas. Si conseguimos que cada una de las vistas est definida sobre subtablas locales (o en su defecto lo ms "cerca" posible) a cada aplicacin, es de esperar un
incremento en el rendimiento.

Bases de datos distribuidas http://www.monografias.com/trabajos82/base-datos-distribuidas/base-datos-distribuidas.shtml

28
Si mltiples vistas de diferentes aplicaciones estn definidas sobre una tabla no fragmentada, se
tiene lo siguiente:

Si la tabla no est replicada entonces se produce generacin de trfico por accesos remotos.

Si la tabla est replicada en todos o algunos de los sitios donde residen cada una de las
aplicaciones entonces la generacin de trfico innecesario es producida por la necesidad de la
actualizacin de las copias.

Algunas de las ventajas que se pueden encontrar al descomponer una relacin en fragmentos
(unidades de distribucin) son las siguientes segn Romero:

Se permite el procesamiento concurrente de transacciones ya que no se bloquean tablas enteras

sino sub-tablas, por lo que dos consultas pueden acceder a la misma tabla pero en fragmentos
distintos.

Se permite el trabajo en paralelo de consultas al poder descomponerlas en sub-consultas, cada

una de la cuales trabajar con un fragmento diferente incrementndose as el rendimiento.

Dentro de las desventajas ms importantes contamos con las siguientes:

Degradacin del rendimiento en vistas definidas sobre varios fragmentos ubicados en sitios
distintos (es necesario realizar operaciones con esos trozos lo cual es costoso)

El control semntico se dificulta y el rendimiento se degrada debido que la verificacin de

restricciones de integridad (referencia a claves forneas, entre otras) implican buscar
fragmentos en mltiples localizaciones.

Esto implica un anlisis detallado sobre la particin de las tablas y su distribucin pensando en la
funcionalidad que tendr la base de datos y las aplicaciones que las utilicen, este proceso de
divisin y ubicacin de los fragmentos no es trivial.

29

Tipos de fragmentacin de datos

Existen tres tipos de fragmentacin:

Fragmentacin horizontal

Fragmentacin vertical

Fragmentacin hbrida

Para que una la fragmentacin de una relacin sea correcta debe satisfacer las siguientes
condiciones segn Romero:

Condicin de completitud.
La descomposicin de una relacin R en los fragmentos R1, R2, ..., Rn es completa si y
solamente si cada elemento de datos en R se encuentra en alguno de los fragmentos Ri.

Condicin de Reconstruccin.
La descomposicin de una relacin R en los fragmentos R1, R2, ..., Rn es completa si y
solamente si cada elemento de datos en R se encuentra en alguno de los fragmentos Ri.

Condicin de Fragmentos Disjuntos.

Si la relacin R se descompone en los fragmentos R1, R2, ..., Rn, y el dato di est en Rj,
entonces, no debe estar en ningn otro fragmento Rk (k?j).

A continuacin mostraremos los tipos de Fragmentacin explicados por Romero:

Fragmentacin horizontal

La fragmentacin horizontal de una relacin R produce una serie de fragmentos R1, R2, ..., Rr,
cada uno de los cuales contiene un subconjunto de las tuplas de R que cumplen determinadas
propiedades

30

Fragmentacin horizontal primaria y derivada

La Fragmentacin Horizontal Primaria (FHP) de una relacin se obtiene usando predicados

que estn definidos en esa relacin.

La Fragmentacin Horizontal Derivada (FHD) por otra parte, es el particionamiento de una

relacin como resultado de predicados que se definen en otra relacin.

Fragmentacin vertical
La fragmentacin vertical de una relacin R produce una serie de fragmentos R1, R2, ..., Rr cada
uno de los cuales contiene un subconjunto de los atributos de R as como la clave primaria de R.

Replicacin
La replicacin es fundamentalmente til para mejorar la disponibilidad de los datos. El caso ms
extremo de replicacin es la de contar en todos los sitios con la misma copia de la base de datos,
con lo cual se asegura tambin el mayor grado de disponibilidad, aunque claramente puede reducir
la eficiencia en las operaciones de actualizacin, dado que las operaciones tienen que replicarse en
cada uno de los sitios, lo que adicionalmente puede traer problemas de integridad y consistencia
en los datos. El problema de la replicacin de segmentos consiste en la determinacin de qu
fragmentos se replicarn en diferentes sitios a pesar de los problemas que acarrea la actualizacin.

La replicacin como hemos sealado distribuye la carga acelera las consultas y mejora la
disponibilidad pero sobretodo es ptima para sistemas con muchas lecturas, sin embargo tiene un
alto costo en cuanto a actualizaciones y almacenamiento.

Las 12 reglas de Edgar Codd sobre los Sistemas de Gestin de Bases de Datos Distribuidas:

31
A continuacin detallaremos las reglas de Codd acerca de las bases de datos distribuidas y que son
indispensable tener en cuenta en el diseo y la arquitectura de una base de datos distribuida. El
principio fundamental de las Bases de Datos Distribuidas o regla cero plantea lo siguiente:
"Desde el punto de vista del usuario, un sistema distribuido deber ser idntico a un sistema no
distribuido"
La regla cero conduce a las restantes 12 reglas. Todas las reglas no son independientes entre s,
ni tienen igual importancia pero son tiles para entender la tecnologa distribuida.

1. Autonoma Local: Los sitios de un sistema distribuido deben ser autnomos. La

autonoma local implica tener en cuenta los siguientes elementos:

Propietario local.

Administracin local.

Responsabilidad local.

Integracin local.

Representacin local.

2. No dependencia de un sitio central. No debe existir un nico sitio, ya que implicara:

Cuellos de botella.

Vulnerabilidad.

3. Operacin continua

Adicin de elementos

Actualizacin de versiones

4. Independencia de Localizacin. El usuario desconoce dnde estn fsicamente los datos.

5. Independencia de fragmentacin. Deseable porque simplifica los programas de los

usuarios y sus actividades en la terminal.

6. Independencia de rplica: La creacin y destruccin de rplicas debe hacerse transparente

al usuario. El uso de rplicas implica lo siguiente:

32

Mayor Prestacin: los datos son locales.

Mayor disponibilidad: los datos son accesibles siempre.

Hay que propagar las actualizaciones.

7. Procesamiento distribuido de consultas: Los Sistemas relacionales brindan herramientas de

consulta muy eficientes, as como varias maneras de trasladar los datos.
8. Manejo distribuido de transacciones. Esto implica:

Transaccin distribuida: varios agentes de la transaccin en varios lugares.

Control de recuperacin: una transaccin atmica. Todos los agentes avanzan o

retroceden juntos.

Control de concurrencia: Bloqueos mediante paso de mensajes.

9. Independencia con respecto al equipo

El SGBD se ejecutar igual sea cual sea el equipo

10. Independencia con respecto al Sistema Operativo

El SGBD debe ser multioperativo sin afectar al usuario.

11. Independencia con respecto a la Red

El SGBD debe soportar mltiples redes sin afectar al usuario.

12. Independencia con respecto al SGBD

Se pueden manejar distintas copias de SGBD si manejan la misma norma estndar

de SQL: Oracle, Informix, Multibase, etc.

Replicacin en MySQL

El servidor MySQL soporta replicacin asncrona unidireccional, esto quiere decir que un servidor
acta como maestro y uno o ms actan como esclavos. El servidor maestro escribe actualizaciones
en el fichero de log binario, y mantiene un ndice de los ficheros para rastrear las rotaciones de
logs. Estos logs sirven como registros de actualizaciones para enviar a los servidores esclavos.

33
Cuando un servidor esclavo se conecta al maestro, informa al maestro de la posicin hasta la que
el esclavo ha ledo los logs en la ltima actualizacin satisfactoria. El esclavo recibe cualquier
actualizacin que ha tenido lugar desde entonces, y se bloquea y espera para que el master le enve
nuevas actualizaciones. A continuacin podemos ver algunas consideraciones de la replicacin en
MySQL.

Un esclavo servidor puede servir como maestro si quiere preparar una cadena de
replicaciones

Tenga en cuenta que cuando usa replicacin, todas las actualizaciones de las tablas
que se replican deben realizarse en el servidor maestro. De otro modo, debe ser
cuidadoso para evitar conflictos entre actualizaciones que hacen los usuarios a las
tablas en el maestro y las actualizaciones que hacen en las tablas de los esclavos.

La replicacin unidireccional tiene beneficios para la robustez, velocidad, y

administracin del sistema:

La robustez se incrementa con un escenario maestro/esclavo. En caso de problemas

con el maestro, puede cambiar al esclavo como copia de seguridad.

Puede conseguirse un mejor tiempo de respuesta dividiendo la carga de consultas de

clientes a procesar entre los servidores maestro y esclavo. Se puede enviar
consultas SELECT al esclavo para reducir la carga de proceso de conultas del
maestro. Sin embargo, las sentencias que modifican datos deben enviarse siempre al
maestro, de forma que el maestro y el esclavo no se desincronicen. Esta estrategia de
balanceo de carga es efectiva si dominan consultas que no actualizan datos, pero este
es el caso ms habitual.

Otro beneficio de usar replicacin es que puede realizar copias de seguridad usando un
servidor esclavo sin molestar al maestro. El maestro contina procesando
actualizaciones mientras se realiza la copia de seguridad.

Procedimiento para montar una replicacin en MySQL

34
A continuacin vamos a explicar el procedimiento que encontramos en la gua de referencia de
MySQL2 para inicializar una replicacin completa de un servidor. Este procedimiento est escrito
en trminos de inicializar un esclavo nico, pero se puede usar para inicializar mltiples esclavos.
Hay que tener en cuenta que para la ejecucin del procedimiento se requiere tener el privilegio
SUPER.

1. Asegrese de que las versiones de MySQL instalado en el maestro y en el esclavo son

compatibles. Idealmente, debe usar la versin ms reciente de MySQL en maestro y
esclavo.
2. Prepare una cuenta en el maestro que pueda usar el esclavo para conectar. Esta cuenta debe
tener el privilegio REPLICATION SLAVE. Se recomienda que esta cuenta solo sea usada
para replicacin por lo que no se necesita dar ningn privilegio adicional.
Vamos a suponer que el dominio a utilizar es mydomain.com y que quiere crear una cuenta
con un nombre de usuario replica que puedan usar los esclavos para acceder al maestro
desde cualquier equipo. Vamos a signar la contrasea de slavepass. Para crear la cuenta,
use el comando GRANT de la siguiente manera:

GRANT REPLICATION SLAVE ON *.*

TO 'replica'@'%.mydomain.com' IDENTIFIED BY 'slavepass';

Si quiere usar los comandos LOAD TABLE FROM MASTER o LOAD DATA FROM
MASTER desde el servidor esclavo, necesita dar a esta cuenta privilegios adicionales de la
siguiente manera:
D a la cuenta el privilegio global SUPER y RELOAD .

Guia de Referencia de MySQL http://downloads.mysql.com/docs/refman-5.0-es.a4.pdf

35
D el privilegio SELECT para todas las tablas que quiere cargar. Cualquier tabla
maestra desde la que la cuenta no puede hacer un SELECT se ignoran por LOAD
DATA FROM MASTER.

3. Si la base de datos slo usa tablas MyISAM , vuelque todas las tablas y bloquee los
comandos de escritura ejecutando un comando el siguiente comando

FLUSH TABLES WITH READ LOCK;

Mientras el bloqueo de FLUSH TABLES WITH READ LOCK est en efecto, lee el valor
del nombre y el desplazamiento del log binario actual en el maestro con el siguiente
comando:
SHOW MASTER STATUS;

La columna File muestra el nombre del log, mientras que Position muestra el
desplazamiento. Guarde los valores. Los necesitar ms tarde cuando inicialice el servidor.
Estos representan las coordenadas de la replicacin en que el esclavo debe comenzar a
procesar nuevas actualizaciones del maestro. Una vez que tiene los datos y ha guardado el
nombre y desplazamiento del log, puede reanudar la actividad de escritura en el maestro:

UNLOCK TABLES;

Si est usando tablas InnoDB, debera usar la herramienta InnoDB Hot Backup. Realiza
una copia consistente sin bloquear el servidor maestro, y guarda el nombre y
desplazamiento del log que se corresponden a la copia para usarlo posteriormente en el
esclavo. InnoDB Hot Backup en http://www.innodb.com/manual.php

36
Una alternativa que funciona para tablas MyISAM y InnoDB es realizar un volcado SQL
del maestro en lugar de una copia binaria como se describe en la discusin precedente. Para
ello, puede usar:
mysqldump --master-data

en su maestro y cargar posteriormente el fichero de volcado SQL en el esclavo. Sin

embargo, esto es ms lento que hacer una copia binaria.
4. Asegrese que la seccin [mysqld] del fichero my.cnf en el maestro incluye una opcin
logbin.
[mysqld]
log-bin=mysql-bin
server-id=1

5. Pare el servidor que se vaya a usar como esclavo y aada lo siguiente a su fichero my.cnf
[mysqld]
server-id=slave_id

El valor slave_id , como el valor master_id , debe ser un entero positivo de 1 a 2^32 - 1.
Adems, es muy importante que el ID del esclavo sea diferente del ID del maestro. Por
ejemplo:

[mysqld]
server-id=2

6. Si ha hecho una copia de seguridad binara de los datos del maestro, cpielo en el directorio
de datos del esclavo antes de arrancar el esclavo. Asegrese que los privilegios en los

37
ficheros y directorios son correctos. El usuario que ejecuta el servidor MySQL debe ser
capaz de leer y escribir los ficheros, como en el maestro.
7. Arranque el esclavo. Si ha estado replicando prviamente, arranque el esclavo con la
opcin -- skip-slave-start para que no intente conectar inmediatamente al maestro. Tambin
puede arrancar el esclavo con la opcin --log-warnings
8. Si hace una copia de seguridad de los datos del maestro usando mysqldump, cargue el
fichero de volcado en el esclavo.
9. Ejecute los siguientes comandos en el esclavo, reemplazando los valores de opciones con
los valores relevantes para su sistema:
CHANGE MASTER TO
MASTER_HOST='master_host_name',
MASTER_USER='replication_user_name',
MASTER_PASSWORD='replication_password',
MASTER_LOG_FILE='recorded_log_file_name',
MASTER_LOG_POS=recorded_log_position;

10. Arranque el flujo esclavo:

START SLAVE;

Una vez realizado este procedimiento, el esclavo debe conectar con el maestro y atapar
cualquier actualizacin que haya ocurrido desde que se obtuvieron los datos.

Bibliografa:

38
CERI, S., PELAGATTI, G. Distributed Database, Principles and Systems. McGraw-Hill, New
York, 1984
DUBOIS, PAUL. MySQL Developers Manual: The definitive guide to using, programming and
administering MySQL 5.5 and MySQL 5.6. 2013.

HUESO IBAEZ, LUIS. Administracin de Sistemas Gestores de Bases de Datos. Ra-Ma 2011.

JAQUE BARBERO, MIGUEL. Manual de Supervivencia del Administrador de MySQL. 2007

RAMOS, MARA JESS. Sistemas gestores de bases de datos. McGraw-Hill. 2006

Enlaces web

MySQL Reference Manual

http://dev.mysql.com/doc/refman/5.7/en/index.html

Base de Datos Distribuidas. Romero Buchilln, Vivian

http://www.monografias.com/trabajos82/base-datos-distribuidas/base-datos-distribuidas.shtml