The
virtual network (virbr0) used for Network address translation (NAT)
which allows guests to access to network services. However, NAT slows
down things and only recommended for desktop installations. To disable
Network address translation (NAT) forwarding type the following
commands:
Display Current Setup
Type the following command: # ifconfig
Sample outputs:
This second installment of "Scaling Web Applications" will list out
the steps necessary for scaling a mysql deployment over two VPS.
The first article in this series laid out the steps needed to
load-balance nginx over two VPS, and it is recommended that you read
that article first.
MySQL replication is the process by which a single data set, stored
in a MySQL database, will be live-copied to a second server. This
configuration, called "master-slave" replication, is a typical setup.
Our setup will be better than that, because master-master replication
allows data to be copied from either server to the other one. This
subtle but important difference allows us to perform mysql read or
writes
from either server. This configuration adds redundancy and increases
efficiency when dealing with accessing the data.
The examples in this article will be based on two VPS, named Server C and Server D. Server C: 3.3.3.3 Server D: 4.4.4.4
Step 1 - Install and Configure MySQL on Server C
The first thing we need to do is to install the mysql-server and
mysql-client packages on our server. We can do that by typing the
following:
sudo apt-get install mysql-server mysql-client
By default, the mysql process will only accept connections on
localhost (127.0.0.1). To change this default behavior and change a few
other
settings necessary for replication to work properly, we need to edit
/etc/mysql/my.cnf on Server C.
There are four lines that we need to change, which are currently set to
the following:
The first of those lines is to uniquely identify our particular
server, in our replication configuration. We need to uncomment that
line, by
removing the "#" before it. The second line indicates the file in which
changes to any mysql database or table will be logged.
The third line indicates which databases we want to replicate between
our servers. You can add as many databases to this line
as you'd like. The article will use a single database named "example"
for the purposes of simplicity. And the last line tells our server
to accept connections from the internet (by not listening on 127.0.0.1).
We next need to change some command-line settings within our mysql
instance. Back at our shell, we can get to our root mysql user by
typing the following:
mysql -u root -p
Please note that the password this command will prompt you for is that of the root mysql user, not the root user on our droplet.
To confirm that you are logged in to the mysql shell, the prompt should look like the following.
mysql>
Once we are logged in, we need to run a few commands.
We need to create a pseudo-user that will be used for replicating data between our two VPS. The examples in this article will
assume that you name this user "replicator". Replace "password" with the password you wish to use for replication.
create user 'replicator'@'%' identified by 'password';
Next, we need to give this user permissions to replicate our mysql data:
grant replication slave on *.* to 'replicator'@'%';
Permissions for replication cannot, unfortunately, be given on a
per-database basis. Our user will only replicate the database(s) that we
instruct it to in our config file.
For the final step of the initial Server C configuration, we need to
get some information about the current MySQL instance which we will
later provide to Server D.
The following command will output a few pieces of important information, which we will need to make note of:
show master status;
The output will looking similiar to the following, and will have two pieces of critical information:
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 | 107 | example | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
We need to make a note of the file and position which will be used in the next step.
Step 2 - Install and Configure MySQL on Server D
We need to repeat the same steps that we followed on Server C.
First we need to install it, which we can do with the following command:
sudo apt-get install mysql-server mysql-client
Once the two packages are properly installed, we need to configure it
in much the same way as we configured Server C. We will start by
editing the /etc/mysql/my.cnf file.
sudo nano /etc/mysql/my.cnf
We need to change the same four lines in the configuration file as we changed earlier.
The defaults are listed below, followed by the changes we need to make.
After you save and quit that file, you need to restart mysql:
sudo service mysql restart
It is time to go into the mysql shell and set some more configuration options.
mysql -u root -p
First, just as on Server C, we are going to create the pseudo-user
which will be responsible for the replication. Replace "password" with
the password you wish to use.
create user 'replicator'@'%' identified by 'password';
Next, we need to create the database that we are going to replicate across our VPS.
create database example;
And we need to give our newly created 'replication' user permissions to replicate it.
grant replication slave on *.* to 'replicator'@'%';
The next step involves taking the information that we took a note of
earlier and applying it to our mysql instance. This will allow
replication to begin. The following should be typed at the mysql shell:
You need to replace 'password' with the password that you have chosen
for replication. Your values for MASTER_LOG_FILE and MASTER_LOG_POS may
differ than those above. You should copy the values that "SHOW MASTER
STATUS" returns on Server C.
The last thing we have to do before we complete the mysql
master-master replication is to make note of the master log file and
position to use to replicate in the other direction (from Server D to
Server C).
We can do that by typing the following:
SHOW MASTER STATUS;
The output will look similiar to the following:
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000004 | 107 | example | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
Take note of the file and position, as we will have to enter those on server C, to complete the two-way replication.
The next step will explain how to do that.
Step 3 - Completing Replication on Server C
Back on Server C, we need to finish configuring replication on the
command line. Running this command will replicate all data from Server
D.
Keep in mind that your values may differ from those above. Please
also replace the value of MASTER_PASSWORD with the password you created
when setting up the replication user.
The output will look similiar to the following:
Query OK, 0 rows affected (0.01 sec)
The last thing to do is to test that replication is working on both
VPS. The last step will explain an easy way to test this configuration.
Step 4 - Testing Master-Master Replication
Now that have all the configuration set up, we are going to test it
now. To do this, we are going to create a table in our example database
on Server C and check on Server D to see if it shows up. Then, we are
going to delete it from Server D and make sure it's no longer showing
up on Server C.
We now need to create the database that will be replicated between
the servers. We can do that by typing the following at the mysql shell:
create database example;
Once that's done, let's create a dummy table on Server C:
create table example.dummy (`id` varchar(10));
We now are going to check Server D to see if our table exists.
show tables in example;
We should see output similiar to the following:
+-------------------+
| Tables_in_example |
+-------------------+
| dummy |
+-------------------+
1 row in set (0.00 sec)
The last test to do is to delete our dummy table from Server D. It should also be deleted from Server C.
We can do this by entering the following on Server D:
DROP TABLE dummy;
To confirm this, running the "show tables" command on Server C will show no tables:
Empty set (0.00 sec)
And there you have it! Working mysql master-master replication.
As always, any feedback is more than welcome
Aquí os dejo mi cheat sheet, o pequeño manual de
referencia, personal sobre Bash. Faltan cosas pero creo que he cubierto
lo más básico. Espero que os guste.
1. Cómo ejecutar scripts Bash
Para escribir en Bash puedes hacerlo directamente desde la
consola/terminal de GNU/Linux, sin embargo, su mayor potencia radica en
poder escribir ‘scripts’ y ejecutar piezas de código para automatizar
tareas. Aquí muestro paso a paso un ejemplo.
1.1. Escribe un ‘script’ Bash
Abre tu editor de textos favoritos y escribe el siguiente código.
#!/bin/bash
echo "Hola mundo"
Guárdalo como holamundo.sh (la extensión no importa pero ésta es renococida por muchos editores de texto) .
1.2. Dale permisos
Para lanzar el ‘script’ Bash, dále permisos de ejecución. Para ello escribe en tu terminal/consola de comandos: chmod u+x holamundo.sh
Recuerda ejecutar este comando y los siguientes en la misma carpeta/directorio donde se encuentra holamundo.sh
1.3. Ejecútalo
Lanza el ‘script’ ejecutando en tu terminal/consola: ./holamundo.sh
Si no ha habido ningún problema se ejecutará el ‘script’ de Bash mostrando la frase “Hola mundo”.
2. Características Bash
Aquí se mostrarán las características de dicho intérprete de comandos o shell de GNU. Recuerda que los comandos son las acciones a ejecutar desde la consola/terminal Linux. En la siguiente sección hay una recopilación de ellos.
2.1. Comentarios
Los comentarios en Bash se hacen línea a línea con el símbolo #.
#!/bin/bash
#
# Hola Mundo comentado
#
echo "Hola mundo"
2.2. Variables
Las variables no tienen tipo, es decir, una variable puede contener una cadena, un número, etc. sin necesidad de definirlo.
La sintaxis es: nombre_variable=valor_variable
Es obligatorio no dejar espacios antes o despues del simbolo ‘=’ ya
que sino Bash interpretaría la variable como un comando Linux.
Para acceder a una variable simplemente escribe como prefijo $ en el nombre de la variable. echo $varname
Un ejemplo sencillo:
#!/bin/bash
# Asignación y salida de variables
mivariable="Me llamo Nacho"
echo $mivariable
2.2.1. Paso de variables
Cuando ejecutas desde tu terminal/consola tienes la posibilidad de pasarle más argumentos. Por ejemplo: ./miScript.sh hola 4
Para recoger estos valores escribe $ y a continuación el número de posición del argumento pasado. El primer argumento tiene valor $1, que sería ‘hola’, y el segundo argumento sería $2, en el ejemplo sería el número 4. La variable $0 es el propio nombre del archivo.
#!/bin/bash
#
# Paso de variables
#
echo "Tu primer argumento es" $1
echo "Tu segundo argumento es" $2
También hay que destacar que $? guarda el valor de salida del último comando ejecutado. $* almacena todos los argumentos y $# es el número de argumentos pasados.
2.3. Comparaciones y/o expresiones
Los condicionales y bucles se rigen mediante la evaluación de una
expresión. Por eso lo primero es saber cómo programar en Bash las
evaluaciones de una expresión.
La evaluación de una expresión da como resultado verdadero o falso.
Si la comparación o evaluación de la expresión es verdadera se
ejecutará el bucle o la condicional, si es falsa la evaluación no se
ejecutará.
En Bash, la sintaxis es la siguiente:
test expresión
ó
[ expresión ]
Un ejemplo de expresión sería [ 3 -eq 5 ] que comprueba si el valor 3 es igual a 5. Como es incorrecto, el valor que devuelve es falso. Los símbolos [ y ] tienen que estar obligatoriamente separados por un espacio.
2.3.1. Comparaciones numéricas
numero1 -eq numero2: Devuelve verdadero si 'numero1' es igual a 'numero2'.
numero1 -ge numero2: Devuelve verdadero si 'numero1' es igual o mayor a 'numero2'.
numero1 -gt numero2: Devuelve verdadero si 'numero1' es mayor a 'numero2'.
numero1 -le numero2: Devuelve verdadero si 'numero1' es igual o menor a 'numero2'.
numero1 -lt numero2: Devuelve verdadero si 'numero1' es menor a 'numero2'.
numero1 -ne numero2: Devuelve verdadero si 'numero1' no es igual a 'numero2'.
2.3.2. Comparaciones de cadenas
cadena1 = cadena2: Devuelve verdadero si 'cadena1' es idéntica a 'cadena2'.
cadena1 != cadena2: Devuelve verdadero si 'cadena1' no es idéntica a 'cadena2'.
cadena1: Devuelve verdadero si 'cadena1' es nulo (no significa que su longitud sea cero).
-n cadena1: Devuelve verdadero si la longitud de caracteres de 'cadena1' es mayor que cero.
-z cadena1: Devuelve verdadero si la longitud de caracteres de 'cadena1' es cero.
2.3.3. Comparaciones de ficheros
-d nombrefichero: Devuelve verdadero si el fichero es un directorio.
-f nombrefichero: Devuelve verdadero si el fichero es un archivo.
-r nombrefichero: Devuelve verdadero si el fichero puede ser leído.
-w nombrefichero: Devuelve verdadero si el fichero puede ser escrito.
-x nombrefichero: Devuelve verdadero si el fichero es ejecutable.
2.3.4. Comparaciones de expresiones
!expresión: Devuelve verdadero si la expresión no se cumple.
expresión1 -a expresión2: Devuelve verdadero si la expresión1 y la expresión2 se cumplen (también vale &&).
expresión1 -o expresión2: Devuelve verdadero si la expresión1 o la expresión2 se cumplen (también vale ||).
2.4. Condicionales
En programación, una sentencia condicional es una instrucción que se
pueden ejecutar o no en función del valor de una expresión. En Bash, las
condicionales más populares son los siguientes:
2.4.1. If – Then
if [ expresión ]
then
comandos
fi
2.4.2. If – Then – Else
if [ expresión ]
then
comandos
else
comandos
fi
2.4.3. If – Then – Else if – Else
if [ expresión1 ]
then
comandos
elif [ expresión2 ]
then
comandos
else
comandos
fi
2.4.4. Case
case cadena in
cadena1)
comandos
;;
cadena2)
comandos
;;
*)
comandos
;;
esac
Se comprueba cadena. Si concuerda con cadena1 se ejecutará los comandos correspondientes hasta llegar a ;;. Lo mismo ocurre con cadena2. Si cadena no coincide con cadena1 o cadena2 entonces se ejecutará *. Se puede añadir tantas cadenas de verificación como uno desee.
2.5. Bucles
Un bucle repite los comandos que uno ha escrito tantas veces hasta que la expresión se verifique.
2.5.1. For
Existen muchas maneras de realizar un bucle for en Bash. Yo sólo uso ésta:
for (( inicializador; condición; incremento ))
do
comandos
done
Su sintaxis es casi idéntica a C. Aquí un ejemplo:
#!/bin/bash
for (( c=1; c<=5; c++ ))
do
echo "Bienvenido $c veces..."
done
2.5.2. While
while [ expresión ]
do
comandos
done
2.5.3. Until
until [ expresión ]
do
comandos
done
3. Comandos Linux
Lista de comandos más importantes según la Wikipedia.
3.1. Ayuda
man: muestra manual del comando que le indiquemos.
--help: da una ayuda de los comandos.
3.2. Archivos y directorios
ls: lista los archivos y directorios.
sort: ordena alfabéticamente una lista de archivos.
cd: cambio de directorio.
pwd: muestra la ruta al directorio actual.
tree: muestra la estructura de directorios y archivos en forma gráfica.
mkdir: crea un directorio.
rmdir: borro directorios.
rm -r: borra directorios no vacíos.
cp: copia archivos.
rm: borra archivos.
mv: mueve o renombra archivos y directorios.
cat: ve el contenido de uno o varios archivos.
more: ve el contenido de los archivos.
less: ve el contenido de los archivos.
split: dividir archivos.
find: busca archivos.
locate: localiza archivos según una lista generada.
updatedb: actualiza la lista de los archivos existentes.
whereis: muestra la ubicación de un archivo.
file: muestra el tipo de archivo.
whatis: muestra descripción del archivo.
wc: cuenta líneas palabras o caracteres en un archivo.
grep: busca un texto en archivos.
head: muestra el inicio de un archivo.
tail: muestra el final de un archivo.
tailf: muestra el final de un archivo y lo que se añada en el instante (logs).
tr: reemplaza caracteres en un fichero de texto.
sed: cambia una cadena de caracteres por otra.
join: cruza la información de dos archivos y muestra las partes que se repiten.
paste: toma la primera línea de cada archivo y las combina para formar una línea de salida.
uniq: elimina líneas repetidas adyacentes del archivo entrada cuando copia al archivo salida.
cut: sirve para seleccionar columnas de una tabla o campos de cada línea de archivo.
ln: crea enlaces a archivos o carpetas.
diff: muestra las diferencias entre dos archivos.
fuser: muestra que usuario tiene en uso o bloqueado un archivo o recurso.
tar: empaqueto archivos.
gzip: comprime archivos gz.
gunzip: descomprime archivos gz.
compress: comprime archivos Z.
uncompress: descomprime archivos Z.
chmod: cambio permisos a archivos y directorios.
chown: cambio de propietario.
chgrp: cambio de grupo.
vi: abre el editor de texto vi.
pico: edita un fichero de texto.
3.3. Usuarios
adduser: agregó nuevo usuario.
useradd: agregó nuevo usuario.
userdel: borra un usuario.
passwd: permite cambiar la contraseña.
su: cambio de usuario.
whoami: muestra el nombre de usuario.
logname: muestra el nombre de usuario.
id: muestra datos de identificación del usuario.
finger: da información de usuario.
chfn: cambia la información del finger.
who: muestra los usuarios del sistema.
w: muestra un detalle de los usuarios.
last: información de los últimos usuarios que han usado el sistema.
mail: programa de correo.
pine: lector de correo en modo texto.
write: manda un mensaje a la pantalla de un usuario.
mesg: activo o desactivo recibir mensajes.
wall: mensaje a todos los usuarios.
talk: establecer una charla con otro usuario.
banner: saca letrero en la pantalla.
set: da información sobre el entorno del usuario.
addgroup: agregó nuevo grupo.
groupadd: agregó nuevo grupo.
chown: cambia el propietario de un fichero.
3.4. Procesos
top: muestra los procesos que se están ejecutando y permite matarlos.
ps: muestra la lista de procesos del usuario.
ps aux: muestra la lista de procesos de la máquina.
kill: mata proceso por ID.
killall: mata proceso por nombre.
time: mide el tiempo que tarda un proceso en ejecutarse.
fg: trae a primer plano un proceso parado o en segundo plano.
bg: pone un proceso en segundo plano.
&: colocado al final de la línea de comando ejecuta en segundo plano.
nice: ajusta la prioridad de un proceso de -20 a 19.
3.5. Discos
mount: monta un disco.
umount: desmonta un disco.
df: muestra el espacio libre de los discos.
du: muestra el espacio usado por el disco o un directorio.
mkfs: formateo un disco.
fsck: estado del disco.
fdisk: gestión de particiones.
3.6. Red
netstat: muestra estado de la red.
ifconfig: muestra la configuración del dispositivo de red.
iwconfig: muestra la configuración del dispositivo de red inalámbrico.
nmap: escanea la red y muestra los puertos que se encuentran disponibles.
ping: indica si hay respuesta por parte del servidor.
nslookup: me da la IP de nuestro servidor DNS.
telnet: me conecto a un equipo remotamente.
netconf: configuro la red.
ntop: muestra los procesos de la red.
route -n: muestra la tabla de rutas.
3.7. Sistema
rlogin: se conecta a otra máquina de forma remota (remote login).
rsh: se conecta a otra máquina de forma remota (remote shell).
ftp: se conecta a otra máquina por el protocolo ftp.
reboot: reinicia la máquina.
halt: apaga el sistema.
shutdown: apaga el sistema.
init0: apaga la máquina.
init6: reinicia la máquina.
uptime: muestra el tiempo transcurrido de encendida la máquina.
exit: cierro sesión actual.
logout: salgo del sistema.
nohup: proporciona inmunidad frente a rupturas de comunicación..
dmesg: muestra mensajes del arranque del ordenador.
history: muestra todos los comandos digitados por el usuario.
uname: da información del sistema operativo.
tee: copia la entrada estándar a la salida estándar y a un archivo.
host: muestra la dirección IP del servidor en una red local.
hostname: muestra el nombre del servidor.
umask: muestra y permite cambiar la máscara de usuario.
chroot: cambia la raíz para que root ejecute algo en forma particular.
chsh: cambia el login shell.
free: estado de la memoria.
date: muestra fecha y hora actual.
cal: muestra calendario.
clear: borro la pantalla.
at: ejecuta un comando más tarde.
env: ver variables de entorno.
export: permite el uso de variables por programas en todos los caminos del usuario.
modprobe: cargo modulo.
startx: arranca el servidor X.
xev: muestra los eventos de las teclas y el ratón.
lspci: muestra los periféricos conectados al puente pci.
lsmod: muestra los modulos cargados en el sistema.
echo: escribe un mensaje en la salida estándar.
alias: crear un alias. Un comando largo abreviado en pocas letras.
unalias: borrar un alias.
bc: calculadora.
mc: ejecuta Midnight Commander.
xkill: mata una ventana gráfica.
rpm: instala los paquetes rpm RedHat.
dpkg: instala los paquetes deb Debian.
kernelcfg: manejo los modulos cargados en el kernel.
insmod: inserta modulos en el kernel.
rmmod: elimina modulos del kernel.
updatedb: actualiza la base de datos interna de archivos.
sh: cambia al bash shell.
setxkbmap: por si no funcionan las teclas con AltGr en modo X.
4. Ejemplos
Introducir dos números diferentes e indicar cuál es el mayor
#!/bin/bash
echo "Introducir dos números:"
read A
read B
if [ $A -gt $B ]
then
echo $A "es el mayor"
else
echo $B "es el mayor"
fi
Pasar dos números como parámetros e indicar el menor
#!/bin/bash
echo $#
if [ $# -ne 2 ]
then
echo "Falta algún parámetro"
elif [ $1 -eq $2 ]
then
echo "Son iguales"
elif [ $1 -lt $2 ]
then
echo $1 "es menor"
else
echo $2 "es menor"
fi
Ver los procesos que está ejecutando un usuario concreto
#!/bin/bash
RES=s
while [ $RES = s ]
do
echo "Introducir nombre de usuario:"
read USU
ps aux|grep $USU
echo "¿Desea continuar?"
read RES
done
Mostrar los usuarios que pasamos como parámetros y saber si están conectados
#!/bin/bash
for i in $*
do
if who|grep -s $i>/dev/null
then
echo $i si está conectado
else
echo $i no está conectado
fi
done
I clearly don’t need to expound on the benefits of master-slave
replication for your MySQL database. It’s simply a good idea; one nicety
I looked forward to was the ability to run backups from the slave
without impacting the performance of our production database. But the
benefits abound. Mosttutorials
on master-slave replication use a read lock to accomplish a consistent
copy during initial setup. Barbaric! With our users sending thousands of
cards and gifts at all hours of the night, I wanted to find a way to
accomplish the migration without any downtime.
@pQd via ServerFault suggests
enabling bin-logging and taking a non-locking dump with the binlog
position included. In effect, you’re creating a copy of the db marked
with a timestamp, which allows the slave to catch up once you’ve
migrated the data over. This seems like the best way to set up a MySQL
slave with no downtime, so I figured I’d document the step-by-step here,
in case it proves helpful for others.
First, you’ll need to configure the master’s /etc/mysql/my.cnf by adding these lines in the [mysqld] section:
Restart the master mysql server and create a replication user that your slave server will use to connect to the master:
CREATE USER replicant@<<slave-server-ip>>;
GRANT REPLICATION SLAVE ON *.* TO replicant@<<slave-server-ip>> IDENTIFIED BY '<<choose-a-good-password>>';
Note: Mysql allows for passwords up to 32 characters for replication users.
Next, create the backup file with the binlog position. It will affect
the performance of your database server, but won’t lock your tables:
Restart the mysql slave, and then import your dump file:
gunzip ~/dump.sql.gz
mysql -u root -p <~/dump.sql
Log into your mysql console on your slave server and run the following commands to set up and start replication:
CHANGE MASTER TO MASTER_HOST='<<master-server-ip>>',MASTER_USER='replicant',MASTER_PASSWORD='<<slave-server-password>>', MASTER_LOG_FILE='<<value from above>>', MASTER_LOG_POS=<<value from above>>;
START SLAVE;
To check the progress of your slave:
SHOW SLAVE STATUS \G
If all is well, Last_Error will be blank, and Slave_IO_State will report “Waiting for master to send event”. Look for Seconds_Behind_Master
which indicates how far behind it is. It took me a few hours to
accomplish all of the above, but the slave caught up in a matter of
minutes. YMMV.
And now you have a newly minted mysql slave server without experiencing any downtime! A parting tip: Sometimes errors occur in
replication. For example, if you accidentally change a row of data on
your slave. If this happens, fix the data, then run:
STOP SLAVE;SET GLOBAL SQL_SLAVE_SKIP_COUNTER =1;START SLAVE;
Update: In following my own post when setting up
another slave, I ran into an issue with authentication. The slave status
showed an error of 1045 (credential error) even though I was able to
directly connect using the replicant credentials. It turns out that
MySQL allows passwords up to 32 characters in length for master-slave
replication.
Hasta
2004 las cosas estaban más o menos bajo control. Los dueños del correo
electrónico, como Microsoft (Hotmail) y Yahoo!, ofrecían bandejas de
entrada de 5 megabytes (MB). Sí, mega. En un mundo de mensajes de texto,
no estaba mal. Parece poco, pero equivalía a unos 4200 mails de una
carilla. Palabra vieja, pero significativa. Esas bandejas de entrada,
que hoy nos parecen de juguete, podían almacenar más de 8 resmas de
papel. Virtualmente, claro. Aún así, conseguíamos administrarlas con
cierta dignidad.
Pero las imágenes, los PDF, los documentos de
Excel y Word y los desmesurados y en general insulsos PPT ya habían
plantado su bandera en el espacio virtual y los 5 MB pronto empezaron a
tirarnos de sisa. Entonces Google lanzó Gmail.
Tal vez fue para celebrar su salida a la bolsa de valores. No lo sé.
Pero patearon el tablero; fue una de las primeras señales de que iban
por todo. En lugar de 5 MB la primera versión de Gmail ofrecía 1
gigabyte (GB). Es decir, 200 veces más que Hotmail o Yahoo! Mail.
Habíamos pasado de 8 a 1600 resmas. O sea una pila de papel de 80 metros
de altura. Veinte metros más que el obelisco.
Foto:SHUTTERSTOCKOh,
sí, allí fuimos, como polillas atraídas por la luz, sin pensar en que
cuando no hace falta borrar nada el amontonamiento puede volverse
ingobernable. Que fue exactamente lo que ocurrió. Entusiasmado, en un
mundo que veía desplomarse el costo del almacenamiento -prefigurando
toda la cosa Nube que se venía-, Google redobló la apuesta y
llevó la casilla de Gmail a 2 GB. Hoy ese valor está en 15 GB y la pila
de papel ya es una montaña de 1200 metros de altura. Microsoft, mediante
Outlook.com, ofrece hoy almacenamiento ilimitado. ¡Hasta el infinito y
más allá!
Hace
justo 3 años (por algún motivo en esta época del año me da por limpiar
el mail) escribí acerca de cómo filtrar los correos, para moverlos, borrarlos, etiquetarlos, reenviarlos o archivarlos automáticamente. Se trata de una vieja herramienta de los clientes de e-mail que los veteranos conocen como reglas de correo. Es la única, tenue barrera que nos separa del alud electrónico.
Pero
las reglas (o filtros, en la jerga de Gmail) no son suficientes cuando
la acumulación aluvial suma, como es mi caso, unos 10.000 mensajes. O
eso dice la pantalla. No los conté, confieso. Me da la impresión de que
son más. Como 10 millones, digamos.
La
cuestión es que liberar espacio, encontrar un mail en particular,
incluso dar con un adjunto que sabemos que nos enviaron en algún momento
de, digamos, 2014, todo eso se convierte en una empresa que está en la
misma categoría que escalar el Everest. O, para el caso, una pila de
1200 metros de papel.
Entran en escena los operadores de búsqueda
avanzada de Gmail. Son, grosso modo, palabras o frases que permiten
refinar una búsqueda según un número bastante amplio de criterios. Por
ejemplo, ¿cuántos mensajes tengo sin leer entre el 1° de enero de 2008 y el 1° de enero de 2012 que no fueron marcados como importantes?
Si no los leí hasta ahora y no me parecieron destacables, ya, fue, es
hora de borrarlos. ¿Suena bien? Sí, y se pone mejor. A propósito, Oulook.com proporciona herramientas similares, que trato más abajo.
Bordado a mano
Esta
columna nació cuando un amigo logró agotar el espacio de almacenamiento
de su Gmail (sí, en serio) y descubrió que no había forma de ordenar
los mensajes por tamaño. Sólo podía listar los que ocuparan cierta
cantidad de bytes. Habituados como estamos a las herramientas de
Windows, Mac y Linux, esto suponía un obstáculo. Pero resulta que la
búsqueda de correos que robaban espacio y merecían borrarse podía
hacerse incluso mejor en Gmail que en una carpeta de Windows. Allá
vamos.
La pantalla de Gmail está dominada por la lista de mensajes. Justo arriba hay una serie de botones (Seleccionar, Actualizar, Más,
etcétera) y, por encima de esos botones, una gran caja vacía con una
lupa. Es donde usualmente ingresamos criterios para encontrar mails. Y
es allí donde los operadores de búsqueda avanzada hacen su magia.
Algunos de estos operadores son bastante obvios. Por ejemplo, from:
sirve para listar los mensajes de cierto remitente. Dato: no hace falta
poner toda la dirección de correo, incluida la arroba y el dominio. Con
una parte funciona, salvo, claro, que tengamos varios amigos cuyas
direcciones son casi iguales. Por ejemplo (observen que no hay que dejar
ningún espacio después de los dos puntos.): from:juanpablo
La
cosa se pone mucho más interesante desde el momento en que los
operadores se pueden combinar. Por ejemplo, busquemos todos los mensajes
de juanpablo en cuyo asunto se menciona la palabra presupuesto. Se haría así: from:juanpablo subject:presupuesto
Por supuesto, las comillas pueden usarse para los asuntos con más de una palabra. from:juanpablo subject:"solicitar cuota"
También from: acepta comillas. Así: from:"Juan Pablo" subject:"solicitar cuota"
Fantástico. Ahora bien, como juanpablo es el administrador de la empresa, un número demasiado grande de sus correos mencionan la palabra presupuesto en el asunto, así que terminamos de nuevo con una lista gigante. Hay que refinar un poco más. Agreguemos un rango de tiempo: from:juanpablo subject:presupuesto after:2015/1/1 before:2016/1/1
Es
decir, todo lo que nos envió durante 2015. Perfecto, ahora la lista se
acotó lo suficiente como para limpiar lo que no sirve o encontrar lo que
buscábamos.
¿Dijimos limpiar? Vamos por los principales
responsables de que el espacio empiece a agotarse: los adjuntos. En el
caso de Google, los 15 GB de Gmail son los mismos que los de Drive, por
lo que si tenés 5 GB de mensajes, sólo te quedan 10 GB para Drive. Y
todo suma. O resta, más bien.
Busquemos, pues, todos los mensajes
con adjuntos de 5 MB que recibimos durante 2009, 2010 y 2011. En ese
caso, deberíamos escribir: size:5000000 has:attachment after:2009/1/1 before:2012/1/1
El ejemplo de arriba da cuenta del servicio que presta has:attachment, pero si no nos importa discriminar los mensajes que tienen adjuntos, también funcionaría si ponemos: size:5000000 after:2009/1/1 before:2012/1/1
El operador has:
(tiene) puede emplearse también para decirle a Gmail que muestre sólo
los mensajes con una estrella amarilla (o de cualquier otro color, para
el caso). Por ejemplo, has:blue-star
Si te estás preguntando por qué sólo tenés estrellas amarillas, la respuesta es que hay que activar las demás desde la pestaña General
de la configuración de Gmail. Una vez hecho esto, para cambiar el color
de la estrella (o escoger otro símbolo; hay varios) sólo hay que darle
clic a la estrellita blanca que se ve junto a cada mail hasta que
aparezca el color o el símbolo que buscamos.
El operador size: tiene dos socios muy útiles, larger: (mayor que) y smaller: (menor que). En rigor, size: funciona igual que larger:.
Supongamos que queremos encontrar todos los mensajes que tengan
estrella amarilla y sean de más de 1 MB. En ese caso, habría que
escribir: larger:1000000 has:yellow-star
Del mismo
modo que en las búsquedas de Google (es, en el fondo, el mismo motor),
el signo menos (-) sirve para excluir de los resultados aquellos mails
que contengan ciertas palabras, sin importar dónde. Por ejemplo, para
buscar todos los mensajes que recibimos en 2012 y que ocupan más de 1 MB
y en los que no aparecen las palabras Juan y Pedro, la línea sería: after:2012/1/1 before:2013/1/1 size:1000000 -juan -pedro
Y para asegurarnos de que no se incluyan los mensajes que guardamos como borradores, añadimos el operador in:, en este caso con inbox: after:2012/1/1 before:2013/1/1 size:1000000 -juan -pedro in:inbox
Por
cierto, también podríamos buscar algo en los Borradores, que es algo
así como ese cajón donde guardamos de todo. Para eso se usa el operador in:draft. Por ejemplo: in:draft subject:boceto
O sea, todos los mensajes en Borradores cuyo asunto diga boceto. Si no ponemos el operador subject:, listará todos los mensajes guardados como borradores en los que aparezca la palabra boceto, en cualquiera de los campos, incluidos from:, to: (para), cc: (con copia) y bcc: (con copia oculta).
Lo
genial es que el signo menos también funciona con operadores. Así, se
pueden excluir de la lista los mensajes con estrellas, que supuestamente
son más importantes para nosotros. De este modo: size:1000000 -juan -pedro in:inbox -has:yellow-star after:2012/1/1 before:2013/1/1
O bien, si usás estrellas de varios tipos: size:1000000 -juan -pedro in:inbox -is:starred after:2012/1/1 before:2013/1/1
Y aún podríamos refinar más, de esta forma, para descartar dos remitentes: size:1000000 -from:juan -from:pedro in:inbox -is:starred after:2012/1/1 before:2013/1/1
Otra
aplicación del signo menos es decirle que liste todos los mensajes
recibidos en cierto período, que ocupan más de 1 MB y que no son
importantes, así: after:2012/1/1 before:2013/1/1 size:1000000 -is:important
Podría
seguir con los ejemplos, pero creo que estos son suficientes. Gmail
recuerda las búsquedas que hicimos (obvio) y muy pronto ni siquiera hará
falta tipear todo. El operador smaller: citado antes es
interesante porque una parte importante del espacio de la bandeja de
entrada se va en pequeñeces, se esfuma por goteo. No es mala idea probar
con una línea como: smaller:50000 -is:starred -is:important is:unread
Es
decir, listar todos los mensajes de menos de 50 KB que no tengan
estrella ni sean importantes y que no hayan sido leídos. Vulgo: todo eso
que nos llega y no le prestamos atención. Se asombrarán de la cantidad
de espacio que pueden liberar.
Otra cosa. El operador in:sent
(en:enviados) es fun-da-men-tal. Pasados varios años, la cantidad de
mensajes que pueden acumularse allí, muchas veces con adjuntos, es
monumental.
Aquí, todas las opciones de operadores de búsqueda avanzada de Gmail. Funcionan sólo con la versión Web, por supuesto, no con clientes de Escritorio como Thunderbird,
pero esto no es en verdad un problema. La mayor parte de nosotros
accede a sus casillas mediante un navegador, y en general usamos el
cliente de Escritorio para mantener un backup de los mensajes, no como
interfaz principal.
Por cierto, es posible usar la caja de
búsqueda que se despliega apretando la flecha, a la derecha de la lupa,
pero los operadores que menciono aquí permiten una precisión mucho
mayor. Los recomiendo enfáticamente.
Outlook.com
El
servicio de correo de Microsoft ofrece hoy prácticamente las mismas
funciones que el de Google, sólo que el espacio de almacenamiento es,
como dije, ilimitado. También ofrece operadores de búsqueda avanzados
con los que, usando otras palabras y frases, se consigue el mismo
resultado.
Por ejemplo, se puede poner from:"bobby moore" about:"status report" para buscar los mensajes que vienen de Bobby Moore y en cuyo asunto figuran la frase exacta status report. En lugar de larger: y smaller: se usan los símbolos mayor (>) que y menor que (<), combinados con la palabra reservada messagesize:, de este modo: messagesize:>5MB (mensajes de más de 5 mega) messagesize:<50KB (mensajes de menos de 50 kilobytes)
HTTP
Strict Transport Security (often abbreviated as HSTS) is a security
feature that lets a web site tell browsers that it should only be
communicated with using HTTPS, instead of using HTTP. This tutorial will
show you how to set up HSTS in Apache2, NGINX and Lighttpd. It is
tested with all mentioned webservers, NGINX 1.1.19, Lighttpd 1.4.28 and
Apache 2.2.22 on Ubuntu 12.04, Debian 6 & 7 and CentOS 6.It should
work on other distro's however, these are just reference values.
If a web site accepts a connection through HTTP and redirects to HTTPS, the user in this case may initially talk to the non-encrypted version of the site before being redirected, if, for example, the user types http://www.foo.com/ or even just foo.com.
This opens up the potential for a man-in-the-middle attack, where the redirect could be exploited to direct a user to a malicious site instead of the secure version of the original page.
The HTTP Strict Transport Security feature lets a web site inform the browser that it should never load the site using HTTP, and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead.
An example scenario:
You log into a free WiFi access point at an airport and start surfing the web, visiting your online banking service to check your balance and pay a couple of bills. Unfortunately, the access point you're using is actually a hacker's laptop, and they're intercepting your original HTTP request and redirecting you to a clone of your bank's site instead of the real thing. Now your private data is exposed to the hacker.
Strict Transport Security resolves this problem; as long as you've accessed your bank's web site once using HTTPS, and the bank's web site uses Strict Transport Security, your browser will know to automatically use only HTTPS, which prevents hackers from performing this sort of man-in-the-middle attack.
Do note that HSTS does not work if you've never visited the website before. A website needs to tell you it is HTTPS only.
Edit your apache configuration file (/etc/apache2/sites-enabled/website.conf and /etc/apache2/httpd.conf for example) and add the following to your VirtualHost:
# Optionally load the headers module:
LoadModule headers_module modules/mod_headers.so
<VirtualHost 67.89.123.45:443>
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
</VirtualHost>
Now your website will set the header every time someone
visits, with an expiration date of two years (in seconds). It sets it at
every visit. So tomorrow, it will say two years again. You do have to set it on the HTTPS vhost only. It cannot be in the http vhost.
To redirect your visitors to the HTTPS version of your website, use the following configuration:
If you only redirect, you dont even need a document root.
You can also use modrewrite, however the above method is simpler and safer. However, modrewrite below redirects the user to the page they were visiting over https, the above config just redirects to /:
<VirtualHost *:80>
[...]
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</IfModule>
</VirtualHost>
The
last tip I'll give you is the X-Frame-Options header, which you can add
to your HTTPS website to make sure it is not embedded in a frame or
iframe. This avoids clickjacking, and might be helpfull for HTTPS
websites. Quoting the Mozilla Developer Network again:
The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a `<frame>` or `<iframe>`. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.
You can change DENY to SAMEORIGIN or ALLOW-FROM uri, see the Mozilla link above for more information on that. (Or the RFC.)
MySQL Cluster es una versión de alta disponibilidad, alta
redundancia de MySQL adaptada para el entorno de computación
distribuida. Usa el motor de almacenamiento
NDB Cluster para permitir la
ejecución de varios servidores MySQL en un cluster. Este motor de
almacenamiento está disponible en las distribuciones binarias de
MySQL 5.0 y en los RPMs compatibles con las distribuciones Linux
más modernas. (Tenga en cuenta que tanto los RPMs
mysql-server como mysql-max
deben instalarse para tener la capacidad de MySQL Cluster .)
Lo sistemas operativos en que MySQL Cluster está disponible son
Linux, Mac OS X, y Solaris. (Agunos usuarios han reportado éxito al
ejecutar MySQL Cluster en FreeBSD, aunque no está soportada
oficialmente por MySQL AB.) Estamos trabajando en hacer que Cluster
se ejecute en todos los sistemas operativos soportados por MySQL,
incluyendo Windows, y actualizaremos esta página en cuanto se
soporten nuevas plataformas.
Este capítulo representa el trabajo en progreso, y sus contenidos
son objeto de revisión mientras MySQL Cluster evoluciona.
Información adicional acerca de MySQL Cluster puede encontrarse en
la web de MySQL AB
http://www.mysql.com/products/cluster/.
Puede usar dos recursos en línea adicionales proporcionados por
MySQL AB:
MySQL Cluster es una tecnología
que permite clustering de bases de datos en memoria en un entorno
de no compartición. La arquitectura de no compartición permite
que el sistema funcione con hardware barato, y sin ningún
requerimiento especial de hardware o software. Tampoco tienen
ningún punto único de fallo porque cada componente tiene su
propia memoria y disco.
MySQL Cluster integra el servidor MySQL estándar con un motor de
almacenamiento clusterizado en memoria llamado
NDB. En nuestra documentación,
el término NDB se refiere a la
parte de la inicialización específica al motor de
almacenamiento, mientras que MySQL
Cluster se refiere a la combinación de MySQL y el
nuevo motor de almacenamiento.
Un MySQL Cluster consiste en un conjunto de máquinas, cada una
ejecutando un número de procesos incluyendo servidores MySQL ,
nodos de datos para NDB Cluster, servidores de administración, y
(posiblemente) programas especializados de acceso a datos. La
relación de estos componentes en un cluster se muestra aquí:
Todos estos programas funcionan juntos para formar un MySQL
Cluster. Cuando se almacenan los datos en el motor NDB Cluster,
las tablas se almacenan en los nodos de datos. Tales tablas son
directamente accesibles desde todos los otros servidores MySQL en
el cluster. Por lo tanto, en una aplicación de pago que almacene
datos en un cluster, si una aplicación actualiza el salario de un
empleado, todos los otros servidores MySQL que acceden a estos
datos pueden ver el cambio inmediatamente.
Los datos almacenados en los nodos de datos de MySQL Cluster
pueden replicarse: el cluster puede tratar fallos de nodos de
datos individuales sin otro impacto a parte de abortar unas pocas
transacciones debido a la pérdida de estado de transacción. Como
las aplicaciones transaccionales se suponen que tratan fallos
transaccionales, esto no debería ser un problema.
Al llevar MySQL Cluster al mundo Open Source , MySQL propociona
tratamiento de datos clusterizado con alta disponibilidad, alto
rendimiento, y escalabilidad disponible para todo el que lo
necesite.
16.2. Conceptos básicos de Basic MySQL Cluster
NDB es un motor de almacenamiento
en memoria que ofrece alta disponibilidad y caracterísitcas de
persistencia de datos.
El motor NDB puede configurarse con un rango de opciones de fallo
y balanceo de carga, pero es más sencillo arrancarlo con el motor
de almacenamiento a nivel de cluster. El motor de MySQL Cluster
NDB contiene un conjunto completo de datos, dependiente sólo de
otros datos dentro del propio cluster.
Ahora describiremos cómo inicializar un MySQL Cluster consistente
de un motor NDB y algunos servidores MySQL .
La porción de cluster del MySQL Cluster está configurada
independientemente de los servidores MySQL . En MySQL Cluster,
cada parte del cluster se considera como un
nod.
Nota: En muchos contextos, el
término "nodo" se usa para indicar una máquina, pero cuando se
discute MySQL Cluster significa un proceso.
Puede haber cualquier número de nodos en una máquina, para los
que se usa el término máquina
cluster.
Hay tres tipos de nodos cluster, y en una configuración MySQL
Cluster mínima, al menos habrán tres nodos, uno de cada tipo:
El nodo de administración (MGM) : El rol
de este tipo de nodo es administrar los otros nodos dentro del
MySQL Cluster, tal como proporcionar datos de configuración,
iniciar y parar nodos, ejecutar copias de seguridad, y así.
Como este tipo de nodo administra la configuración de otros
nodos, un nodo de este tipo debe arrancarse primero, antes de
cualquier otro nodo. Un nodo MGM se arranca con el comando
ndb_mgmd.
El nodo de datos: Este es el
tipo de nodo que almacena los datos del cluster. Hay tantos
nodos de datos como réplicas, multiplicado por el número de
fragmentos. Por ejemplo, con dos réplicas, cada uno teniendo
dos fragmentos, necesita cuatro nodos de datos. No es
necesario tener más de una réplica. Un nodo de datos se
arranca con el comando ndbd.
El nodo SQL: Este es el nodo
que accede a los datos del cluster. En el caso de MySQL
Cluster, un nodo cliente es un servidor MySQL tradicional que
usa el motor NDB Cluster . Un nodo SQL típicamente se arranca
con el comando mysqld --ndbcluster o
símplemente usando mysqld con
ndbcluster añadido a
my.cnf.
La configuración de un cluster implica configurar cada nodo
individual en el cluster y inicializar los enlaces de
comunicación individual entre los nodos. MySQL Cluster está
diseñado con la intención que los nodos de almacenamiento son
homogéneos en términos de procesador, espacio de memoria, y
ancho de banda. Además, para proporcionar un punto único de
configuración, todos los datos de configuración del cluster
entero se guardan en un único fichero de configuración.
El servidor de administración (nodo MGM) administra el fichero de
configuración del cluster y el log. Cada nodo en el cluster
recibe los datos de configuración del servidor de
administración, y necesita una forma de determinar dónde reside
el servidor de administración. Cuando ocurren eventos
interesantes en los nodos de datos, los nodos transfieren
información acerca de estos eventos al servidor de
administración, que guarda la información en el log del cluster.
Además, puede haber cualquier número de procesos clientes del
cluster o aplicaciones. Hay de dos tipos:
Clientes MySQL estándar: No
son diferentes para MySQL Cluster que para cualquier MySQL (no
cluster). En otras palabras,MySQL Cluster puede ser accedido
para aplicaciones MySQL existentes escritas en PHP, Perl, C,
C++, Java, Python, Ruby, y así.
Clientes de administración:
Estos clientes conectan al servidor de administración y
proporcionan comandos para arrancar y parar nodos, arrancar y
parar traceo de mensajes (sólo en versiones de depuración),
mostrar versiones y estatus de nodos, arrancar y parar copias
de seguridad, y así.
Esta sección es un “Cómo” (“How-To”)
en el que describimos las bases para planear, instalar,
configurar, y ejecutar un MySQL Cluster. A diferencia del ejemplo
de Sección 16.4, “Configuración de MySQL Cluster”, el resultado de
las guías y procedimientos descritos a continuación deben ser
utilizables para MySQL Cluster con unos requerimientos mínimos
para disponibilidad y salvaguardia de los datos.
En esta sección, cubrimos requerimientos de hardware y software;
red; instalación de MySQL Cluster; configuración; arrancar,
parar y reiniciar el cluster; cargar una base de datos de ejemplo;
y realizar consultas.
Suposiciones básicas
Este How-To hace las siguientes suposiciones:
Estamos preparando un cluster con 4 nodos, cada uno en
máquinas separadas, y cada uno con dirección de red fija en
una Ethernet como se muestra:
Nodo
Dirección IP
Nodo de administración (MGM)
192.168.0.10
Nodo MySQL server (SQL)
192.168.0.20
Nodo de datos (NDBD) "A"
192.168.0.30
Nodo de datos (NDBD) "B"
192.168.0.40
Puede verse mejor en el siguiente diagrama:
Nota: Para mayor simplicidad,
usamos sólo direcciones IP numéricas en este How-To. Sin
embargo, si la resolución de DNS está disponible en su red,
es posible usar nombres de equipos en lugar de direcciones IP
al configurar el cluster. Alternativamente, puede usar el
fichero /etc/hosts o el equivalente en su
sistema operativo para proporcionar significado al hacer la
búsqueda de equipos si está disponible.
Cada equipo en nuestro escenario es un PC de sobremesa basado
en Intel con una distribución Linux genérica instalada en
disco con una configuración estándar, y ejecutando sólo los
servicios necesarios. El sistema operativo con un cliente de
red TCP/IP estándar es suficiente. Para simplicidad, asumimos
que el sistema de ficheros en todas las máquinas está
configurado igual. En caso que no fuera así, necesita adaptar
estas instrucciones.
Tarjetas 100 Mbps o 1 gigabit Ethernet están instaladas en
cada máquina, junto con sus drivers, y las cuatro máquinas
están conectadas via un elemento de red Ethernet como un
switch. (Todas las máquinas deben usar tarjetas de red con la
misma velocidad; esto es, las cuatro máquinas del cluster
deben tener tarjetas 100 Mbps o las 4
máquinas deben tener tarjetas 1 Gbps.) MySQL Cluster
funcionará en una red 100 Mbps ; sin embargo, gigabit
Ethernet proporciona mejor rendimiento.
Tenga en cuenta que MySQL Cluster
no está diseñado para una
conectividad de red menor a 100 Mbps. Por esta razón (entre
otras), intentar ejecutar un MySQL Cluster en una red pública
como Internet no funcionará y no está recomendado.
Para nuestros datos de prueba, usaremos la base de datos
world disponible para descarga en la web de
MySQL AB. Como ocupa poco espacio, suponemos que cada máquina
tiene 256 MB RAM, que debe ser suficiente para ejecutar el
sistema operativo, proceso NDB del equipo y (para los nodos de
datos) almacenar la base de datos.
Aunque nos referimos a Linux en este How-To, las instrucciones y
procedimientos que proporcionamos aquí pueden adaptarse tanto a
Solaris como a Mac OS X. Suponemos que sabe realizar una
instalación mínima y configurar el sistema operativo con
capacidad de red, o que puede obtener asistencia cuando lo
necesite.
Discutimos los requerimientos hardware ,software, y de red de
MySQL Cluster con más detalle en la siguiente sección .
(Consulte Sección 16.3.1, “Hardware, software y redes”.)
16.3.1. Hardware, software y redes
Una de las ventajas de MySQL Cluster es que puede ejecutarse en
hardware normal sin ningún requerimiento especial a parte de
grandes cantidades de RAM, debido al hecho que todos los datos
se almacenan en memoria. (Tenga en cuenta que esto puede cambiar
y que queremos implementar almacenamiento en disco en versiones
futuras.) Naturalmente, CPUs múltiples y más rápidas mejoran
el rendimiento. Los requerimientos de memoria para procesos
cluster son relativamente pequeños.
Los requerimientos de software para Cluster son modestos. Los
sistemas operativos de las máquinas no requieren ningún modulo
no usual, servicios, aplicaciones o configuración extraña para
soportar MySQL Cluster. Para Mac OS X o Solaris, la instalación
estándar es suficiente. Para Linux, una instalación estándar
debe ser todo lo necesario. Los requerimientos del software
MySQL son simples: todo lo necesario es una versión de
producción de MySQL-max 5.0; debe usar la versión
-max de MySQL 5.0 para tener soporte de
cluster. No es necesario compilar MySQL para usar cluster. En
este How-To, asumimos que está usando el
-max binario apropiado para Linux. Solaris, o
Mac OS X disponible en la página de descargas de MySQL
http://dev.mysql.com/downloads.
Para comunicación entre nodos, el cluster soporta red TCP/IP en
cualquier topología estándar, y como mínimo se espera una red
100 Mbps Ethernet , más un switch, hub, o router para
proporcionar conectividad de red al cluster entero. Recomendamos
que MySQL Cluster se ejecute en su subred que no está
compartida con máquinas no-cluster por las siguientes razones:
Seguridad: La comunicación
entre nodos del cluster no están encriptadas. La única
forma de proteger transmisiones dentro de un MySQL Cluster
es ejecutar su cluster en una red protegida. Si trata de
usar MySQL Cluster para aplicaciones Web , el cluster debe
residir detrás de un firewall y no en su DMZ
(DMZ)
o en otro lugar.
Eficiencia: Inicializar un
MySQL Cluster en una red privada o protegida permite que el
cluster haga uso exclusivo del ancho de banda entre
máquinas del cluster. Usar un switch esparado para su MySQL
Cluster no sólo ayuda a protegerse de accesos no
autorizados a los datos del clsuter, también asegura que
los nodos del cluster están protegidos de interferencias
causadas por transmisiones entre otras máquinas en la red.
Para mayor confianza puede usar switches duales y tarjetas
duales para eliminar la red como punto único de fallo;
varios dispositivos soportan fallos para estos enlaces de
comunicación.
Cada máquina MySQL Cluster ejecutando nodos de almacenamiento o
SQL deben tener insalados el binario MySQL-max . Para nodos de
almacenamiento, no es necesario tener el binario MySQL server
instalado, pero tiene que instalar el demonio del servidor MGM y
los binarios de clientes (ndb_mgmd y
ndb_mgm, respectivamente). En esta sección,
cubrimos los pasos necesarios para instalar los binarios
correctos para cada tipo de nodo del cluster.
MySQL AB proporciona binarios precompilados que soportan cluster
y que no tiene que compilar. (Si necesita un binario
personalizado, consulte
Sección 2.8.3, “Instalar desde el árbol de código fuente de desarrollo”.) Por lo tanto, el
primer paso del proceso de instalación para cada máquina del
cluster es bajar la versión más reciente de su plataforma
desde MySQL
downloads area. Asumimos que los guarda en el directorio
/var/tmp de cada máquina.
Hay RPMs disponibles para plataformas Linux 32-bit y 64-bit; los
binarios -max instalados por los RPMs
soportan el motor NDBCluster . Si elige
usarlos en lugar de los binarios, tenga en cuenta que debe
instalar ambos el paquete
-server y el -max en todas
las máquinas que tendrán nodos del cluster. (Consulte
Sección 2.4, “Instalar MySQL en Linux” para más información acerca de
instalar MySQL usando RPMs.) Tras instalar de los RPM, todavía
tiene que configurar el cluster como se discute en
Sección 16.3.3, “Configuración”.
Nota: Tras completar la
instalación no arranque los binarios. Le mostraremos como
hacerlo siguiendo la configuración de todos los nodos.
Instalación de nodos de almacenamiento y
SQL
En cada una de las 3 máquinas designadas para tener los nodos
de almacenamiento o SQL, realice los siguientes pasos como root
del sistema:
Compruebe los ficheros /etc/passwd y
/etc/group ( o use cualquier
herramienta proporcionada por el sistema operativo para
tratar usuarios y grupos) para ver si hay un grupo
mysql y usuario mysql
en el sistema, como algunas de las distribuciones de sistema
operativo los crean como parte del proceso de instalación.
Si no están presentes, cree un nuevo grupo
mysql y un usuario
mysql para este grupo:
groupadd mysql
useradd -g mysql mysql
Cambie al directorio que contiene el fichero descargado;
desempaquételo; cree un symlink al ejecutable mysql-max.
Tenga en cuenta que el nombre del fichero y difectorio
cambia en función del número de versión de MySQL .
cd /var/tmp
tar -xzvf -C /usr/local/bin mysql-max-5.0.10-pc-linux-gnu-i686.tar.gz
ln -s /usr/local/bin/mysql-max-5.0.10-pc-linux-gnu-i686 mysql
Cambie al directorio mysql , y ejecute
el script proporcionado para crear las bases de datos del
sistema:
cd mysql
scripts/mysql_install_db --user=mysql
Configure los permisos necesarios para los directorios de
MySQL server y de datos:
chown -R root .
chown -R mysql data
chgrp -R mysql .
Tenga en cuenta que el directorio de datos en cada máquina
con un nodo de datos es
/usr/local/mysql/data. Haremos uso de
esta información al configurar el nodo de administración .
(Consulte Sección 16.3.3, “Configuración”.)
Copie el script de arranque de MySQL en el directorio
apropiado, hágalo ejecutable, y configúrelo para arrancar
junto al sistema operativo:
Aquí usamos Red Hat chkconfig para crear
enlaces a los scripts de arranque; use lo que sea apropiado
para su sistema operativo / distribución, tal como
update-rc.d en Debian.
Recuerde que los pasos listados anteriormente deben realizarse
separadamente en cada máquina en que el nodo de almacenamiento
o SQL residen.
Instalación del nodo de
administración
Para el nodo MGM (administración), no es necesario instalar el
ejecutable mysqld, sólo los binarios para el
cliente y servidor MGM, que pueden encontrarse en el archivo
-max descargado. De nuevo asumimos que ha
guardado este fichero en /var/tmp. Como
root del sistema (esto es, tras usar sudo,
su root, o su equivalente en su sistema para
asumir temporalmente los privilegios de administrador de
sistema), realice los siguientes pasos para instalar
ndb_mgmd y ndb_mgm en el
nodo de administración del cluster:
Mueva el directorio /var/tmp , y
extraiga ndb_mgm y
ndb_mgmd del archivo a un directorio
disponible como /usr/local/bin:
cd /var/tmp
tar -zxvf mysql-max-5.0.10-pc-linux-gnu-i686.tar.gz /usr/local/bin '*/bin/ndb_mgm*'
Vaya al directorio en que ha desempaquetado los ficheros, y
hágalos ejecutables:
cd /usr/local/bin
chmod +x ndb_mgm*
En Sección 16.3.3, “Configuración”, crearemos y escribiremos los
ficheros de configuración para todos los nodos del cluster de
ejemplo.
16.3.3. Configuración
Para nuestro cluster de 4 nodos y 4 equipos, necesitamos
escribir 4 ficheros de configuración, 1 por nodo/equipo.
Cada nodo de datos o SQL necesita un fichero
my.cnf que proporciona dos
informaciones: un
connectstring diciendo al
nodo dónde encontrar el nodo MGM , y una línea diciendo al
servidor MySQL en este equipo (la máquina del nodo de
datos) que se ejecute en modo NDB.
Para más información de connectstrings, consulte
Sección 16.4.4.2, “El connectstring de MySQL Cluster”.
El nodo de administración necesita un fichero
config.ini que le diga cuántas
replicas mantener, cuánta memoria reservar para datos e
índices en cada nodo de datos, dónde encontrar los nodos
de datos, dónde se guardarán los datos en cada nodo de
datos, y dónde encontrar los nodos SQL.
Configuración de los nodos de
almacenamiento y SQL
El fichero my.cnf necesitado por los nodos
de datos es muy simple. El fichero de configuración debe estar
localizado en el directorio /etc y puede
editarse (y crearse en caso necesario) usando un editor de
texto, por ejemplo:
vi /etc/my.cnf
Para cada nodo de datos y SQL en nuestra configuración de
ejemplo, my.cnf debe tener este aspecto:
[MYSQLD] # Options for mysqld process:
ndbcluster # run NDB engine
ndb-connectstring=192.168.0.10 # location of MGM node
[MYSQL_CLUSTER] # Options for ndbd process:
ndb-connectstring=192.168.0.10 # location of MGM node
Tras introducir lo anterior, guarde este fichero y salga del
editor de texto. Hágalo pra las máquinas que guarden el nodo
de datos "A", el "B" y el nodo SQL.
Configuración del nodo de
administración
El primer paso al configurar el nodo MGM es crear el directorio
en que puede encontrarse el fichero de configuración y crear el
fichero própiamente dicho. Por ejemplo (ejecutando como root):
mkdir /var/lib/mysql-cluster
cd /var/lib/mysql-cluster
vi config.ini
Mostramos vi para crear el fichero, pero
puede usar cualquier editor de textos.
Para nuestra inicialización representativa, el fichero
config.ini debe leerse así:
[NDBD DEFAULT] # Options affecting ndbd processes on all data nodes:
NoOfReplicas=2 # Number of replicas
DataMemory=80M # How much memory to allocate for data storage
IndexMemory=18M # How much memory to allocate for index storage
# For DataMemory and IndexMemory, we have used the
# default values. Since the "world" database takes up
# only about 500KB, this should be more than enough for
# this example Cluster setup.
[TCP DEFAULT] # TCP/IP options:
portnumber=2202 # This the default; however, you can use any
# port that is free for all the hosts in cluster
# Note: It is recommended beginning with MySQL 5.0 that
# you do not specify the portnumber at all and simply allow
# the default value to be used instead
[NDB_MGMD] # Management process options:
hostname=192.168.0.10 # Hostname or IP address of MGM node
datadir=/var/lib/mysql-cluster # Directory for MGM node logfiles
[NDBD] # Options for data node "A":
# (one [NDBD] section per data node)
hostname=192.168.0.30 # Hostname or IP address
datadir=/usr/local/mysql/data # Directory for this data node's datafiles
[NDBD] # Options for data node "B":
hostname=192.168.0.40 # Hostname or IP address
datadir=/usr/local/mysql/data # Directory for this data node's datafiles
[MYSQLD] # SQL node options:
hostname=192.168.0.20 # Hostname or IP address
datadir=/usr/local/mysql/data # Directory for SQL node's datafiles
# (additional mysqld connections can be
# specified for this node for various
# purposes such as running ndb_restore)
(NOTA: La base de datos "world"
puede descargarse desde http://dev.mysql.com/doc/
donde puede encontrarse en "Examples".)
Una vez que todos los ficheros de configuración se han creado y
se han especificado estas opciones, está preparado para
arrancar el cluster y verificar que todos los procesos están en
ejecución. Se discute acreca de esto en
Sección 16.3.4, “Arranque inicial”.
Para información más detallada acerca de los parámetros de
configuración de MySQL Cluster y sus usos, consulte
Sección 16.4.4, “Fichero de configuración” y
Sección 16.4, “Configuración de MySQL Cluster”. Para
configuración de MySQL Cluster para realizar copias de
seguridad, consulte
Sección 16.6.4.4, “Configuración para copias de seguridad de un nodo”.
Nota: El puerto por defecto
para administración del cluster es 1186; el puerto por defecto
para nodos de datos es 2202. A partir de MySQL 5.0.3, esta
restricción se elimina, y el cluster reserva los puertos de los
nodos de datos automáticamente de los que están libres.
16.3.4. Arranque inicial
Arrancar el cluster no es complicado una vez configurado. Cada
proceso de los nodos del cluster debe arrancarse separadamente,
y en la máquina en que reside. Mientras es posible arrancar los
nodos en cualquier orden, seguidos por los nodos de
almacenamiento y finalmente por los nodos SQL:
En la máquina de administración, realice el siguiente
comando del shell del sistema para arrancar los procesos del
nodo MGM:
En cada equipo de los nodos de datos, ejecute este comando
para arrancar el proceso NDBD por primera vez:
shell> ndbd --initial
Tenga en cuenta que es muy imporante usar el parámetro
--initialsólo al arrancar
ndbd por primera vez, o tras reiniciar
tras una copia de seguridad/restauración o cambio de
configuración. Esto es debido a que este parámetro hará
que el nodo borre cualquier fichero creado por instancias
ndbd anteriormente necesarios para la
restauración, incluyendo el fichero log de restauración.
En la máquina cluster donde reside el nodo SQL, ejecute un
mysqld normal como se muestra:
shell> mysqld &
Si todo ha ido bien, y el cluster se ha inicializado
correctamente, el cluster debería ser operacional. Puede
comprobarlo invocando el nodo cliente de administración
ndb_mgm ; la salida debe parecerse a la que
hay a continuación:
Puede encontrar ligeras diferencias en función de la versión
exacta de MySQL que use.
Nota: Si usa una versión
antigua de MySQL, puede ver el nodo SQL referenciado como
'[mysqld(API)]'. Esto refleja un uso antiguo
que ya está obsoleto.
Debería ser capaz de trabajar con bases de datos, tablas y
datos en MySQL Cluster. Consulte
Sección 16.3.5, “Cargar datos de ejemplo y realizar consultas” para una breve
discusión.
16.3.5. Cargar datos de ejemplo y realizar consultas
Trabajar don datos en MySQL Cluster no es muy distinto que
trabajar con MySQL sin Cluster. Hay que tener en cuenta dos
puntos al hacerlo:
Las tablas deben crearse con la opción
ENGINE=NDB o
ENGINE=NDBCLUSTER , o cambiarse (mediante
ALTER TABLE) para usar el motor NDB
CLuster para que puedan replicarse en el cluster. Si está
importando tablas de una base de datos existente usando la
salida de mysqldump, puede abrir el
script SQL en un editor de texto y añadir está opción a
cualquier comando de creación de tablas, o reemplazar
cualquier opción ENGINE (o
TYPE) existente con alguna de estas. Por
ejemplo, suponga que tiene la base de datos de ejemplo
world en otro MySQL server (que no
soporta MySQL Cluster), y desea exportar la definición de
la tabla City :
shell> mysqldump --add-drop-table world City > city_table.sql
El fichero city_table.sql resultante
contendrá el comando de creación de la tabla ( y el
comando INSERT necesario para importar
los datos de la tabla):
DROP TABLE IF EXISTS City;
CREATE TABLE City (
ID int(11) NOT NULL auto_increment,
Name char(35) NOT NULL default '',
CountryCode char(3) NOT NULL default '',
District char(20) NOT NULL default '',
Population int(11) NOT NULL default '0',
PRIMARY KEY (ID)
) TYPE=MyISAM;
INSERT INTO City VALUES (1,'Kabul','AFG','Kabol',1780000);
INSERT INTO City VALUES (2,'Qandahar','AFG','Qandahar',237500);
INSERT INTO City VALUES (3,'Herat','AFG','Herat',186800);
# (remaining INSERT statements omitted)
Necesitará asegurarse que MySQL usa el motor NDB para esta
tabla. Hay dos formas de hacerlo. Una es,
antes de importar la tabla
en la base de datos del cluster, modificar su definición
para que lea (usando City como ejemplo):
DROP TABLE IF EXISTS City;
CREATE TABLE City (
ID int(11) NOT NULL auto_increment,
Name char(35) NOT NULL default '',
CountryCode char(3) NOT NULL default '',
District char(20) NOT NULL default '',
Population int(11) NOT NULL default '0',
PRIMARY KEY (ID)
) ENGINE=NDBCLUSTER;
INSERT INTO City VALUES (1,'Kabul','AFG','Kabol',1780000);
INSERT INTO City VALUES (2,'Qandahar','AFG','Qandahar',237500);
INSERT INTO City VALUES (3,'Herat','AFG','Herat',186800);
# (etc.)
Esto debe hacerse para la definición de cada tabla que
será parte de la base de datos clusterizada. La forma más
fácil de hacerlo es símplemente hacer un buscar y
reemplazar en el fichero world.sql y
reemplazar todas las instancias de
TYPE=MyISAM con
ENGINE=NDBCLUSTER. Si no quiere modificar
el fichero, puede usar ALTER TABLE;
consulte a continuación las particularidades.
Asumiendo que ha creado la base de datos llamada
world en el nodo SQL del cluster, puede
usar el cliente de línea de comandos
mysql para leer
city_table.sql, y crear y llenar de
datos la tabla correspondiente de la forma usual:
shell> mysql world < city_table.sql
Es muy importante recordar que el comando anterior debe
ejecutarse en la máquina en que corre el nodo SQL -- en
este caso, la máquina con dirección IP
192.168.0.20.
Para crear una copia de la base de datos
world en el nodo SQL, guarde el fichero
en /usr/local/mysql/data, luego ejecute
shell> cd /usr/local/mysql/data
shell> mysql world < world.sql
Por supuesto, el script SQL debe ser leíble por el usuario
mysql . Si guarda el fichero en un lugar
distinto, ajuste lo anterior correctamente.
Es importante tener en cuenta que NDB Cluster en MySQL 5.0
no soporta descubrimiento automático de bases de datos.
(Consulte Sección 16.8, “Limitaciones conocidas de MySQL Cluster”.) Esto
significa que , una vez que la base de datos
world y sus tablas se han creado en un
nodo de datos, necesitará ejecutar el comando
CREATE DATABASE world; (a partir de MySQL
5.0.2, puede usar CREATE SCHEMA world; en
su lugar), seguido por FLUSH TABLES; en
cada nodo de datos del cluster. Esto hará que el nodo
reconozca la base de datos y lea sus definiciones de tablas.
Ejecutar consultas SELECT en el nodo SQL
no es distinto a ejecutarlas en cualquier otra instancia de
un MySQL server. Para ejecutar consultas de línea de
comandos, primero necesita loguearse en el MySQL Monitor
normalmente:
shell> mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.1.9-max
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
Si no modifica las cláusulas ENGINE= en
las definiciones de tabla antes de importar el script SQL,
debe ejecutar los siguientes comandos en este punto:
mysql> USE world;
mysql> ALTER TABLE City ENGINE=NDBCLUSTER;
mysql> ALTER TABLE Country ENGINE=NDBCLUSTER;
mysql> ALTER TABLE CountryLanguage ENGINE=NDBCLUSTER;
Tenga en cuenta que símplemente usamos la cuenta
root por defecto del sistema con una
contraseña vacía. Por supuesto, en un sistema de
producción, debe siempre
seguir las precauciones de seguridad para instalar un MySQL
server, incluyendo una contraseña de root y la creación de
una cuenta de usuario con sólo los permisos necesarios para
realizar las tareas necesarias para ese usuario. Para más
información acerca de esto, consulte
Sección 5.6, “El sistema de privilegios de acceso de MySQL”.
Vale la pena tener en cuenta que los nodos del cluster no
utilizan el sistema de permisos de MySQL al acceder el uno
al otro, y preparar o cambiar las cuentas de usuario de
MySQL (incluyendo la cuenta root ) no
tiene efecto en la interacción entre nodos, sólo en
aplicaciones accediendo al nodo SQL.
Seleccionar una base de datos y ejecutar una consulta
SELECT contra una tabla en la base de
datos se realiza de la forma normal, como salir del MySQL
Monitor:
mysql> USE world;
mysql> SELECT Name, Population FROM City ORDER BY Population DESC LIMIT 5;
+-----------+------------+
| Name | Population |
+-----------+------------+
| Bombay | 10500000 |
| Seoul | 9981619 |
| São Paulo | 9968485 |
| Shanghai | 9696300 |
| Jakarta | 9604900 |
+-----------+------------+
5 rows in set (0.34 sec)
mysql> \q
Bye
shell>
Las aplicaciones usando MySQL pueden usar APIs estándar. Es
importante recordar que sus aplicaciones deben acceder al
nodo SQL, y no al nodo MGM o a los de almacenamiento. Este
breve ejemplo muestra cómo puede ejecutar la misma consulta
que la anterior usando la extensión de PHP 5
mysqli ejecutando un servidor web en
cualquier punto de la red:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<title>SIMPLE mysqli SELECT</title>
</head>
<body>
<?php
# connect to SQL node:
$link = new mysqli('192.168.0.20', 'root', '', 'world');
# parameters for mysqli constructor are:
# host, user, password, database
if( mysqli_connect_errno() )
die("Connect failed: " . mysqli_connect_error());
$query = "SELECT Name, Population
FROM City
ORDER BY Population DESC
LIMIT 5";
# if no errors...
if( $result = $link->query($query) )
{
?>
<table border="1" width="40%" cellpadding="4" cellspacing ="1">
<tbody>
<tr>
<th width="10%">City</th>
<th>Population</th>
</tr>
<?
# then display the results...
while($row = $result->fetch_object())
printf(<tr>\n <td align=\"center\">%s</td><td>%d</td>\n</tr>\n",
$row->Name, $row->Population);
?>
</tbody
</table>
<?
# ...and verify the number of rows that were retrieved
printf("<p>Affected rows: %d</p>\n", $link->affected_rows);
}
else
# otherwise, tell us what went wrong
echo mysqli_error();
# free the result set and the mysqli connection object
$result->close();
$link->close();
?>
</body>
</html>
Suponemos que el proceso ejecutándose en el servidor web
puede alcanzar la IP del nodo SQL.
De forma parecida, puede usar la MySQL C API, Perl-DBI,
Python-mysql, o los conectores propios de MySQL AB para
realizar las tareas de definición y manipulación de datos
como haría normalmente con MySQL.
Recuerde que cada tabla NDB
debe tener una clave primaria. Si no se define
clave primaria por el usuario cuando se crea la tabla, el
motor NDB Cluster creará una oculta
automáticamente. (Nota:
esta clave oculta ocupa espacio como cualquier otro índice
de tabla. No es raro encontrar problemas debido a espacio
insuficiente en memoria para guardar estos índices creados
automáticamente.)
16.3.6. Apagado y encendido seguros
Para parar el cluster símplemente introduzca lo siguiente en
una shell en la máquina con el nodo MGM :
shell> ndb_mgm -e shutdown
Esto hará que ndb_mgm,
ndb_mgmd, y cualquier proceso
ndbd termine normalmente. Cualquier nodo SQL
puede terminarse usando mysqladmin shutdown y
otros medios. Tenga en cuenta que la opción
-e aquí se usa para pasar un comando al
cliente ndb_mgm desde el shell. Consulte
Sección 4.3.1, “Usar opciones en la línea de comandos”.
Para reiniciar el cluster, símplemente ejecute estos comandos:
En el equipo de administración
(192.168.0.10 en nuestra configuración):
Un MySQL server que es parte de un MySQL Cluster difiere sólo en
un aspecto de un servidor MySQL normal (no cluster), en que emplea
el motor NDB Cluster . Este motor también se
conoce símplemente como NDB, y las dos formas
del nombre son sinónimas.
Para evitar reserva innecesaria de recursos, el servidor se
configura por defecto con el motor NDB
desactivado. Para activar NDB, necesitará
configurar el fichero de configuración
my.cnf del servidor con la opción
--ndbcluster .
Desde que MySQL server es parte del cluster, necesita datos de
configuración que sepa cómo acceder al nodo MGM para obtener
datos de configuración del cluster. El comportamiento por defecto
es buscar el nodo MGM en localhost. Sin
embargo, puede necesitar especificar su localización donde se
encuentre, esto puede hacerse en my.cnf o en
la línea de comandos del servidor MySQL. Antes de poderse usar el
NDB, al menos un nodo MGM debe ser operacional,
así como los nodos de datos deseados.
16.4.1. Generar MySQL Cluster desde el código fuente
NDB, el motor del cluster, está disponible
en distribución binaria para Linux, Mac OS X, y Solaris. No
está disponible en Windows, pero queremos que lo esté para
win32 y otras plataformas en un futuro próximo.
Si elige compilar desde un paquete fuente o desde el MySQL 5.0
BitKeeper tree, asegúrese de usar la opción
--with-ndbcluster cuando ejecute
configure. Puede usar el script
BUILD/compile-pentium-max . Tenga en cuenta
que este script incluye OpenSSL,así que debe tener u obtener
OpenSSL para compilar con éxito; de otro modo, necesitará
modificar compile-pentium-max para excluir
este requerimiento. Por supuesto, puede seguir las instrucciones
estándar para compilar sus propios binarios, luego realizar los
tests usuales y procedimiento de instalación. Consulte
Sección 2.8.3, “Instalar desde el árbol de código fuente de desarrollo”.
16.4.2. Instalar el software
En las siguientes secciones, asumimos que conoce el proceso de
instalación de MySQL,y cubrimos sólo las diferencias entre
configurar MySQL Cluster y configurar MySQL sin clustering.
(Consulte Capítulo 2, Instalar MySQL si necesita más
información sobre lo último.)
Encontrará la configuración del cluster más sencilla si ya
tiene todos los nodos de administración y datos en ejecución;
esta es la parte más costosa de tiempo de la configuración.
Editar el fichero my.cnf es sencillo y esta
sección cubre sólo las diferencias de configurar MySQL sin
clustering.
16.4.3. Rápido montaje de prueba de MySQL Cluster
Para familiarizarse con los conceptos básicos, describimos la
configuración más sencilla para un MySQL Cluster. Después,
debería poder diseñar su inicialización deseada a partir de
la información proporcionada en las otras secciones de este
capítulo.
Primero, necesita crear un directorio de configuración tal como
/var/lib/mysql-cluster, ejecutando el
siguiente comando como root del sistema:
shell> mkdir /var/lib/mysql-cluster
En este directorio, cree un fichero llamado
config.ini con la siguiente información,
substituyendo los valores apropiados por
HostName y DataDir como
sea necesario para su sistema.
# file "config.ini" - showing minimal setup consisting of 1 data node,
# 1 management server, and 3 MySQL servers.
# The empty default sections are not required, and are shown only for
# the sake of completeness.
# Data nodes must provide a hostname but MySQL Servers are not required
# to do so.
# If you don't know the hostname for your machine, use localhost.
# The DataDir parameter also has a default value, but it is recommended to
# set it explicitly.
# Note: DB, API, and MGM are aliases for NDBD, MYSQLD, and NDB_MGMD
# respectively. DB and API are deprecated and should not be used in new
# installations.
[NDBD DEFAULT]
NoOfReplicas= 1
[MYSQLD DEFAULT]
[NDB_MGMD DEFAULT]
[TCP DEFAULT]
[NDB_MGMD]
HostName= myhost.example.com
[NDBD]
HostName= myhost.example.com
DataDir= /var/lib/mysql-cluster
[MYSQLD]
[MYSQLD]
[MYSQLD]
Ahora puede arrancar el servidor de administración:
shell> cd /var/lib/mysql-cluster
shell> ndb_mgmd
Arranque un nodo DB sencillo usando ndbd. Al
arrancar ndbd para un nodod DB dado por
primera vez, debe usar la opción --initial :
shell> ndbd --initial
Para arrancar ndbd de nuevo,normalmente
no necesitará usar esta
opción:
shell> ndbd
Esto es porque la opción --initial borra todos
los ficheros de datos y log existentes (así como todos los
metadatos de tablas) para este nodo de datos y crea nuevos. Una
excepción a esta regla es al reiniciar el cluster y restaurar
desde una copia de seguridad tras añadir nuevos nodos de datos.
Por defecto, ndbd buscará el servidor de
administración en localhost en el puerto
1186.
Nota: Si ha instalado MySQL
desde un tarball binario, necesitará especificar la ruta de los
servidores ndb_mgmd y ndbd
explícitamente. (Normalemnte, se encuentran en
/usr/local/mysql/bin.)
Finalmente, vaya al directorio de datos de MySQL (usualmente
/var/lib/mysql o
/usr/local/mysql/data), y asegúrese que el
fichero my.cnf contiene la opción
necesaria para permitir el motor NDB :
[mysqld]
ndbcluster
Ahora puede arrancar el servidor MySQL normalmente:
shell> mysqld_safe --user=mysql &
Espere un momento para asegurarse que el servidor MySQL está
corriendo apropiadamente. Si ve mysql ended,
chequee el fichero .err del servidor para
averiguar qué ha fallado.
Si todo ha ido bien, puede arrancar usando el cluster:
shell> mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.0.10-Max
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> SHOW ENGINES;
+------------+---------+------------------------------------------------------------+
| Engine | Support | Comment |
+------------+---------+------------------------------------------------------------+
...
| NDBCLUSTER | DEFAULT | Clustered, fault-tolerant, memory-based tables |
| NDB | YES | Alias for NDBCLUSTER |
...
mysql> USE test;
Database changed
mysql> CREATE TABLE ctest (i INT) ENGINE=NDBCLUSTER;
Query OK, 0 rows affected (0.09 sec)
mysql> SHOW CREATE TABLE ctest \G
*************************** 1. row ***************************
Table: ctest
Create Table: CREATE TABLE `ctest` (
`i` int(11) default NULL
) ENGINE=ndbcluster DEFAULT CHARSET=latin1
1 row in set (0.00 sec)
Para chequear que sus nodos se han inicializado correctamente,
arranque el cliente de administración como se muestra:
shell> ndb_mgm
Puede usar el comando SHOW desde el cliente
de administración para obtener un reporte del estado del
cluster:
NDB> SHOW
Cluster Configuration
---------------------
[ndbd(NDB)] 1 node(s)
id=2 @127.0.0.1 (Version: 3.5.3, Nodegroup: 0, Master)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @127.0.0.1 (Version: 3.5.3)
[mysqld(API)] 3 node(s)
id=3 @127.0.0.1 (Version: 3.5.3)
id=4 (not connected, accepting connect from any host)
id=5 (not connected, accepting connect from any host)
En este punto, ha inicializado correctamente un cluster MySQL.
Ya puede almacenar datos en el cluster usando cualquier tabla
creada con ENGINE=NDBCLUSTER o su alias
ENGINE=NDB.
Configurar MySQL Cluster requiere trabajar con dos ficheros:
my.cnf: Especifica opciones para todos
los ejecutables del MySQL Cluster . Este fichero, con el que
debe familiarizarse de trabajar anteriormente con MySQL,
debe ser accesible por cada ejecutable del cluster.
config.ini: Este fichero es de sólo
lectura por el servidor de administración del MySQL Cluster
, que distribuye la información contenida en el mismo a
todos los procesos participantes en el cluster.
config.ini contiene una descripción de
cada nodo del cluster. Esto incluye los parámetros de
configuración para nodos de datos y parámetros de
configuración para conexiones entre todos los nodos del
cluster.
Mejoramos la configuración del cluster contínuamente y
tratamos de simplicar el proceso. Mientras tratamos de mantener
compatibilidad con versiones anteriores, puede ser que a veces
hagamos cambios incompatibles. Si encuentra uno de estos cambios
no documentados, use nuestra
Bugs Database para
reportarlo.
16.4.4.1. Ejemplo de configuración para MySQL Cluster
Para soportar MySQL Cluster, necesita actualizar
my.cnf como se muestra en el siguiente
ejemplo. Tenga en cuenta que las opciones mostradas aquí no
deben confundirse con las de los ficheros
config.ini . Puede especificar estos
parámetros al invocar los ejecutables desde línea de
comandos
# my.cnf
# example additions to my.cnf for MySQL Cluster
# (valid in MySQL 5.0)
# enable ndbcluster storage engine, and provide connectstring for
# management server host (default port is 1186)
[mysqld]
ndbcluster
ndb-connectstring=ndb_mgmd.mysql.com
# provide connectstring for management server host (default port: 1186)
[ndbd]
connect-string=ndb_mgmd.mysql.com
# provide connectstring for management server host (default port: 1186)
[ndb_mgm]
connect-string=ndb_mgmd.mysql.com
# provide location of cluster configuration file
[ndb_mgmd]
config-file=/etc/config.ini
# my.cnf
# example additions to my.cnf for MySQL Cluster
# (will work on all versions)
# enable ndbcluster storage engine, and provide connectstring for management
# server host to the default port 1186
[mysqld]
ndbcluster
ndb-connectstring=ndb_mgmd.mysql.com:1186
Puede usar una sección separada
[mysql_cluster] en el cluster
my.cnf para configuración que deba ser
leída y afecte a todos los ejecutables:
Actualmente el fichero de configuración está en formato INI,
y se llama config.ini por defecto . Lo
lee ndb_mgmd al arrancar y puede situarse
en cualquier sitio. Su localización y nombre se especifican
usando
--config-file=[<path>]<filename>
en la línea de comandos con ndb_mgmd. Si
el fichero de configuración no se especifica,
ndb_mgmd trata por defecto de leer el
fichero config.ini localizado en el
directorio de trabajo actual.
Los valores por defecto se definen para la mayoría de
parámetros, y pueden especificarse en
config.ini. Para crear una sección de
valores por defecto, añada la palabra
DEFAULT al nombre de sección. Por ejemplo,
los nodos de datos se configuran usando las secciones
[NDBD]. Si todos los nodos de datos usan el
mismo tamaño de memoria de datos, y este no es le mismo que
el tamaño por defecto, cree una sección [NDBD
DEFAULT] que contenga una línea con
DataMemory para especificar el tamaño por
defecto de la memoria de datos para todos los nodos de datos.
El formato INI consiste en secciones precedidas por cabeceras
de secciones (rodeados por corchetes), segidos por los nombres
y valores apropiados de parámetros. Una desviación del
formato estándar es que el nombre y valor del parámetro
puede separarse por un punto y coma (':')
así como el signo de igualdad ('='); otra
es que las secciones no se identifican únicamente por el
nombre. En su lugar, las entradas únicas (tales como dos
nodos distintos del mismo tipo) se identifican por un ID
único.
Como mínimo, el fichero de configuración debe definir las
máquinas y nodos involucrados en el cluster y en qué
máquinas están estos nodos. Como ejemplo de un fichero de
configuración simple para un cluster con un servidor de
administración, dos nodos de datos y dos servidores MySQL se
muestra a continuación:
# file "config.ini" - 2 data nodes and 2 SQL nodes
# This file is placed in the startup directory of ndb_mgmd (the management
# server)
# The first MySQL Server can be started from any host. The second can be started
# only on the host mysqld_5.mysql.com
[NDBD DEFAULT]
NoOfReplicas= 2
DataDir= /var/lib/mysql-cluster
[NDB_MGMD]
Hostname= ndb_mgmd.mysql.com
DataDir= /var/lib/mysql-cluster
[NDBD]
HostName= ndbd_2.mysql.com
[NDBD]
HostName= ndbd_3.mysql.com
[MYSQLD]
[MYSQLD]
HostName= mysqld_5.mysql.com
Hay seis secciones distintas en este fichero de
configuración:
[COMPUTER]: Define las máquinas del
cluster.
[NDBD]: Define los nodos de datos del
cluster.
[MYSQLD]: Define los nodos MySQL del
cluster.
[MGM] o [NDB_MGMD]:
Define el nodo de administración del cluster.
[TCP]: Define conexiones TCP/IP entre
nodos en el cluster, siendo TCP/IP el protocolo de
conexión por defecto.
[SHM]: Define conexiones de memoria
compartida entre nodos. Antiguamente, este tipo de
conexión estaba disponible sólo en binarios compilados
con la opción --with-ndb-shm . En MySQL
5.0-Max, está activado por defecto, pero debe
considerarse experimental.
Tenga en cuenta que cada nodo tiene su propia sección en
config.ini. Por ejemplo, desde que el
cluster tiene dos nodos de datos, el fichero de configuración
contiene dos secciones definiendo estos nodos.
Puede definir valores DEFAULT para cada
sección. En MySQL 5.0, todos los nombres de parámetros no
son sensibles a mayúsculas.
16.4.4.2. El connectstring de MySQL Cluster
Con excepción del servidor de administración MySQL Cluster
(ndb_mgmd), cada nodo de un MySQL Cluster
requiere de un connectstring que apunte
a la localización del servidor de administración. Se usa
para establecer una conexión al servidor de administración
así como realizar otras tareas en función del rol del nodo
en el cluster. La sintaxis para el connectstring es la
siguiente:
<id> es un entero mayor que 1 que
identifica un nodo en config.ini
<port> es un entero que se refiere a
un puerto unix regular <host> es una
cadena que tiene una dirección de equipo de internet válida
example 1 (long): "nodeid=2,myhost1:1100,myhost2:1100,192.168.0.3:1200"
example 2 (short): "myhost1"
Todos los nodos usan localhost:1186 como
valor connectstring por defecto si no se especifica otro. Si
se omite <port> del connectstring, el
puerto por defecto es 1186. Este puerto debe estar siempre
disponible en la red, ya que se ha asignado por la IANA para
este propósito (consulte
http://www.iana.org/assignments/port-numbers
para más detalles).
Listando múltiples valores
<host-specification> , es posible
diseñar varios servidores de administración redundantes. Un
nodo del cluster tratará de contactar con administradores
sucesivamente en cada equipo en el orden especificado, hasta
que se establezca una conexión.
Hay un número de distintos modos de especificar el
connectstring:
Cada ejecutable tiene su propia opción de línea de
comandos que permite especificar el servidor de
administración al arrancar. (Consulte la documentación
para los respectivos ejecutables.)
Es posible en MySQL 5.0 Cluster inicializar el
connectstring para todos los nodos en el cluster a la vez
poniéndolo en la sección
[mysql_cluster] en el fichero del
servidor de administración my.cnf.
Para compatibilidad con versiones anteriores, hay dos
otras opciones disponibles, usando la misma sintaxis:
Inicialice la variable de entorno
NDB_CONNECTSTRING para que contenga
el connectstring.
Escriba el connectstring para cada ejecutable en un
fichero de texto llamado
Ndb.cfg y guarde este fichero
en el directorio de arranque del ejecutable.
Sin embargo, esto está ahora obsoleto y no debería
usarse en nuevas instalaciones.
El método recomendado para especificar el connectstring es
inicializarlo en la línea de comandos o en el fichero
my.cnf para cada ejecutable.
16.4.4.3. Definir los equipos que forman un cluster MySQL
La sección [COMPUTER] no tiene otro
significado a parte de servir como forma de eliminar la
necesidad de definir nombres de equipos para cada nodo en el
sistema. Todos los parámetros mencionados aquí son
necesarios.
[COMPUTER]Id
Este valor es un entero, usado para referirse la máquina
equipo en cualquier punto del fichero de configuración.
[COMPUTER]HostName
Este es el nombre de equipo o dirección IP de la
máquina.
16.4.4.4. Definición del servidor de administración de MySQL Cluster
La sección [NDB_MGMD] (o su alias
[MGM]) se usa para configurar el
comportamiento del servidor de administración. Todos los
parámetros de la siguiente lista puede omitirse y, si así
es, se asumen sus valores por defecto.
Nota: Si ni el parámetro
ExecuteOnComputer ni
HostName están presentes, se asume para
ambos el valor por defecto localhost .
[NDB_MGMD]Id
Cada nodo en el cluster tiene un identificador único, que
está representado por un valor entero en el rango de 1 a
63 inclusive. Este ID se usa por todos los mensajes de
cluster internos para dirigirse al nodo.
[NDB_MGMD]ExecuteOnComputer
Esto se refiere a una de las máquinas definidas en la
sección [COMPUTER] .
[NDB_MGMD]PortNumber
Este es el número de puerto en que escucha el servidor de
administración para peticiones de configuración o
comandos de administración.
[NDB_MGMD]LogDestination
Este parámetro especifica dónde enviar la información
de logueo del cluster. Hay tres opciones al respecto:
CONSOLE, SYSLOG, y
FILE:
CONSOLE envía el log a
stdout:
CONSOLE
SYSLOG envía el log a un
syslog , siendo los valores
posibles uno de auth,
authpriv,
cron, daemon,
ftp, kern,
lpr, mail,
news, syslog,
user, uucp,
local0,
local1,
local2,
local3,
local4,
local5,
local6, o
local7.
Nota: No todos los
dispositivos son soportadas necesariamente por cada
sistema operativo.
SYSLOG:facility=syslog
FILE envía por un pipe la salida
del log del cluster a un fichero normal de la misma
máquina. Pueden especificarse los siguientes
valores:
filename: Nombre del fichero
de log.
maxsize: Tamaño máximo al
que puede crecer el fichero antes de pasar el
log a un nuevo fichero. Cuando esto ocurre, el
antiguo fichero de log se renombra añadiendo
.x al nombre del fichero,
donde x es el siguiente
número no usado todavía por este nombre.
El valor por defecto para el parámetro
FILE es
FILE:filename=ndb_<id>_cluster.log,maxsize=1000000,maxfiles=6,
donde <id> es el ID del
nodo.
[NDB_MGMD]ArbitrationRank
Este parámetro se usa para definir qué nodos pueden
actuar como árbitros. Sólo los nodos MGM y SQL pueden
serlo. ArbitrationRank puede tener uno
de los siguientes valores:
0: El nodo nunca se usará como
árbitro.
1: El nodo tiene alta prioridad,
esto es, será preferido como árbitro sobre los
nodos con baja prioridad.
2: Indica que un nodo de baja
prioridad será usado como árbitro sólo si un nodo
con una prioridad alta no está disponible para este
propósito.
Normalmente, el servidor de administración debe
configurarse como árbitro poniendo
ArbitrationRank a 1 (el valor por
defecto) y todos los nodos SQL a 0.
[NDB_MGMD]ArbitrationDelay
Un valor entero hace que las respuestas a peticiones de
árbitro al servidor de administración se retrasen el
número de milisegundos indicado. Por defecto, este valor
es 0, normalmente no es necesario cambiarlo.
[NDB_MGMD]DataDir
Cambia el directorio donde se guardan los ficheros de
salida del servidor de administración. Estos ficheros
incluyen ficheros de log del cluster, ficheros de salida
de procesos, y los ficheros pid de los demonios. (Para
ficheros de log, esto puede sobreescribirse poniendo el
parámetro FILE para
[NDB_MGMD]LogDestination como se
discute préviamente en esta sección.)
16.4.4.5. Definir los nodos de MySQL Cluster
La sección [NDBD] se usa para configurar
el comportamiento de los nodos de datos del cluster. Hay
varios parámetros que controlan los tamaños de buffer, de
pool, timeouts, y así. Los únicos parámetros obligatorios
son:
O ExecuteOnComputer o
HostName.
El parámetro NoOfReplicas
Se tienen que definir en la sección [NDBD
DEFAULT] .
La mayoría de parámetors de los nodos de datos se
inicializan en la sección [NDBD DEFAULT] .
Sólo los parámetros marcados como capaces de cambiar valores
locales se permiten cambiar en la sección
[NDBD] . HostName,
Id y ExecuteOnComputerdeben definirse en la sección
[NDBD] local.
Identificar nodos de datos
El valor Id (esto es, el identificador del
nodo de datos) puede cambiarse en la línea de comandos cuando
se arranca el nodo o en el fichero de configuración.
Para cada parámetro es posible usar k,
M, o G como sufijo para
indicar unidades de 1024, 1024*1024, o 1024*1024*1024. (Por
ejemplo, 100k significa 100 * 1024 =
102400.) Los parámetros y valores son sensibles a
mayúsculas.
[NBDB]Id
Este es el ID del nodo usado como dirección del nodo para
todos los mensajes internos del cluster. Este es un entero
entre 1 y 63. Cada nodo en el cluster tiene una identidad
única.
[NDBD]ExecuteOnComputer
Se refiere a uno de las máquinas (equipos) definidos en
la sección COMPUTER .
[NDBD]HostName
Especificar este parámetro tiene un efecto similar a
especificar ExecuteOnComputer. Define
el nombre de equipo de la máquina en que reside el nodo
de almacenamiento. Este parámetro o
ExecuteOnComputer es necesario para
especificar un nombre de equipo distinto a
localhost.
(OBSOLETO)
[NDBD]ServerPort
Cada nodo en el cluster usa un puerto para conectarse a
otros nodos. Este puerto se usa también para transporte
distinto a TCP en la fase de establecimiento de la
conexión. Ahora, el puerto por defecto se reserva
dinámicamente de forma que se asegura que dos nodos en la
misma máquina reciban el mismo número de puerto, no debe
ser necesario indicar un valor para este parámetro.
[NDBD]NoOfReplicas
Este parámetro global sólo puede cambiarse en la
sección [NDBD DEFAULT] , y define el
número de replicas para cada tabla almacenada en el
cluster. Este parámetro también especifica el tamaño de
los grupos de nodos. Un grupo de nodos es un conjunto de
nodos que almacenan todos la misma información.
Los grupos de nodos se forman implítamente. El primer
grupo de nodos se forma por el conjunto de nodos de datos
con los IDs de nodo más bajos, el siguiente grupo de
nodos se conforma con el conjunto del siguiente conjunto
de identidades de nodos más baja, y así. Como ejemplo,
asuma que tenemos 4 nodos de datos y que
NoOfReplicas es 2. Los cuatro nodos de
datos tienen los IDs 2, 3, 4 y 5. El primer grupo de nodos
está formado con los nodos 2 y 3, y el segundo grupo con
los nodos 4 y 5. Es importante configurar el cluster de
forma que los nodos en el mismo grupo no se guarden en la
misma máquina, ya que en esta situación un fallo de
hardware haría que fallare el cluster entero.
Si no hay IDs de nodos el orden de los nodos de datos es
el factor determinante para el grupo de nodos. Se haga o
no una asignación explícita, puede verse en la salida
del comando del cliente administrador
SHOW .
No hay valor por defecto para
NoOfReplicas; el valor máximo posible
es 4.
[NDBD]DataDir
Este parámetro especifica el directorio donde los
ficheros de traceo, ficheros de log, ficheros pid y logs
de errores se guardan.
[NDBD]FileSystemPath
Este parámetro especifica el directorio donde se guardan
todos los ficheros para metadatos, logs de REDO, logs de
UNDO y ficheros de datos. Por defecto es el directorio
especificado por DataDir.
Nota: Este directorio
debe existir antes de inciar el proceso
ndbd.
La jerarquía de directorio recomendada para MySQL Cluster
incluye /var/lib/mysql-cluster, bajo
qué directorio se crea un sistema de ficheros de un nodo.
Este subdirectorio contiene el ID del nodo. Por ejemplo,
si el ID del nodo es 2, el subdirectorio se llama
ndb_2_fs.
[NDBD]BackupDataDir
Es posible especificar el directorio en que se guardan las
copias de seguridad. Por defecto, este directorio es
FileSystemPath/BACKUP.
(Consulte secciones anteriores.)
Memoria de datos e índice DataMemory y IndexMemory
son parámetros especificando el tamaño de los segmentos de
memoria usados para almacenar los registros actuales y sus
índices. Al inicializar los valores de los mismos, es
importante entender cómo se usan
DataMemory y IndexMemory
, ya que usualmente necesitan actualizarse para reflejar el
uso real del cluster:
[NDBD]DataMemory
Este parámetro define la cantidad de espacio disponible
para almacenar registros de base de datos. La cantidad
entera se guardará en memoria, así que es extremadamente
importante que la máquina tenga sufuciente memoria
física para guardar este valor.
La memoria reservada por DataMemory se
usa para almacenar los registros y los índices. Cada
registro tiene una longitud fija . (Incluso columnas
VARCHAR se almacenan como columnas de
longitud fija.) Hay una sobrecarga de 16-byte para cada
registro; una cantidad adicional para cada registro se
necesita porque se almacena en páginas de 32KB con
sobrecarga de 128 byte por página (consulte a
continuación). También hay una pequeña cantidad gastada
por página debido al hecho que cada registro se almacena
en sólo una página. El tamaño de registro máximo
actualmente es de 8052 bytes.
El espacio de memoria definido por
DataMemory se usa para almacenar
índices ordenados, que usa acerca de 10 bytes por
registor. Cada registro de tabla se representa en el
índice ordenado. Un error común entre usuarios es asumir
que todos los índices se almacenan en la memoria
reservada por IndexMemory, pero no es
así: sólo claves primarias e índices hash únicos usan
esta memoria; los índices ordenados usan la memoria
almacenada por DataMemory. Sin embargo,
crear una clave primar única o índice hash único
también crea un índice ordenado en la misma clave, a no
ser que especifique USING HASH en el
comando de creación del índice. Esto puede verificarse
ejecutando ndb_desc -d
db_nametable_name en el
cliente de administración.
El espacio de memoria reservado por
DataMemory consiste en 32KB páginas,
que se reservan en fragmentos de tabla. Cada tabla se
particiona normalmente en el mismo número de fragmentos
como hay nodos de datos en el cluster. Por lo tanto, por
cada nodo, hay el mismo número de fragmentos así como se
especifica en NoOfReplicas. Una vez que
una página se ha reservado, no es posible retornarla al
pool de páginas libres, excepto borrando la tabla.
Ejecutar el modo de recuperación también comprime la
partición ya que todos los registros se insertan en
particiones vacías por parte de los otros nodos vivos.
El espacio de memoria DataMemory
también contiene información UNDO: Para cada
actualización, se reserva una copia de los registros no
alterados en DataMemory. También hay
una referencia de cada copia en los índices de tablas
ordenadas. Los índices hash únicos se modifican sólo
cuando las columnas de índice único se actualizan, en
tal caso se inserta una nueva entrada en la tabla de
índices y la antigua entrada se borra al hacer un commit.
Por esta razón, es necesario reservar espacio necesario
para tratar la transacción más grande realizada por
aplicaciones usando el cluster. En cualquier caso,
realizar unas cuantas transacciones muy grandes no tiene
ventaja sobre usar muchas pequeñas, por las siguientes
razones:
Las transacciones grandes no son más rápidas que
las pequeñas.
Las transacciones grandes incrementan el número de
operaciones que se pierden y deben repetirse en caso
de fallo de transacción
Las transacciones grandes usan más memorias
El valor por defecto de DataMemory es
80MB; el mínimo es 1MB. No hay tamaño máximo, pero en
realidad el tamaño máximo tiene que adaptarse para que
el proceso no empiece ha hacer swapping cuando llega al
límite. Este límite se determina por la cantidad de RAM
física disponible en la máquina y por la cantidad de
memoria que el sistema operativo puede asignar a un
proceso. Sistemas operativos 32-bit están normalmente
limitados a 2-4GB por proceso; los sistemas opertivos de
64-bit pueden usar más. Para bases de datos grandes,
puede ser preferible usar un sistema operativo 64-bit por
esta razón. Además, es posible ejecutar más de un
proceso ndbd por máquina, y esto puede
ser ventajoso en máquinas con múltiples CPUs.
[NDBD]IndexMemory
Este parámetro controla la cantidad de almacenamiento
usado por índices hash en MySQL Cluster. Los índices
hash siempre son usados por índices de clave primaria,
índices únicos y restricciones únicas. Tenga en cuenta
que cuando define una clave primaria y un índice único,
se crean dos índices, uno de los cuales es un índice
hash usado por todos los accesos a tuplas así como
tratamiento de bloqueos. También se usa para forzar
restricciones únicas.
El tamaño del índice hash es de 25 bytes por registro,
más el tamaño de la clave primaria. Para claves
primarias mayores a 32 bytes se añaden otros 8 bytes .
Considere una tabla definida por
CREATE TABLE example
(
a INT NOT NULL,
b INT NOT NULL,
c INT NOT NULL,
PRIMARY KEY(a),
UNIQUE(b)
) ENGINE=NDBCLUSTER;
Hay una sobrecarga de 12 bytes (tener columnas no nulas
ahorra 4 bytes de sobrecarga) más 12 bytes de datos por
registro. Además tenemos dos índices ordenados en las
columnas a y
b consumiendo cerca de 10
bytes cada uno por registro. Hay un índice hash de clave
primaria en la tabla base con unos 29 bytes por registro.
La restricción única se implementa por tablas separadas
con b como clave primaria
y a como columna. Esta
tabla consumirá otros 29 bytes de memoria de índice por
registro en la tabla
ejemplo así como 12
bytes de sobrecarga, más 8 bytes de datos de registros.
Así, para un millón de registros, necesitamos 58 MB para
memoria de índices para tratar los índices hash para la
clave primaria y la restricción única. También
necesitamos 64 MB para los registros de la tabla base y la
tabla de índice único, más las dos tablas con índice
ordenado.
Puede ver que los índices hash tienen una buena cantidad
de espacio de memoria; sin embargo, proporcionan acceso
muy rápido a los datos retornados. También se usan en
MySQL Cluster para tratar restricciones únicas.
Actualmente el único algoritmo de partición es hashing y
los índices ordenados son locales para cada nodo. Por lo
tanto los índices ordenados no pueden usarse para tratar
restricciones únicas en caso general.
Un punto importante paraIndexMemory y
DataMemory es que el tamaño de base de
datos total es la suma de toda la memoria de datos y toda
la memoria de índice para cada grupo de nodos. Cada grupo
de nodos se usa para guardar información replicada, así
que si hay cuatro nodos con 2 réplicas, habrá dos nodos
de grupos. Por lo tanto, la cantidad total de memoria
disponible es 2*DataMemory para cada
nodo de datos.
Se recomienda que DataMemory y
IndexMemory se inicialice con el mismo
valor para todos los nodos. Desde que los datos se
distribuyen eventualmente sobre todos los nodos en el
cluster la cantidad de espacio máxima disponible no es
mejor que la del menor nodo del cluster.
DataMemory y
IndexMemory pueden cambiarse, pero
decrementar cualquiera de ellos puede ser arriesgado; al
hacerlo puede hacer que un nodo o incluso el cluster
entero no sea capaz de reiniciar debido a que hay memoria
insuficiente. Incrementar estos valores está bien, pero
se recomienda que estas actualizaciones se realicen de la
misma manera que una actualización de software,
comenzando con una actualización del fichero de
configuración, y luego reiniciando el servidor de
administración seguido del reinicio de cada nodo de
datos.
Las actualizaciones no incrementan la cantidad de memoria
índice usada. Las inserciones tienen efecto
inmediatamente; sin embargo, los registros no se borran
realmente hasta que la transacción hace un commit.
El valor por defecto para IndexMemory
es 18MB. El mínimo es 1MB.
Parámetros de transacción
Los siguientes tres parámetros que discutimos son importanets
porque afectan al número de transacciones paralelas y los
tamaños de transacciones que pueden tratarse por el sistema.
MaxNoOfConcurrentTransactions es el número
de transacciones posibles en un nodo;
MaxNoOfConcurrentOperations es el número
de registros que pueden estar en fase de actualización o
bloqueados simultáneamente.
Ambos parámetros (especialmente
MaxNoOfConcurrentOperations) son objetivos
probables para que los usuarios especifiquen valores
específicos y no usen el valor por defecto. El valor por
defecto es para sistemas con transacciones pequeñas, para
asegurar que no usan excesiva cantidad de memoria.
[NDBD]MaxNoOfConcurrentTransactions
Para cada transacción activa en el cluster debe haber
un registro en uno de los nodos del cluster. La tarea de
coordinar transacciones se envía entre los nodos: el
número total de registros de transacciones en el
cluster es el número de transacciones en cualquier nodo
por el número de nodos en el cluster.
Los registros de transacciones se guardan en servidores
MySQL individuales. Normalmente al menos hay un registro
de transacción por conexión que usa cualquier tabla en
el cluster. Por esta razón, debe asegurarse que hay
más registros de transacciones en el cluster que
conexiones concurrentes en todos los servidores MySQL
del cluster.
Este parámetro debe inicializarse al mismo valor para
todos los nodos del cluster.
Cambiar este parámetro nunca es seguro y puede causar
que un cluster falle. Cuando un nodo falla uno de los
nodos (el nodo superviviente más antiguo) levanta el
estado de transacción de todas las transacciones que
haya en funcionamiento en todos los nodos que han
fallado cuando ha ocurrido el fallo. Por lo tanto es
importante que este nodo tenga tantos registros de
transacción como el nodo que ha fallado.
El valor por defecto para este parámetro es 4096.
[NDBD]MaxNoOfConcurrentOperations
Es una buena idea ajustar el valor de este parámetro
según el tamaño y número de transacciones. Cuando se
realizan transacciones de sólo unas cuantas operaciones
y que no involucren muchos registros, no hay necesidad
de inicializar este parámetro con un valor muy alto.
Cuando realiza transacciones grandes involucrando muchos
registros necesita cambiar a un valor mayor este
parámetro.
Los registros se mantienen para cada transacción que
actualice los datos del cluster, tanto en el coordinador
de la transacción como en los nodos donde se hacen las
actualizaciones. Estos registros contienen información
de estado necesaria para encontrar registros UNDO para
deshacer cambios, bloquear colas y otros propósitos.
Este parámetro debe inicializarse al número de
registros a actualizar simultáneamente en
transacciones, dividido por el número de nodos de datos
del cluster. Por ejemplo, en un cluster que tenga 4
nodos de datos y del que se espera que trate 1,000,000
de actualizaciones concurrentes usando transacciones
debe inicializar este valor a 1000000 / 4 = 250000.
Leer consultas que hacen bloqueos hace que se creen
registros. Se reserva un espacio extra en los nodos
individuales para los casos en que la distibución no es
perfecta entre los nodos.
Cuando las consultas usan el índice hash único, hay
dos registros de operación usados para registrar la
transacción. El primer registro representa la lectura
en la tabla índice y el segundo trata la operación en
la tabla base.
El valor por defecto para este parámetro es 32768.
Este parámetro trata dos valores que se pueden
configurar separadamente. El primero de ellos especifica
cuántos registros de operación se tienen que situar en
el coordinador de la transacción. La segunda parte
especifica cuántos registros de operación serán
locales en la base de datos.
Una transacción muy grande realizada en un cluster de 8
nodos requiere tantos registros de operación en el
coordinador de transacción como lecturas,
actualizaciones y operaciones de borrado involucradas en
la transacción. Sin embargo, los registros de
operación se envían a los 8 nodos. Por lo tanto, si es
necesario configurar el sistema para una transacción
muy grande, es buena idea configurar las dos partes por
separado. MaxNoOfConcurrentOperations
se usará siempre para calcular el número de registros
de operación en la porción del coordinador de
transacción del nodo.
Es importante tener una idea de los requerimientos de
memoria para registros de operaciones. Actualmente es
aproximadamente 1KB por registro.
[NDBD]MaxNoOfLocalOperations
Por defecto, este parámetro se calcula como 1.1 *
MaxNoOfConcurrentOperations que
encaja en sistemas con muchas transacciones
simultáneas, ninguna de ellas demasiado grande. Si hay
una necesidad de tratar una transacción muy grande de
golpe y hay muchos nodos, es buena idea sobreescribir el
valor por defecto especificando explícitamente este
parámetro.
Almacenamiento temporal de
transacciones
El siguiente conjunto de parámetros se usa para determinar
almacenamiento temporal al ejecutar una consulta que es parte
de una transacción de Cluster. Todos los registros se liberan
al completar la consulta y el cluster espera para un commit o
rollback.
Los valores por defecto de estos parámetros son adecuados
para la mayoría de situaciones. Sin embargo, los usuarios con
necesidad de soportar transacciones que involucren gran
cantidad de registros u operaciones pueden necesitar
incrementarlos para activar un mejor paralelistmo en el
sistema, mientras que los usuarios cuyas aplicaciones
necesitan transacciones relativamente pequeñas pueden
decrementar los valores para ahorrar memoria.
[NDBD]MaxNoOfConcurrentIndexOperations
Para consultas usando un índice hash único, el conjunto
temporal de registros de operaciones se usa durante la
fase de ejecución de una consulta. Este parámetro
delimita el tamaño del conjunto de registros. Así este
registro sólo se reserva mientras se ejecuta una parte de
una consulta, en cuanto ha acabado la ejecución se libera
el registro. El estado necesario para tratar abortos y
commits se trata mediante los registros operacionales
normales donde el tamaño del pool se asigna por el
parámetro MaxNoOfConcurrentOperations.
El valor por defecto de este parámetro es 8192. Sólo en
casos raros de paralelismo extremadamente alto usando
índices hash únicos debería ser necesario incrementar
este valor. Usar un valor menor es posible y puede ahorrar
memoria si el DBA está seguro que un cierto grado de
paralelismo no es necesario en el cluster.
[NDBD]MaxNoOfFiredTriggers
El valor por defecto de
MaxNoOfFiredTriggers es 4000, que es
suficiente para la mayoría de situaciones. En algunos
casos puede decrementarse si el DBA está seguro que el
cluster no necesita un paralelismo alto.
Se crea un registro cuando se realiza una operación que
afecta un índice hash único. Insertar o borrar un
registro en una tabla con índices hash únicos o
actualizar una columna que es parte de un índice hash
único provoca una inserción o borrado en la tabla
índice. El registro resultante se usa para representar
esta operación de la tabla índice mientras se espera a
que la operación original se complete. Esta operación
tiene una vida corta pero puede requerir un gran número
de registros en su pool para situaciones en que muchas
operaciones de escritura paralelas en una tabla base que
contenga un conjunto de índices hash únicos.
[NDBD]TransactionBufferMemory
La memoria afectada por este parámetro se usa para
tracear operaciones disparadas al actualizar tablas
índice y leer índices únicos. Esta memoria se usa para
almacenar la información de clave y columna para estas
opraciones. Es muy raro que el valor de este parámetro
necesite alterarse.
Las operaciones normales de lectura y escritura usan un
búffer similar, cuyo uso es incluso de vida más corta.
El parámetro de tiempo de compilación
ZATTRBUF_FILESIZE (que se encuentra en
ndb/src/kernel/blocks/Dbtc/Dbtc.hpp)
es 4000*128 bytes (500KB). Un buffer similar para
información de claves,
ZDATABUF_FILESIZE (también en
Dbtc.hpp) contiene 4000*16 = 62.5KB
de tamaño de búffer. Dbtc es el
módulo que trata la coordinación de transacciones.
Escaneos y búffering
Hay parámtros adicionales en el módulo
Dblqh (en
ndb/src/kernel/blocks/Dblqh/Dblqh.hpp)
que afecta a lecturas y actualizaciones. Incluyen
ZATTRINBUF_FILESIZE, por defecto
10000*128 bytes (1250KB) y
ZDATABUF_FILE_SIZE, por defecto 10000*16
bytes (unos 156KB) de tamaño de buffer. Hasta hoy, no ha
habido ningún reporte de usuarios ni resultados de nuestros
tests que sugieran que deba incrementarse estos límites en
tiempo de compilación.
El valor por defecto de
TransactionBufferMemory es 1MB.
[NDBD]MaxNoOfConcurrentScans
Este parámetro se usa para controlar el número de
escaneos paralelos que pueden realizarse en el cluster.
Cada coordinador de transacción puede tratar el número
de escaneos paralelos definidos por este parámetro. Cada
consulta de escaneo se realiza escaneando todas las
particiones en paralelo. Cada escaneo de partición usa un
registro de escaneo en el nodo donde se encuentra la
partición, siendo el número de registros el valor de
este parámetro por el número de nodos. El clúster debe
ser capaz de sostener
MaxNoOfConcurrentScans escaneos
concurrentes de todos los nodos en el cluster.
Los escaneos se realizan en dos casos. El primero cuando
no existe un índice hash u ordenado para tratar la
consulta, en cuyo caso la consulta se ejecuta realizando
un escaneo de la tabla completa. El segundo caso se
encuentra cuando no hay índice hash para soportar la
consulta pero hay un índice ordenado. Usar el índice
ordenado significa ejecutar un escaneo de rango paralelo.
Como el orden se mantiene en las particiones locales
sólo, es necesario realizar el escaneo de índice en
todas las particiones.
El valor por defecto de
MaxNoOfConcurrentScans es 256. El valor
máximo es 500.
Este parámetro especifica el número de escaneos posibles
en el coordinador de transacción. Si el número de
registros de escaneos locales no se proporciona, se
calcula como el producto de
MaxNoOfConcurrentScans y el número de
nodos de datos en el sistema.
[NDBD]MaxNoOfLocalScans
Especifica el número de registros de escaneo locales si
varios escaneos no están paralelizados completamente.
[NDBD]BatchSizePerLocalScan
Este parámetro se usa para calcular el número de
registros bloqueados que necesitan estar ahí para tratar
varias operaciones de escaneo concurrentes.
El valor por defecto es 64; este valor tiene una fuerte
conexión con ScanBatchSize definido en
los nodos SQL.
[NDBD]LongMessageBuffer
Este es un buffer interno usado para pasar mensajes entre
nodos individuales y entre nodos. Aunque es muy improbable
que este valor deba cambiarse, es configurable. Por
defecto es 1MB.
Logueo y establecer
Checkpoins
[NDBD]NoOfFragmentLogFiles
Este parámetro especifica el tamaño del fichero de log
REDO del nodo. Los ficheros de log REDO se organizan en un
anillo. Es muy importante que el fichero primero y último
del log (a veces conocidos como "cabeza" y "cola",
respectivamente) no se encuentren; cuando se aproximan el
uno al otro demasiado, el nodo empieza a abortar todas las
transacciones que realizan actualizaciones debido a la
falta de espacio para nuevos registros de log.
Un registro de log REDO no se elimina hasta que se han
completado tres checkpoints locales desde la inserción
del último registro del log. Establecer checkpoints
frecuentemente viene determinado por su propio conjunto de
parámetros de configuración discutidos en este
capítulo.
El valor por defecto del parámetro es 8, que significa 8
conjuntos de 4 ficheros de 16MB para un total de 512MB. En
otras palabras, el espacio de log REDO debe reservarse en
bloques de 64MB. En escenarios que necesitan muchas
actualizaciones, el valor de
NoOfFragmentLogFiles puede necesitar
ser tan grande como 300 o incluso mayor para proporcionar
suficiente espacio para logs REDO.
Si se hacen pocos checkpoings y hay tantas escrituras en
la base de datos que los ficheros de log se llenan y la
cola de logs no puede cortarse sin recuperación jeapo
rdising , se abortan todas las transacciones con un
código de error interno 410, o Out of log file
space temporarily. Esta condición prevalecerá
hasta que se complete un checkpoint y se mueva la cola de
log.
[NDBD]MaxNoOfSavedMessages
Este parámetro especifica el máximo número de ficheros
de traceo que se mantienen antes de sobreescribir los
antiguos. Los ficheros de traceo se generan cuando, por
alguna razón, el nodo cae.
Por defecto son 25 ficheros de traceo.
Objetos de metadatos
El siguiente conjunto de parámetros definen tamaños de pool
para objetos de metadatos. Es necesario definir el máximo
número de atributos, tablas, índices y disparadores usados
por índices, eventos y replicaciones entre clusters.
[NDBD]MaxNoOfAttributes
Define el número de atributos que pueden definirse en el
cluster.
El valor por defecto para este parámetro es 1000, cuyo
valor mínimo posible es 32. No hay máximo. Cada atributo
consume acerca de 200 bytes de almacenamiento por nodo
debido a que todos los metadatos están replicados en los
servidores.
[NDBD]MaxNoOfTables
Se reserva un objeto tabla para cada tabla, índice hash
único e índice ordenado. Este parámetro especifica el
máximo número de objetos tabla para el cluster en total.
Para cada atributo que tiene un tipo de datos
BLOB se usa una tabla extra para
almacenar la mayoría de datos BLOB .
Estas tablas deben tenerse en cuenta al definir el número
total de tablas.
El valor por defecto es 128. El mínimo es 8 y el máximo
es 1600. Cada objeto tabla consume aproximadamente 20KB
por nodo.
[NDBD]MaxNoOfOrderedIndexes
Para cada índice ordenado en este cluster, un objeto se
reserva que describe lo que se indexa y sus segmentos de
almacenamiento. Por defecto cada índice definido así
también define un índice ordenado. Cada índice único y
clave primaria tiene un índice ordenado e índice hash.
El valor por defecto es 128. Cada objeto consume unos 10KB
de datos por nodo.
[NDBD]MaxNoOfUniqueHashIndexes
Para cada índice único que no sea clave primaria, se
reserva una tabla especial que mapea la clave única con
la clave primaria de la tabla indexada. Por defecto hay un
índice ordenado que se define para cada índice único.
Para evitarlo, debe usar la opción USING
HASH al definir el índice único.
El valor por defecto es 64. Cada índice consume
aproximadamente 15KB por nodo.
[NDBD]MaxNoOfTriggers
Los disparadores internos de actualización, inserción y
borrado se reservan para cada índice hash único. (Esto
significa que se crean 3 disparadores para cada índice
hash.) Sin embargo, un índice
ordenado necesita sólo un objeto
disparador. Las copias de seguridad también usan tres
objetos disparadores para cada tabla normal en el cluster.
Nota: Cuando se soporta
replicación entre clusters, esta hará uso de
disparadores internos.
Este parámetro inicializa el número máximo de objetos
disparadores en el cluster.
El valor por defecto es 768.
[NDBD]MaxNoOfIndexes
Este parámetro está obsoleto en MySQL 5.0; debe usar
MaxNoOfOrderedIndexes y
MaxNoOfUniqueHashIndexes en su lugar.
Este parámetro se usa sólo en índices hash únicos.
Debe haber un registro en este pool para cada índice hash
único definido en el cluster.
El valor por defecto es 128.
Parámetros booleanos
El comportamiento de los nodos de datos se ve afectado por un
conjunto de parámetros booleanos. Estos parámetros pueden
especificarse como TRUE poniéndolos a
1 o Y, y como
FALSE poniéndolos a 0 o
N.
[NDBD]LockPagesInMainMemory
Para algunos sistemas operativos, incluyendo Solaris y
Linux, es posible bloquear el proceso en memoria y evitar
el swapping de disco. Esto puede usarse para ayudar a
garantizar las características de tiempo real del
cluster.
Por defecto, esta característica está desactivada.
[NDBD]StopOnError
Este parámetro especifica si un proceso NDBD debe salir o
reiniciarse automáticamente cuando se encuentra una
condición de error.
Esta característica está activada por defecto.
[NDBD]Diskless
Es posible especificar tablas cluster como
diskless, que significa
que no se hacen checkpoints en disco y que no se loguean.
Estas tablas sólo existen en memoria. Una consecuencia de
usar estas tablas es que no se pueden mantener tras una
caida. Sin embargo, cuando el modo diskless está
operativo se puede ejecutar ndbd en una
máquina sin disco.
Nota: Actualmente, esta
característica hace que el cluster entero funcione en
modo diskless.
Actualmente, cuando está característica está activa,
las copias de seguridad se realizan pero los datos no se
almacenan. En futuras versiones esperamos hacer la copia
de seguridad diskless un parámetro separado y
configurable.
Esta característica está activada mediante poner
Diskless a 1 o
Y. Diskless está
desactivado por defecto.
[NDBD]RestartOnErrorInsert
Esta característica es accesible sólo al compilar la
versión de debug cuando es posible insertar errores en la
ejecución de bloques de código individuales como parte
del testeo.
Por defecto, esta característica está desactivada.
Controlar timeouts, intervalos y
paginación de disco
Hay un número de parámetros que especifican timeouts e
intervalos entre varias acciones en nodos de datos del
culster. La mayoría de los timeouts se especifican en
milisegundos. Cualquier excepción se menciona a
continuación.
[NDBD]TimeBetweenWatchDogCheck
Para evitar que el flujo principal quede en un bucle sin
fin en algún punto, un “watchdog” chequea el
flujo principal. Este parámetro especifica el número de
milisegundos entre chequeos. Si el proceso sigue siendo el
mismo tras tres chequeos, lo mata el flujo watchdog.
Este parámetro puede cambiarse fácilmente para
propósitos de experimentación o para adaptar las
condiciones locales. Puede especificarse por nodo aunque
parece que no hay grandes razones para hacerlo.
El timeout por defecto es de 4000 milisegundos (4
segundos).
[NDBD]StartPartialTimeout
Este parámetro especifica lo que esperará el cluster
para que arranquen los nodos de almacenamiento cuando se
invoca la rutina de inicialización . Este timeout se usa
para evitar un arranque parcial del cluster cuando es
posible.
El valor por defecto es de 30000 milisegundos (30
segundos). 0 significa timeout eterno;
en otras palabras, el cluster puede arrancar sólo si
todos los nodos están disponibles.
[NDBD]StartPartitionedTimeout
Si el cluster está preparado para arrancar tras esperar
durante StartPartialTimeout
milisegundos pero todavía es posible en un estado
particionado, el cluster espera hasta que este timeout
pasa.
El timeout por defecto es 60000 milisegundos (60
segundos).
[NDBD]StartFailureTimeout
Si un nodo de datos no ha completado su secuencia de
arranque en el tiempo especificado por este parámetro, el
arranque del nodo falla. Poner este parámetro a
0 significa que no se aplica ningún
timeout para el nodo de datos.
El valor por defecto es 60000 milisegundos (60 segundos).
Para los nodos de datos con cantidades de datos
extremadamente grandes, este parámetro debe
incrementarse. Por ejemplo, en el caso de un nodo de
almacenamiento que contenga varios gigabytes de datos, un
perido de 10-15 minutos (esto es, 600,000 a 1,000,000
milisegundos) puede ser necesario para realizar una
reinicialización de nodo.
[NDBD]HeartbeatIntervalDbDb
Uno de los métodos primarios de descubrimiento de nodos
fallidos es el uso de heartbeats. Este parámetro refleja
la frecuencia con que las señales heartbeat se envían y
con que frecuencia se espera su recepción. Tras perder
tres intervalos heartbeat seguidos, el nodo se declara
muerto. Así el máximo tiempo para descubrir un fallo a
través del mecanismo heartbeat es cuatro veces el
intervalo heartbeat.
El intervalo de heartbeat por defecto es de 1500
milisegundos (1.5 segundos). Este parámetro no debe
cambiarse drásticamente y no debe variar demasiado entre
nodos. Si un nodo usa 5000 milisegundos y el nodo
observador usa 1000 milisegundos entonces óbviamente se
declarará muerto rápidamente. Este parámetro puede
cambiarse durande una actualización de software en línea
pero sólo en pequeños incrementos.
[NDBD]HeartbeatIntervalDbApi
Cada nodo de datos envía señales heartbeat a cada MySQL
server (nodo SQL ) para segurar que permanece en contacto.
Si un MySQL server falla para enviar un heartbeat a tiempo
se declara “muerto”, en cuyo caso todas las
transacciones activas se completan y todos los recursos se
liberan. El nodo SQL no puede reconectar hasta que todas
las actividades iniciadas por la instancia MySQL prévia
se ha completado. El criterio de tres heartbeats para esta
discriminación es la misma que se describe en
HeartbeatIntervalDbDb.
El intervalo por defecto es de 1500 milisegundos (1.5
segundos). Este intervalo puede variar entre nodos de
datos individuales ya que cada nodo de almacenamiento
vigila los servidores MySQL conectados a ellos,
independientemente de todos los otros nodos de datos..
[NDBD]TimeBetweenLocalCheckpoints
Este parámetro es una excepción en que no especifica un
tiempo para esperar antes de arrancar un nuevo checkpoint
local; en lugar de esto, se usa para asegurarse que los
checkpoints locales no se realizan en un cluster donde
tienen lugar relativamente pocas actualizaciones. En la
mayoría de clusters con altos ratios de actualización,
es probable que se arranquen checkpoints locales
inmediatamente tras que se hayan completado los previos.
El tamaño de todas las operaciones de escritura
ejecutadas desde el arranque de los chekpoints locales
prévios. Este parámetro es excepcional ya que se
especifica como el logaritmo en base 2 del número de
palabras de 4 bytes, así que el valor por defecto 20
significa 4MB (4 * 220) de
operaciones de escritura, 21 significaría 8MB, y así
hasta un máximo de 31, que son 8GB de operaciones de
escritura.
Todas las operaciones de escritura en el cluster se
añaden juntas. Poner
TimeBetweenLocalCheckpoints a 6 o menos
significa que los checkpoints locales se ejecutarán
contínuamente sin pausa, independientemente de la carga
de trabajo del cluster.
[NDBD]TimeBetweenGlobalCheckpoints
Cuando se hace un commit de una transacción, se realiza
en memoria principal en todos los nodos en que los datos
se replican. Sin embargo, los registros del log de
transacción no se vuelcan en disco como parte del commit.
El razonamiento de este comportamiento es que tener la
transacción con un commit en al menos dos máquinas
autónomas debe cumplir estándars razonables para
durabilidad.
También es importante asegurarse que incluso el peor caso
— una caída completa del cluster — se trata
apropiadamente . Para garantizar que esto ocurre, todas
las transacciones que tienen lugar dentro de un intervalo
dado se ponen en un checkpoint global, que puede
entenderse como un conjunto de transacciones volcadas en
disco. En otras palabras, como parte del proceso de
commit, una transacción se guarda en el grupo de
checkpoint global; posteriormente, este registro de log de
grupo se vuelca en disco, y luego se guarda en disco el
completo grupo de transacciones en todas las máquinas del
cluster.
Este parámetro define el intervalo entre checkpoints
globales. Por defecto son 2000 milisegundos.
[NDBD]TimeBetweenInactiveTransactionAbortCheck
El tratamiento de time-outs se realiza chequeando un timer
en cada transacción una vez por cada intervalo
especificado por este parámetro. Por lo tanto, si este
parámetro se pone a 1000 milisegundos, cada transacción
se chequea para hacer un time out una vez por segundo.
El valor por defecto para este parámetro es 1000
milisegundos (1 segundo).
[NDBD]TransactionInactiveTimeout
Si la transacción no está realizando ninguna consulta
pero esta esperando más datos de entrada del usuario,
este parámetro indica el tiempo máximo que el usuario
puede esperar entes de abortar la transacción.
Por defecto este parámetro es cero (no timeout). Para una
base de datos en tiempo real que necesita asegurarse que
las transacciones no mantienen bloqueos demasiado tiempo
se debe inicializar con un valor mucho más pequeño. La
unidad es milisegundos.
[NDBD]TransactionDeadlockDetectionTimeout
Cuando un nodo ejecuta una consulta que implique una
transacción, el nodo espera para que respondan los otros
nodos en el cluster antes de continuar. Puede que haya un
fallo al responder por cualquiera de las siguientes
razones:
El nodo está “muerto”
La operación ha entrado en una cola de bloqueo
El nodo con la petición de realizar la acción
puede estar muy sobrecargado.
Este parámetro de timeout indica cuánto espera el
coordinador de la transacción para la ejecución de la
consulta por otro nodo antes de abortar la transacción, y
es importante para tratamiento de fallo de nodo y
detección de deadlocks. Ponerlo a un valor muy alto puede
causar comportamiento no deseables en situaciones que
impliquen deadlocks y fallos de nodos.
El timeout por defecto es 1200 milisegundos (1.2
segundos).
[NDBD]NoOfDiskPagesToDiskAfterRestartTUP
Al ejecutar un checkpoint local el algoritmo vuelca todas
las páginas de datos a disco. Hacer esto tan rápidamente
como sea posible sin ninguna moderación es posible que
imponga demasiada carga de procesador, red y disco. Para
controlar la velocidad de escritura, este parámetro
especifica cuántas paginas se escriben en 100
milisegundos. En este contexto, una “página”
se define como 8KB; por lo tanto, este parámetro se
especifica en unidades de 80KB por segundo. Por lo tanto,
poner
NoOfDiskPagesToDiskAfterRestartTUP a un
valor de 20 significa escribir 1.6MB de páginas de datos
en disco cada segundo durante checkpoints locales. Este
valor incluye escribir registros del log UNDO para
páginas de datos; esto es, este parámetro trata la
limitación de escrituras de memoria de datos. Los
registros del log UNDO para páginas de índice se tratan
mediante los parámetros
NoOfDiskPagesToDiskAfterRestartACC.
(Consulte la entrada para IndexMemory
para información acerca de páginas de índice.)
Resumiendo, este parámetro especifique con qué velocidad
se realizan los checkpoints locales, y opera en
conjunción con NoOfFragmentLogFiles,
DataMemory, y
IndexMemory.
El valor por defecto es 40 (3.2MB de páginas de datos por
segundo).
[NDBD]NoOfDiskPagesToDiskAfterRestartACC
Este parámetro usa las mismas unidades que
NoOfDiskPagesToDiskAfterRestartTUP y
actúa de forma similar, pero limita la velocidad de
escritura de páginas índices de memoria índice.
El valor por defecto de este parámetro es 20 páginas
índice de memoria por segundo (1.6MB por segundo).
[NDBD]NoOfDiskPagesToDiskDuringRestartTUP
Este parámero parecido a
NoOfDiskPagesToDiskAfterRestartTUP y
NoOfDiskPagesToDiskAfterRestartACC,
sólo lo hace en función de los checkpoints locales
ejecutados en el nodo donde se reinicia un nodo. Como
parte de todo reinicio de nodo siempre se realiza un
checkpoint. Durante el reinicio de un nodo es posible
escribir en disco a una velocidad superior que otras
veces, ya que se realizan menos actividades en el nodo.
Este parámetro cubre páginas escritas de memoria de
datos.
El valor por defecto es 40 (3.2MB por segundo).
[NDBD]NoOfDiskPagesToDiskDuringRestartACC
Controla el número de páginas de memoria índice que
pueden escribirse en disco durante la fase de checkpoint
local del reinicio de un nodo.
Como con
NoOfDiskPagesToDiskAfterRestartTUP y
NoOfDiskPagesToDiskAfterRestartACC, los
valores para este parámetro se expresan en términos de
8KB páginas escritas en 100 milisegundos (80KB/segundo).
El valor por defecto es 20 (1.6MB por segundo).
[NDBD]ArbitrationTimeout
Este parámetro especifica el tiempo que esperará el nodo
de datos en respuesta al árbitro. Si se excede, se asume
que la red se ha partido.
El valor por defecto es de 1000 milisegundos (1 segundo).
Buffering y Logueo
Varios parámetros de configuración se corresponden a
antiguos parámetros en tiempo de compilación que todavía
están disponibles. Esto permite al usuario avanzado tener
más control sobre los recursos usados por los procesos nodo y
para ajustar varios tamaños de buffer según sea necesario.
Estos buffers se usan como front ends para el sistema de
ficheros cuando se escriben los registros de log en disco. Si
el nodo está ejecutándose en modo diskless, y estos
parámetros pueden cambiarse a sus valores mínimos sin
penalización debido al hecho que las escrituras en disco se
"falsean" por parte la capa de abstracción del sistema de
ficheros del motor de almacenamiento NDB.
[NDBD]UndoIndexBuffer
Este buffer se usa durante los checkpoints locales. El
motor NDB usa un esquema de recuperación basado en
consistencia de checkpoints en conjunción con un log REDO
operacional. Para producir un checkpoint consistente con
bloquear el sistema entero para escrituras, el logueo de
UNDO se hace mientras se realiza el checkpoint local. El
logueo UNDO se activa en un fragmento de tabla único cada
vez. Esta optimización es posible porque las tablas se
almacenan completamente en memoria.
El buffer UNDO índice se usa para las actualizaciones en
el índice de clave hash primaria. Las inserciones y
borrados modifican el índice hash; el motor NDB escribe
registros en el log UNDO que mapean todos los cambios
físicos en una página índice de forma que pueden
deshacerse al reiniciar al sistema. También loguea todas
las operaciones de inserciones activas para cada fragmento
al arranque del checkpoint local.
Lee y actualiza el conjunto de bits de bloquea y actualiza
una cabecera en la entrada del índice hash. Estos cambios
los trata el algoritmo de escritura de páginas para
asegurar que estas operaciones no necesitan logueo UNDO.
Este búffer es de 2MB por defecto. El valor mínimo es de
1MB, y para la mayoría de aplicaciones el mínimo es
suficiente. Para aplicaciones que realicen un número de
inserciones y borrados muy alto junto con transacciones
muy grandes y claves primaria grandes, puede ser necesario
incrementar el tamaño de este buffer. Si el buffer es muy
pequeño, el motor NDB realiza un código de error interno
677 Index UNDO buffers overloaded.
[NDBD]UndoDataBuffer
El buffer de datos UNDO juega el mismo rol que el buffer
de indice UNDO, excepto que se usa a con la memoria de
datos en lugar de la de índice. Este buffer se usa
durante la fase de checkpoint local de un fragmento para
inserciones, borrados y actualizaciones.
Como UNDO las entradas de log tienden a crecer mayores
mientras más operaciones se loguean, este buffer también
es mayor que su contraparte de memoria índice, con un
valor por defecto de 16MB.
Para algunas aplicaciones esta cantidad de memoria puede
ser innecesariamente grande. En tales casos es posible
decrementar este tamaño a un mínimo de 1MB.
Ráramente es necesario incrementar el tamaño de este
buffer. Si hay tal necesidad, es una buena idea chequear
si el disco puede tratar la carga causada por la actividad
de actualización de la base de datos. Una falta de
espacio de disco no puede evitarse incrementando el
tamaño de este buffer.
Si este buffer es demasiado pequeño y se congestiona, el
motor NDB realiza un código de error interno 891
Data UNDO buffers overloaded.
[NDBD]RedoBuffer
Todas las actividades de actualización necesitan
loguearse. Este log hace posible rehacer estas
actualizaciones cuando el sistema se reinicia. El
algoritmo de recuperación NDB usa un checkpoint
“fuzzy” de los datos junto con el log UNDO,
luego aplica el log REDO para aplicar todos los cambios
hasta el punto de restauración.
Este buffer es de 8MB por defecto. El valor mínimo es
1MB.
Si este buffer es demasiado pequeño, el motor NDB realiza
un código de error 1221 REDO log buffers
overloaded.
Al administrar el cluster, es muy importante ser capaz de
controlar el número de mensajes de log enviados por distintos
tipos de eventos a stdout. Hay 16 niveles
posibles de evento (numerados de 0 a 15). Realizar un reporte
de evento para una categoría de evento dada a nivel 15
significa que todos los reportes de evento en esta categoría
se envían a stdout; ponerlo a 0 significa
que no habrá reportes de eventos en esta categoría.
Por defecto, sólo el mensaje de arranque se envía
stdout, con los valores por defecto de los
niveles de reporte pendientes puestos a 0 . La razón para
esto es que estos mensajes también se envían al log de
administración del cluster.
Un conjunto de niveles análogo puede ponerse para el cliente
de administración para determinar qué niveles de evento
registrar en el log de cluster.
[NDBD]LogLevelStartup
Reportar niveles para eventos generados durante el
arranque del proceso.
El nivel por defecto es 1.
[NDBD]LogLevelShutdown
El nivel de reporte para eventos generados como parte de
un cierre de un nodo.
El nivel por defecto es 0.
[NDBD]LogLevelStatistic
El nivel de reporte para eventos estadísticos tales como
número de lecturas de clave primaria, número de
actualizaciones, número de inserciones, información
acerca del uso de búffer, y así.
El nivel por defecto es 0.
[NDBD]LogLevelCheckpoint
Nivel de reporte para eventos generados por los
checkpoints locales y globales.
El nivel por defecto es 0.
[NDBD]LogLevelNodeRestart
Nivel de reporte para eventos generados durante reinicio
de nodo.
El nivel por defecto es 0.
[NDBD]LogLevelConnection
El nivel de reporte para eventos generados por conexiones
entre nodos del cluster.
El nivel por defecto es 0.
[NDBD]LogLevelError
Nivel de reporte para eventos generados por errores y
advertencias por el cluster global. Estos errores no
causan ningún fallo de nodo pero se considera que vale la
pena de reportar.
El nivel por defecto es 0.
[NDBD]LogLevelInfo
Nivel de reporte para eventos generados por información
acerca del estado general del cluster.
El nivel por defecto es 0.
Parámetros de copia de
seguridad
Los parámetros de esta sección definen buffers de memoria
para ejecución de copias de seguridad en línea.
[NDBD]BackupDataBufferSize
Al crear una copia de seguridad, hay dos búffers usados
para enviar data a disco. El buffer de copia de seguridad
de datos se usa para rellenar con datos registrados al
escanear las tablas de un nodo. Una vez que este buffer se
ha rellenado al nivel especificado por
BackupWriteSize (vea a continuación),
las páginas se envían a disco. Al volcar los datos a
disco, el proceso de copia de seguridad puede continuar
rellenando este buffer hasta que se queda sin espacio.
Cuando ocurre, el proceso de copia de seguridad pausa el
escaneo y espera hasta que se completan algunas escrituras
en disco y han liberado memoria de forma que pueda
continuar el escaneo.
El valor por defecto de este paráemtro es 2MB.
[NDBD]BackupLogBufferSize
El buffer de log de copia de seguridad tiene un rol
similar al jugado por el buffer de copia de seguridad de
datos , excepto que se usa para generar un log de todas
las escrituras de tabla realizadas durante la ejecución
de una copia de seguridad. Los mismos principios se
aplican para escribir estas páginas como con el buffer de
datos de copia de seguridad, excepto que cuando no hay
más espacio en el buffer de log de copia de seguridad, la
copia falla. Por esta razón, el tamaño del buffer de log
de copia de seguridad debe ser lo bastante grande para
tratar la carga causada por las actividades de escritura
mientras se realiza la copia de seguridad.
El valor por defecto de este parámetro debe ser
suficiente para la mayoría de aplicaciones. De hecho, es
más fácil que un fallo de copia de seguridad sea causado
por velocidad de escritura en disco insuficiente que por
que el buffer de log esté lleno. Si el subsistema de
disco no está configurado para la carga de escritura
causada por las aplicaciones, el cluster posiblemente
será capaz de realizar las operaciones deseadas.
Es preferible configurar nodos del cluster de forma que el
procesador sea el cuello de botella en lugar que los
discos o las conexiones de red.
El valor por defecto es 2MB.
[NDBD]BackupMemory
Este parámetro es la suma de
BackupDataBufferSize y
BackupLogBufferSize.
El valor por defecto es 2MB + 2MB = 4MB.
[NDBD]BackupWriteSize
Este parámetro especifica el tamaño de los mensajes
escritos en disco por los buffers de log y datos de copia
de seguridad.
El valor por defecto es 32KB.
16.4.4.6. Definir los servidores MySQL (nodos sql) en un MySQL Cluster
La sección [MYSQLD] del fichero
config.ini define el comportamiento de
los servidores MySQL (nodos SQL) usados para acceder a los
datos del cluster. Ninguno de los parámetros mostrados es
necesario. Si no se proporciona máquina ni nombre de equipo,
entonces cualquier equipo puede usar este nodo SQL.
[MYSQLD]Id
Este valor se usa como dirección del nodo por todos los
mensajes internos del cluster, y debe ser un entero entre
1 y 63. Cada nodo del cluster debe tener una identidad
única dentro del cluster.
[MYSQLD]ExecuteOnComputer
Se refiere a una de las máquinas definidas en la sección
[COMPUTER] del fichero de
configuración.
[MYSQLD]ArbitrationRank
Este parámetro se usa para definir qué nodos pueden
actuar como árbitros. Pueden serlo los nodos MGM y SQL.
Un valor de 0 significa que el nodo dado nunca se usará
como árbitro, un valor de 1 le da al nodo alta prioridad
como árbitro, y un valor de 2 le da baja prioridad. Una
configuración normal usa el servidor de administración
como árbitro, poniendo se
ArbitrationRank a 1 (por defecto) y los
nodos SQL a 0.
[MYSQLD]ArbitrationDelay
Poner este parámetro con cualquier valor distinto a 0
(valor por defecto) significa que las respuestas al
árbitro se retrasan el número indicado de milisegundos.
Usualmente no es necesario cambiar este valor.
[MYSQLD]BatchByteSize
Para consultas traducidas en escaneos completos de tabla o
escaneo de rangos de índices, es importante pare un mejor
rendimiento tratar registros en batchs de tamaño
apropiado. Es posible poner el tamaño adecuado en
términos de número de registros
(BatchSize) y en términos de bytes
(BatchByteSize). El tamaño batch real
viene limitado por ambos parámetros.
La velocidad a la que se realizan las consultas puede
variar más de un 50$ en función de cómo se ajusta este
parámetro. En versiones futuras, el servidor MySQL
realizará conjeturas sobre cómo ajustar estos
parámetros según el tamaño batch basado en el tipo de
consulta.
Este parámetro se mide en bytes y por defecto es igual a
32KB.
[MYSQLD]BatchSize
Este parámetro se mide en número de registros y por
defecto es 64. El tamaño máximo es 992.
[MYSQLD]MaxScanBatchSize
El tamaño batch es el tamaño de cada batch envíado por
cada nodo de datos. La mayoría de escaneos se realizan en
paralelo para proteger que el servidor MySQL reciba
demasiados datos de demasiados nodos en paralelo; este
parámetro ajusta el límite del tamaño total batch en
todos los nodos.
El valor por defecto de este parámetro se ajusta a 256KB.
Su tamaño máximo es 16MB.
16.4.4.7. Conexiones TCP/IP de MySQL Cluster
TCP/IP es el mecanismo de transporte por defecto para
establecer conexiones en MySQL Cluster. Normalmente no es
necesario definir conexiones ya que el cluster
automáticamente crea una conexión entre todos los nodos de
datos, entre cada nodo de datos y los nodos MySQL server y
entre cada nodo y el servidor de administración. (Para una
excepción a esta regla consulte
Sección 16.4.4.8, “Conexiones TCP/IP de MySQL Cluster usando conexiones directas”.)
Sólo es necesario definir una conexión para sobreescribir
los parámetros por defecto de conexión. En tal caso es
necesario definir al menos NodeId1,
NodeId2, y los parámetros a
cambiar.
Es posible cambiar los valores por defecto para estos
parámetros cambiándolos en la sección [TCP
DEFAULT] .
[TCP]NodeId1
,
[TCP]NodeId2
Para identificar una conexión entre dos nodos es
necesario proporcionar los identificadores de nodo para
ambos en la sección [TCP] del fichero
de configuración.
[TCP]SendBufferMemory
TCP usa un buffer para almacenar todos los mensajes antes
de realizar la llamada de envío del sistema operativo.
Cuando este buffer llega a 64KB sus contenidos se envían;
también se envían cuando se ha ejecutado una ronda de
mensajes. Para tratar situaciones de sobrecarga temporal
es posible definir un buffer de envio mayor. El tamaño
por defecto del buffer de envío es 256KB.
[TCP]SendSignalId
Para poder trazar un diagrama de mensaje distribuído es
necesario identificar cada mensaje. Cuando este parámetro
es Y, los IDs de mensaje se transportan
por la red. Esta característica está desactivada por
defecto.
[TCP]Checksum
Este parámetro es booleano
(Y/N o
1/0) , y está
desactivado por defecto. Cuando está activado, los
checksums de todos los mensajes se calculan antes de
ponerlos en el buffer de envío. Esta característica se
asegura que los mensajes no se corrompan mientras esperan
en el buffer de envío, o por el mecanismo de transporte.
[TCP]PortNumber
(OBSOLETO.) Antiguamente
especificada el número de puerto a usar para escuchar las
conexiones de otros nodos. Este paráemtro no debe usarse
más.
[TCP]ReceiveBufferMemory
Especifica el tamaño del buffer usado al recibir datos
del socket TCP/IP . No hay necesidad de cambiar el valor
por defecto de este parámetro de 64KB, excepto para
ahorrar memoria.
16.4.4.8. Conexiones TCP/IP de MySQL Cluster usando conexiones directas
Ajustar el cluster usando conexiones directas entre nodos de
datos requiere curzar explícitamente las direcciones IP de
los nodos de datos conectados así en la sección
[TCP] del fichero
config.ini del cluster.
En el siguiente ejemplo, tenemos un cluster con al menos 4
equipos, uno para un servidor de administración, un nodo SQL,
y dos nodos de datos. El cluster reside en la subred
172.23.72.* de una LAN. Además de las
conexiones de red usuales, los dos nodos de datos se conectan
directamente usando un cable cruzado, y comunican entre ellos
directamente usando direcciones IP en el rango IP
1.1.0.* como se muestra:
El uso de conexiones directas entre nodos de datos puede
mejorar la eficiencia global del cluster permitiendo a los
nodos de datos cortocircuitar un equipo de Ethernet como un
switch, hub o router, disminuyendo la latencia del cluster. Es
importante tener en cuenta que para obtener el mayor
rendimiento de las conexiones directas con más de 2 nodos de
datos, necesitará tener una conexión directa entre cada
datos de nodos y cada uno de los nodos de datos en el mismo
grupo de nodos.
16.4.4.9. Conexiones de MySQL Cluster que comparten memoria
En MySQL 5.0, MySQL Cluster tata de usar transporte a través
de memoria compartida y configurarla automáticamente cuando
sea posible, principalmente donde más 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 sólo cuando el binario
-max se compila usando
--with-ndb-shm.) Cuando se define la memoria
compartida explícitamente como método de conexión, es
necesario definir como mínimo NodeId1,
NodeId2 y ShmKey. Todos
los otros parámetros tienen valores por defecto que funciona
bien en la mayoría de casos.
Nota: El soporte SHM debe
considerarse experimental.
[SHM]NodeId1,
[SHM]NodeId2
Para identificar una conexión 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 unívocamente el
segmento de memoria compartida para usar para la
comunicación. Se expresa como un entero que no tiene
valor por defecto.
[SHM]ShmSize
Cada conexión SHM tiene un segmento de memoria compartida
dónde los nodos entre mensajes se guardan por parte del
que envía y donde lo lee el receptor. El tamaño de este
segmento lo define ShmSize. El valor
por defecto es 1MB.
[SHM]SendSignalId
Para obtener la traza de la ruta de un mensaje
distribuído, es necesario proporcionar un identificador
único a cada mensaje. Poner este parámetro a
Y hace que los IDs de mensajes se
transporten sobre la red también. Esta característica
está desactivada por defecto.
[SHM]Checksum
Este parámetro 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 envío.
Esta característica evita que los mensajes se corrompan
mientras esperan en el buffer de envío. También sirve
como chequeo para que no se corrompan los datos durante el
transporte.
16.4.4.10. Conexiones de transporte SCI en MySQL Cluster
Se soporta el uso de transporte SCI en MySQL Cluster sólo
cuando los binarios MySQL-Max se compilan usando
--with-ndb-sci=/your/path/to/SCI.
El path debe apuntar a un
directorio que contiene como mínimo los directorios
lib y include con
las bibliotecas SISCI y ficheros de cabecera.
Además, SCI necesita hardware especializado.
Es muy recomendable usar SCI Transporters sólo para
comunicación entre procesos ndbd .
Además, usar SCI Transporters significa que los procesos
ndbd nunca duermen. Por esta razón, los
SCI Transporters deben usarse sólo en máquinas con al menos
2 CPUs dedicadas para usar con procesos
ndbd . Al menos debe haber 1 CPU por
proceso ndbd , con al menos 1 CPU en
reserva para tratar actividades del sistema operativo.
[SCI]NodeId1,
[SCI]NodeId2
Para identificar una conexión entre dos nodos es
necesario proporcionar identificadores de nodo para cada
uno de ellos, como NodeId1 y
NodeId2.
[SCI]Host1SciId0
Esto identifica el nodo ID SCI en el primer nodo del
Cluster (identificado por NodeId1).
[SCI]Host1SciId1
Es posible preparar SCI Transporters para tratar fallos
entre dos tarjetas SCI que deban usar redes separadas
entre los nodos. Esto identifica el ID del nodo y la
segunda tarjeta SCI a usar en el primer nodo.
[SCI]Host2SciId0
Esto identifica el ID del nodo SCI en el segundo nodo del
Cluster (identificado por NodeId2).
[SCI]Host2SciId1
Cuando dos tarjetas SCI para proporcionar tolerancia a
fallos, este parámetro identifica la segunda tarjeta SCI
a usar en el segundo nodo.
[SCI]SharedBufferSize
Cada SCI transporter tiene un segmento de memoria
compartido usado para la comunicación entre los dos
nodos. Especificar el segmento de este valor por defecto
de 1 MB debería ser suficiente para la mayoría de
aplicaciones. Usar un valor menor puede llevar a problemas
al realizar muchas inserciones paralelas; si un buffer
compartido es demasiado pequeño, puede resultar en una
caída del proceso ndbd .
[SCI]SendLimit
Un buffer pequeño en frente del medio SCI almacena
mensajes antes de transmitirlos en la red SCI. Por defecto
se pone 8kB. Nuestras pruebas muestras que el rendimiento
es mejor con 64 kB pero 16kB alcanza un pequeño
porcentaje de esto, y hay poca ventaja si se incrementa
más allá de 8kB.
[SCI]SendSignalId
Para tracear un mensaje distribuído es necesario
identificar cada mensaje únicamente. Cuando este
parámetro se pone a Y, los IDs de
mensaje se transportan sobre la red. Esta característica
se desactiva por defecto.
[SCI]Checksum
Este parámetro es un valor booleano, y está desactivado
por defecto. Cuando Checksum está
activado, los checksums se calculan para todos los
mensajes antes de ponerlos en el buffer de envío. Esta
característica evita que los mensajes se corrompan
mientras esperan en el buffer de salida durante el
transporte.
Entender cómo administrar MySQL Cluster requiere un conocimiento
de cuatro procesos esenciales. En las siguientes secciones de este
capítulo, cubrimos los roles jugados por estos procesos en un
cluster, cómo usarlos, y qué opciones de arranque están
disponibles para cada uno de ellos.
16.5.1. El uso del proceso del servidor MySQL para MySQL Cluster
mysqld es el proceso de MySQL server
tradicional. mysqld debe compilarse con
soporte para el motor NDB Cluster , como lo está en los
binarios -max precompilados disponibles en
mysql.com.
Si el binario mysqld se ha compilado de esta
forma, el motor NDB Cluster todavía está desactivado por
defecto. Tiene dos opciones para activar el motor NDB Cluster :
Use --ndbcluster como opción de arranque
para mysqld
Inserte una línea con ndbcluster en la
sección [mysqld] en el fichero
my.cnf .
Una forma sencilla de verificar que su servidor está ejecutando
el motor NDB Cluster es ejecutar el comando
SHOW ENGINES en MySQL Monitor
(mysql). Debe ver el valor
YES en el registro
NDBCLUSTER; si ve NO en
este registro (o si no se muestra este registro en la salida),
no está ejecutando la versión NDB-activada
de mysqld. Si ve DISABLED
en este registro, entonces su servidor es capaz de usar el motor
NDBCLUSTER , pero debe activarse mediante
algunos de los métodos ya descritos.
Para leer los datos de configuración del cluster, el MySQL
server necesita como mínimo 3 informaciones:
El ID del nodo del servidor MySQL.
El nombre de equipo o dirección IP para el servidor de
administración (nodo MGM).
El puerto en el que puede conectarse al servidor de
administración.
Los ID de nodo pueden registrarse dinámicamente en MySQL 5.0,
así que no es estrictamente necesario especificarlo
explícitamente.
El parámetro de mysqldndb-connectstring se usa para especificar el
connectstring en la línea de comandos al arrancar
mysqld o en my.cnf. El
connectstring contiene el nombre de equipo o direcciones IP así
como el puerto donde puede encontrarse el servidor de
administración.
En el siguiente ejemplo, ndb_mgmd.mysql.com
es el equipo en que reside el servidor de administración, y el
servidor de administracion escucha los mensajes del cluster en
el puerto 1186:
Consulte Sección 16.4.4.2, “El connectstring de MySQL Cluster” para más
información sobre los connectstrings.
Dada esta información el servidor MySQL será un participante
activo del cluster. (En ocasiones nos referimos a un proceso
mysqld que se ejecute de este modo como nodo
SQL.) Será consciente de todos los nodos de datos del cluster
así como de su estado, y establecerá conexiones con todos los
nodos de datos. En este caso, es capaz de usar cualquier nodo de
datos como un coordinador de transacción y para acceder nodos
de datos para leer y actualizar.
16.5.2. ndbd, el proceso del nodo de motor de almacenamiento
ndbd es el proceso que se usa para tratar
todos los datos en las tablas usando el motor de almacenamiento
NDB Cluster. Este proceso fuerza un nodo de almacenamiento a que
cumpla el tratamiento de transacciones distribuídas,
recuperación de nodos, realización de checkpoints, copia de
seguridad en línea, y tareas relacionadas.
En MySQL Cluster, un conjunto de procesos
ndbd cooperan para tratar datos. Estos
procesos pueden ejecutarse en la misma máquina (equipo) o en
máquinas distintas. Las correspondencias entre nodos de datos y
máquinas cluster son completamente configurables.
En MySQL 5.0, ndbd genera un conjunto de
ficheros de log que se guardan en el directorio especificado por
DataDir en el fichero de configuración.
Estos ficheros de log se listan a continuación. Tenga en cuenta
que <NodeID> representa el
identificador único del nodo. Por ejemplo,
ndb_2_error.log es el log de error generado
por el nodo de almacenamiento cuyo ID de nodo es
2.
ndb_<NodeID>_error.log
es un fichero que contiene registros de todas las caídas
que ha encontrado el proceso referenciado
ndbd. Cada registro en este fichero
contiene un breve mensaje de error y una referencia a un
fichero de traceo para este fallo. Una entrada típica en
este fichero puede ser parecida a:
Date/Time: Saturday 30 July 2004 - 00:20:01
Type of error: error
Message: Internal program error (failed ndbrequire)
Fault ID: 2341
Problem data: DbtupFixAlloc.cpp
Object of reference: DBTUP (Line: 173)
ProgramName: NDB Kernel
ProcessID: 14909
TraceFile: ndb_2_trace.log.2
***EOM***
ndb_<NodeID>_trace.log.<TraceID>
es un fichero de traceo que describe exactamente qué ha
ocurrido jusnto antes de que ocurra el error. Esta
información es útil para su análisis por parte del equipo
de desarrollo de MySQL Cluster .
Es posible configurar el número de estos ficheros de traceo
que se crean antes que los ficheros antiguos se
sobreescriban. <TraceID> es
un número que se incrementa para cada fichero de traceo
sucesivo.
ndb_<NodeID>_trace.log.next
es el fichero que se encarga del siguiente número de traceo
para fichero a asignar.
ndb_<NodeID>_out.log
es un fichero que contiene cualquier salida de datos del
proceso ndbd . Este fichero se crea sólo
si ndbd se arranca como demonio.
ndb_<NodeID>.pid
es un fichero que contiene el ID de proceso del proceso
ndbd cuando se arranca como demonio.
También funciona como fichero de bloqueo para evitar
arrancar los nodos con el mismo identificador.
ndb_<NodeID>_signal.log
es un fichero usado sólo en versiones de depuración de
ndbd, donde es posible tracear toda la
entrada, salida, y mensajes internos con sus datos en el
proceso ndbd .
Se recomiendo no usar un directorio montado mediante NFS porque
en algunos entornos puede causar problemas donde el bloqueo del
fichero pid sigue en efecto tras la finalización del proceso.
Al reiniciar ndbd puede ser necesario
especificar un nombre de equipo del servidor de administración
y el puerto en que está escuchando. (Opcionalmente, se puede
especificar el ID de nodo que usará el proceso.
Consulte Sección 16.4.4.2, “El connectstring de MySQL Cluster” para más
información sobre este tema.
Cuando ndbd arranca, inicia dos procesos. El
primero de ellos se llama el proceso “angel
process”; su trabajo es descubrir cuándo se completa el
proceso de ejecución, y luego reinicia el proceso
ndbd si se configura para hacerlo. Por lo
tanto, is trata de matar ndbd via comando
Unix kill , es necesario matar a ambos
procesos. Una forma más adecuada de matar un proceso
ndbd es usar el cliente de administración y
parar el proceso desde allí.
El proceso en ejecución usa un flujo para lectura, escritura y
escaneo de datos, así como otras actividades. Este flujo se
implementa asíncronamente para que pueda tratar fácilmente
miles de actividades concurrentes. Además, un flujo watch-dog
supervisa el flujo de ejecución para asegurarse que no se
cuelga en un bucle infinito. Un pool de flujos trata ficheros de
entrada/salida, siendo cada flujo capaz de tratar un fichero
abierto. Los flujos pueden usarse por las conexiones en el
proceso de transporet de ndbd . En un sistema
que realice un gran número de operaciones, incluyendo
actualizaciones, el proceso ndbd consume
hasta 2 CPUs si se permite hacerlo. Para máquinas con varias
CPUs se recomienda usar varios procesos ndbd
que pertenecen a diferentes grupos de nodos.
16.5.3. El proceso del servidor de administración ndb_mgmd
El sevidor de administración es el proceso que lee el fichero
de configuración del cluster y distribuye esta información a
todos los nodos en el cluster que la piden. También mantiene un
log de las actividades del cluster. Los clientes de
administración pueden conectar al servidor de administración y
chequear el estado del cluster.
No es estrictamente necesario especificar un connectstring al
arrancar un servidor de administración. Sin embargo, si está
usando más de un servidor de administración, debe
proporcionarse un connectstring y cada nodo en el cluster debe
especificar su ID de nodo explícitamente.
Los siguientes ficheros se crean o usan por
ndb_mgmd en su directorio de arranque. En
MySQL 5.0 Cluster, los ficheros de log y PID se guardan en el
DataDir como se especifica en el fichero de
configuración. En la lista a continuación,
<NodeID> es el único
identificador de nodo.
config.ini es el fichero de
configuración para el cluster como un todo. Este fichero se
crea por el usuario y lo lee el servidor de administración.
La configuración de este fichero se discute en
Sección 16.4, “Configuración de MySQL Cluster”.
ndb_<NodeID>_cluster.log
es el ficheor de log de eventos del cluster. Ejemplos de
tales eventos incluyen inicio y finalización de
checkpoints, eventos de arranque de nodos, fallos de nodos,
y niveles de uso de memoria. Una lista completa de eventos
de cluster con descripciones puede encontrarse en
Sección 16.6, “Administración de MySQL Cluster”.
Cuando el tamaño del log del cluster alcanza un millón de
bytes el fichero se renombra a
ndb_<NodeID>_cluster.log.SeqID,
donde SeqID es el número de
secuencia del fichero de log del cluster . (Por ejemplo: si
1,2, y 3 ya existen, el siguiente fichero de log se llamará
con el número 4.)
ndb_<NodeID>_out.log
es el fichero usado por stdout y
stderr cuando se ejecuta el servidor de
administración como demonio.
ndb_<NodeID>.pid
es el fichero PID usado cuando se ejecuta el servidor de
administración como demonio.
16.5.4. El proceso de cliente de administración ndb_mgm
El proceso de cliente de administración no es necesario que se
ejecute en el cluster. Su validez estriba en proporcionar un
conjunto de comandos para chequear el estado del cluster,
arrancar copias de seguridad, y realizar otras funciones
administrativas. El cliente de administración accede al
servidor de administración usando la API C que pueden emplear
los usuarios avanzados para programación dedicada a procesos de
administración que pueden realizar tareas similares a las
realizadas por ndb_mgm.
Al arrancar el cliente de administración, es necesario
proporcionar el nombre de equipo y puerto del servidor de
administración como en el ejemplo posterior. Los valores por
defecto en MySQL 5.0 son localhost y
1186.
Todos los ejecutables de MySQL Cluster (excepto
mysqld) tienen las siguientes opciones. Los
usuarios de versiones anteriores de MySQL Cluster deben tener en
cuenta que algunas de estas opciones han cambiado desde MySQL
4.1 Cluster para hacerlos consistentes entre ellos así como con
mysqld. Puede usar la opción
-? para ver un listado de las opciones
soportadas.
-?, --usage, --help
Muestra una pequeña lista con descripciones de las opciones
de comandos disponibles.
-V, --version
Muestra el número de versión del proceso
ndbd. El número de versión es el
número de MySQL Cluster. El número de versión es
relevante porque no todas las versiones pueden usarse
juntas, y al arrancar el proceso MySQL Cluster verifica que
las versoines de los binarios usados pueden coexistir en el
mismo cluster. Esto es importante al realizar una
actualización de software en línea de MySQL Cluster
(consulte Software Upgrade of MySQL
Cluster).
-c connect_string,
--connect-string connect_string Cambia la cadena
de conexión del servidor de administración como opción de
comando.
--debug[=options]
Esta opción sólo puede usarse para opciones compiladas con
depuración activada. Se usa para permitir la salida de las
llamadas de depuración de la misma forma que para el
proceso mysqld .
-e, --execute
Puede usarse para enviar un comando al ejecutable cluster
desde el shell de sistema. Por ejemplo, cualquiera de los
siguientes comandos:
16.5.5.1. Opciones de mysqld relacionadas con MySQL Cluster
--ndbcluster
Si el binario incluye soporte para el motor NDB
Cluster puede evitarse la desactivación por
defecto del motor NDB mediante el uso
de esta opción. El uso del motor NDB
Cluster es necesario para MySQL Cluster.
--skip-ndbcluster
Desactiva el motor NDB Cluster. Esta
opción está activa por defecto para binarios donde se
incluye; en otras palabras, el motor NDB
Cluster se desactiva hasta que se activa via
--ndbcluster. Esta opción se activa
sólo si el servidor se compiló con soporte para el motor
NDB Cluster .
--ndb-connectstring=connect_string
Al usar el motor NDB, es posible
mediante esta opción especificar el servidor de
almacenamiento que distribuye los datos de configuración
del cluster.
-d, --daemon
Le dice a ndbd que se ejecute como un
proceso demonio. En MySQL 5.0, es el comportamiento por
defecto.
--nodaemon
Le dice a ndbd que no arranque como
proceso demonio. Es útil cuando ndbd
se depura y se quiere que la salida se redirija a la
pantalla.
--initial
Le dice a ndbd que realice un escaneo
inicial. Un arranque inicial borra cualquier fichero
creado con motivos de recuperación de instancias prévias
de ndbd. También recrea ficheros log
de recuperación. Tenga en cuenta que en algunos sistemas
operativos este proceso puede llevar una cantidad de
tiempo substancial.
Un arranque --initial se usa sólo la
primera vez que se arranca el proceso
ndbd , y borra todos los ficheros del
sistema de ficheros del cluster y recrea todos los
ficheros de log REDO. Las excepciones a esta regla son:
Cuando se realiza una actualización de software que
cambia los contenidos de cualquier fichero.
Al reiniciar el nodo con una nueva versión de
ndbd.
Como medida de última hora cuando por alguna razón
el reinicio repetitivo del nodo o sistema fallan. En
este caso el nodo no puede seguir usándose para
restaurar datos debido a la destrucción de los
ficheros de datos.
Esta opción no afecta ningún fichero de copia de
seguridad que se ha creado por el nodo afectado.
--nostart
Le dice a ndbd que no arranque
automáticamente. Cuando se usa esta opción,
ndbd conecta el servidor de
administración , obtiene datos de configuración del
mismo, e inicia los objetos de comunicación. Sin embargo,
no arranca realmente el motor hasta que se le pida que lo
haga explícitamente por parte del servidor de
administración. Esto puede realizarse ejecutando el
comando apropiado por parte del cliente de
administración.
-f filename,
--config-file=filename,
(OBSOLETE): -c
filename
Le dice al servidor de administración qué fichero debe
usar como fichero de configuración. Esta opción debe
especificarse. El fichero por defecto es
config.ini.
Nota: La abreviación
-c es obsoleta en MySQL 5.0 Cluster y
no debe usarse en nuevas instalaciones.
-d, --daemon
Le dice a ndb_mgmd que arranque como
demonio. Este es el comportamiento por defecto.
-nodaemon
Le dice al servidor de administración que no arranque
como demonio.
[host_name
[port_num]]
Para arrancar el cliente de administración es necesario
especificar dónde reside el servidor de administración,
que significa especificar el nombre de equipo y puerto. El
equipo por defecto es localhost; el
puerto por defecto es 1186.
--try-reconnect=number
Si la conexión al servidor de administración se rompe,
entonces el nodo trata de reconectar al mismo cada 5
segundos hasta que tiene éxito. Usando esta opción, es
posible limitar el número de reintentos con
number antes de abandonar y
reportar un error en su lugar.
Administar un MySQL Cluster implica un número de tareas, la
primera de ellas es configurar y arrancar el MySQL Cluster. Esto
se cubre en Sección 16.4, “Configuración de MySQL Cluster” y
Sección 16.5, “Gestión de procesos en MySQL Cluster”.
Las siguientes secciones cubren la administración de un MySQL
Cluster en ejecución.
Esencialmente hay dos métodos de administrar activamente un MySQL
Cluster en ejecución. El primero de ellos es mediante el uso de
comandos entrados en el cliente de administración donde puede
chequearse el estado del cluster, cambiar los niveles de log,
arrancar y parar copias de seguridad y parar y arrancar nodos. El
segundo método implica estudiar el contenido del log del cluster
ndb_<NodeID>_cluster.log
en el directorio del servidor de adminisración
DataDir . (Recuerde que
<NodeID> representa el
identificador único del nodo cuya actividad se está logueando.)
El log del cluster contiene reportes de eventos generados por
ndbd. Es posible también enviar entradas del
log del cluster a un log de sistema Unix.
16.6.1. Comandos del cliente de administración
Además del fichero de configuración central, un cluster puede
ser controlado mediante una interfaz de línea de comandos
disponible a través del cliente de administración
ndb_mgm. Esta es la interfaz administrativa
primaria para un cluster en ejecución.
El cliente de administración tiene los siguientes comandos
básicos. En la lista que sigue,
<id> dentoa un ID de nodo de
base de datos o la palabra clave ALL, que
indica que el comando debe aplicarse a todos los nodos de datos
en el cluster.
HELP
Muestra información de todos los comandos disponibles.
SHOW
Muestra informaicón del estado del cluster.
<id>
START
Arranca el nodo de datos identificado por
<id> (o todos los nodos de
datos).
<id>
STOP
Para el nodo de datos identificado por
<id> (o todos los nodos de
datos).
<id> RESTART [-N]
[-I]
Reinicia el nodo de datos identificado por
<id> (o todos los nodos de
datos).
<id>
STATUS
Muestra información de estado para el nodo de datos
identificado por <id> (o
todos los nodos de datos).
ENTER SINGLE USER MODE
<id>
Entra en modo de usuario único, donde sólo el servidor
MySQL identificado por el ID del nodo
<id> tiene permiso para
acceder a la base de datos.
EXIT SINGLE USER MODE
Abandona el modo de usuario único permitiendo a todos los
nodos SQL (esto es, todos los procesos
mysqld en ejecución) para acceder a la
base de datos.
QUIT
Termina el cliente de administración.
SHUTDOWN
Para todos los nodos del cluster, excepto los nodos SQL, y
sale.
Los comandos para los logs de eventos se dan en la siguiente
sección; los comandos para creación de copias de seguridad y
restaurar de una copia de seguridad se proporcionan en una
sección separada de estos temas.
16.6.2. Informes de eventos generados por MySQL Cluster
En esta sección dicutimos los tipos de logs de eventos
proporcionados por MySQL Cluster, y los tipos de eventos que se
loguean.
MySQL Cluster proporciona dos tipos de log de evento. Son
cluster log, que incluye
eventos generados por todos los nodos del cluster, y
node logs, que son locales en
cada nodo de datos.
La salida generada por el logueo de eventos del cluster puede
tener varias destinaciones incluyendo un fichero, la consola del
servidor de administración o syslog. La
salida generada por el logueo de eventos de un nodo se escribe
en la ventana de consola de datos del nodo.
Ambos tipos de logueo de eventos pueden configurarse para
loguear distintos subconjuntos de eventos.
Nota: El log del cluster es el
log recomendado para la mayoría de usos, ya que proporciona
información de logueo para un cluster entero en un único
fichero . Los logs de nodos están pensados para ser usados
sólo durante desarrollo de aplicaciones, o para depurar código
de aplicación.
Cada evento reportable puede distinguirse según tres criterios
distintos:
Categoría: Puede tener uno de los
siguientes valores: STARTUP,
SHUTDOWN, STATISTICS,
CHECKPOINT,
NODERESTART,
CONNECTION, ERROR, o
INFO.
Prioridad: Representada por un número
de 1 a 15 incluidos, donde 1 indica “más
importante” y 15 “menos importante”.
Nivel de severidad: Puede ser uno de
los siguientes valores: ALERT,
CRITICAL, ERROR,
WARNING, INFO, o
DEBUG.
El log de cluster y el log de nodo pueden filtrarse con estas
propiedades.
16.6.2.1. Registrar comandos de control
Los siguientes comandos de administación están relacionados
con el log de cluster:
CLUSTERLOG ON
Activa el log del cluster.
CLUSTERLOG OFF
Desactiva el log del cluster
CLUSTERLOG INFO
Información acerca de la configuración del log del
cluster.
<id> CLUSTERLOG
<category>=<threshold>
Loguea eventos de category con
prioridad menor o igual a
threshold en el log del
cluster.
CLUSTERLOG FILTER
<severity>
Cambia a loguear eventos del cluster de la
severity especificada.
La siguiente tabla describe la configuración por defecto (
para todos los nodos de datos ) del umbral de categoría del
log del cluster. Si un evento tiene una prioridad con un valor
menor o igual al umbral de prioridad, se reporta en el log del
cluster.
Tenga en cuenta que los eventos se reportan por nodo de datos,
y que el umbral puede configurarse con distintos valores en
nodos diferentes
Categoría
Umbral por defecto (todos los nodos de
datos)
STARTUP
7
SHUTDOWN
7
STATISTICS
7
CHECKPOINT
7
NODERESTART
7
CONNECTION
7
ERROR
15
INFO
7
Los umbrales se usan para filtrar eventos dentro de cada
categoría. Por ejemplo, un evento STARTUP
con una prioridad de 3 no se loguea a no ser que el umbral
para STARTUP se cambie a 3 o menos. Sólo
los eventos con prioridad de 3 o menor se envían si el umbral
es 3.
Los niveles de seguridad de los eventos se muestran a
continuación. (Nota: Se
corresponde a niveles syslog Unix, excepto
para LOG_EMERG y
LOG_NOTICE, que no se usan o mapean.)
1
ALERT
Condición que debe corregirse inmediatamente, tal como una base de
datos de sistema corrupta
2
CRITICAL
Condiciones críticas, tales como errores de dispositivos o recursos
insuficientes
3
ERROR
Condiciones que deben corregirse, tales como errores de configuración
4
WARNING
Condiciones que no son errores, pero que pueden requerir tratamiento
especial
5
INFO
Mensajes de información
6
DEBUG
Mensajes de depuración usados para desarrollo NDB
Cluster
Los niveles de severidad de eventos pueden activarse o
desactivarse. Si un invel de severidad se activa, todos los
eventos con una prioridad menor o igual que los umbrales de
categoría se loguan. Si el nivel de severidad se deactiva no
se loguan los eventos pertenecientes a ese nivel.
16.6.2.2. Registro de eventos
Un reporte de evento se reporta en el log de eventos con el
siguiente formato:
<datetime>
[<string>]
<severity> --
<message>. Por
ejemplo:
Todos los eventos reportables se discuten en esta sección,
ordenados por categoría y nivel de severidad dentro de cada
categoría.
CONNECTION
Eventos
Hay eventos asociados con conexiones entre nodos del cluster.
Evento
Prioridad
Nivel de severidad
Descripción
nodos DB conectados
8
INFO
nodos de datos conectados
nodos DB desconectados
8
INFO
nodos de datos desconectados
comunicación cerrada
8
INFO
conexión con nodo SQL o de datos node cerrada
Comunicación abierta
8
INFO
conexión con nodo SQL o de datos node abierta
CHECKPOINT
Eventos
Los mensajes de log que se muestran se asocian con
checkpoints.
(Nota: GCP = Global
Checkpoint, LCP = Local Checkpoint.)
Evento
Prioridad
Nivel de severidad
Descripción
LCP parado en el cálculo de mantenimiento de GCI
0
ALERT
LCP parado
Fragmento de checkpoint local completo
11
INFO
LCP en un fragmento se ha completado
Checkpoint global completo
10
INFO
GCP finalizado
Checkpoint global arrancado
9
INFO
Arranque de GCP: REDO log escrito en disco
Checkpoint local completado
8
INFO
LCP completado normalmente
Checkpoint local arrancado
7
INFO
Arranque de LCP: datos escritos en disco
Reporte del log de undo bloqueado
7
INFO
Logueo de UNDO bloqueado; buffer cerca de desbordarse
STARTUP
Eventos
Los siguientes eventos se generan en respuesta al arranque de
un nodo o del cluster y de su éxito o fallida. También
proporciona información relacionada con el progreso del
proceso de arranque, incluyendo información acerca de las
actividades de logueo.
Evento
Prioridad
Nivel de severidad
Descripción
Señal de arranque interna recibida STTORRY
15
INFO
Bloques recibidos tras completar el reinicio
Registros Undo rejecutados
15
INFO
Arrancado nuevo log REDO
10
INFO
GCI guarda X, los GCI restaurables más
nuevos Y
Nuevo log arrancado
10
INFO
Parte X de log, arranca MB
Y, para MB
Z
El nodo se ha rehusado para incluir en el cluster
8
INFO
El nodo no puede incluirse en el cluster debido a fallos de
configuración, inabilidad de establecer
comunicación, u otros problemas
DB nodos vecinos
8
INFO
Muestra nodos de datos vecino
DB nodo arranca fase X completada
4
INFO
Un inicio de fase de nodo se ha completado
El nodo se ha incluido con éxito en el cluster
3
INFO
Muestra el nodo, nodo de administración, e ID dinámico
Fases de arranque de nodo DB iniciadas
1
INFO
Nodos de cluster NDB arrancando
Todas las fases de arranque del nodo DB completadas
1
INFO
Nodos NDB Cluster arrancados
Parada de nodo DB iniciada
1
INFO
Parada de nodos de datos comenzada
Parada de nodo DB abortada
1
INFO
Incapaz de cerrar el nodo de datos normalmente
NODERESTART
Eventos
Los siguientes eventos se generan al reiniciar un nodo y
están relacionados con el éxito o fracaso del proceso de
reinicio del nodo.
Evento
Prioridad
Nivel de severidad
Descripción
Fase de fallo de nodo completa
8
ALERT
Rerporta la finalización de las fases de fallo de nodo
El nodo ha fallado, el estado del nodo era X
8
ALERT
Reporta que el nodo ha fallado
Reporta el resultado del árbitro
2
ALERT
Hay 8 resultados distintos posibles de arbitraciones:
Chequeo de arbitración fallido - quedan menos
de 1/2 de los nodos.
Chequeo de arbitración exitoso - mayoría de
nodos del grupo.
Chequeo de arbitración fallido - falta un grupo
de nodos.
Partición de red - arbitración necesaria
Arbitración exitosa - respuesta afirmativa del
nodo X
Arbitración fallida - respuesta negativa del
nodo X
Partición de red - no hay árbitro disponible
Partición de red - no hay árbitro configurado
Completada la copia de fragmento
10
INFO
Completada la copia de información de directorio
8
INFO
Completada la copia de información de distribución
8
INFO
Iniciada la copia de fragmentos
8
INFO
Completada la copia de todos los fragmentos
8
INFO
Control de GCP iniciado
7
INFO
Control de GCP completado
7
INFO
Control de LCP iniciado
7
INFO
Control de LCP completado (estado = X)
7
INFO
Reporta si se encuentra un árbitro o no
6
INFO
Hay 7 salidas distintas al buscar un árbitro:
El servidor de administración reinicia el flujo
árbitro [estado=X]
Prepara nodo árbitro
X
[ticket=Y]
Recibe nodo árbitro
X
[ticket=Y]
Nodo árbitro iniciado
X
[ticket=Y]
Nodo árbitro perdido
X - proceso fallido
[estado=Y]
Lost arbitrator node
X - process exit
[state=Y]
Nodo árbitro perido
X <error msg>
[estado=Y]
STATISTICS
Eventos
Los siguientes eventos son de naturaleza estadística.
Proporcionan información tal como números de transacción y
otras operaciones, cantidad de datos enviados o recibidos por
nodos individuales, y uso de memoria.
Evento
Prioridad
Nivel de severidad
Descripción
Reporta estadísticas de planificación de trabajos
9
INFO
Estadísticas de planificación de trabajos internos
Número de bytes enviados
9
INFO
Número de bytes enviados al nodoX
Recibidos # bytes
9
INFO
Número de bytes recibidos del nodo X
Reporte de estadísticas de transacción
8
INFO
Número de: transacciones, commits, lecturas, lecturas simples,
escrituras, operaciones concurrentes, información de
atributos, y abortos
Operaciones de reporte
8
INFO
Número de operaciones
Creación de tabla de reportes
7
INFO
Uso de memoria
5
INFO
Uso de datos e índices (80%, 90% y 100%)
ERROR
Eventos
Estos eventos están relacionados con errores y advertencias
del cluster; la presencia de uno o más de ellos indica
generalmente que un fallo importante ha ocurrido.
Evento
Prioridad
Severidad
Descripción
Muerte debida a un heartbeat fallido
8
ALERT
Nodo X declarado “dead” debido a
un heartbeat fallido
Errores de transporte
2
ERROR
Advertencias de transporte
8
WARNING
Heartbeats perdidos
8
WARNING
Nodo X ha perdido el heartbeat
#Y
Eventos de advertencia generales
2
WARNING
INFO
Eventos
Estos eventos proporcionan información general sobre el
estado del cluster y actividades asociadas con el
mantenimiento del mismo, tales como logueo y transmisión de
heartbeat .
Evento
Prioridad
Severidad
Descripción
Heartbeat enviado
12
INFO
Heartbeat enviado a nodo X
Bytes de log creado
11
INFO
Parte de log, fichero de log, MB
Eventos de información general
2
INFO
16.6.3. Modo de usuario único
El modo de usuario único permite al administrador de la base de
datos restringir el acceso al sistema de base de datos a un
único servidor MySQL (nodo SQL): Al entrar en el modo de
usuario único todas las conexiones a todos los otros servidores
MySQL se cierran y todas las transacciones en ejecución se
abortan. No se permiten nuevas transacciones.
Una vez que el cluster ha entrado en modo de usuario único,
sólo el nodo SQL designado tiene acceso a la base de datos.
Puede usar el comando all status para ver si
el cluster ha entrado en este modo.
Ejemplo:
NDB> ENTER SINGLE USER MODE 5
Tras la ejecución de este comando y que el cluster entre en
modo de usuario único, el nodo SQL cuyo ID de nodo es
5 pasa a ser el único usuario permitido del
cluster.
El nodo especificado en el comando superior debe ser un nodo
MySQL Server ; Un intento de especificar cualquier otro tipo de
nodo se rehusará.
Nota: Cuando se invoca el
comando anteior, todas las transacciones en ejecución en el
nodo designado se abortan, la conexión se cierra y el servidor
debe reiniciarse.
El comando EXIT SINGLE USER MODE cambia el
estado de los nodos del datos del cluster de modo de usuario
único a modo normal. Los servidores MySQL esperando conexiones
(esto es, a que el cluster pase a estar preparado y disponible),
pueden conectarse: El servidor MySQL denotado como el nodo de
usuario único SQL continúa ejecutándose (si todavía está
conectado) durante y tras el cambio de estado.
Ejemplo:
NDB> EXIT SINGLE USER MODE
La forma recomendada de tratar un fallo de nodo al ejecutar el
modo de usuario único es una de las siguientes:
Terminar todas las transacciones de modo de usuario
único.
Ejecutar el comando EXIT SINGLE USER
MODE
Reiniciar los nodos de datos del cluster
or
Reinicia los nodos de base de datos antes de entrar en modo
de usuario único.
16.6.4. Copias de seguridad On-line para MySQL Cluster
Esta sección describe cómo crear una copia de seguridad y
cómo restaurar la base de datos de una copia de seguridad
posteriormente.
16.6.4.1. Conceptos de copias de seguridad de nodos
Una copia de seguridad es una fotografía de la base de datos
en un momento dado. La copia de seguridad tiene tres partes
principales:
Metadatos: nombres y
definiciones de todas las tablas de la base de datos.
Registros de tabla: los
datos guardados realmente en las tablas de la base de
datos cuando se hizo la copia de seguridad
Log de transacción: un
registro secuencial diciendo cómo y cuándo se han
almacenado los datos en la base de datos.
Cada uno de ellos se guarda en todos los nodos participantes
en la copia de seguridad. Durante la copia de seguridad cada
nodo guarda estas tres partes en tres ficheros en disco:
BACKUP-<BackupId>.<NodeId>.ctl
Un fichero de control con información de control y
metadatos. Cada nodo guarda las mismas definiciones de
tabla (para todas las tablas en el cluster) en su propia
versión de este fichero.
BACKUP-<BackupId>-0.<NodeId>.data
Un fichero de datos conteniendo los registros de tabla,
que se guardan en fragmentos; esto es, distintos nodos
guardan distintos fragmentos durante la copia de
seguridad. El fichero guardado por cada nodo comienza con
una cabecera que explica a qué tabla pertenencen los
registros. A continuación de la lista de registros, hay
un pie que contiene un checksum de los registros.
BACKUP-<BackupId>.<NodeId>.log
Un fichero de log con registros de transacciones
finalizadas. Sólo las transacciones de tablas guardadas
en la copia de seguridad se guardan en el log. Los nodos
involucrados en la copia de seguridad guardan distintos
registros, ya que distintos nodos guardan distintos
fragmentos de base de datos.
En la tabla anterior
<BackupId> es el
identificador de la copia de seguridad y
<NodeId> es el identificador
único para el nodo que crea el fichero.
16.6.4.2. Usar el servidor de administración para crear una copia de seguridad
Antes de iniciar una copia de seguridad, asegúrese que el
cluster está debidamente configurado para ello. (consulte
Sección 16.6.4.4, “Configuración para copias de seguridad de un nodo”.)
Para crear una copia de seguridad usando el servidor de
administración implica los siguientes pasos:
Arrancar el servidor de administración
(ndb_mgm).
Ejecutar el comando START BACKUP.
El servidor de administración responderá con el mensaje
“Start of backup ordered”.
Esto significa que el servidor de administración ha
enviado la petición al cluster, pero no ha recibido
respuesta aun.
El servidor de administración responderá
“Backup
<BackupId>
started”, donde
<BackupId> es el
identificador único para esta copia de seguridad. (Este
ID se guardará en el log del cluster, si no ha sido
configurado de otro modo.) Esto significa sólo que el
cluster ha recibido y procesado la petición de copia de
seguridad. Esto no significa que se
haya completado.
El servidor de administración envía la señal que la
copia ha finalizado con el mensaje “Backup
<BackupId>
completed”.
Es posible iniciar la copia de seguridad de la shell del
sistema usando
shell> ndb_mgm -e "START BACKUP"
Para abortar una copia en marcha:
Arranque el servidor de administración.
Ejecute el comando 'ABORT BACKUP
<BackupId>'. El
número <BackupId> es el
identificador de la copia que se incluyó en la respuesta
del servidor de administración cuando se inició la copia
(en el mensaje '"Backup
<BackupId>
started"').
El servidor de administración reconocerá la petición de
aborto con “Abort of backup
<BackupId>
ordered”; tenga en cuenta que no se ha
recibido todavía respuesta a esta petición.
Una vez que la copia de seguridad se ha abortado, el
servidor de administración reportará
“Backup
<BackupId> has been
aborted for reason
msg”. Esto
significa que el cluster ha terminado la copia y que todos
los ficheros relacionados con la misma se han eliminado
del sistema de ficheros del cluster.
Es posible abortar una copia de seguridad en curso desde el
shell de sistema usando este comando:
shell> ndb_mgm -e "ABORT BACKUP BackupId"
Nota: Si no hay una copia con
ID <BackupId> en ejecución
cuando se aborta, el servidor de administración no hace
ninguna respuesta explícita. Sin embargo, el hecho que se
envió un comando de aborto incorrecto se indica en el log del
cluster.
16.6.4.3. Cómo restablecer una copia de seguridad de un nodo
El programa de restauración del cluster se implementa como
utilidad de línea de comandos separada
ndb_restore, que lee los ficheros creados
por la copia de seguridad e inserta la información almacenada
en la base de datos. El programa de restauración debe
ejecutarse una vez para cada conjunto de ficheros de la copia,
esto es, tantas veces como nodos había cuando se creo la
copia.
La primera vez que ejecute el programa de restauración,
necesita restaurar los metadatos; en otras palabras, debe
recrear las tablas de la base de datos. (Tenga en cuenta que
el cluster debe tener una base de datos vacía cuando empieza
a restaurar una copia de seguridad.) El program de
restauración actúa como una API contra el cluster y por lo
tanto necesita una conexión libre para conectar al cluster.
Esto puede verificarse con el comando
ndb_mgmSHOW (o desde
una shell de sistema usando ndb_mgm -e
SHOW). La opción -c
<connectstring>
puede usarse para localizar el nodo MGM (consulte
Sección 16.4.4.2, “El connectstring de MySQL Cluster” para
información acerca de connectstrings). Los ficheros de la
copia de seguridad deben estar presentes en el directorio dado
como argumento al programa de restauración.
Es posible restaurar una copia de seguridad a una base de
datos con una configuración distinta a la que tenía en el
momento de su creación. Por ejemplo, suponga que una copia de
seguridad con ID 12,se creó en un cluster
con dos nodos de base de datos con los IDs de nodo
2 y 3, se restaura en un
cluster con cuatro nodos. Entonces
ndb_restore debe ejecutarse dos veces
— una por cada nodo de base de datos en el cluster donde
se hizo la copia de seguridad.
Nota: Para una restauración
rápida, los datos pueden restaurarse en paralelo, dado que
haya una cantidad de conexiones de cluster disponibles. Sin
embargo, los ficheros de datos deben siempre aplicarse antes
que los logs.
16.6.4.4. Configuración para copias de seguridad de un nodo
Hay cuatro parámetros de configuración esenciales para una
copia de seguridad:
BackupDataBufferSize
Cantidad de memoria usada para buffer de los datos antes
de escribir en disco.
BackupLogBufferSize
Cantidad de memoria usada para buffer de registros de lob
antes de escribir en disco.
BackupMemory
Memoria total reservada en un nodo de base de datos para
copia de seguridad. Debe ser la suma de memoria reservada
para el buffer de datos y el de log.
BackupWriteSize
Tamaño de los blocks escritos en disco. Esto se aplica
tanto para el buffer de datos como para el de log.
16.6.4.5. Resolver problemas con copias de seguridad
Si se retorna un código de error al hacer una petición de
copia de seguridad la causa más probable es memoria
insuficiente o espacio de disco insuficiente. Debe chequear
que hay suficiente memoria reservada para la copia de
seguridad. También que hay espacio suficiente en la
partición del disco duro.
En MySQL 5.0, NDB no soporta lecturas
repetibles, que puede causar problemas en el proceso de
restauración. Mientras que el proceso de copia de seguridad
es“hot”, restaurar un MySQL Cluster desde una
copia de seguridad no es un proceso 100% “hot” .
Esto se debe a que, por la duración del proceso de
restauración, las transacciones en ejecución obtienen
lecturas no repetibles de los datos restaurados. Esto
significa que el estado de los datos es incosistente mientras
que la restauración está en marcha.
16.7. Usar interconexiones de alta velocidad con MySQL Cluster
Antes que comenzara el diseño de NDB Cluster
en 1996, era evidente que uno de los mayores problemas que
encontraríamos al construir bases de datos paralelas sería la
comunicación entre los nodos de la red. Por esta razón,
NDB Cluster se diseñó desde el comienzo para
permitir el uso de un número de mecanismos de transporte
distintos. En este manual, usamos el término
transporter para ello.
Actualmente el código MySQL Cluster incluye soporte para 4
transportes distintos. La mayoría de usuarios usan TCP/IP sobre
Ethernet ya que es ubicuo. Este también es el transporter más
probado en MySQL Cluster.
Estamos trabajando para asegurar que la comunicación con el
proceso ndbd se hace en “chucnks”
tan grandes como sea posible ya que esto beneficia a todos los
tipos de transimisión de datos.
Para los usuarios que lo deseen, también es posible usar
interconexión de cluster para mejorar el rendimiento. Hay dos
formas de hacerlo: puede diseñar un transporter a medida o puede
usar implementaciones de socket que sobrepasen la pila TCP/IP de
una forma u otra. Hemos expermientando con ambas técnicas usando
la tecnología SCI (Scalable Coherent Interface) desarrollada por
Dolphin.
16.7.1. Configurar MySQL Cluster para que utilice Sockets SCI
En esta secció mostraremos cómo se puede adaptar un cluster
configurado para comunicación TCP/IP normal para que use SCI
Sockets. Esta documentación se basa en SCI Sockets versión
2.3.0 de 01 Octubre 2004.
Prerequisitos
Cualquier máquina que quiera que use SCI Sockets necesita
disponer de tarjetas SCI .
Es posible usar SCI Sockets con cualquier versión de MySQL
Cluster. No se necesita ninguna compilación especial ya que usa
llamadas de socket normales que están disponibles en MySQL
Cluster. Sin embargo, SCI Sockets se soportan sólo en los
kernels Linux 2.4 y 2.6 . SCI Transporters se ha probado con
éxito en sistemas operativos adicionales aunque sólo lo hemos
verificado con Linux 2.4 hasta ahora.
Esencialmente hay cuatro requerimientos para SCI Sockets:
Compilar las bibliotecas SCI Socket.
Instlara las bibliotecas del kernel SCI Socket.
Instalación de uno o dos ficheros de configuración.
La biblioteca de kernel SCI Socket debe estar activada
para toda la máquina o para la shell en que se arranca el
proceso MySQL Cluster.
Este proceso debe repetirse para cada máquina del cluster en
que quiera usar SCI Sockets para comunicación entre nodos.
Necesita dos paquetes para que funcione SCI Sockets :
El paquete de código fuente con las bibliotecas de
soporte DIS para las bibliotecas SCI Sockets .
El paquete de código fuente para las bibliotecas SCI
Socket mismas.
Actualmente, estan disponible sólo en formato de código
fuente. Las últimas versiones de estos paquetes al escribir
esto están disponibles como (respectivamente)
DIS_GPL_2_5_0_SEP_10_2004.tar.gz y
SCI_SOCKET_2_3_0_OKT_01_2004.tar.gz.
Debería poder encontrar estas versiones (o posteriores) en
http://www.dolphinics.no/support/downloads.html.
Instalación de paquetes
Una vez que tiene los paquetes con las bibliotecas, el siguiente
paso es descomprimirlas en los directorios apropiados, con la
biblioteca SCI Sockets en un directorio bajo el código DIS.
Luego, necesita compilar las bibliotecas. Este ejemplo muestra
los comandos usados en Linux/x86 para realizar esta tarea:
shell> tar xzf DIS_GPL_2_5_0_SEP_10_2004.tar.gz
shell> cd DIS_GPL_2_5_0_SEP_10_2004/src/
shell> tar xzf ../../SCI_SOCKET_2_3_0_OKT_01_2004.tar.gz
shell> cd ../adm/bin/Linux_pkgs
shell> ./make_PSB_66_release
Es posible compilar estas bibliotecas para algunos procesadores
64-bit. Para compilar las bibliotecas para Opteron CPUs usando
la extensión 64-bit , ejectue
make_PSB_66_X86_64_release en lugar a
make_PSB_66_release; si la compilación se
hace en una máquina Itanium, debe usar
make_PSB_66_IA64_release. La variante X86-64
debe funcionar para arquitecturas Intel EM64T pero no se ha
probado.
Una vez que se completa el proceso de compilación ,las
bibliotecas compiladas se encuentran en un fichero tar zipeado
con un nombre entre las líneas de
DIS-<operating-system>-time-date.
Es hora de instalar el paquete en el lugar apropiado. En este
ejemplo lo guardaremos en /opt/DIS.
(Nota: Seguramente necesitará
ejecutar lo siguiente como root del sistema.)
shell> cp DIS_Linux_2.4.20-8_181004.tar.gz /opt/
shell> cd /opt
shell> tar xzf DIS_Linux_2.4.20-8_181004.tar.gz
shell> mv DIS_Linux_2.4.20-8_181004 DIS
Configuración de red
Ahora que todos los binarios y bibliotecas están en su lugar
adecuado, necesitamos asegurarnos que las tarjetas SCI tiene IDs
de nodo adecuados en el espacio de direcciones SCI.
Es necesario decidir la estructura de red antes de seguir. Hay
tres tipo de estructura de red que pueden usarse en este
contexto:
Anillo simple unidimensional
Uno o más switches con un anilo para cada puerto de switch
Un toro de dos o tres dimensiones.
Cada una de estas topologías tiene su propio método para
proporcionar Ids de nodo. Discutimos cada una de las mismas
brévemente.
Un anillo simple usa IDs de nodo que son múltipes de 4
distintos a cero: 4, 8, 12,...
La siguiente posibilidad usa swithces SCI. Un switch SCI tiene 8
puertos, cada uno de los cuales puede soportar un anillo. Es
necesario asegurarse que distintos anillos usan distintos
espacios de nombres. En una configuración típica, el primer
puerto usa IDs de nodo por debajo de 64 (4 - 60), el siguiente
puerto los siguientes 64 IDs (68 - 124) , y así, con IDs de
nodo 452 - 508 siendo asignados al octavo puerto.
Las estructuras de red de toro bi o tri dimensional se tienen en
cuenta donde cada nodo se localiza en cada dimensión,
incrementando en 4 para cada nodo en la primera dimensión, en
63 cada nodo en la segunda dimensión, y (donde sea aplicable)
en 1024 en la tercera dimensión. Consulte
Dolphin's
Web site para más documentación.
En nuestras pruebasa hemos usado switches, aunque las
instalaciones de cluster más grandes usan toros bi o tri
dimensionales. La ventaja proporcionada por switches es que, con
tarjetas SCI duales y switches duales, es posible constuir con
facilidad relativa una red redundante donde el tiempo de fallo
medio en la red SCI es del orden de 100 microsegundos. Esto lo
soporta el transporte SCI en MySQL Cluster y también está bajo
desarrollo par la implementación SCI Socket .
Evitar fallos en el toro 2D/3D es posible pero requiere el
envío de nuevos índices de enrutamiento a todos los nodos. Sin
embargo, esto requiere sólo 100 milisegundos o así para
completarse y debería ser aceptable para la mayoría de casos
de alta disponibilidad.
Situar los nodos de datos del cluster adecuadamente en la
arquitectura de switch hace que sea posible usar 2 switches para
construir una arquitectura en que puedan interconectarse 16
máquinas y que un fallo único no pueda afectar a más de una.
Con 32 máquinas y 2 switches se puede configurar el cluster de
forma que un fallo único no pueda causar la pérdida de más de
dos nodos; en este caso es posible saber qué par de nodos está
afectado. Por lo tanto, poner los dos nodos en grupos de nodos
separados hace que la instalación de MySQL Cluster sea
“segura” .
Para poner el ID de nodo en una tarjeta SCI use el siguiente
comando en el directorio /opt/DIS/sbin. En
este ejemplo -c 1 se refiere al número de la
tarjeta SCI (siempre será 1 si sólo hay 1 tarjeta en la
máquina) , -a 0 se refiere al adaptador 0, y
68 es el ID del nodo:
shell> ./sciconfig -c 1 -a 0 -n 68
Si tiene varias tarjetas SCI en la misma máquina, puede
determinar qué tarjeta tiene cada slot ejecutando el siguiente
comando (de nuevo asumimos que el directorio de trabajo actual
es /opt/DIS/sbin):
shell> ./sciconfig -c 1 -gsn
Esto le retorna el número de serie de la tarjeta SCI. Luego
repita este procedimiento con -c 2, y siga
con cada tarjeta en la máquina. Una vez que ha relacionado cada
tarjeta con cada slot, puede poner los IDs de nodo para todas
las tarjetas.
Una vez instaladas la bibliotecas y binarios necesarios, y
configurado el ID de nodo SCI, el siguiente paso es configurar
el mapeo de nombres de equipo (o direcciones IP) con el ID del
nodo SCI. Esto se realiza en el fichero de configuración de los
sockets SCI, que debería encontrarse en
/etc/sci/scisock.conf. En este fichero,
cada nombre de máquina o dirección IP se mapea con el ID de
nodo SCI. Aquí hay un ejemplo sencillo de un fichero de
configuración:
#host #nodeId
alpha 8
beta 12
192.168.10.20 16
Es posible limitar la configuración para que se aplique sólo a
un subconjunto de los puertos disponibles para estos equipos. Un
fichero de configuración adicional
/etc/sci/scisock_opt.conf puede usarse para
esto, como se muestra aquí:
Instalación de drivers
Con los ficheros de configuración en su lugar, se pueden
instalar los drivers.
Primero los drivers de bajo nivel y luego el driver del socket
SCI:
shell> cd DIS/sbin/
shell> ./drv-install add PSB66
shell> ./scisocket-install add
Si se desea, la instalación puede chequearse invocando un
script que verifica que todos los nodos en el los ficheros de
configuración del socket SCI son accesibles:
shell> cd /opt/DIS/sbin/
shell> ./status.sh
Si descubre un error y necesita cambiar la configuración del
socket SCI, es necesario usar ksocketconfig
para ello:
shell> cd /opt/DIS/util
shell> ./ksocketconfig -f
Testing y Setup
Para asegurar que los sockets SCI están siendo usados, puede
emplear el programa de testeo latency_bench .
Usando este componente del servidor de utilidades, los clientes
pueden conectar con el servidor para testear la latencia de la
conexión; determinar si el SCI está activado o no debe ser muy
simple observando la latencia.
(Nota: Antes de usar
latency_bench, es necesario incializar la
variable de entorno LD_PRELOAD como se
muestra posteriormente.)
Para inicializar un servidor, use:
shell> cd /opt/DIS/bin/socket
shell> ./latency_bench -server
Para ejecutar un cliente, use latency_bench
de nuevo, excepto que esta vez con la opción
-client :
shell> cd /opt/DIS/bin/socket
shell> ./latency_bench -client server_hostname
La configuración del socket SCI debería estar completa ahora y
MySQL Cluster preparado para usar SCI Sockets y SCI transporter
(consulte Sección 16.4.4.10, “Conexiones de transporte SCI en MySQL Cluster”).
Arrancar el Cluster
El siguiente paso en el proceso es arrancar MySQL Cluster. Para
permitir el uso de SCI Sockets es necesario inicializar la
variable de entorno LD_PRELOAD antes de
arrancar ndbd, mysqld, y
ndb_mgmd. Esta variable debe apuntar a la
biblioteca kernel para SCI Sockets.
Para arrancar ndbd en un bash shell, haga:
Nota: MySQL Cluster sólo puede
usar la variante de kernel de SCI Sockets.
16.7.2. Entender el impacto de interconexiones de nodos
El proceso ndbd tiene un número de
constructores simples que se usan para acceder a los datos en
MySQL Cluster. Hemos creado un benchmark sencillo para comprobar
el rendimiento de cada uno de ellos y los efectos en el
rendimiento de varias interconexiones.
Hay cuatro métodos de acceso:
Acceso por clave primaria
Este es el acceso simple a un registro a través de su clave
primaria. Es el caso más sencillo en que sólo se accede a
un registro a la vez, que significa que el coste total de
preparar un número de mensajes TCP/IP y un número de
costes para cambio de contexto se envían mediante esta
simple petición. En el caaso en que se envían accesos a
varias claves primarias en un proceso batch estos accesos
comparten el coste de preparar los mensajes TPC/IP
necesarios y los cambios de contexto. Si los mensajes TCP/IP
son para destinaciones distintas, se debe preparar mensajes
adicionales.
Acceso por clave única
Son similares a los anteriores, con la excepción que los
accesos por clave única se ejecutan como lecturas en una
tabla índice seguidos por su acceso por clave primaria a la
tabla. Sin embargo, sólo se envía una petición desde el
servidor MySQL, y la lectura de la tabla índice es tratada
por ndbd. Estas peticiones también se
benefician del uso de batch.
Escaneo de toda la tabla
Cuando no existen índices para la búsqueda en una tabla,
se realiza un escaneo completo. Se envía como petición
úncia al proceso ndbd , que divide el
escaneo de tabla en un conjunto de escaneos paralelos en
todos los procesos ndbd del proceso. En
futuras versiones de MySQL Cluster, un nodo SQL será capaz
de filtrar algunos de estos escaneos.
Escaneo de rangos usando índices
ordenados
Cuando se usa un índice ordenado, realiza un escaneo igual
que lo hace un escaneo de tabla completo, excepto que
escanea sólo los registros en el rango usados por la
consulta transmitidas por el MySQL server (nodo SQL).
Para chequear el rendimiento base de estos métodos de acceso
hemos desarrollado un conjunto de benchmarks. Uno de ellos
testReadPerf, testea accesos simple y en
batch por clave primaria y única. Este benchmark también mide
el coste de preparar los escaneos de rango ejecutando escaneos
que retornan un único registro. Hay una variante de este
benchmark que usa un escaneo de rango para recibir un batch de
registros.
De este modo, podemos determinar el coste de accesos de clave
única y accesos de escaneo de registro simple, así como medir
el impacto del medio de comunicación usdo, en métodos de
acceso base.
En nuestros tests, ejecutamos los benchmarks para transporters
normales usando sockets TCP/IP sockets y una configuración
similar usando sockets SCI. Las figuras posteriores son
pequeños accesos de 20 registros por acceso. Las diferencias
entre accesos seriales y mediante batch se decrementan en un
factor de 3 a 4 usando registros de 2 kB. SCI Sockets no se
testearon con registros de 2 kB. Los tests se realizaron en un
cluster con 2 nodos de datos en 2 máquinas de CPU dual
equipadas con procesadores AMD MP1900+ .
También realizamos otro conjunto de tests para chequear el
rendimiento de los SCI Sockets vis-à-vis contra el SCI
transporter, y ambos comparados con el TCP/IP transporter. Todos
estos tests usaron acceso por clave primaria de forma serial o
multi-flujo, o multi-flujo y batch.
Los tests mostraron que los sockets SCI eran 100% más rápido
que TCP/IP. El transporter SCI era más rápido en la mayoría
de casos comparado con los sockets SCI. Un caso notable
ocurrión con muchos flujos en el programa de test, que mostró
que el tramporter SCI no funcionaba muy bien usado por el
proceso mysqld.
Nuestra conclusión global fue que, para la mayoría de
benchmarks, usando sockets SCI mejoraba el rendimiento
aproximadamente 100% sobre TCP/IP, excepto en raros casos cuando
el rendimiento de la configuración no es un tema importante.
Esto puede ocurrir cuando los filtros de escaneo toman la
mayoría del tiempo de proceso o cuando los procesos batchs muy
grandes de accesos por clave primaria se realizan. En tal caso,
el proceso de la CPU en los procesos ndbd es
la mayor parte del proceso.
Usar el transporter SCI en lugar de SCI Sockets sólo es de
interés en comunicación entre procesos
ndbd. Usar el SCI transporter también es
sólo de interés si una CPU puede dedicarse al proceso
ndbd ya que el SCI transporter se asegura que
su proceso nunca estará en espera. Es importante asegurar que
la prioridad del proceso ndbd está
configurada de tal modo que el proceso no pierde prioridad
debido a ejecutarse durante un periodo de tiempo extendido, como
puede pasar por bloqueo de procesos por la CPU en Linux 2.6. Si
tal configuración es posible, entonces el proceso
ndbd se beneficiará de un 10-70% comparado
con usar SCI sockets. (Las diferencias más grandes se verán al
realizar actualizaciones y probablemente en escaneos paralelos
también
Hay otras implementaciones de socket para clusters de máquinas,
incluyendo Myrinet, Gigabit Ethernet, Infiniband y la interfaz
VIA . Hemos testeado MySQL Cluster hasta ahora sólo con SCI
sockets.También incluímos documentación acerca de cómo
preparar SCI sockets usando TCP/IP ordinario para MySQL Cluster.
16.8. Limitaciones conocidas de MySQL Cluster
En esta sección, proporcionamos un listado de las limitaciones
conocidas en versiones de MySQL Cluster en las series 4.1.x
comparadas con características disponibles al usar los motores
MyISAM e InnoDB. Actualmente, no hay planes para arreglarlas en
próximas versiones 4.1; sin embargo, intentaremos proporcionar
soluciones para éstas en MySQL 5.0 y versiones posteriores. Si
chequea la categoría de Cluster en la base de datos de bug de
MySQL en http://bugs.mysql.com, encontrará bugs
conocidos que (si están marcados como 4.1) intentaremos arreglar
en próximas versiones de MySQL 4.1.
No cumplimiento de la
sintaxis (resultando en errores al ejecutar
aplicaciones existentes):
No se soportan todos los conjuntos de caracteres y
colaciones.
No hay índices prefijo; sólo los campos completos pueden
indexarse.
Los índices de texto no están soportados.
Tipos de datos geométricos (WKT y WKB) no soportados.
No cumplimiento con
límites/comportamiento (puede resultar en errores
al ejecutar aplicaciones existentes):
No hay rollback parcial de transacciones. Una clave
duplicada o error similar resultará en un rollback de la
transacción completa.
Existen un número de límites de hard que son
configurables, pero la memoria disponible en el cluster
delimite al límite. Consulte la lista completa de
parámetros de configuración en
Sección 16.4.4, “Fichero de configuración”. La mayoría
de parámetros de configuración pueden actualizarse en
línea. Estos límites de hard incluyen:
Tamaño de memoria de base de datos y de memoria
índice (DataMemory y
IndexMemory, respectivamente).
El máximo número de transacciones que pueden
ejecutarse se delimita mediante el parámetro
MaxNoOfConcurrentOperations. Tenga
en cuenta que la cantidad de carga , TRUNCATE
TABLE, y ALTER TABLE se
tratan como casos especiales mediante ejecución de
transacciones múltiples, y por lo tanto no están
sujetas a esta limitación.
Los distintos límites relacionados con tablas e
índices. Por ejemplo, el número máximo de índices
ordenados por tabla lo determina
MaxNoOfOrderedIndexes.
Los nombres de bases de datos, tablas y atributos no
pueden ser tan largos en NDB como con otros motores. Los
nombres de atributos se truncan a 31 caracteres, y si no
son únicos tras truncarse da lugar a error. Los nombres
de base de datos y de tabla pueden tener en total un
máximo de 122 caracteres. (Esto es, la longitud máxima
para un nombre de tabla en un cluster NDB es 122
caracteres menos el número de caracteres en el nombre
de la base de datos de la tabla.)
En MySQL 4.1 y 5.0, todos los registros de tabla de
Cluster son de longitud fija. Esto significa (por ejemplo)
que si una tabla tiene uno o más campos
VARCHAR conteniendo sólo valores
pequeños, serán necesarios más memoria y espacio de
disco al usar el motor NDB que el que sería para la misma
tabla y datos usando el motor MyISAM. Estamos trabajando
para rectificar este punto en MySQL 5.1.
El máximo número de objetos de metadatos está limitado
a 1600, incluyendo tablas de base de datos, tablas de
sistema, índices y BLOBs. Estamos trabajando para
incrementar esto a aproximadamente 20k en MySQL 5.0.
El máximo número de atributos por tabla está limitado a
128.
El tamaño máximo permitido de registro es 8k, sin
incluir datos almacenados en columnas BLOB. Esperamos
incrementar esto a aproximadamente 32k en MySQL 5.1.
El máximo número de atributos por clave es 32.
Características no
soportadas (no causan errores, pero no están
soportadas o forzadas):
El constructor de clave primaria se ignora, como en tablas
MyISAM .
Los puntos de chequeo y rollbacks se ignoran como en
MyISAM.
Rendimiento y temas relacionados con
limitaciones :
La caché de consulta está desactivada, ya que no está
invalidad si ocurre una actualización en distintos
servidores MySQL.
Hay temas de rendimiento de consulta debido a acceso
secuencial al motor NDB; también es relativamente más
costoso hacer varios escaneos de rango que con MyISAM o
InnoDB.
La estadística Records in range no
está soportada, resultando en planes de consulta no
óptimos en algunos casos. Use USE
INDEX o FORCE INDEX como
solución.
Índices hash únicos creados con USING
HASH no pueden usarse para acceder a una tabla
si NULL se da como parte de la clave.
Caracterísitcas no
incluídas:
El único nivel de isolación soportado es
READ_COMMITTED. (InnoDB soporta
READ_COMMITTED,
REPEATABLE_READ, y
SERIALIZABLE.) Consulte
Sección 16.6.4.5, “Resolver problemas con copias de seguridad”
para información sobre cómo puede afectar a las copias
de seguridad y restauración de bases de datos Cluster.
Commits no durables en disco. Los commits se replican,
pero no hay garantía que los logs se vuelquen a disco en
un commit.
Problemas relacionados con múltiples
MySQL servers (no relacionados con MyISAM o
InnoDB):
ALTER TABLE no es completamente
bloqueante cuando se ejecutan múltiples MySQL servers (no
hay bloqueo de tabla distribuído).
La replicación MySQL no funcionará correctamente si las
acutalizaciones se hacen en múltiples MySQL servers. Sin
embargo, si el esquema de particionado de la base de datos
es en nivel de aplicación, y no hay transacciones entre
estas particiones, la replicación puede funcionar.
El autodescubrimiento de bases de datos no se soporta para
múltiples MySQL servers accediendo al mismo MySQL
Cluster. Sin embargo, el autodescubrimiento de tablas se
soporta en estos casos. Lo que significa que si tras una
base de datos llamada db_name
se crea o importa usando un MySQL server, debe ejecutar un
CREATE DATABASE
db_name; en cada
MySQL server adicional que accede al mismo MySQL Cluster.
(Desde MySQL 5.0.2 puede usar CREATE SCHEMA
db_name;.) Una vez
hecho esto para un MySQL server dado, el servidor debería
ser capaz de detectar las tablas de la base de datos sin
error.
Temas exclusivos de MySQL
Cluster (no relacionados con MyISAM o InnoDB):
Todas las máquinsa usadas en el cluster deben tener la
misma arquitectura; esto es, todas las máquinas con nodos
deben ser o big-endian o little-endian, y no puede usar
una mezcla. Por ejemplo, no puede tener un nodo de
administración ejecutándose en un PPC con un nodo datos
en una máquina x86 . Esta restricción no se aplica a
máquinas que ejecuten sólo mysql u
otros clientes que puedan estar accediendo a los nodos SQL
del cluster.
No es posible hacer cambios del esquema en línea tales
como los realizados usando ALTER TABLE
o CREATE INDEX, ya que NDB Cluster no
soporta autodescubrimiento de tales cambios. (Sin embargo,
puede importar o crear una tabla que use distintos
motores, convertirlos a NDB usando ALTER TABLE
tbl_name
ENGINE=NDBCLUSTER;. En tales casos, necesitará
ejecutar un comando FLUSH TABLES para
forzar al cluster a recoger los cambios.)
Añadir o eliminar nodos en línea no es posible (el
cluster debe reiniciarse en tales casos).
Cuando se usan múltiples servidores de administración
debe dar a los nodos explícitamente los IDs en los
connectstrings ya que la reserva automática de IDs de
nodo no funciona entre múltiples servidores de
administración.
Usando varios servidores de administración debe tener
cuidado de tener la misma configuración para todos los
servidores de administración. El cluster no hace chequeos
para ello.
El número máximo de nodos de datos es 48.
El número máximo de nodos en MySQL Cluster es 63. Este
número incluye todos los MySQL Servers (nodos SQL), nodos
de datos, y servidores de administración.
Este listado trata de ser completo respecto al conjunto de
condiciones del principio de esta sección. Puede reportar
cualquier discrepancia que encuentre a la base de datos de bugs de
MySQL en http://bugs.mysql.com/. Si no planeamos arreglar el
problema n MySQL 4.1, lo añadiremos a la lista anterior.
En esta sección, discutimos los cambios en la implementación de
MySQL Cluster en MySQL 5.0 comparadas con MySQL 4.1. También
discutiremos nuestra planificación para futuras mejoras en MySQL
Cluster planeadas para MySQL 5.1.
En el pasado hemos recomendado que los usuarios de MySQL Cluster
no usen la versión 5.0 de MySQL ya que MySQL Cluster en las
series 5.0.x no estaba completamente testeada. A partir de MySQL
5.0.3-beta la funcionalidad de clustering de MySQL 5.0 es
comparable a la de MySQL 4.1. MySQL 4.1 es la recomendada para
producción por ahora; sin embargo, MySQL 5.0 es de alta calidad
también, y le animamos a testear Cluster en MySQL 5.0 si piensa
que está interesado en usarla cuando enter en producción a
finales de 2005. Hay pocos cambios entre implementaciones NDB
Cluster en MySQL 4.1 y en 5.0, así que la actualización es
relativamente sencilla y rápida.
Desde que MySQL 5.0.3-beta está disponible, casi todas las nuevas
características significativas desarrolladas para MySQL Cluster
van al árbol de MySQL 5.1 . Proporcionamos algunas pistas acerca
de lo que Cluster en MySQL 5.1 incluirá en el final de esta
sección (consulte Sección 16.9.2, “Mapa de desarrollo de MySQL 5.1 para MySQL Cluster”).
16.9.1. Cambios de MySQL Cluster en MySQL 5.0
MySQL 5.0.3-beta y posterior contiene un número de nuevas
características que son de interés:
Condiciones Push-Down: Una
consulta como
SELECT * FROM t1 WHERE non_indexed_attribute = 1;
usará un escaneo de toda la tabla y la condición se
evaluará en los nodos de datos del cluster. Por lo tanto no
es necesario enviar el registro a la red para evaluación.
(Esto es, la transporte de función se usa, en lugar del
transporte de datos.) Para este tipo de consultas debe
observar un factor de incremento de velocidad de 5-10. Tenga
en cuenta que esta característica actualmente está
desactivada por defecto (pendiente de más testeo), pero
debería funcionar en la mayoría de casos. Esta
característica puede estar activada mediante el comando
SET engine-condition-pushdown=On; .
Alternativamente, puede ejecutar mysqld
con esta característica activada arrancando MySQL server
con la nueva opción
--engine-condition-pushdown.
Puede usar EXPLAIN para determinar
cuándo se usan las condiciones push-down .
Un beneficio principal de este cambio es que las consultas
se ejecutan en paralelo. Esto significa que las consultas
contra columnas no indexadas pueden mejorar de 5 a 10 veces,
veces por el número de nodos de datos,
más rápido que préviamente, ya que CPUs múltiples pueden
funcionar en la consulta en paralelo.
Decrementado uso de
IndexMemory: En MySQL 5.0,
cada registro consume aproximadamente 25 bytes de memoria
índice, y cada índice único usa 25 bytes por registro de
memoria índice (además de alguna memoria de datos ya que
se almacena en una tabla separada). Esto es porque no hay
almacenamiento de la clave primaria en la memoria índice.
Nuevas optimizaciones: Una
optimización que merece atención particular es que una
interfaz de lectura batch se usa ahora en algunas consultas.
Por ejemplo, considere la siguiente consulta:
SELECT * FROM t1 WHERE primary_key IN (1,2,3,4,5,6,7,8,9,10);
Esta consulta se ejecutará 2 o 3 veces más rápido que en
versiones anteriores de MySQL Cluster debido al hecho que
todas las 10 búsquedas de clave se envían en un batch
único en lugar de uno cada vez.
Límite en número de objetos de
metadatos : En MySQL 4.1, cada base de datos de
Cluster puede contener un máximo de 1600 objetos de
metadatos, incluyendo tablas de base de datos, tablas de
sistema, índices y BLOBs. En MySQL 5.0, esperamos
incrementar este número a 20,320. Esperamos implementar
esta mejora en MySQL 5.0.6 beta a mediados de 2005.
16.9.2. Mapa de desarrollo de MySQL 5.1 para MySQL Cluster
Aquí se habla de un reporte de estado basado en recientes
commits en el árbol fuente MySQL 5.1 . Debería tenerse en
cuenta que todo el desarrollo 5.1 está sujeto a cambio.
Actualmente hay 4 nuevas funcionalidades mayores en desarrollo
para MySQL 5.1:
Integración de MySQL Cluster con
MySQL Replication: Esto hará posible actualizar
desde cualquier MySQL Server en el cluster y tener MySQL
Replication tratada por uno de los MySQL Servers en el
cluster y la instalación de un esclavo consistente.
Soporte para registros basados en
disco: Los registros en disco se soportarán. Los
campos índice incluyendo el índice hash de clave primaria
debe almacenarse en RAM pero todos los otros campos pueden
estar en disco.
Registros de tamaño
variable: Una columna definida como
VARCHAR(255) actualmente usa 260 bytes de
almacenamiento independiente de lo que se almacena en un
registro particular. En tablas MySQL 5.1 Cluster sólo la
porción del campo tomada por el registro se almacena. Esto
hará posible una reducción de los requerimientos de
espacio para tales columnas por un factor de 5 en muchos
casos.
Partición definida por el
usuario: Los usuarios serán capaces de definir
particiones basadas en las partes de los campos de la clave
primaria. El MySQL Server será capaz de descubrir si es
posible de eliminar algunas de las particiones de la
cláusula WHERE . La partición basada en
KEY, HASH,
RANGE, y LIST será
posible, así como subparticiones. Esta característica debe
estar disponible para otros criterios.
Además, estamos trabajando para incrementar el límite de
tamaño de 8k para los registros que contienen columnas de tipos
distintos a BLOB o TEXT en tablas cluster. Esto es debido al
hecho que los registros están fijados en tamaño y el tamaño
de página es de 32,768 bytes (menos 128 bytes para la cabecera
del registro.) Esto significa actualmente que si permitimos más
de 8k por registro, cualquier espacio que quede (hasta
aproximandamente 14,000 bytes) quedaría vacío. En MySQL 5.1,
planeamos para arreglar esta limitación para que use más de 8k
en un registro dado no resulta en que se gaste lo que queda de
la página.
16.10. Preguntas frecuentes sobre MySQL Cluster
¿Qué diferencia hay entre usar cluster y
replicación?
En una replicación, un servidor maestro MySQL actualiza uno o
más esclavos. Las transacciones hacen commit secuencialmente,
y una transacción lenta puede causar que el esclavo quede
desactualizado. Esto significa que si falla el maestro, es
posible que el esclavo pueda no haber registrado las últimas
transacciones. Si un motor transaccional como InnoDB se usa,
una transacción será completa en el esclavo o no aplicada en
absoluto, pero la replicación no garantiza que todos los
datos en el maestro y el esclavo sean consistentes siempre. En
MySQL Cluster,todos los nodos de datos con un commit hecho por
algun nodo de datos se realiza un commit para todos los nodos.
En caso de un fallo de un nodo de datos, todos los nodos de
datos restantes quedarán en un estado consistente.
En breve, mientras que la replicación estándar MySQL es
asíncrona, MySQL Cluster es síncrono.
Planeamos implementar replicación asíncrona para Cluster en
MySQL 5.1. Esto incluye la capacidad de replicar entre dos
cluster y entre un cluster MySQL y un MySQL server no cluster.
¿Necesito hacer alguna configuración especial de
red para el Cluster? (¿Cómo se comunican las máquinas en un
cluster?)
MySQL Cluster está pensado para usarse en un entorno de gran
ancho de banda, con máquinas conectadas via TCP/IP. Su
rendimiento depende directamente en la velocidad de conexión
entre las máquinas del cluster. Los requerimientos de
conectividad mínimo para cluster incluyen una red típica
100-megabit Ethernet o equivalente. Recomendamos usar Ethernet
cuando sea posible.
También se soporta el protocolo SCI (más rápido), pero
necesita hardware especial. Consulte
Sección 16.7, “Usar interconexiones de alta velocidad con MySQL Cluster” para más
información acerca de SCI.
¿Cuántas máquinas necesito para ejecutar un
cluster, y porqué?
Como mínimo se necesitan tres máquinas. Sin embargo, el
número mínimo recomendado
en MySQL Cluster es cuatro: una para el nodo de
administración y otra para el de SQL, y dos para servir como
nodos de almacenamiento. El propósito de los dos nodos de
datos es proporcionar redundancia; el nodo de administración
debe ejecutarse en una máquina separada para garantizar
servicio de arbitración contínuo en caso que un nodo de
datos falle.
¿Qué hacen las distintas máquinas en un
cluster?
Un MySQL Cluster tiene organización física y lógica, con
máquinas como elementos físicos. Los elementos lógicos son
los nodos, y una máquina
hospedando un nodo es un huesped
cluster. Idealmente, habrá un nodo por huesped
cluster, aunque es posible ejecutar más de un nodo en una
máquina. Hay tres tipos de nodos, cada uno correspondiente a
un rol específico en el cluster. Son:
nodo de administración (nodo MGM)
: Proporciona servicios de administración para
todo el cluster, incluyendo arranque, parada, copias de
seguridad, y datos de configuración en otros nodos. El
nodo de administración se implementa como la aplicación
ndb_mgmd; el cliente de administración
usado para controlar MySQL Cluster via nodo MGM es
ndb_mgm.
nodo de datos: Almacena y
replica datos. La funcionalidad de los nodos de datos la
trata una instancia del proceso NDB
ndbd.
nodo SQL: Símplemente es
una instancia de MySQL Server (mysqld)
arrancado con la opción --ndb-cluster.
¿Qué sistemas operativos pueden usar
Cluster?
En MySQL 5.0, MySQL Cluster se soporta oficialmente en Linux,
Mac OS X, y Solaris. Estamos trabajando para añadir soporte a
cluster para otras plataformas, incluyendo Windows, y nuestra
finalidad es eventualmente ofrecer MySQL Cluster en todas las
plataformas en que se soporta MySQL .
Puede ser posible ejecutar procesos Cluster en otros sistemas
operativos. Hemos tenido reportes de usuarios que dicen que
han ejecutado Cluster en FreeBSD. Sin embargo, Cluster en
cualquier plataforma que no sen las 3 mencionadas aquí se
considera software alfa (como mucho), no puede garantizarse el
buen funcionamiento en un entorno de producción, y
no lo soporta MySQL AB.
¿Cuáles son los requerimientos de hardware para
ejecutar MySQL Cluster?
Cluster debe ejecutarse en cualquier plataforma en que los
binarios de NDB estén disponibles. Naturalmente, una CPU más
rápida y más memoria mejora el rendimiento, y CPUs de 64
bits serán mejores que los procesadores de 32. Debe haber
suficiente memoria en las máquinas usadas por los nodos de
datos para tratar cada parte de la base de datos (consulte
¿Cuánta RAM necesito? para
más información). Los nodos pueden comunicarse via TCP/IP
estándard y su hardware. Para soporte SCI, se necesita
hardware especial de red.
Como MySQL Cluster usa TCP/IP, ¿significa que puedo
usarlo en Internet, con uno o más nodos en una localización
remota?
Es importante tener presente que la comunicación
entre nodos en MySQL Cluster no es segura ; no
está encriptada ni guardada por ningún otro mecanismo. La
configuración más segura para un cluster es en una red
privada detrás de un firewall, sin acceso directo a ningún
nodo de datos ni de administración desde fuera.
Es muy dudoso que un cluster se muestre fiable bajo tales
condiciones, ya que se diseñó e implementó con la
suposición que se ejecutaría bajo condiciones que
garantizaran conectividad dedicada de alta velocidad como las
encontradas en configuraciones en una LAN con 100 Mbps o
gigabit Ethernet (mejor la última). No testeamos ni
garantizamos el rendimiento usando algo más lento que esto.
¿Debo usar nuevos lenguajes de programación o de
consulta para usar Cluster?
No. Aunque se usan algunos comandos especializados para
administrar y configurar el cluster, solo comandos estándard
(My)SQL se necesitan para:
Crear, alterar y borrar tablas
Insertar, actualizar y borrar datos de tabla
Crear, cambiar y borrar índices únicos y primarios
Configurar y administrar nodos SQL (servidores MySQL)
¿Cómo puedo sabar qúe significan loa mensajes de
error o advertencias al usar Cluster?
Se puede hacer de dos modos:
Desde el MySQL Monitor, use SHOW ERRORS
o SHOW WARNINGS inmediatamente al
recibir la notificación del error o advertencia. También
se pueden mostrar en MySQL Query Browser.
De un shell de sistema, use perror --ndb
error_code.
¿Es MySQL Cluster transaccional? ¿Qué tipo de
tablas se soportan en Cluster ?
Sí. MySQL Cluster utiliza tablas creadas con el motor
NDB , que soporta transacciones.
NDB es el único motor que soporta cluster.
¿Qué significa “NDB”?
Significa "Network
Database".
¿Qué versiones de MySQL software soportan Cluster?
¿Debo compilarlo de las fuentes?
Cluster se soporta en todos los binarios MySQL-max en la serie
5.0, excepto lo que se explica en el siguiente parágrafo.
Puede determinar si su servidor soporta o no NDB usando los
comandos SHOW VARIABLES LIKE 'have_%'; o
SHOW ENGINES;. (Consulte
Sección 5.1.2, “El servidor extendido de MySQL mysqld-max” para más información.)
Usuarios de Linux , tengan en cuenta que
NDBno se incluye en
los RPM estándar de MySQL server. Desde MySQL 5.0.4, hay
paquetes RPM separados para el motor NDB junto con
herramientas de administración; consulte la sección de
descargas NDB RPM de MySQL 5.0 Downloads . (Antes de 5.0.4,
debe usar los binarios -max proporcionados
como .tar.gz . Todabía es posible, pero
no es un requerimiento, así que puede usar su administración
de RPMs de Linux si lo prefiere.) Puede obtener soporte NDB
compilando los binarios -max de las
fuentes, pero no es necesario hacerlo para usar MySQL Cluster.
Para descargar los últimos binarios, RMP o distribución
fuente en la serie MySQL 5.0 visite
http://dev.mysql.com/downloads/mysql/5.0.html.
¿Cuánta RAM necesito? ¿Es posible usar memoria de
disco?
Actualmente, Cluster sólo funciona en memoria. Esto significa
que todos los datos de tabla (incluyendo índices) se almacena
en RAM. Por lo tanto, si sus datos ocupan 1 GB de espacio y
quiere replicarlo en el cluster, necesitará 2 GB de memoria
para ello. Esto es a parte de la memoria necesaria para el
sistema operativo y cualquier aplicación ejecutándose en las
máquinas del cluster.
Puede usar la siguiente fórmula para obtener una estimación
aproximada de cuánta RAM necesita para cada nodo de datos en
el cluster:
Para calcular los requerimientos de memoria con más exactitud
debe determinar, para cada tabla en la base de datos del
cluster, el espacio de almacenamiento requerido por registro
(consulte Sección 11.5, “Requisitos de almacenamiento según el tipo de columna” para más
detalles), y multiplicarlo por el número de registros. Debe
recordar tener en cuenta cualquier índice de columna como
sigue:
Cada clave primaria o índice hash creado para una tabla
NDBCluster necesita 21-25 bytes por
registro. Estos índices usan
IndexMemory.
Cada índice ordenado necesita 10 bytes de almacenamiento
por registro, usando DataMemory.
Crear una clave primaria o índice único también crea un
índice ordenado, a no ser que este índice se cree con
USING HASH. En otras palabras, si se
crea sin USING HASH, una clave primaria
o índice único en una tabla Cluster ocupará hasta 31-35
bytes por registro en MySQL 5.0.
Tenga en cuenta que crear tablas MySQL Cluster con
USING HASH para todas las claves
primarias e índices únicos generalmente causará que las
actualizaciones de tablas sean más rápidas. Esto es
debido al hecho que se necesita menos memoria (ya que no
se crean índices únicos), y que debe usarse menos CPU
(ya que se deben leer y actualizar menos índices).
Es especialmente importante tener en mente que
cada tabla en MySQL Cluster
debe tener clave primaria, que el motor NDB creará una clave
primaria automáticamente si no se define y que esta clave
primaria se crea sin USING HASH.
No hay una forma sencilla en MySQL 5.0 para determinar
exactamente cuánta memoria se está usando para almacenar
índices Cluster en un momento dado; sin embargo, las
advertencias se escriben en el log del cluster cuando el 80%
de memoria DataMemory y/o
IndexMemory está en uso, y de nuevo al
85%, 90% etc.
A menudo vemos preguntas de usuarios que reportan que, cuando
intentan rellenar una base de datos cluster, el proceso de
carga termina prematuramente y aparece un mensaje de error
como este:
ERROR 1114: The table 'my_cluster_table' is full
Cuando esto ocurre, la causa es que su configuración no
proporciona suficiente RAM para todos los datos de tablas e
índice , incluyendo la clave primaria requerida por
el motor NDB y creada automáticamente en
el caso que la definición de tabla no incluya la definición
de la clave primaria.
Vale la pena tener en cuenta que todos los nodos de datos
deben tener la misma cantidad de RAM, ya que ningún nodo de
datos en el cluster puede usar más memoria que la mínima
cantidad disponible para cualquier nodo de datos individual.
En otras palabras, si hay tres máquinas con nodos de datos y
dos tienen 3 GB RAM disponibles y otro sólo 1 GB de RAM,
entonces cada nodo sólo puede usar 1 GB para el cluster.
En caso de un fallo catastrófico — por
ejemplo, que la ciudad entera se queda sin electricidad
y mi UPS falla —
¿perdería todos mis datos?
Todas las transacciones con commit se loguean. Por lo tanto,
aunque es posible perder algunos datos en caso de catástrofe,
debería ser algo limitado. La pérdida de datos puede
reducirse minimizando el número de operaciones por
transacción. (No es buena idea realizar un gran número de
operaciones por transacción en cualquier caso.)
¿Es posile usar índices
FULLTEXT con Cluster?
La indexación FULLTEXT no se soporta en el
motor NDB , o por cualquier motor que no
sea MyISAM. Estamos trabajando para añadir
esta funcionalidad en nuevas versiones.
¿Puedo ejectura múltiples nodos en una sola
máquina?
Es posible pero no recomendable. Una de las razones
principales para ejecutar un cluster es proporcionar
redundancia; para tener todos los beneficios de esta
redundancia, cada nodo debe residir en máquinas separadas. Si
tiene múltiples nodos en una misma máquina y esta falla,
pierde todos estos nodos. Dado que MySQL Cluster puede
ejecutarse en hardware dedicado cargado con sistemas
operativos de bajo o ningún coste, vale la pena el gasto en
una o dos máquina extra para guardar datos críticos.
También vale la pena tener en cuenta que los requerimientos
para una máquina cluster ejectuando un nodo de
administración son mínimos; esta tarea puede realizarse con
una CPU 200 MHz Pentium y suficiente RAM para el sistema
operativo más una mínima cantidad de sobrecarga para los
procesos ndb_mgmd y
ndb_mgm .
¿Puedo añadir nodos en un cluster sin
reiniciarlo?
No. Un reinicio es necesario para añadir nuevos nodos MGM o
SQL. Al añadir nodos de datos el proceso es más complejo, y
necesita los siguientes pasos:
Hacer una copia de seguridad completa de todos los datos
del cluster.
Parar todo el cluster y procesos de los nodos.
Reiniciar el cluster, usando la opción
--initial
Restaurar todos los datos desde la copia de seguridad
En el futuro, esperamos implementar capacidad de
reconfiguración “hot” para MySQL Cluster para
minimizar (o eliminar) los requerimientos para reiniciar el
cluster al añadir nuevos nodos.
¿Hay alguna limitación que deba tener en cuenta al
usar Cluster?
Las tablas NDB tienen las siguientes
limitaciones:
No se soportan todos los conjuntos de caracteres y
colaciones.
Índices FULLTEXT y prefijo no están
soportados. Sólo pueden indexarse columnas completas.
Sólo se soporta rollback completo para transacciones. Los
rollback parciales y rollbacks en checkpoints no se
soportan.
El máximo número de atributos permitidos por tabla es
128, y los nombres de atributo no pueden tener más de 31
caracteres. Para cada tabla, la longitud máxima
combinada del nombre de tabla y de base de datos es 122
caracteres.
El tamaño máximo para un registro de tabla es de 8
kilobytes, sin contar BLOBs. No hay límite para el
número de registros por tabla; los límites de tamaño de
tabla dependen en un número de factores, en particular la
cantidad de RAM disponible para cada nodo de datos.
El motor NDB no soporta claves foráneas. Como con tablas
MyISAM, se ignoran.
¿Cómo importo una base de datos existente en un
cluster?
Puede importar bases de datos en MySQL Cluster como con
cualquier otra versión de MySQL. A parte de las limitaciones
mencionadas anteriormente, el único requerimiento especial es
que cualquier tabla que se incluya en el cluster debe usar el
motor NDB. Esto significa que las tablas
deben crearse con la opción ENGINE=NDB o
ENGINE=NDBCLUSTER.
¿Cómo se comunican los nodos del cluster entre
ellos?
Los nodos del Cluster pueden comunicarse meiante tres
protocolos: TCP/IP, SHM (memoria compartida), y SCI (Scalable
Coherent Interface). Donde está disponible, SHM se usa por
defecto entre nodos residentes en el mismo equipo de cluster.
SCI es un protocolo de alta velocidad (1 gigabit por segundo o
más), alta disponibilidad usado en construir sistemas
escalables de multi procesador; requiere hardware especial y
drivers. Consulte
Sección 16.7, “Usar interconexiones de alta velocidad con MySQL Cluster” para más
información usando SCI como mecanismo de transporte en MySQL
Cluster.
¿Qué es un “árbitro”?
Si uno o más nodos en un cluster fallan, es posible que no
todos los nodos del cluster será capaz de
“verse” entre ellos. De hecho, es posible que dos
conjuntos de nodos puedan a estar aislados de los otros en una
partición de red, también conocido como un escenario
“split brain”. Este tipo de situación no es
deseable ya que cada conjunto de nodos trata de comportarse
como si fuera el cluster entero.
Cuando caen los nodos del cluster, hay dos posibilidades. Si
más del 50% de los nodos restantes pueden comunicarse entre
ellos, entonces tenemos lo que a veces se llama “reglas
de mayoría” , y este conjunto de nodos se consideran
como el cluster. El árbitro entra en juego cuando hay un
número impar de nodos: en tales casos, el conjunto de nodos
al que pertenece el árbitro se considera el cluster, y los
nodos que no pertenecen a este grupo se paran.
La información anterior está simplificada; a continuación
hay una explicación más completa:
Cuando todos los nodos en al menos un grupo de nodos está
vivo, la partición de la red no es un problema, porque
ninguna porción del cluster puede formar un cluster
funcional. El problem real es cuando un grupo no tiene todos
sus nodos vivos, en tal caso la partición de red (el
escenario “split-brain” mencinado anteriormente)
es posible. Cuando se necesita un árbitro, que normalmente es
el servidor de administración; sin embargo, es posible
configurar cualquier MySQL Server en el cluster para que
actúe como el árbitro. El árbitro acepta el primer conjunto
de nodos del cluster que contacten con el, y le dice al resto
que mueran. La selección del árbitro se controla mediante el
parámetro de configuración
ArbitrationRank para los nodos MySQL Server
y de administración. (Consulte
Sección 16.4.4.4, “Definición del servidor de administración de MySQL Cluster” para más
detalles.) Debe tener en cuenta que el rol de administrador no
impone ninguna demanda en la máquina designada, y por lo
tanto la máquina árbitro no necesita ser particularmente
rápida o tener memoria extra para este propósito.
¿Qué tipos de columna soport MySQL
Cluster?
MySQL Cluster soporta todos los tipos de columna MySQL
usuales, con la excepción de los asocidados con las
extensiones espaciales. (Consulte
Capítulo 18, Extensiones espaciales de MySQL.) Además, hay algunas
diferencias respecto a los índices cuando se usan con tablas
NDB. Nota: En MySQL 5.0, las
tablas Cluster (esto es, tablas creadas con
ENGINE=NDBCLUSTER) tiene sólo registros de
longitud fija. Esto significa que (por ejemplo, cada registro
conteniendo una columna VARCHAR(255)
necesitará 256 bytes de almacenamiento para esa columna,
independientemente del tamaño de los datos almacenados. Este
punto se arreglará en futuras versiones.
Consulte Sección 16.8, “Limitaciones conocidas de MySQL Cluster” para más
información.
¿Cómo arranco y paro MySQL Cluster?
Es necesario arrancar cada nodo en el cluster por separado en
el siguiente orden:
Arranque el nodo de administración con el comando
ndb_mgmd .
Arranque cada nodo de datos con el comando
ndbd.
Arranque cada servidor MySQL (nodo SQL) usando
mysqld_safe --user=mysql &.
Cada uno de estos comandos debe ejecutarse en una shell de
sistema en la máquina que contenga el nodo afectado. Puede
verificar que el cluster está en ejecución arrancando el
cliente de administración MGM . ndb_mgm en
la máquina con el nodo MGM.
¿Qué ocurre a los datos del cluster cuando el
cluster se para?
Los datos en memoria de los nodos de datos se escriben en
disco, y se recargan en memoria la siguiente vez que se inicia
el cluster.
Para parar el cluster, introduzca lo siguiente en una shell en
la máquina del nodo MGM:
¿Es útil tener más de un nodo de administración
para el cluster?
Puede ser útil para ser más seguro. Sólo un nodo MGM
controla el cluster en un momento dado, pero es posible
configurar un MGM como primario, y otro o más nodos
adicionales para tomar el control en caso de fallo del nodo
MGM primario.
¿Puedo mezclar hardware y sistemas operativos
distintos en un Cluster?
Sí, mientras todas las máquinas y sistemas operativos tengan
la misma endian. Es posible usar distintas versiones de MySQL
Cluster en nodos distintos; sin embargo, recomendamos que esto
se haga sólo como parte del procedimiento de actualización.
¿Puedo ejecutar dos nodos de datos en una misma
máquina? ¿Dos nodos SQL?
Sí. En el caso de múltiples nodos de datos, cada nodo debe
usar un directorio de datos distinto. Si quiere ejectuar
múltiples nodos SQL en una máquina, entonces cada instancia
de mysqld debe usar un puerto TCP/IP
distinto.
¿Puedo usar nombres de equipo con MySQL
Cluster?
Sí, es posible usar DNS y DHCP para equipos del cluster. Sin
embargo, si su aplicación necesita disponibilidad de "cinco
nueves", recomendamos usar direcciones IP fijas. Esto es
porque hacer la comunicación entre equipos del cluster
dependiente de estos servicios introduce puntos de fallo
adicionales, y mientras menos haya, mejor.
16.11. Glosario de MySQL Cluster
Los siguientes términos son útiles para enteneder MySQL Cluster
o tienen significado eespecial cuando se usan referidos a ellos.
Cluster:
En sentido genérico, un cluster es un conjunto de máquinas
funcionando como unidad y trabajando juntas para tratar una
única tarea.
NDB
Cluster:
Este es el motor de almacenamiento usado en MySQL para
implementar almacenamiento de datos, recuperación y
administración distribuída entre varias máquinas.
MySQL Cluster:
Se refiere a un grupo de máquinas trabajando juntas usando el
motor NDB para soportar una base de datos
MySQL distribuída en una arquitectura de
compartición nula usando
almacenamiento en memoria.
Ficheros de configuración:
Ficheros de texto conteniendo directivas e información
respecto al cluster, sus máquinas y sus nodos. Son leídos
por los nodos de administración de cluster y cuando arranca
el cluster. Consulte
Sección 16.4.4, “Fichero de configuración” para detalles.
Copia de seguridad:
Una copia completa de todos los datos de cluster,
transacciones y logs, guardados en disco y otro medio de
almacenamiento.
Restauración:
Retornar el cluster a un prévio estado, como se almacenó en
la copia de seguridad.
Checkpoint:
Generalmente hablando, cuando los datos se guardan en disco,
se dice que se llega a un checkpoint. Más específicamente
para el cluster, es un punto en tiempo donde todas las
transacciones que han hecho un commit se guardan en disco.
Respecto al motor NDB, hay dos clases de
checkpoints que trabajan juntas para asegurar que se mantiene
una vista consistente del cluster:
Local Checkpoint (LCP):
Este es un checkpoint específico a un nodo; sin embargo
LCP se realizan para todos los nodos de forma más o
menos concurrentes en todo el cluster. Un LCP inplica
guardar todos los datos de los nodos en disco, y esto
ocurre normalmente cada pocos minutos. El intervalo
preciso varía, y depende de la cantidad de datos
almacenada por el nodo, el nivel de la actividad del
cluster y otros factores.
Global Checkpoint
(GCP):
Un GCP se realiza cada pocos segundos, cuando las
transacciones para todos los nodos se sincronizan y el
log de redo se vuelca en disco.
Equipo Cluster:
Una máquina que forma parte del MySQL Cluster. Un cluster
tiene una estructura física y una
lógica . Físicamente, el cluster
consiste en un número de máquinas , conocidas como
equipos del cluster (o más
símplemente equipos . Consulte
Nodo y
Grupo de Nodos a
continuación.
Nodo:
Se refiere a un unidad lógica o funcional de MySQL Cluster, y
a veces se denomina como nodo de
cluster . En el contexto de MySQl Cluster, usamos
el término “nodo” para indicar un
proceso en lugar de un componente físico
del cluster. Hay tres tipos de nodo requeridos para
implementar un MySQL Cluster. Son:
Nodos de administración
(MGM):
Administra los otros nodos dentro del MySQL Cluster.
Proporciona datos de configuración de los otros nodos;
arranca y para nodos; trata partición de red; crea copias
de seguridad y restaura desde las mismas, y así.
Nodos SQL (MySQL server):
Instancias de MySQL Server que sirve como front end para
cuardar datos en los nodos de datos
del cluster. Clientes que quieran almacenan,
recuperar o actualizar datos pueden acceder a un nodo SQL
sólo como si fuera cualquier otro MySQL Server, empleando
los métodos de autenticación usual y API; la
distribución subyacente de datos entre grupos de nodos es
transparente a los usuarios y aplicaciones. Los nodos SQL
acceden a las bases de datos del cluster como un total sin
tener en cuenta la distribución de datos entre distintos
nodos de datos o máquinas del cluster.
Nodos de datos:
Estos nodos almacenan los datos. Los fragmentos de datos
se almacenan en un conjunto de grupos de nodos. Cada uno
de los nodos creando un grupo de nodos almacena una
réplica del fragmento para el que ese grupo de nodos es
responsable. Actualmente un único cluster puede soportar
hasta 48 nodos de datos en total.
Es posible que más de un nodo coexista en una única
máquina. (De hecho, es posible tener un cluster completo en
una única máquina, aunque no es
recomendable hacerlo en un entorno de producción.) Puede ser
útil recordar que, cuando se trabaja con MySQL Cluster, el
término máquina se refiere a un
componente físico del cluster mientras que
nodo es un componente lógico o
funcional. (un proceso).
Nota respecto a términos obsoletos: En
versiones más antiguas de la documentación de MySQL Cluster
, los nodos de datos se llaman a veces "nodos de bases de
datos" o "nodos DB". Además, los nodos SQL a veces se conocen
como "nodos cliente" o "nodos API". Esta terminología antigua
ha quedado obsoleta para minimizar confusión, y por estas
razones debería evitarse.
Grupo de nodos:
Conjunto de nodos de datos. Todos los nodos de datos en un
grupo de nodos contienen los mismos datos (fragmentos), y
todos los nodos en un mismo grupo deben estar en distintas
máquinas. Es posible controlar qué nodos pertenecen a qué
grupos de nodos.
Fallo de nodo:
MySQL Cluster no sólo depende de la funcionalidad de un
único nodo en el cluster; el cluster puede continuar
funcionando si uno o más nodos fallan. El número preciso de
fallos de nodo que puede tolerar un único cluster depende en
el número de nodos de la configuración del cluster.
Reinicio de nodo:
El proceso de restaurar un nodo de cluster fallido.
Reinicio de nodo inicial:
El proceso de arrancar un nodo de cluster con su sistema de
fichero eliminado. Esto a veces se usa en actualizaciones de
software y en otras circunstancias especiales.
Fallo de sistema:
Puede ocurrir cuando han fallado tantos nodos que el estado
del cluster no puede garantizarse.
Reinicio de sistema:
El proceso de reiniciar el cluster y reinicializar su estado
de logs de disco y checkpoints. Se requiere tras una parada
planficada o no del cluster.
Fragmento:
Una porción de una tabla; en el motor NDB
una tabla se divide y almacena como un número de fragmentos.
Un fragmento es a veces llamado “partición”; sin
embargo, “fragmento” es la denominación
preferida.Las tablas fragmentadas en MySQL Cluster se usan
para facilitar balanceo de carga entre máquinas y nodos.
Réplica:
Bajo el motor NDB , cada fragmento de tabla
tiene un número de réplicas almacenadas en otros nodos de
datos para proporcionar redundancia. Hay actualmente 4
réplicas por fragmento.
Transporter:
Protocolo que proporciona transferencia de datos entre nodos.
MySQL Cluster soporta 4 tipos distintos de conexiones de
transporters:
TCP/IP (local)
Protocolo de red habitual que existe bajo HTTP, FTP (y
así ) en Internet.
TCP/IP (remoto)
Lo mismo que el anterior, excepto que se usa para
comunicación remota.
SHM
shared
memory segments
(segmentos de memoria compartida). Donde se soporta, SHM
se usa automáticamente para conectar nodos en la misma
máquina. La
página de man Unix para
shmop(2) es un buen sitio
para obtener información adicional acerca de este tema.
Nota: El transporter del
cluster es interno. Las aplicaciones que usan MySQL Cluster se
comunican con nodos SQL como se hace con cualquier otra
versión de MySQL Server (via TCP/IP, o a través del uso de
sockets Unix o Windows named pipes). Las consultas pueden
enviarse y recibirse los resultados usando la API estándar
MySQL .
NDB:
Significa Network
Database,
y se refiere al motor de almacenamiento usando para permitir
MySQL Cluster. El motor NDB soporta todos
los tipos de columna MySQL habituales y comandos SQL , y
cumple las reglas ACID. Este motor proporciona soporte para
transacciones (commits y rollbacks).
Arquitectura de compartición
cero:
Arquitectura ideal para MySQL Cluster. En un entorno sin
compartición, cada nodo se ejecuta en máquinas separadas. La
ventaja de este entorno es que ninguna máquina puede ser un
punto de fallida único o como cuello de botella del sistema.
Almacenamiento en memoria:
Todos los datos almacenados en cada nodo de datos se mantiene
en memoria en la máquina del nodo. Para cada nodo de datos en
el cluster, debe tener disponible una cantidad de RAM igual al
tamaño de la base de datos multiplicado por el número de
réplicas, dividido por el número de nodos de datos. Por lo
tanto, si la base de datos ocupa 1 GB de memoria, y quiere
tener 4 réplicas en el cluster, necesita para cada nodo un
mínimo de 500 . Tenga en cuenta que esto es además de
cualquier requerimiento para el sistema operativo u otra
aplicación que puede ejecutarse en el equipo.
Tabla:
Como es normal en el contexto de bases de datos relacionales,
el término “tabla” denota un conjunto ordenado
de requistros de idéntica estructura. En MySQL Cluster, una
tabla de base de datos se almacena en un nodo de datos como un
conjunto de fragmentos, cada uno de ellos se replica en nodos
de datos adicionales. El conjunto de nodos de datos replicando
el mismo fragmento o conjunto de fragmentos se conoce como
grupo de nodos.
Programas del Cluster:
Son programas de línea de comandos usados para ejecutar,
configurar y administrar MySQL Cluster. Incluyen demonios:
ndbd:
Demonio de nodo de datos (ejecuta un proceso de nodo de
datos)
ndb_mgmd:
Demonio de servidor de administración (ejecuta un proceso
de servidor de administración)
y programas cliente:
ndb_mgm:
El cliente de administración (proporciona una interfaz
para ejectuar comandos de administración)
ndb_waiter:
Usado para verificar el estado de todos los nodos del
cluster
ndb_restore:
Restaura datos del cluster de una copia de seguridad
Log de eventos:
MySQL Cluster loguea eventos por categoría (arranque, parada,
errores,checkpoints, y así), prioridad, y severidad. Un
listado completo de todos los eventos reportables pueden
encontrarse en Sección 16.6.2, “Informes de eventos generados por MySQL Cluster”.
Los logs de eventos son de dos tipos:
Log de Cluster:
Mantiene un registro de todos los eventos reportables
deseados para el cluster entero.
Log de Node:
Un log separado que se mantiene para cada nodo individual.
Bajo circunstancias normales, es necesario y suficiente
mantener y examinar sólo el log del cluster. Los logs de nodo
tienen que ser consultados sólo para desarrollo de
aplicaciones y depuración.
Ésta es una traducción del manual de referencia de MySQL, que
puede encontrarse en
dev.mysql.com.
El manual de referencia original de MySQL está escrito en inglés, y esta
traducción no necesariamente está tan actualizada como la
versión original. Para cualquier sugerencia sobre la
traducción y para señalar errores de cualquier tipo, no dude en
dirigirse a
mysql-es@vespito.com.
