Instituto Tecnolgico Superior de

Nochistln

Ingeniera en Sistemas Computacionales

ADMINISTRACIN DE BASES DE DATOS
Ing. J. Jess Minero Guardado

Actividad 3.1 Configuracin y administracin de

espacio en disco (MySQL).
Jorge Luis Valln Medel
Nochistln de Meja, Zacatecas. 20 de febrero de 2014

NDICE
INTRODUCCIN __________________________________________________________ 2
MOTORES DE ALMACENAMIENTO DE MYSQL Y TIPOS DE TABLAS __________________ 2
USAR UN ESPACIO DE TABLAS PARA CADA TABLA _______________________________ 3
BITCORAS EN MYSQL _____________________________________________________ 5
PARTICIONES EN MYSQL ___________________________________________________ 8
GESTIN DE FICHEROS ____________________________________________________ 11
CONEXIONES DE MYSQL CLSTER QUE COMPARTEN MEMORIA __________________ 12
EJECUTAR MS DE UN SERVIDOR MYSQL EN LA MISMA MQUINA ________________ 13
CONCLUSIONES _________________________________________________________ 15
BIBLIOGRAFA___________________________________________________________ 15

INTRODUCCIN
En esta investigacin se muestra como se almacena la informacin en MySQL, as como se
llevan las bitcoras y se asignan las particiones en disco. Tambin los espacios pblicos,
privados y para objetos. Adems de la memoria compartida e instancias mltiples.

MOTORES DE ALMACENAMIENTO DE MYSQL Y TIPOS DE TABLAS

MySQL soporta varios motores de almacenamiento que tratan con distintos tipos de tabla.
Los motores de almacenamiento de MySQL incluyen algunos que tratan con tablas
transaccionales y otros que no lo hacen:

MyISAM trata tablas no transaccionales. Proporciona almacenamiento y

recuperacin de datos rpida, as como posibilidad de bsquedas fulltext. MyISAM
se soporta en todas las configuraciones MySQL, y es el motor de almacenamiento
por defecto a no ser que tenga una configuracin distinta a la que viene por defecto
con MySQL.
El motor de almacenamiento MEMORY proporciona tablas en memoria. El motor de
almacenamiento MERGE permite una coleccin de tablas MyISAM idnticas ser
tratadas como una simple tabla. Como MyISAM, los motores de almacenamiento
MEMORY y MERGE tratan tablas no transaccionales y ambos se incluyen en MySQL
por defecto.

Nota: El motor de almacenamiento MEMORY anteriormente se conoca como HEAP.

Los motores de almacenamiento InnoDB y BDB proporcionan tablas transaccionales.

BDB se incluye en la distribucin binaria MySQL-Max en aquellos sistemas
operativos que la soportan. InnoDB tambin se incluye por defecto en todas las
distribuciones binarias de MySQL 5.0 . En distribuciones fuente, puede activar o
desactivar estos motores de almacenamiento configurando MySQL a su gusto.
El motor de almacenamiento EXAMPLE es un motor de almacenamiento "tonto" que
no hace nada. Puede crear tablas con este motor, pero no puede almacenar datos
ni recuperarlos. El objetivo es que sirva como ejemplo en el cdigo MySQL para
ilustrar cmo escribir un motor de almacenamiento. Como tal, su inters primario
es para desarrolladores.
NDB Cluster es el motor de almacenamiento usado por MySQL Cluster para
implementar tablas que se particionan en varias mquinas. Est disponible en
distribuciones binarias MySQL-Max 5.0. Este motor de almacenamiento est
disponible para Linux, Solaris, y Mac OS X . Aadiremos soporte para este motor de
almacenamiento en otras plataformas, incluyendo Windows en prximas versiones.
El motor de almacenamiento ARCHIVE se usa para guardar grandes cantidades de
datos sin ndices con una huella muy pequea.
El motor de almacenamiento CSV guarda datos en ficheros de texto usando formato
de valores separados por comas.
El motor de almacenamiento FEDERATED se aadi en MySQL 5.0.3. Este motor
guarda datos en una base de datos remota. En esta versin slo funciona con MySQL
a travs de la API MySQL C Client. En futuras versiones, ser capaz de conectar con
otras fuentes de datos usando otros drivers o mtodos de conexin clientes.

USAR UN ESPACIO DE TABLAS PARA CADA TABLA

En MySQL 5.0, se puede almacenar cada tabla InnoDB y sus ndices en su propio fichero.
Esta caracterstica se llama multiple tablespaces (espacios de tablas mltiples) porque, en
efecto, cada tabla tiene su propio espacio de tablas.
El uso de mltiples espacios de tablas puede ser beneficioso para usuarios que desean
mover tablas especficas a discos fsicos separados o quienes deseen restaurar respaldos de
tablas sin interrumpir el uso de las dems tablas InnoDB.
Se pueden habilitar mltiples espacios de tablas agregando esta lnea a la seccin [mysqld]
de my.cnf:
[mysqld]
innodb_file_per_table
Luego de reiniciar el servidor, InnoDB almacenar cada nueva tabla creada en su propio
fichero nombre_tabla.ibd en el directorio de la base de datos a la que pertenece la tabla.
3

Esto es similar a lo que hace el motor de almacenamiento MyISAM, pero MyISAM divide la
tabla en un fichero de datos tbl_name.MYD y el fichero de ndice tbl_name.MYI. Para
InnoDB, los datos y los ndices se almacenan juntos en el fichero .ibd. El fichero
tbl_name.frm se sigue creando como es usual.
Si se quita la lnea innodb_file_per_table de my.cnf y se reinicia el servidor, InnoDB crear
nuevamente las tablas dentro de los ficheros del espacio de tablas compartido.
innodb_file_per_table afecta solamente la creacin de tablas. Si se inicia el servidor con
esta opcin, las tablas nuevas se crearn empleando ficheros .ibd, pero an se puede
acceder a las tablas existentes en el espacio de tablas compartido. Si se remueve la opcin,
las nuevas tablas se crearn en el espacio compartido, pero an se podr acceder a las
tablas creadas en espacios de tablas mltiples.
InnoDB siempre necesita del espacio de tablas compartido. Los ficheros .ibd no son
suficientes para que funcione InnoDB. El espacio de tablas compartido consiste de los ya
conocidos ficheros ibdata, donde InnoDB coloca su diccionario de datos interno y los
registros para deshacer cambios (undo logs).
No se puede mover libremente ficheros .ibd entre directorios de bases de datos en la
misma forma en que se hace con ficheros de tablas MyISAM. Esto se debe a que la definicin
de las tablas se almacena en el espacio de tablas compartido de InnoDB, y tambin porque
InnoDB debe preservar la consistencia de los identificadores de transacciones y los nmeros
de secuencia de registros (log).
Dentro de una determinada instalacin MySQL, se puede mover un fichero .ibd y las tablas
asociadas de una base de datos a otra con la conocida sentencia RENAME TABLE:
RENAME TABLE nombre_bd_anterior.nombre_tabla TO nombre_bd_nuevo.nombre_tabla;
Si se tiene un respaldo limpio de un fichero .ibd, se lo puede restaurar dentro de la
instalacin MySQL de donde proviene del siguiente modo:
1. Utilizando esta sentencia ALTER TABLE:
2. ALTER TABLE nombre_tabla DISCARD TABLESPACE;
Precaucin: Esto eliminar el actual fichero .ibd.
3. Colocando el fichero .ibd nuevamente en el directorio de la base de datos adecuada.
4. Utilizando esta sentencia ALTER TABLE:
5. ALTER TABLE nombre_tabla IMPORT TABLESPACE;
En este contexto, un respaldo limpio de un fichero .ibd significa:

El fichero .ibd no contiene modificaciones realizadas por transacciones sin

confirmar.
No quedan entradas sin combinar en el buffer de inserciones en el fichero .ibd.
Se han quitado todos los registros de ndice marcados para eliminacin en el fichero
.ibd.
mysqld ha descargado todas las pginas modificadas del fichero .ibd desde el buffer
pool hacia el fichero.

Se puede realizar un respaldo limpio del fichero .ibd con el siguiente mtodo:
1. Detener toda actividad del servidor mysqld y confirmar todas las transacciones.
2. Esperar hasta que SHOW INNODB STATUS indique que no hay transacciones activas
en la base de datos, y el estado del subproceso (trhead) principal de InnoDB sea
Waiting for server activity (Esperando por actividad del servidor). Entonces, se
puede hacer una copia del fichero .ibd.
Otro mtodo para hacer una copia limpia de un fichero .ibd es utilizar la herramienta
comercial InnoDB Hot Backup:
1. Utilizar InnoDB Hot Backup para respaldar la instalacin InnoDB.
2. Iniciar un segundo servidor mysqld sobre el respaldo y permitirle limpiar los ficheros
.ibd del mismo.
Figura en la lista de pendientes (TODO) para permitir mover ficheros .ibd limpios a otra
instalacin MySQL. Esto necesita que se inicialicen los IDs (identificadores) de transacciones
y los nmeros de secuencia de registros (log) en el fichero .ibd.

BITCORAS EN MYSQL
Con el crecimiento de Internet, y el desarrollo de sistemas de informacin bajo la
arquitectura Cliente/Servidor, los sistemas de cmputo ,en general, estn expuestos a
mltiples amenazas, vulnerabilidades y ataques cada vez ms complejos. Por lo tanto, es
importante que las organizaciones implementen bitcoras (o archivos logs) para almacenar
los sucesos que ocurren en el sistema. La informacin contenida en una bitcora es muy
importante y til cuando ocurre un incidente de seguridad o cuando se realiza una auditora
de sistemas.
Una bitcora puede registrar mucha informacin acerca de eventos relacionados con el
sistema que la genera los cuales pueden ser:

Fecha y hora.
Host origen.
5

Usuario.
Actividad realizada.

La importancia de las bitcoras es la de recuperar informacin ante incidentes de seguridad,

deteccin de comportamiento inusual, informacin para resolver problemas, evidencia
legal, es de gran ayuda en las tareas de cmputo forense.
Enseguida plantear un ejemplo de una bitcora desarrollada para la siguiente base de
datos de MySQL, llamada proyecto, que tiene las tablas carrera, departamento y maestros.
CREATE DATABASE proyecto;
USE proyecto
CREATE TABLE IF NOT EXISTS `carrera` (`clave_carrera` int(11) NOT NULL, `nom_carrera`
varchar(20) NOT NULL, `num_depto` int(11) NOT NULL, PRIMARY KEY (`clave_carrera`),
KEY `num_depto` (`num_depto`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE IF NOT EXISTS `departamento` ( `num_departamento` int(11) NOT
NULL,`nombre_dept` varchar(20) NOT NULL, `jefe_num_tarjet` int(11) NOT NULL,
PRIMARY KEY (`num_departamento`), KEY `jefe_num_tarjet` (`jefe_num_tarjet`) )
ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE IF NOT EXISTS `maestros` (`num_tarjeta` int(11) NOT NULL DEFAULT
0,`nombre` varchar(50) DEFAULT NULL, PRIMARY KEY (`num_tarjeta`)) ENGINE=InnoDB
DEFAULT CHARSET=latin1;
La estructura de la tabla bitcora sera la siguiente:
CREATE TABLE IF NOT EXISTS `bitacora` (`id` int(11) NOT NULL AUTO_INCREMENT,
`operacion` varchar(10) DEFAULT NULL, `usuario` varchar(40) DEFAULT NULL, `host`
varchar(30) NOT NULL, `modificado` datetime DEFAULT NULL, `tabla` varchar(40) NOT
NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1
AUTO_INCREMENT=1 ;
La bitcora debe registrar todos los movimientos (insertar, eliminar y modificar) que se
realicen en las tablas de la base de datos. Para lograr lo anterior es necesario crear un trigger
para que se ejecute despus de la operacin de insertar, otro para despus de eliminar y el
ltimo para despus de modificar para cada una de las 3 tablas de la base de datos. Los
nueve triggers necesarios para que funcione la bitcora son los siguientes:
DROP TRIGGER IF EXISTS `bit_carr_ins`;
DELIMITER //
CREATE TRIGGER `bitacora` AFTER INSERT ON `carrera`
6

FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla)
VALUES (SUBSTRING(USER(), (INSTR(USER(),@')+1)),
SUBSTRING(USER(),1,(instr(user(),@')-1)), INSERTAR, NOW(), CARRERA)
//
DROP TRIGGER IF EXISTS `bit_carr_upd`;
CREATE TRIGGER `bit_carr_upd` AFTER UPDATE ON `carrera`
FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES
(SUBSTRING(USER(), (INSTR(USER(),@')+1)), SUBSTRING(USER(),1,(instr(user(),@')-1)),
ACTUALIZAR, NOW(), CARRERA)
//
DROP TRIGGER IF EXISTS `bit_carr_del`;
CREATE TRIGGER `bit_carr_del` AFTER DELETE ON `carrera`
FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES
(SUBSTRING(USER(), (INSTR(USER(),@')+1)), SUBSTRING(USER(),1,(instr(user(),@')-1)),
ELIMINAR, NOW(), CARRERA)
//
DROP TRIGGER IF EXISTS `bit_depto_ins`;
CREATE TRIGGER `bit_depto_ins` AFTER INSERT ON `departamento`
FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla)
VALUES (SUBSTRING(USER(), (INSTR(USER(),@')+1)),
SUBSTRING(USER(),1,(instr(user(),@')-1)), INSERTAR, NOW(), DEPARTAMENTO)
//
DROP TRIGGER IF EXISTS `bit_depto_upd`;
CREATE TRIGGER `bit_depto_upd` AFTER UPDATE ON `departamento`
FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES
(SUBSTRING(USER(), (INSTR(USER(),@')+1)), SUBSTRING(USER(),1,(instr(user(),@')-1)),
ACTUALIZAR, NOW(), DEPARTAMENTO)
//
DROP TRIGGER IF EXISTS `bit_depto_del`;
CREATE TRIGGER `bit_depto_del` AFTER DELETE ON `departamento`
FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES
(SUBSTRING(USER(), (INSTR(USER(),@')+1)), SUBSTRING(USER(),1,(instr(user(),@')-1)),
ELIMINAR, NOW(), DEPARTAMENTO)
//
DROP TRIGGER IF EXISTS `bit_mae_ins`;
CREATE TRIGGER `bit_mae_ins` AFTER INSERT ON `maestros`
FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla)
VALUES (SUBSTRING(USER(), (INSTR(USER(),@')+1)),
7

SUBSTRING(USER(),1,(instr(user(),@')-1)), INSERTAR, NOW(), MAESTROS)

//
DROP TRIGGER IF EXISTS `bit_mae_upd`;
CREATE TRIGGER `bit_mae_upd` AFTER UPDATE ON `maestros`
FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES
(SUBSTRING(USER(), (INSTR(USER(),@')+1)), SUBSTRING(USER(),1,(instr(user(),@')-1)),
ACTUALIZAR, NOW(), MAESTROS)
//
DROP TRIGGER IF EXISTS `bit_mae_del`;
CREATE TRIGGER `bit_mae_del` AFTER DELETE ON `maestros`
FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES
(SUBSTRING(USER(), (INSTR(USER(),@')+1)), SUBSTRING(USER(),1,(instr(user(),@')-1)),
ELIMINAR, NOW(), MAESTROS)
//

PARTICIONES EN MYSQL
Cuando alguna de las tablas de tu base de datos llega a crecer tanto que el rendimiento
empieza a ser un problema, es hora de empezar a leer algo sobre optimizacin. ndices, el
comando EXPLAIN, el registro de consultas lentas, estas son herramientas bsicas que
todo el mundo debera conocer. Una caracterstica algo menos conocida, aunque se
introdujo en la versin 5.1 de MySQL, son las particiones.
En el hospital en que trabajo la mayor tabla con la que tenemos que lidiar es la que
almacena todos y cada uno de los contratos de todos los trabajadores que alguna pasaron
por el hospital desde que se fund en los aos 50. Esto supone slo un par de cientos de
miles de tuplas, lo cual no debera dar muchos dolores de cabeza con una base de datos
bien optimizada, consultas razonables, y un hardware decente. Sin embargo, hay personas
que tienen que tratar con cantidades de datos realmente obscenas, que multiplican estos
nmeros por 10 veces 10.
Una solucin que nos puede venir a la cabeza, sobre todo si la mayor parte de la informacin
se almacena a modo de histrico y no se accede a ella frecuentemente, es dividir la tabla
en varias porciones. Podramos mantener una tabla para el ao en curso y otra para el resto
de aos, por ejemplo; o una para cada uno de los aos; una por lustro; por dcada
dependiendo de cmo se trabaje con los datos.
El particionado es un concepto parecido, aunque automatizado, que puede ahorrarnos
muchos quebraderos de cabeza. Consiste en dividir los datos en particiones ms pequeas
8

(hasta 1024) procurando, porque de otra forma sera absurdo, que slo haya que acceder a
una particin a la hora de buscar una tupla.
Se puede particionar una tabla de 5 maneras diferentes:

Por rango: para construir nuestras particiones especificamos rangos de valores. Por
ejemplo, podramos segmentar los datos en 12 particiones: una para los contratos
de 1950 a 1960, otra para los aos 60, los 70, 80, 90, la dcada del 2000 y la dcada
actual

1. ALTER TABLE contratos

2. PARTITION BY RANGE(YEAR(fechaInicio)) (
3.
PARTITION partDecada50 VALUES LESS THAN (1960),
4.
PARTITION partDecada60 VALUES LESS THAN (1970),
5.
PARTITION partDecada70 VALUES LESS THAN (1980),
6.
PARTITION partDecada80 VALUES LESS THAN (1990),
7.
PARTITION partDecada90 VALUES LESS THAN (2000),
8.
PARTITION partDecada00 VALUES LESS THAN (2010),
9.
PARTITION partDecada10 VALUES LESS THAN MAXVALUE
10. );
Por listas: para construir nuestras particiones especificamos listas de valores
concretos.
1. ALTER TABLE contratos
2. PARTITION BY LIST(YEAR(fechaInicio)) (
3.
PARTITION partDecada50 VALUES IN (1950, 1951, 1952, 1953, 1954, 195
5, 1956, 1957, 1958, 1959),
4.
PARTITION partDecada60 VALUES IN (1960, 1961, 1962, 1963, 1964, 196
5, 1966, 1967, 1968, 1969),
5.
PARTITION partDecada70 VALUES IN (1970, 1971, 1972, 1973, 1974, 197
5, 1976, 1977, 1978, 1979),
6.
PARTITION partDecada80 VALUES IN (1980, 1981, 1982, 1983, 1984, 198
5, 1986, 1987, 1988, 1989),
7.
PARTITION partDecada90 VALUES IN (1990, 1991, 1992, 1993, 1994, 199
5, 1996, 1997, 1998, 1999),
8.
PARTITION partDecada00 VALUES IN (2000, 2001, 2002, 2003, 2004, 200
5, 2006,
9. 2007, 2008, 2009),
10. PARTITION partDecada10 VALUES IN (2010, 2011, 2012, 2013, 2014, 201
5, 2016,
11. 2017, 2018, 2019)
12. );
9

Por hash: MySQL se encarga de distribuir las tuplas automticamente usando una
operacin de mdulo. Slo hay que pasarle una columna o expresin que resulte en
un entero (el hash) y el nmero de particiones que queramos crear.
1. ALTER TABLE contratos
2. PARTITION BY HASH(YEAR(fechaInicio))
3. PARTITIONS 7;
Por clave: similar a la particin por hash, pero en este caso no necesitamos pasarle
un entero; MySQL utilizar su propia funcin de hash para generarlo. Si no se indica
ninguna columna a partir de la que generar el hash, se utiliza la clave primaria por
defecto.
1. ALTER TABLE contratos
2. PARTITION BY KEY()
3. PARTITIONS 7;
Compuesta: podemos combinar los distintos mtodos de particionado y crear
particiones de particiones
Por ltimo, un pequeo ejemplo de cmo afectara el particionado a una consulta
sencilla como obtener el nmero total de tuplas que cumplen una condicin. Estas
son las estadsticas de la consulta sin particionado (ni ndices)
1. EXPLAIN SELECT COUNT(*)
2. FROM contratos
3. WHERE fechaInicio BETWEEN '1950-01-01' AND '1955-12-31'
select_type table
type key rows Extra
SIMPLE
contratos ALL
239796 Using where
Y este el resultado de aadir las particiones (ntese la palabra clave PARTITIONS
para que nos muestre tambin la informacin relativa a las particiones)
1. EXPLAIN PARTITIONS SELECT COUNT(*)
2. FROM contratos
3. WHERE fechaInicio BETWEEN '1950-01-01' AND '1955-12-31'
select_type table
partitions
type key rows Extra
SIMPLE
contratos partDecada50 ALL
8640 Using where
Como vez, el nmero de tuplas que MySQL tiene que comprobar se ve disminuido
en 2 rdenes de magnitud.

10

GESTIN DE FICHEROS
Los ficheros de datos definidos en el fichero de configuracin forman el espacio de tablas
de InnoDB. Los ficheros simplemente son concatenados para formar el espacio de tablas.
No se utiliza striping (grabacin de datos a travs de varios discos en simultneo).
Actualmente no se puede definir en qu parte del espacio de tablas se ubicarn las tablas.
Sin embargo, en un espacio de tablas nuevo, InnoDB asigna el espacio comenzando por el
primer fichero de datos.
El espacio de tablas consiste en pginas de base de datos con un tamao por defecto de
16KB. Las pginas se agrupan en reas de 64 pginas consecutivas. Los ficheros dentro
de un espacio de tablas se llaman segmentos en InnoDB. El trmino segmento de
cancelacin (rollback segment) es un tanto confuso porque en realidad contiene varios
segmentos del espacio de tablas.
Por cada ndice de InnoDB se asignan dos segmentos. Uno es para los nodos que no son
hojas del B-tree, el otro es para los nodos hoja. La idea es mejorar la secuencialidad de los
nodos hoja, los cuales contienen los datos.
Cuando un segmento crece dentro del espacio de tablas, InnoDB ubica las primeras 32
pginas individualmente. Luego de ello, comienza a ubicar reas enteras en el segmento.
InnoDB puede adicionar a un segmento grande hasta 4 reas de pginas cada vez, para
asegurar una adecuada secuencialidad de los datos.
Algunas pginas en el espacio de tablas contienen bitmaps de otras pginas, por lo tanto
unas pocas reas en un espacio de tablas InnoDB no puede asignarse a segmentos como un
todo, sino solamente como pginas individuales.
Cuando se consulta el espacio libre disponible en el espacio de tablas mediante una
sentencia SHOW TABLE STATUS, InnoDB informa las reas que estn totalmente libres en
el espacio de tablas. InnoDB siempre reserva algunas reas para depuracin y otros
propsitos internos; estas reas reservadas no se cuentan en el espacio libre.
Cuando se eliminan datos de una tabla, InnoDB reduce los correspondientes ndices B-tree.
Depende del patrn seguido por las eliminaciones, si se liberan pginas individuales o reas
del espacio de tablas, de forma que el espacio desocupado quede disponible para otros
usuarios. Eliminar una tabla, o todas las filas que contiene, seguramente servir para liberar
el espacio, pero no hay que olvidar que las filas eliminadas solamente desaparecen
fsicamente cuando dejan de ser necesarias para cancelar transacciones o de integrar
lecturas consistentes.

11

CONEXIONES DE MYSQL CLSTER QUE COMPARTEN MEMORIA

En MySQL 5.0, MySQL Cluster trata de usar transporte a travs de memoria compartida y
configurarla automticamente cuando sea posible, principalmente donde ms de un nodo
se ejecuta concurrentemente en el mismo equipo del cluser. (En versiones anteriores de
MySQL Cluster, los segmentos de memoria compartida se soportan slo cuando el binario max se compila usando --with-ndb-shm.) Cuando se define la memoria compartida
explcitamente como mtodo de conexin, es necesario definir como mnimo NodeId1,
NodeId2 y ShmKey. Todos los otros parmetros tienen valores por defecto que funciona
bien en la mayora de casos.
Nota: El soporte SHM debe considerarse experimental.

[SHM]NodeId1, [SHM]NodeId2
Para identificar una conexin entre dos nodos es necesario proporcionar
identificadores para cada uno de ellos como NodeId1 y NodeId2.

[SHM]ShmKey
Cuando se inicializan segmentos de memoria compartido, un ID de nodo se
identifica para identificar unvocamente el segmento de memoria compartida para
usar para la comunicacin. Se expresa como un entero que no tiene valor por
defecto.

[SHM]ShmSize
Cada conexin SHM tiene un segmento de memoria compartida dnde los nodos
entre mensajes se guardan por parte del que enva y donde lo lee el receptor. El
tamao de este segmento lo define ShmSize. El valor por defecto es 1MB.

[SHM]SendSignalId
Para obtener la traza de la ruta de un mensaje distribudo, es necesario proporcionar
un identificador nico a cada mensaje. Poner este parmetro a Y hace que los IDs
de mensajes se transporten sobre la red tambin. Esta caracterstica est
desactivada por defecto.

[SHM]Checksum
Este parmetro es Y/N, y est desactivado por defecto. Cuando se activa, se calculan
los checksums para todos los mensajes y se guardan en el buffer de envo.

12

Esta caracterstica evita que los mensajes se corrompan mientras esperan en el

buffer de envo. Tambin sirve como chequeo para que no se corrompan los datos
durante el transporte.

EJECUTAR MS DE UN SERVIDOR MYSQL EN LA MISMA MQUINA

En algunos casos, podra querer ejecutar mltiples servidores mysqld en la misma mquina.
Quiz quiera probar una nueva versin de MySQL dejando la configuracin de produccin
sin cambios. O quiz quiera dar acceso para diferentes usuarios a diferentes servidores
mysqld que ellos mismos puedan administrar. (Por ejemplo, podra ser un proeedor de
servicios de Internet que proporcione instalaciones de MySQL independientes para cada
cliente.)
Para ejecutar mltiples servidores en una nica mquina, cada servidor tiene que tener
valores nicos para los diferentes parmetros de operacin. Estos se pueden establecer en
la lnea de comandos o en archivos de opciones. Consulte Seccin 4.3, Especificar opciones
de programa.
Al menos las siguientes opciones deben ser diferentes para cada servidor:

--port=port_num
--port controla el nmero de puerto de las conexiones TCP/IP.

--socket=path
--socket controla la ruta del archivo socket de Unix y el nombre de la named pipe en
Windows. En Windows, es necesario especificar diferentes nombres de pipe solo
para los servidores que soporten conexiones mediante named pipe.

--shared-memory-base-name=name
Esta opcin, actualmente, se utiliza slo en Windows. Designa el nombre de
memoria compartida utilizado por un servidor Windows para permitir a los clientes
conectarse mediante memoria compartida.

--pid-file=path
Esta opcin se utiliza nicamente en Unix. Indica el nombre del archivo en el que el
servidor escribe su ID de proceso.

13

Si utiliza las siguientes opciones de archivo de registro, deben ser diferentes para cada
servidor:

--log=path
--log-bin=path
--log-update=path
--log-error=path
--bdb-logdir=path

Las opciones de archivo de registro se explican en Seccin 5.10.5, Mantenimiento de

ficheros de registro (log).
Para un mejor rendimiento, puede especificar las siguientes opciones a cada servidor, de
manera que se distribuya la carga entre discos fsicos:

--tmpdir=path
--bdb-tmpdir=path

Tener diferentes directorios temporales tambin es una buena prctica, para hacer ms
fcil determinar qu servidor MySQL cre cualquier archivo temporal.
Generalmente, cada servidor debera utilizar un directorio de datos diferente, lo que se
especifica con la opcin --datadir=path.
Atencin: Normalmente no debera tener dos servidores que actualicen los datos de la
misma base de datos. Esto podra llevar a obtener sorpresas indeseadas si su sistema
operativo no tiene soporte para bloqueos sin posibilidad de fallo. Si (a pesar de este aviso)
ejecuta mltiples servidores que utilicen el mismo directorio de datos y tienen el registro
activado, debera utilizar las opciones adecuadas para especificar nombres de archivos de
registro que sean nicos para cada servidor. De otra manera, lo servidores intentan registrar
en los mismos archivos. Por favor, tengan cuenta que este tipo de configuracin slo
funciona con tablas MyISAM y MERGE, y no con ningn otro de los motores de
almacenamiento.
Este aviso en contra de compartir un directorio de datos entre servidores tambin se aplica
en entornos NFS. Permitir que mltiples servidores MySQL accedan a un directorio comn
es una muy mala idea.

El principal problema es que NFS es un cuello de botella de velocidad. No est

diseado para un uso tal.
Otro riesgo con NFS es que tiene que encontrar una manera de asegurarse que dos
o ms servidores no se interfieran unos con otros. Usualmente, el bloqueo de
archivos de NFS est gestionado por el demonio lockd, pero de momento no hay
ninguna plataforma que realice bloqueos 100% seguros en todas las situaciones.
14

Faciltese las cosas: Olvdese de compartir un directorio de datos entre servidores sobre
NFS. Una solucin mejor es tener una mquina que tenga diferentes CPUs y utilizar un
sistema operativo que gestione los hilos de ejecucin eficientemente.
Si tiene mltiples instalaciones de MySQL en diferentes lugares, normalmente puede
especificar el directorio base de instalacin para cada uno con la opcin --basedir=path, de
manera que cada servidor utilice un directorio de datos, archivo de registro, y archivo de
PID diferentes. (Los valores por defecto de todos ellos son determinados en relacin al
directorio base). En ese caso, las nicas opciones adicionales que necesita especificar son
las opciones --socket y --port. Por ejemplo, suponga que debe instalar diferentes versiones
de MySQL utilizando distribuciones binarias en archivos tar. Se instalan en diferentes
lugares, as que puede iniciar el servidor de cada instalacin utilizando el comando
bin/mysqld_safe bajo su correspondiente directorio base. mysqld_safe determina la
opcin --basedir apropiada para pasarle a mysqld, y usted slo necesita especificar las
opciones --socket y --port a mysqld_safe.
Tal como se explica en las siguientes secciones, es posible iniciar servidores adicionales
mediante el establecimiento de sus variables de entorno, o especificando opciones de lnea
de comandos apropiadas. Aun as, si necesita ejecutar servidores mltiples de manera
permanente, es ms conveniente utilizar archivos de opciones para especificar a cada
servidor las opciones que deben ser nicas para l.

CONCLUSIONES
Es indispensable conocer todos los tipos de tablas y datos que podemos guardar en MySQL
ya que de esto depende como podamos almacenar y particionar nuestra base de datos, cabe
sealar que MySQL soporta varios servidores a la vez que quiere decir que soporta instancias
mltiples, en mi opinin es uno de los mejores SMBD que existe.

BIBLIOGRAFA
ORACLE. (2014). MYSQL The world's most popular open source database. Obtenido de
dev.mysql.com/doc/refman/5.0/es/multiple-windows-servers.html

15