Setting up MySQL 5.0 Cluster on Debian and Ubuntu

Posted by Kris under Tech [4] Comments

This guide explains how to turn standard debian or ubuntu mysql-server installs into a full ndb cluster. As we’re using the standard mysql-server package, you won’t need to download any non .deb binaries or do any compiling. If everything goes well, this should take under 10 minutes to get working. I don’t plan to cover much theory here, as it is just a guide to getting the server up and running.

Please note that clustering works differently in MySQL 5.1, so this guide may not be relevant for that.

I also recommend the book ‘MySQL Clustering’ by Alex Davies and Harrison Fisk (ISBN 0-672-32855-0) as it explains how the cluster works in a lot more detail than I plan to here.

I will explain how to set up 3 servers, with the following roles:

server-a = management node (IP 10.1.0.10)server-b = storage and sql node (IP 10.1.0.11)server-c = storage and sql node (IP 10.1.0.12)

It is easy to have storage and sql nodes on separate servers, but to make this guide easier to follow (and so we don’t need 5 machines), I’ll use 3 servers.

All servers will need to have mysql-server installed. If you need help doing this, have a look at this guide.

Setting up the management node (10.1.0.10)

Default debian/ubuntu installs look for /etc/mysql/ndb_mgmd.cnf for the management node, so we need to create this file, with the following contents:

[NDBD DEFAULT]NoOfReplicas=2DataDir= /var/lib/mysql-cluster

# Management Node[NDB_MGMD]HostName=10.1.0.10DataDir=/var/lib/mysql-cluster

# Storage Nodes (one for each node)[NDBD]HostName=10.1.0.11DataDir=/var/lib/mysql-cluster[NDBD]HostName=10.1.0.12DataDir=/var/lib/mysql-cluster

# SQL Nodes (one for each node)[MYSQLD]HostName=10.1.0.11[MYSQLD]HostName=10.1.0.12

The line beginning NoOfReplicas tells the cluster how many copies of data should be kept.

Now we start the management node, and it will sit waiting for connections from the storage and SQL nodes:

/etc/init.d/mysql-ndb-mgm start

Setting up SQL and data nodes

All we need to do here is make a few changes to /etc/mysql/my.cnf (the mysql config file)

First, add the following 2 lines (using the IP of your management node) inside the [mysqld] section of the config file:

ndbclusterndb-connectstring=10.1.0.10

And near the bottom of the file there will be a section for [MYSQL_CLUSTER] which you will need to uncomment, and change the ndb-connectstring line to your management nodes IP.

If you are using separate data and sql nodes, the [mysqld] part is relevant to the sql nodes only, and the [MYSQL_CLUSTER] part is relevant to the data nodes only.

Before we start the services, we have to create the /var/lib/mysql-cluster directory and set it to be owned by the mysql user:

mkdir /var/lib/mysql-clusterchown mysql:mysql /var/lib/mysql-cluster

Now we need to start the node services:

/etc/init.d/mysql restart(which starts the sql node)/etc/init.d/mysql-ndb restart(which starts the data node)

By now, everything should be running, so we connect to the management node (by running ndb_mgm from the command line) and check that the other nodes have connected properly (using the show command):

ndb_mgm> show;Cluster Configuration———————[ndbd(NDB)]     2 node(s)id=2    @10.1.0.11  (Version: 5.0.51, Nodegroup: 0)id=3    @10.1.0.12  (Version: 5.0.51, Nodegroup: 0, Master)

[ndb_mgmd(MGM)] 1 node(s)id=1    @10.1.0.10  (Version: 5.0.51)

[mysqld(API)]   2 node(s)id=4    @10.1.0.11  (Version: 5.0.51)id=5    @10.1.0.12  (Version: 5.0.51)

This shows that everything has connected properly. If connections are missing, then it’s worth checking /var/log/syslog on the affected server to see if there are any error messages.

Using the cluster

It’s worth noting that any databases already on the servers will continue to work as before. Tables only become part of the cluster when their engine type is changed to ‘ndbcluster’ by issuing this command (from a mysql prompt):

alter table tablename engine=ndbcluster;

But for now we will create a new database and clustered table, and test that the data is clustered. The cluster setup applies to tables only, not databases, so we first need to create the database on both sql nodes:

create database cluster;

Now, when we create a table inside the cluster database, as long as the engine is ndbcluster, the data will be synced across data nodes, which we can test by doing the following (from a mysql prompt on either sql node):

create table clustertest (i int) engine=ndbcluster;insert into clustertest () values (1);select i from clustertest;

Which should return the single row with the value of 1. Now connect to the other SQL node and try…

insert into clustertest () values (2);select i from clustertest;

Which should return both rows, which will happen whichever SQL node you connect to as the table is now stored in the cluster.

If you receive an error like:

ERROR 1015 (HY000): Can’t lock file (errno: 4009)

Then it is likely that some of your cluster nodes haven’t started correctly, so its worth checking the management interface again.

Shutting down and restarting the cluster

To shutdown the data nodes and management node, all you need to do is enter the command ’shutdown’ in the management interface.

To restart, simply run

/etc/init.d/mysql-ndb-mgm start

On the management node, and

/etc/init.d/mysql-ndb start

On the data nodes. The SQL nodes continue running, and can be stopped/started using the standard mysql init script.

That’s it, you’ve now should have a working MySQL cluster. As you have NoOfReplicas=2 in the management config, you should be able to unplug either data node at any time and still have access to all of the clustered tables.

MySQL Cluster: Two webserver setup

HOWTO set up a MySQL Cluster for two servers (three servers required for true redundancy)

Introduction

This HOWTO was designed for a classic setup of two servers behind a loadbalancer. The aim is to have true redundancy - either server can be unplugged and yet the site will remain up.

Notes:

You MUST have a third server as a managment node but this can be shut down after the cluster starts. Also note that I do not recommend shutting down the managment server (see the extra notes at the bottom of this document for more information). You can not run a MySQL Cluster with just two servers And have true redundancy.

Although it is possible to set the cluster up on two physical servers you WILL NOT GET the ability to "kill" one server and for the cluster to continue as normal. For this you need a third server running the managment node.

I am going to talk about three servers:

mysql1.domain.com 192.168.0.1mysql2.domain.com 192.168.0.2mysql3.domain.com 192.168.0.3

Servers 1 and 2 will be the two that end up "clustered". This would be perfect for two servers behind a loadbalancer or using round robin DNS and is a good replacement for replication. Server 3 needs to have only minor changes made to it and does NOT require a MySQL install. It can be a low-end machine and can be carrying out other tasks.

STAGE 1: Install MySQL on the first two servers:

Complete the following steps on both mysql1 and mysql2:

cd /usr/local/http://dev.mysql.com/get/Downloads/MySQL-4.1/mysql-max-4.1.9-pc-linux-gnu-i686.tar.gz/

from/http://www.signal42.com/mirrors/mysql/groupadd mysqluseradd -g mysql mysqltar -zxvf mysql-max-4.1.9-pc-linux-gnu-i686.tar.gz

rm mysql-max-4.1.9-pc-linux-gnu-i686.tar.gzln -s mysql-max-4.1.9-pc-linux-gnu-i686 mysqlcd mysqlscripts/mysql_install_db --user=mysqlchown -R root .chown -R mysql datachgrp -R mysql .cp support-files/mysql.server /etc/rc.d/init.d/chmod +x /etc/rc.d/init.d/mysql.serverchkconfig --add mysql.server

Do not start mysql yet.

STAGE 2: Install and configure the managment server

You need the following files from the bin/ of the mysql directory: ndb_mgm and ndb_mgmd. Download the whole mysql-max tarball and extract them from the bin/ directory.

mkdir /usr/src/mysql-mgmcd /usr/src/mysql-mgmhttp://dev.mysql.com/get/Downloads/MySQL-4.1/mysql-max-4.1.9-pc-linux-gnu-i686.tar.gz/

from/http://www.signal42.com/mirrors/mysql/tar -zxvf mysql-max-4.1.9-pc-linux-gnu-i686.tar.gzrm mysql-max-4.1.9-pc-linux-gnu-i686.tar.gzcd mysql-max-4.1.9-pc-linux-gnu-i686mv bin/ndb_mgm .mv bin/ndb_mgmd .chmod +x ndb_mg*mv ndb_mg* /usr/bin/cdrm -rf /usr/src/mysql-mgm

You now need to set up the config file for this managment:

mkdir /var/lib/mysql-cluster cd /var/lib/mysql-cluster vi [or emacs or any other editor] config.ini

Now, insert the following (changing the bits as indicated):

[NDBD DEFAULT]NoOfReplicas=2[MYSQLD DEFAULT][NDB_MGMD DEFAULT][TCP DEFAULT]# Managment Server[NDB_MGMD]HostName=192.168.0.3 # the IP of THIS SERVER# Storage Engines[NDBD]HostName=192.168.0.1 # the IP of the FIRST SERVERDataDir= /var/lib/mysql-cluster[NDBD]HostName=192.168.0.2 # the IP of the SECOND SERVERDataDir=/var/lib/mysql-cluster# 2 MySQL Clients# I personally leave this blank to allow rapid changes of the mysql clients;# you can enter the hostnames of the above two servers here. I suggest you dont.[MYSQLD][MYSQLD]

Now, start the managment server:

ndb_mgmd

This is the MySQL managment server, not maganment console. You should therefore not expect any output (we will start the console later).

STAGE 3: Configure the storage/SQL servers and start mysql

On each of the two storage/SQL servers (192.168.0.1 and 192.168.0.2) enter the following (changing the bits as appropriate):

vi /etc/my.cnf

Enter i to go to insert mode again and insert this on both servers (changing the IP address to the IP of the managment server that you set up in stage 2):

[mysqld]ndbclusterndb-connectstring=192.168.0.3 # the IP of the MANAGMENT (THIRD) SERVER[mysql_cluster]ndb-connectstring=192.168.0.3 # the IP of the MANAGMENT (THIRD) SERVER

Now, we make the data directory and start the storage engine:

mkdir /var/lib/mysql-cluster cd /var/lib/mysql-cluster /usr/local/mysql/bin/ndbd --initial /etc/rc.d/init.d/mysql.server start

If you have done one server now go back to the start of stage 3 and repeat exactly the same procedure on the second server.

Note: you should ONLY use --initial if you are either starting from scratch or have changed the config.ini file on the managment.

STAGE 4: Check its working

You can now return to the managment server (mysql3) and enter the managment console:

/usr/local/mysql/bin/ndb_mgm

Enter the command SHOW to see what is going on. A sample output looks like this:

[root@mysql3 mysql-cluster]# /usr/local/mysql/bin/ndb_mgm-- NDB Cluster -- Management Client --ndb_mgm> showConnected to Management Server at: localhost:1186Cluster Configuration---------------------[ndbd(NDB)] 2 node(s)id=2 @192.168.0.1 (Version: 4.1.9, Nodegroup: 0, Master)id=3 @192.168.0.2 (Version: 4.1.9, Nodegroup: 0)

[ndb_mgmd(MGM)] 1 node(s)id=1 @192.168.0.3 (Version: 4.1.9)

[mysqld(API)] 2 node(s)

id=4 (Version: 4.1.9)id=5 (Version: 4.1.9)

ndb_mgm>

If you see

not connected, accepting connect from 192.168.0.[1/2/3]

in the first or last two lines they you have a problem. Please email me with as much detail as you can give and I can try to find out where you have gone wrong and change this HOWTO to fix it.

If you are OK to here it is time to test mysql. On either server mysql1 or mysql2 enter the following commands: Note that we have no root password yet.

mysql use test; CREATE TABLE ctest (i INT) ENGINE=NDBCLUSTER; INSERT INTO ctest () VALUES (1); SELECT * FROM ctest;

You should see 1 row returned (with the value 1).

If this works, now go to the other server and run the same SELECT and see what you get. Insert from that host and go back to host 1 and see if it works. If it works then congratulations.

The final test is to kill one server to see what happens. If you have physical access to the machine simply unplug its network cable and see if the other server keeps on going fine (try the SELECT query). If you dont have physical access do the following:

ps aux | grep ndbd

You get an output like this:

root 5578 0.0 0.3 6220 1964 ? S 03:14 0:00 ndbdroot 5579 0.0 20.4 492072 102828 ? R 03:14 0:04 ndbdroot 23532 0.0 0.1 3680 684 pts/1 S 07:59 0:00 grep ndbd

In this case ignore the command "grep ndbd" (the last line) but kill the first two processes by issuing the command kill -9 pid pid:

kill -9 5578 5579

Then try the select on the other server. While you are at it run a SHOW command on the managment node to see that the server has died. To restart it, just issue

ndbd

Note: no --inital!

Further notes about setup

I strongly recommend that you read all of this (and bookmark this page). It will almost certainly save you a lot of searching.

The Managment Server

I strongly recommend that you do not stop the managment server once it has started. This is for several resons:

The server takes hardly any server resources If a cluster falls over, you want to be able to just ssh in and type ndbd to stat it. You dont want

to have to start messing around with another server If you want to take backups then you need the managment server up The cluster log is sent to the management server so to check what is going on in the cluster or

has happened since last this is an important tool All commands from the ndb_mgm client is sent to the management server and thus no

management commands without management server. The managment server is required in case of cluster reconfiguration (crashed server or network

split). In the case that it is not running, "split-brain" scenario will occure. The management server arbitration role is required for this type of setup to provide better fault tollerance.

However you are welcome to stop the server if you prefer.

Starting and stopping ndbd automatically on boot

To achieve this, do the following on both mysql1 and mysql2:

echo "ndbd" > /etc/rc.d/init.d/ndbd chmod +x /etc/rc.d/init.d/ndbd chkconfig --add ndbd

Note that this is a really quick script. You ought really to write one that at least checks if ndbd is already started on the machine.

Use of hostnames

You will note that I have used IP addresses exclusively throught this setup. This is because using hostnames simply increases the number of things that can go wrong. Mikael Ronstro"m of MySQL AB kindly explains: "Hostnames certainly work with MySQL Cluster. But using hostnames introduces quite a few error sources since a proper DNS lookup system must be set-up, sometimes /etc/hosts must be edited and their might be security blocks ensuring that communication between certain machines is not possible other than on certain ports". I strongly suggest that while testing you use IP addresses if you can, then once it is all working change to hostnames.

RAM

Use the following formula to work out the amount of RAM that you need on each storage node:

(Size of database * NumberofReplicas * 1.1) / Number of storage nodes

NumberofReplicas is set to two by default. You can change it in config.ini if you want. So for example to run a 4GB database over two servers with NumbeOfReplicas set to two you need 4.4 GB of RAM on each storage node. For the SQL nodes and managment nodes you dont need much RAM at all. To run a 4GB database over 4 servers with NumberOfReplicas set to two you would need 2.2GB per node.

Note: A lot of people have emailed me querying the maths above! Remember that the cluster is fault tolerant, and each piece of data is stored on at least 2 nodes. (2 by default, as set by NumberOfReplicas). So you need TWICE the space you would need just for one copy, multiplied by 1.1 for overhead.

Adding storage nodes

If you decide to add storage nodes, bear in mind that 3 is not an optimal numbers. If you are going to move from two (above) then move to 4. Adding SQL nodes

Adding SQL nodes

To add storage nodes, you need to add another [NDBD] section to config.ini as per the template above, edit the /etc/my.cnf on the new storage node as per the example above and then create the directory /var/lib/mysql-cluster. You then need to SHUTDOWN the cluster, start the managment daemon (ndb_mgmd) start all the ndbd nodes including the new one and then restart all the MySQL servers.

[mysqld]ndbclusterndb-connectstring=192.168.0.3 # the IP of the MANAGMENT (THIRD) SERVER[mysql_cluster]ndb-connectstring=192.168.0.3 # the IP of the MANAGMENT (THIRD) SERVER

Then you need to make sure that there is another [MYSQLD] line at the end of config.ini on the managment server. Restart the cluster (see below for an important note) and restart mysql on the new API. It should be connected.

Important note on changing config.ini

If you ever change config.ini you must stop the whole cluster and restart it to re-read the config file. Stop the cluster with a SHUTDOWN command to the ndb_mgm package on the managment server and then restart all the storage nodes.

Some useful configuration options that you will need if you have large tables:

DataMemory: defines the space available to store the actual records in the database. The entire DataMemory will be allocated in memory so it is important that the machine contains enough memory to handle the DataMemory size. Note that DataMemory is also used to store ordered indexes. Ordered indexes uses about 10 bytes per record. Default: 80MB

IndexMemory The IndexMemory is the parameter that controls the amount of storage used for hash indexes in MySQL Cluster. Hash indexes are always used for primary key indexes, unique indexes, and unique constraints. Default: 18MB

MaxNoOfAttributes This parameter defines the number of attributes that can be defined in the cluster. Default: 1000

MaxNoOfTables Obvious (bear in mind that each BLOB field creates another table for various reasons so take this into account). Default: 128

View this page for further information about the things you can put in the [NDBD] section of config.ini

A note about security

MySQL cluster is not secure. By default anyone can connect to your managment server and shut the whole thing down. I suggest the following precautions:

Install APF and block all ports except those you use (do NOT include any MySQL cluster ports). Add the IPs of your cluster machines to the /etc/apf/allow_hosts file.

Run MySQL cluster over a second network card on a second, isolated, network.

Thanks

I must thank several others who have contributed to this: Mikael Ronström from MySQL AB for helping me to get this to work and spotting my silly mistake right at the end, Lewis Bergman for proof-reading this page and pointing out some improvements, as well as suffering the frustration with me and Martin Pala for explaining the final reason to keep the managment server up as well as a few other minor changes. Thanks also to Terry from Advanced Network Hosts who paid me to set a cluster up and at the same time produce a HOWTO.

Alex Davies would love to hear from you if you successfully set this cluster up, if you get stuck on something, if you find a mistake in his HOWTO or you have any suggestions. Please Contact Him.

Please also see the Cluster forum and Cluster mailing list

16.1. Panorámica de MySQL ClusterMySQL 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.

É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.

16.2. Conceptos básicos de Basic MySQL ClusterNDB 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í.

É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.

16.3. Cómo configurar varios ordenadores[+/-]

16.3.1. Hardware, software y redes 16.3.2. Instalación 16.3.3. Configuración 16.3.4. Arranque inicial 16.3.5. Cargar datos de ejemplo y realizar consultas 16.3.6. Apagado y encendido seguros

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:

1. 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

2. Puede verse mejor en el siguiente diagrama:

3.4. 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.

5. 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.

6. 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.

7. 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.

Es posible usar la Scalable Coherent Interface (SCI) con MySQL Cluster, pero no es un requerimiento. Consulte Sección   16.7, “Usar interconexiones de alta velocidad con MySQL Cluster” para más informació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

16.3.2. Instalació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:

1. 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:

2. groupadd mysql3. useradd -g mysql mysql4. 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 .

5. cd /var/tmp6. tar -xzvf -C /usr/local/bin mysql-max-5.0.10-pc-linux-gnu-i686.tar.gz7. ln -s /usr/local/bin/mysql-max-5.0.10-pc-linux-gnu-i686 mysql8. Cambie al directorio mysql , y ejecute el script proporcionado para crear las bases de datos del

sistema: 9. cd mysql10. scripts/mysql_install_db --user=mysql11. Configure los permisos necesarios para los directorios de MySQL server y de datos: 12. chown -R root .13. chown -R mysql data14. 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” .)

15. Copie el script de arranque de MySQL en el directorio apropiado, hágalo ejecutable, y configúrelo para arrancar junto al sistema operativo:

16. cp support-files/mysql.server /etc/rc.d/init.d/17. chmod +x /etc/rc.d/init.d/mysql.server18. chkconfig --add mysql.server

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:

1. Mueva el directorio /var/tmp , y extraiga ndb_mgm y ndb_mgmd del archivo a un directorio disponible como /usr/local/bin:

2. cd /var/tmp3. tar -zxvf mysql-max-5.0.10-pc-linux-gnu-i686.tar.gz /usr/local/bin

'*/bin/ndb_mgm*'4. Vaya al directorio en que ha desempaquetado los ficheros, y hágalos ejecutables: 5. cd /usr/local/bin6. 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 enginendb-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-clustercd /var/lib/mysql-clustervi 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 replicasDataMemory=80M # How much memory to allocate for data storageIndexMemory=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 nodedatadir=/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 addressdatadir=/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 addressdatadir=/usr/local/mysql/data # Directory for this data node's datafiles

[MYSQLD] # SQL node options:hostname=192.168.0.20 # Hostname or IP addressdatadir=/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:

1. En la máquina de administración, realice el siguiente comando del shell del sistema para arrancar los procesos del nodo MGM:

2. shell> ndb_mgmd -f /var/lib/mysql-cluster/config.ini

Tenga en cuenta que ndb_mgmd debe saber dónde encontrar su fichero de configuración , usando la opción -f o --config-file . (Consulte Sección   16.5.3, “El proceso del servidor de administración ndb_mgmd ” para más detalles.)

3. En cada equipo de los nodos de datos, ejecute este comando para arrancar el proceso NDBD por primera vez:

4. shell> ndbd --initial

Tenga en cuenta que es muy imporante usar el parámetro --initial só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.

5. En la máquina cluster donde reside el nodo SQL, ejecute un mysqld normal como se muestra: 6. 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:

shell> ndb_mgm-- NDB Cluster -- Management Client --ndb_mgm> showConnected to Management Server at: localhost:1186Cluster Configuration---------------------[ndbd(NDB)] 2 node(s)id=2 @192.168.0.30 (Version: 5.0.11, Nodegroup: 0, Master)id=3 @192.168.0.40 (Version: 5.0.11, Nodegroup: 0)

[ndb_mgmd(MGM)] 1 node(s)id=1 @192.168.0.10 (Version: 5.0.11)

[mysqld(SQL)] 1 node(s)id=4 (Version: 5.0.11)

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/datashell> 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 registrarse en el MySQL Monitor normalmente:

shell> mysql -u root -pEnter 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> \qBye

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): shell> ndb_mgmd -f /var/lib/mysql-cluster/config.ini En cada uno de los nodos de datos (192.168.0.30 y 192.168.0.40): shell> ndbd

Recuerde de no invocar este comando con la opción --initial cuando reinicie el nodo NDBD normalmente.

Y en el equipo SQL (192.168.0.20): shell> mysqld &

Para inforamción de hacer copias de seguridad de clusters, consulte Sección   16.6.4.2, “Usar el servidor de administración para crear una copia de seguridad”.

Para restaurar un cluster de una copia de seguridad requiere el uso del comando ndb_restore . Esto se trata en Sección   16.6.4.3, “Cómo restablecer una copia de seguridad de un nodo” .

Más información sobre la configuración del cluster MySQL puede encontrarse en Sección   16.4, “Configuración de MySQL Cluster”.

16.4. Configuración de MySQL Cluster[+/-]

16.4.1. Generar MySQL Cluster desde el código fuente 16.4.2. Instalar el software 16.4.3. Rápido montaje de prueba de MySQL Cluster 16.4.4. Fichero de 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.comDataDir= /var/lib/mysql-cluster

[MYSQLD][MYSQLD][MYSQLD]

Ahora puede arrancar el servidor de administración:

shell> cd /var/lib/mysql-clustershell> 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> mysqlWelcome 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: ctestCreate Table: CREATE TABLE `ctest` ( `i` int(11) default NULL) ENGINE=ndbcluster DEFAULT CHARSET=latin11 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> SHOWCluster 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.

16.4.4. Fichero de configuración[+/-]

16.4.4.1. Ejemplo de configuración para MySQL Cluster 16.4.4.2. El connectstring de MySQL Cluster 16.4.4.3. Definir los equipos que forman un cluster MySQL

16.4.4.4. Definición del servidor de administración de MySQL Cluster 16.4.4.5. Definir los nodos de MySQL Cluster 16.4.4.6. Definir los servidores MySQL (nodos sql) en un MySQL Cluster 16.4.4.7. Conexiones TCP/IP de MySQL Cluster 16.4.4.8. Conexiones TCP/IP de MySQL Cluster usando conexiones directas 16.4.4.9. Conexiones de MySQL Cluster que comparten memoria 16.4.4.10. Conexiones de transporte SCI en MySQL Cluster

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]ndbclusterndb-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

(Para más información acerca de los connectstrings, consulte Sección   16.4.4.2, “El connectstring de MySQL Cluster”.)

# 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]ndbclusterndb-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:

# cluster-specific settings[mysql_cluster]ndb-connectstring=ndb_mgmd.mysql.com:1186

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= 2DataDir= /var/lib/mysql-cluster

[NDB_MGMD]Hostname= ndb_mgmd.mysql.comDataDir= /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:

<connectstring> :=[<nodeid-specification>,]<host-specification>[,<host-specification>]<nodeid-specification> := nodeid=<id><host-specification> := <host>[:<port>]

<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:

a. Inicialice la variable de entorno NDB_CONNECTSTRING para que contenga el connectstring. b. 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 registro 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:

o filename: Nombre del fichero de log. o 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.

o maxfiles: Número máximo de ficheros de log. FILE:filename=cluster.log,maxsize=1000000,maxfiles=6

Es posible especificar múltiples destinaciones de logs como se muestra aquí, usando una cadena delimitada por puntos y comas:

CONSOLE;SYSLOG:facility=local0;FILE:filename=/var/log/mgmd

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 ExecuteOnComputer deben 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_name table_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.

Registro 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 registran. 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:

a. El nodo está “muerto” b. La operación ha entrado en una cola de bloqueo c. 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:

# Management Server[NDB_MGMD]Id=1HostName=172.23.72.20

# SQL Node[MYSQLD]Id=2HostName=172.23.72.21

# Data Nodes[NDBD]Id=3HostName=172.23.72.22

[NDBD]Id=4HostName=172.23.72.23

# TCP/IP Connections[TCP]NodeId1=3NodeId2=4HostName1=1.1.0.1HostName2=1.1.0.2

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.

16.5.1. El uso del proceso del servidor MySQL para MySQL Cluster 16.5.2. ndbd , el proceso del nodo de motor de almacenamiento 16.5.3. El proceso del servidor de administración ndb_mgmd 16.5.4. El proceso de cliente de administración ndb_mgm 16.5.5. Opciones de comando para procesos de MySQL Cluster

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 mysqld ndb-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:

shell> mysqld --ndb-connectstring=ndb_mgmd.mysql.com: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.

shell> ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186"

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 servidor 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.

shell> ndb_mgm localhost 1186

Más información puede acerca de ndb_mgm puede encontrarse en Sección   16.5.5.4, “Opciones de comando para ndb_mgm ” y Sección   16.6.1, “Comandos del cliente de administración” .

16.5.5. Opciones de comando para procesos de MySQL Cluster[+/-]

16.5.5.1. Opciones de mysqld relacionadas con MySQL Cluster 16.5.5.2. Opciones de comando para ndbd 16.5.5.3. Opciones del comando ndb_mgmd 16.5.5.4. Opciones de comando para ndb_mgm

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.

shell> ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186" --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:

shell> ndb_mgm -e show

o

shell> ndb_mgm --execute="SHOW"

es equivalente a

NDB> SHOW;

Esto es análogo a cómo la opción -e funciona con el cliente de línea de comandos mysql . Consulte Sección   4.3.1, “Usar opciones en la línea de 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.

16.5.5.2. Opciones de comando para ndbd

Para opciones comunes consulte Sección   16.5.5, “Opciones de comando para procesos de MySQL 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.

16.5.5.3. Opciones del comando ndb_mgmd

Para algunas opciones comunes consulte Sección   16.5.5, “Opciones de comando para procesos de MySQL Cluster”.

-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.

16.5.5.4. Opciones de comando para ndb_mgm

Para algunas opciones comunes consulte Sección   16.5.5, “Opciones de comando para procesos de MySQL Cluster”.

[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.

16.6. Administración de MySQL Cluster[+/-]

16.6.1. Comandos del cliente de administración 16.6.2. Informes de eventos generados por MySQL Cluster 16.6.3. Modo de usuario único 16.6.4. Copias de seguridad On-line para MySQL Cluster

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.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 7SHUTDOWN 7STATISTICS 7CHECKPOINT 7NODERESTART 7CONNECTION 7ERROR 15INFO 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:

09:19:30 2005-07-24 [NDB] INFO -- Node 4 Start phase 4 completed

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 3 INFO Muestra el nodo, nodo de administración, e

con éxito en el cluster 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 7 INFO  

completado

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:

a. Terminar todas las transacciones de modo de usuario único. b. Ejecutar el comando EXIT SINGLE USER MODE c. 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[+/-]

16.6.4.1. Conceptos de copias de seguridad de nodos 16.6.4.2. Usar el servidor de administración para crear una copia de seguridad 16.6.4.3. Cómo restablecer una copia de seguridad de un nodo 16.6.4.4. Configuración para copias de seguridad de un nodo 16.6.4.5. Resolver problemas con copias de seguridad

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:

1. Arrancar el servidor de administración (ndb_mgm). 2. Ejecutar el comando START BACKUP. 3. 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.

4. 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.

5. 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:

1. Arranque el servidor de administración. 2. 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"').

3. 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.

4. 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_mgm SHOW (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.

Puede encontrar información más detallada sobre estos parámetros en Sección   16.4, “Configuración de MySQL Cluster”.

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

[+/-]

16.7.1. Configurar MySQL Cluster para que utilice Sockets SCI 16.7.2. Entender el impacto de interconexiones de nodos

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:

1. Compilar las bibliotecas SCI Socket. 2. Instlara las bibliotecas del kernel SCI Socket. 3. Instalación de uno o dos ficheros de configuración. 4. 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 :

1. El paquete de código fuente con las bibliotecas de soporte DIS para las bibliotecas SCI Sockets . 2. 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.gzshell> cd DIS_GPL_2_5_0_SEP_10_2004/src/shell> tar xzf ../../SCI_SOCKET_2_3_0_OKT_01_2004.tar.gzshell> cd ../adm/bin/Linux_pkgsshell> ./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 , ejecute 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 /optshell> tar xzf DIS_Linux_2.4.20-8_181004.tar.gzshell> 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 #nodeIdalpha 8beta 12192.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í:

#-key -type -valuesEnablePortsByDefault yesEnablePort tcp 2200DisablePort tcp 2201EnablePortRange tcp 2202 2219DisablePortRange tcp 2220 2231

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 PSB66shell> ./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/utilshell> ./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/socketshell> ./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/socketshell> ./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:

bash-shell> export LD_PRELOAD=/opt/DIS/lib/libkscisock.sobash-shell> ndbd

En un entorno tcsh se puede hacer lo mismo con:

tcsh-shell> setenv LD_PRELOAD=/opt/DIS/lib/libkscisock.sotcsh-shell> ndbd

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+ .

Tipo de acceso: TCP/IP sockets SCI SocketAcceso Serial clave primaria: 400 microsegundos 160 microsegundosAcceso Batched clave primaria 28 microsegundos 22 microsegundosAcceso Serial indice unico: 500 microsegundos 250 microsegundosAcceso Batched indice unico: 70 microsegundos 36 microsegundosAcceso Indexado igualdad: 1250 microsegundos 750 microsegundosÍndice rango: 24 microsegundos 12 microsegundos

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 ClusterEn 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:

o Tamaño de memoria de base de datos y de memoria índice (DataMemory y IndexMemory, respectivamente).

o 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.

o 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.

16.9. Mapa de desarrollo de MySQL Cluster[+/-]

16.9.1. Cambios de MySQL Cluster en MySQL 5.0 16.9.2. Mapa de desarrollo de MySQL 5.1 para MySQL Cluster

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.

Caché de consulta activada para MySQL Cluster: Consulte Sección   5.12, “La caché de consultas de MySQL” para información acerca de configurar el uso de la caché de consulta.

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:

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.

2. 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.

3. 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.

4. 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 algún 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 huésped cluster. Idealmente, habrá un nodo por huésped 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:

a. 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.

b. nodo de datos: Almacena y replica datos. La funcionalidad de los nodos de datos la trata una instancia del proceso NDB ndbd.

c. 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ándar 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ándar (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 saber qué significan los mensajes de error o advertencias al usar Cluster?

Se puede hacer de dos modos:

a. 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.

b. 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 NDB no 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 . Todaví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:

(SizeofDatabase * NumberOfReplicas * 1.1 ) / NumberOfDataNodes

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 ejecutar 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 ejecutando 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. Capítulo   18, Extensiones espaciales de MySQL no se soportan. 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. No se soporta el caché de consulta.

Para información adicional de limitaciones de cluster, consulte Sección   16.8, “Limitaciones conocidas de MySQL Cluster”.

¿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 mediante 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 problema real es cuando un grupo no tiene todos sus nodos vivos, en tal caso la partición de red (el escenario “split-brain” mencionado 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:

a. Arranque el nodo de administración con el comando ndb_mgmd . b. Arranque cada nodo de datos con el comando ndbd. c. 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:

shell> ndb_mgm -e shutdown

Esto hace que ndb_mgm, ndb_mgm, y cualquier proceso ndbd termina correctamente. MySQL servers corriendo como nodos Cluster SQL pueden pararse usando mysqladmin shutdown.

Para más información, consulte Sección   16.6.1, “Comandos del cliente de administración” y Sección   16.3.6, “Apagado y encendido seguros” .

¿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 ejecutar 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 ClusterLos 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.

SCI

Scalable Coherent Interface es un protocolo de alta velocidad usado para montar sistemas multiprocesador y aplicaciones paralelas. El uso de SCI con MySQL Cluster requiere hardware especializado y se discute en Sección   16.7.1, “Configurar MySQL Cluster para

que utilice Sockets SCI”. Para una introducción básica a SCI, consulte este ensayo de dolphinics.com.

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 ejecutar 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

Para más información de estos programas, consulte Sección   16.5, “Gestión de procesos en MySQL Cluster”.

Log de eventos:

MySQL Cluster registra 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.

Introduction

This document provides a high-level overview of Red Hat Cluster Suite for Red Hat Enterprise Linux 5 and is is organized as follows:

Chapter   1, Red Hat Cluster Suite Overview Chapter   2, Red Hat Cluster Suite Component Summary

Although the information in this document is an overview, you should have advanced working knowledge of Red Hat Enterprise Linux and understand the concepts of server computing to gain a good comprehension of the information.

For more information about using Red Hat Enterprise Linux, refer to the following resources:

Red Hat Enterprise Linux Installation Guide — Provides information regarding installation of Red Hat Enterprise Linux 5.

Red Hat Enterprise Linux Deployment Guide — Provides information regarding the deployment, configuration and administration of Red Hat Enterprise Linux 5.

For more information about Red Hat Cluster Suite for Red Hat Enterprise Linux 5, refer to the following resources:

Configuring and Managing a Red Hat Cluster — Provides information about installing, configuring and managing Red Hat Cluster components.

LVM Administrator's Guide: Configuration and Administration — Provides a description of the Logical Volume Manager (LVM), including information on running LVM in a clustered environment.

Global File System: Configuration and Administration — Provides information about installing, configuring, and maintaining Red Hat GFS (Red Hat Global File System).

Using Device-Mapper Multipath — Provides information about using the Device-Mapper Multipath feature of Red Hat Enterprise Linux 5.

Using GNBD with Global File System — Provides an overview on using Global Network Block Device (GNBD) with Red Hat GFS.

Linux Virtual Server Administration — Provides information on configuring high-performance systems and services with the Linux Virtual Server (LVS).

Red Hat Cluster Suite Release Notes — Provides information about the current release of Red Hat Cluster Suite.

Red Hat Cluster Suite documentation and other Red Hat documents are available in HTML, PDF, and RPM versions on the Red Hat Enterprise Linux Documentation CD and online at http://www.redhat.com/docs/.

1.1. Cluster Basics

A cluster is two or more computers (called nodes or members) that work together to perform a task. There are four major types of clusters:

Storage High availability Load balancing High performance

Storage clusters provide a consistent file system image across servers in a cluster, allowing the servers to simultaneously read and write to a single shared file system. A storage cluster simplifies storage administration by limiting the installation and patching of applications to one file system. Also, with a cluster-wide file system, a storage cluster eliminates the need for redundant copies of application data and simplifies backup and disaster recovery. Red Hat Cluster Suite provides storage clustering through Red Hat GFS.

High-availability clusters provide continuous availability of services by eliminating single points of failure and by failing over services from one cluster node to another in case a node becomes inoperative. Typically, services in a high-availability cluster read and write data (via read-write mounted file systems). Therefore, a high-availability cluster must maintain data integrity as one cluster node takes over control of a service from another cluster node. Node failures in a high-availability cluster are not visible from clients outside the cluster. (High-availability clusters are sometimes referred to as failover clusters.) Red Hat Cluster Suite provides high-availability clustering through its High-availability Service Management component.

Load-balancing clusters dispatch network service requests to multiple cluster nodes to balance the request load among the cluster nodes. Load balancing provides cost-effective scalability because you

can match the number of nodes according to load requirements. If a node in a load-balancing cluster becomes inoperative, the load-balancing software detects the failure and redirects requests to other cluster nodes. Node failures in a load-balancing cluster are not visible from clients outside the cluster. Red Hat Cluster Suite provides load-balancing through LVS (Linux Virtual Server).

High-performance clusters use cluster nodes to perform concurrent calculations. A high-performance cluster allows applications to work in parallel, therefore enhancing the performance of the applications. (High performance clusters are also referred to as computational clusters or grid computing.)

1.2. Red Hat Cluster Suite Introduction

Red Hat Cluster Suite (RHCS) is an integrated set of software components that can be deployed in a variety of configurations to suit your needs for performance, high-availability, load balancing, scalability, file sharing, and economy.

RHCS consists of the following major components (refer to Figure   1.1, “Red Hat Cluster Suite Introduction”):

Cluster infrastructure — Provides fundamental functions for nodes to work together as a cluster: configuration-file management, membership management, lock management, and fencing.

High-availability Service Management — Provides failover of services from one cluster node to another in case a node becomes inoperative.

Cluster administration tools — Configuration and management tools for setting up, configuring, and managing a Red Hat cluster. The tools are for use with the Cluster Infrastructure components, the High-availability and Service Management components, and storage.

Linux Virtual Server (LVS) — Routing software that provides IP-Load-balancing. LVS runs in a pair of redundant servers that distributes client requests evenly to real servers that are behind the LVS servers.

You can supplement Red Hat Cluster Suite with the following components, which are part of an optional package (and not part of Red Hat Cluster Suite):

Red Hat GFS (Global File System) — Provides a cluster file system for use with Red Hat Cluster Suite. GFS allows multiple nodes to share storage at a block level as if the storage were connected locally to each cluster node.

Cluster Logical Volume Manager (CLVM) — Provides volume management of cluster storage.

Global Network Block Device (GNBD) — An ancillary component of GFS that exports block-level storage to Ethernet. This is an economical way to make block-level storage available to Red Hat GFS.

For a lower level summary of Red Hat Cluster Suite components and optional software, refer to Chapter   2, Red Hat Cluster Suite Component Summary .

Red Hat Cluster Suite Introduction

1.3. Cluster Infrastructure

The Red Hat Cluster Suite cluster infrastructure provides the basic functions for a group of computers (called nodes or members) to work together as a cluster. Once a cluster is formed using the cluster infrastructure, you can use other Red Hat Cluster Suite components to suit your clustering needs (for example, setting up a cluster for sharing files on a GFS file system or setting up service failover). The cluster infrastructure performs the following functions:

Cluster management Lock management Fencing Cluster configuration management

1.3.1. Cluster Management

Cluster management manages cluster quorum and cluster membership. CMAN (an abbreviation for cluster

manager) performs cluster management in Red Hat Cluster Suite for Red Hat Enterprise Linux 5. CMAN is a

distributed cluster manager and runs in each cluster node; cluster management is distributed across all

nodes in the cluster (refer to Figure   1.2, “CMAN/DLM Overview” ).

CMAN keeps track of cluster quorum by monitoring the count of cluster nodes. If more than half the nodes

are active, the cluster has quorum. If half the nodes (or fewer) are active, the cluster does not have quorum,

and all cluster activity is stopped. Cluster quorum prevents the occurrence of a "split-brain" condition — a

condition where two instances of the same cluster are running. A split-brain condition would allow each

cluster instance to access cluster resources without knowledge of the other cluster instance, resulting in

corrupted cluster integrity.

Quorum is determined by communication of messages among cluster nodes via Ethernet. Optionally,

quorum can be determined by a combination of communicating messages via Ethernet and through a

quorum disk. For quorum via Ethernet, quorum consists of 50 percent of the node votes plus 1. For quorum

via quorum disk, quorum consists of user-specified conditions.

1.3.2. Lock Management

Lock management is a common cluster-infrastructure service that provides a mechanism for other cluster

infrastructure components to synchronize their access to shared resources. In a Red Hat cluster, DLM

(Distributed Lock Manager) is the lock manager. As implied in its name, DLM is a distributed lock manager

and runs in each cluster node; lock management is distributed across all nodes in the cluster (refer to

Figure   1.2, “CMAN/DLM Overview” ). GFS and CLVM use locks from the lock manager. GFS uses locks from

the lock manager to synchronize access to file system metadata (on shared storage). CLVM uses locks from

the lock manager to synchronize updates to LVM volumes and volume groups (also on shared storage).

1.3.3. Fencing

Fencing is the disconnection of a node from the cluster's shared storage. Fencing cuts off I/O from shared

storage, thus ensuring data integrity. The cluster infrastructure performs fencing through the fence daemon,

fenced.

When CMAN determines that a node has failed, it communicates to other cluster-infrastructure components

that the node has failed. fenced, when notified of the failure, fences the failed node. Other cluster-

infrastructure components determine what actions to take — that is, they perform any recovery that needs

to done. For example, DLM and GFS, when notified of a node failure, suspend activity until they detect that

fenced has completed fencing the failed node. Upon confirmation that the failed node is fenced, DLM and

GFS perform recovery. DLM releases locks of the failed node; GFS recovers the journal of the failed node.

The fencing program determines from the cluster configuration file which fencing method to use. Two key

elements in the cluster configuration file define a fencing method: fencing agent and fencing device. The

fencing program makes a call to a fencing agent specified in the cluster configuration file. The fencing agent,

in turn, fences the node via a fencing device. When fencing is complete, the fencing program notifies the

cluster manager.

Red Hat Cluster Suite provides a variety of fencing methods:

Power fencing — A fencing method that uses a power controller to power off an inoperable node.

Fibre Channel switch fencing — A fencing method that disables the Fibre Channel port that connects

storage to an inoperable node.

GNBD fencing — A fencing method that disables an inoperable node's access to a GNBD server.

Other fencing — Several other fencing methods that disable I/O or power of an inoperable node,

including IBM Bladecenters, PAP, DRAC/MC, HP ILO, IPMI, IBM RSA II, and others.

Figure   1.3, “Power Fencing Example” shows an example of power fencing. In the example, the fencing

program in node A causes the power controller to power off node D. Figure   1.4, “Fibre Channel Switch

Fencing Example” shows an example of Fibre Channel switch fencing. In the example, the fencing program

in node A causes the Fibre Channel switch to disable the port for node D, disconnecting node D from storage.

Power Fencing Example

Figure 1.3. Power Fencing Example

Fibre Channel Switch Fencing Example

Figure 1.4. Fibre Channel Switch Fencing Example

Specifying a fencing method consists of editing a cluster configuration file to assign a fencing-method name,

the fencing agent, and the fencing device for each node in the cluster.

The way in which a fencing method is specified depends on if a node has either dual power supplies or

multiple paths to storage. If a node has dual power supplies, then the fencing method for the node must

specify at least two fencing devices — one fencing device for each power supply (refer to Figure   1.5,

“Fencing a Node with Dual Power Supplies”). Similarly, if a node has multiple paths to Fibre Channel storage,

then the fencing method for the node must specify one fencing device for each path to Fibre Channel

storage. For example, if a node has two paths to Fibre Channel storage, the fencing method should specify

two fencing devices — one for each path to Fibre Channel storage (refer to Figure   1.6, “Fencing a Node with

Dual Fibre Channel Connections”).

Fencing a Node with Dual Power Supplies

Figure 1.5. Fencing a Node with Dual Power Supplies

Fencing a Node with Dual Fibre Channel Connections

Figure 1.6. Fencing a Node with Dual Fibre Channel Connections

You can configure a node with one fencing method or multiple fencing methods. When you configure a node

for one fencing method, that is the only fencing method available for fencing that node. When you configure

a node for multiple fencing methods, the fencing methods are cascaded from one fencing method to another

according to the order of the fencing methods specified in the cluster configuration file. If a node fails, it is

fenced using the first fencing method specified in the cluster configuration file for that node. If the first

fencing method is not successful, the next fencing method specified for that node is used. If none of the

fencing methods is successful, then fencing starts again with the first fencing method specified, and

continues looping through the fencing methods in the order specified in the cluster configuration file until the

node has been fenced.

1.3.4. Cluster Configuration System

The Cluster Configuration System (CCS) manages the cluster configuration and provides configuration

information to other cluster components in a Red Hat cluster. CCS runs in each cluster node and makes sure

that the cluster configuration file in each cluster node is up to date. For example, if a cluster system

administrator updates the configuration file in Node A, CCS propagates the update from Node A to the other

nodes in the cluster (refer to Figure   1.7, “CCS Overview” ).

CCS Overview

Figure 1.7. CCS Overview

Other cluster components (for example, CMAN) access configuration information from the configuration file

through CCS (refer to Figure   1.7, “CCS Overview” ).

Accessing Configuration Information

Figure 1.8. Accessing Configuration Information

The cluster configuration file (/etc/cluster/cluster.conf) is an XML file that describes the following cluster

characteristics:

← Cluster name — Displays the cluster name, cluster configuration file revision level, and basic fence

timing properties used when a node joins a cluster or is fenced from the cluster.

← Cluster — Displays each node of the cluster, specifying node name, node ID, number of quorum

votes, and fencing method for that node.

← Fence Device — Displays fence devices in the cluster. Parameters vary according to the type of

fence device. For example for a power controller used as a fence device, the cluster configuration

defines the name of the power controller, its IP address, login, and password.

← Managed Resources — Displays resources required to create cluster services. Managed resources

includes the definition of failover domains, resources (for example an IP address), and services.

Together the managed resources define cluster services and failover behavior of the cluster services.

1.4. High-availability Service Management

High-availability service management provides the ability to create and manage high-availability cluster

services in a Red Hat cluster. The key component for high-availability service management in a Red Hat

cluster, rgmanager, implements cold failover for off-the-shelf applications. In a Red Hat cluster, an application

is configured with other cluster resources to form a high-availability cluster service. A high-availability cluster

service can fail over from one cluster node to another with no apparent interruption to cluster clients.

Cluster-service failover can occur if a cluster node fails or if a cluster system administrator moves the service

from one cluster node to another (for example, for a planned outage of a cluster node).

To create a high-availability service, you must configure it in the cluster configuration file. A cluster service

comprises cluster resources. Cluster resources are building blocks that you create and manage in the cluster

configuration file — for example, an IP address, an application initialization script, or a Red Hat GFS shared

partition.

You can associate a cluster service with a failover domain. A failover domain is a subset of cluster nodes that

are eligible to run a particular cluster service (refer to Figure   1.9, “Failover Domains” ).

NoteFailover domains are not required for operation.

A cluster service can run on only one cluster node at a time to maintain data integrity. You can specify

failover priority in a failover domain. Specifying failover priority consists of assigning a priority level to each

node in a failover domain. The priority level determines the failover order — determining which node that a

cluster service should fail over to. If you do not specify failover priority, a cluster service can fail over to any

node in its failover domain. Also, you can specify if a cluster service is restricted to run only on nodes of its

associated failover domain. (When associated with an unrestricted failover domain, a cluster service can

start on any cluster node in the event no member of the failover domain is available.)

In Figure   1.9, “Failover Domains” , Failover Domain 1 is configured to restrict failover within that domain;

therefore, Cluster Service X can only fail over between Node A and Node B. Failover Domain 2 is also

configured to restrict failover with its domain; additionally, it is configured for failover priority. Failover

Domain 2 priority is configured with Node C as priority 1, Node B as priority 2, and Node D as priority 3. If

Node C fails, Cluster Service Y fails over to Node B next. If it cannot fail over to Node B, it tries failing over to

Node D. Failover Domain 3 is configured with no priority and no restrictions. If the node that Cluster Service

Z is running on fails, Cluster Service Z tries failing over to one of the nodes in Failover Domain 3. However, if

none of those nodes is available, Cluster Service Z can fail over to any node in the cluster.

Failover domains

Figure 1.9. Failover Domains

Figure   1.10, “Web Server Cluster Service Example” shows an example of a high-availability cluster service

that is a web server named "content-webserver". It is running in cluster node B and is in a failover domain

that consists of nodes A, B, and D. In addition, the failover domain is configured with a failover priority to fail

over to node D before node A and to restrict failover to nodes only in that failover domain. The cluster

service comprises these cluster resources:

← IP address resource — IP address 10.10.10.201.

← An application resource named "httpd-content" — a web server application init script

/etc/init.d/httpd (specifying httpd).

← A file system resource — Red Hat GFS named "gfs-content-webserver".

Web Server Cluster Service Example

Figure 1.10. Web Server Cluster Service Example

Clients access the cluster service through the IP address 10.10.10.201, enabling interaction with the web

server application, httpd-content. The httpd-content application uses the gfs-content-webserver file system.

If node B were to fail, the content-webserver cluster service would fail over to node D. If node D were not

available or also failed, the service would fail over to node A. Failover would occur with no apparent

interruption to the cluster clients. The cluster service would be accessible from another cluster node via the

same IP address as it was before failover.

1.5. Red Hat GFS

Red Hat GFS is a cluster file system that allows a cluster of nodes to simultaneously access a block device

that is shared among the nodes. GFS is a native file system that interfaces directly with the VFS layer of the

Linux kernel file-system interface. GFS employs distributed metadata and multiple journals for optimal

operation in a cluster. To maintain file system integrity, GFS uses a lock manager to coordinate I/O. When

one node changes data on a GFS file system, that change is immediately visible to the other cluster nodes

using that file system.

Using Red Hat GFS, you can achieve maximum application uptime through the following benefits:

← Simplifying your data infrastructure

← Install and patch applications once for the entire cluster.

← Eliminates the need for redundant copies of application data (duplication).

← Enables concurrent read/write access to data by many clients.

← Simplifies backup and disaster recovery (only one file system to back up or recover).

← Maximize the use of storage resources; minimize storage administration costs.

← Manage storage as a whole instead of by partition.

← Decrease overall storage needs by eliminating the need for data replications.

← Scale the cluster seamlessly by adding servers or storage on the fly.

← No more partitioning storage through complicated techniques.

← Add servers to the cluster on the fly by mounting them to the common file system.

Nodes that run Red Hat GFS are configured and managed with Red Hat Cluster Suite configuration and

management tools. Volume management is managed through CLVM (Cluster Logical Volume Manager). Red

Hat GFS provides data sharing among GFS nodes in a Red Hat cluster. GFS provides a single, consistent view

of the file-system name space across the GFS nodes in a Red Hat cluster. GFS allows applications to install

and run without much knowledge of the underlying storage infrastructure. Also, GFS provides features that

are typically required in enterprise environments, such as quotas, multiple journals, and multipath support.

GFS provides a versatile method of networking storage according to the performance, scalability, and

economic needs of your storage environment. This chapter provides some very basic, abbreviated

information as background to help you understand GFS.

You can deploy GFS in a variety of configurations to suit your needs for performance, scalability, and

economy. For superior performance and scalability, you can deploy GFS in a cluster that is connected

directly to a SAN. For more economical needs, you can deploy GFS in a cluster that is connected to a LAN

with servers that use GNBD (Global Network Block Device) or to iSCSI (Internet Small Computer System

Interface) devices. (For more information about GNBD, refer to Section   1.7, “Global Network Block Device” .)

The following sections provide examples of how GFS can be deployed to suit your needs for performance,

scalability, and economy:

← Section   1.5.1, “Superior Performance and Scalability”

← Section   1.5.2, “Performance, Scalability, Moderate Price”

← Section   1.5.3, “Economy and Performance”

1.5.1. Superior Performance and Scalability

You can obtain the highest shared-file performance when applications access storage directly. The GFS SAN

configuration in Figure   1.11, “GFS with a SAN” provides superior file performance for shared files and file

systems. Linux applications run directly on cluster nodes using GFS. Without file protocols or storage servers

to slow data access, performance is similar to individual Linux servers with directly connected storage; yet,

each GFS application node has equal access to all data files. GFS supports over 300 GFS nodes.

GFS with a SAN

Figure 1.11. GFS with a SAN

1.5.2. Performance, Scalability, Moderate Price

Multiple Linux client applications on a LAN can share the same SAN-based data as shown in Figure   1.12,

“GFS and GNBD with a SAN”. SAN block storage is presented to network clients as block storage devices by

GNBD servers. From the perspective of a client application, storage is accessed as if it were directly attached

to the server in which the application is running. Stored data is actually on the SAN. Storage devices and

data can be equally shared by network client applications. File locking and sharing functions are handled by

GFS for each network client.

GFS and GNBD with a SAN

Figure 1.12. GFS and GNBD with a SAN

1.5.3. Economy and Performance

Figure   1.13, “GFS and GNBD with Directly Connected Storage” shows how Linux client applications can take

advantage of an existing Ethernet topology to gain shared access to all block storage devices. Client data

files and file systems can be shared with GFS on each client. Application failover can be fully automated with

Red Hat Cluster Suite.

GFS and GNBD with Direct-Attached Storage

Figure 1.13. GFS and GNBD with Directly Connected Storage

1.6. Cluster Logical Volume Manager

The Cluster Logical Volume Manager (CLVM) provides a cluster-wide version of LVM2. CLVM provides the

same capabilities as LVM2 on a single node, but makes the volumes available to all nodes in a Red Hat

cluster. The logical volumes created with CLVM make logical volumes available to all nodes in a cluster.

The key component in CLVM is clvmd. clvmd is a daemon that provides clustering extensions to the standard

LVM2 tool set and allows LVM2 commands to manage shared storage. clvmd runs in each cluster node and

distributes LVM metadata updates in a cluster, thereby presenting each cluster node with the same view of

the logical volumes (refer to Figure   1.14, “CLVM Overview” ). Logical volumes created with CLVM on shared

storage are visible to all nodes that have access to the shared storage. CLVM allows a user to configure

logical volumes on shared storage by locking access to physical storage while a logical volume is being

configured. CLVM uses the lock-management service provided by the cluster infrastructure (refer to

Section   1.3, “Cluster Infrastructure” ).

1.7. Global Network Block Device

Global Network Block Device (GNBD) provides block-device access to Red Hat GFS over TCP/IP. GNBD is

similar in concept to NBD; however, GNBD is GFS-specific and tuned solely for use with GFS. GNBD is useful

when the need for more robust technologies — Fibre Channel or single-initiator SCSI — are not necessary or

are cost-prohibitive.

GNBD consists of two major components: a GNBD client and a GNBD server. A GNBD client runs in a node

with GFS and imports a block device exported by a GNBD server. A GNBD server runs in another node and

exports block-level storage from its local storage (either directly attached storage or SAN storage). Refer to

Figure   1.18, “GNBD Overview” . Multiple GNBD clients can access a device exported by a GNBD server, thus

making a GNBD suitable for use by a group of nodes running GFS.

CLVM Overview

Figure 1.18. GNBD Overview

1.8. Linux Virtual Server

Linux Virtual Server (LVS) is a set of integrated software components for balancing the IP load across a set of

real servers. LVS runs on a pair of equally configured computers: one that is an active LVS router and one

that is a backup LVS router. The active LVS router serves two roles:

← To balance the load across the real servers.

← To check the integrity of the services on each real server.

The backup LVS router monitors the active LVS router and takes over from it in case the active LVS router

fails.

Figure   1.19, “Components of a Running LVS Cluster” provides an overview of the LVS components and their

interrelationship.

Components of a Running LVS Cluster

Figure 1.19. Components of a Running LVS Cluster

The pulse daemon runs on both the active and passive LVS routers. On the backup LVS router, pulse sends a

heartbeat to the public interface of the active router to make sure the active LVS router is properly

functioning. On the active LVS router, pulse starts the lvs daemon and responds to heartbeat queries from

the backup LVS router.

Once started, the lvs daemon calls the ipvsadm utility to configure and maintain the IPVS (IP Virtual Server)

routing table in the kernel and starts a nanny process for each configured virtual server on each real server.

Each nanny process checks the state of one configured service on one real server, and tells the lvs daemon if

the service on that real server is malfunctioning. If a malfunction is detected, the lvs daemon instructs

ipvsadm to remove that real server from the IPVS routing table.

If the backup LVS router does not receive a response from the active LVS router, it initiates failover by calling

send_arp to reassign all virtual IP addresses to the NIC hardware addresses (MAC address) of the backup LVS

router, sends a command to the active LVS router via both the public and private network interfaces to shut

down the lvs daemon on the active LVS router, and starts the lvs daemon on the backup LVS router to

accept requests for the configured virtual servers.

To an outside user accessing a hosted service (such as a website or database application), LVS appears as

one server. However, the user is actually accessing real servers behind the LVS routers.

Because there is no built-in component in LVS to share the data among real servers, you have have two

basic options:

← Synchronize the data across the real servers.

← Add a third layer to the topology for shared data access.

The first option is preferred for servers that do not allow large numbers of users to upload or change data on

the real servers. If the real servers allow large numbers of users to modify data, such as an e-commerce

website, adding a third layer is preferable.

There are many ways to synchronize data among real servers. For example, you can use shell scripts to post

updated web pages to the real servers simultaneously. Also, you can use programs such as rsync to replicate

changed data across all nodes at a set interval. However, in environments where users frequently upload

files or issue database transactions, using scripts or the rsync command for data synchronization does not

function optimally. Therefore, for real servers with a high amount of uploads, database transactions, or

similar traffic, a three-tiered topology is more appropriate for data synchronization.

1.8.1. Two-Tier LVS Topology

Figure   1.20, “Two-Tier LVS Topology” shows a simple LVS configuration consisting of two tiers: LVS routers

and real servers. The LVS-router tier consists of one active LVS router and one backup LVS router. The real-

server tier consists of real servers connected to the private network. Each LVS router has two network

interfaces: one connected to a public network (Internet) and one connected to a private network. A network

interface connected to each network allows the LVS routers to regulate traffic between clients on the public

network and the real servers on the private network. In Figure   1.20, “Two-Tier LVS Topology” , the active LVS

router uses Network Address Translation (NAT) to direct traffic from the public network to real servers on the

private network, which in turn provide services as requested. The real servers pass all public traffic through

the active LVS router. From the perspective of clients on the public network, the LVS router appears as one

entity.

Two-Tier LVS Topology

Figure 1.20. Two-Tier LVS Topology

Service requests arriving at an LVS router are addressed to a virtual IP address or VIP. This is a publicly-

routable address that the administrator of the site associates with a fully-qualified domain name, such as

www.example.com, and which is assigned to one or more virtual servers[1]. Note that a VIP address migrates

from one LVS router to the other during a failover, thus maintaining a presence at that IP address, also

known as floating IP addresses.

VIP addresses may be aliased to the same device that connects the LVS router to the public network. For

instance, if eth0 is connected to the Internet, then multiple virtual servers can be aliased to eth0:1.

Alternatively, each virtual server can be associated with a separate device per service. For example, HTTP

traffic can be handled on eth0:1, and FTP traffic can be handled on eth0:2.

Only one LVS router is active at a time. The role of the active LVS router is to redirect service requests from

virtual IP addresses to the real servers. The redirection is based on one of eight load-balancing algorithms:

← Round-Robin Scheduling — Distributes each request sequentially around a pool of real servers. Using

this algorithm, all the real servers are treated as equals without regard to capacity or load.

← Weighted Round-Robin Scheduling — Distributes each request sequentially around a pool of real

servers but gives more jobs to servers with greater capacity. Capacity is indicated by a user-

assigned weight factor, which is then adjusted up or down by dynamic load information. This is a

preferred choice if there are significant differences in the capacity of real servers in a server pool.

However, if the request load varies dramatically, a more heavily weighted server may answer more

than its share of requests.

← Least-Connection — Distributes more requests to real servers with fewer active connections. This is a

type of dynamic scheduling algorithm, making it a better choice if there is a high degree of variation

in the request load. It is best suited for a real server pool where each server node has roughly the

same capacity. If the real servers have varying capabilities, weighted least-connection scheduling is

a better choice.

← Weighted Least-Connections (default) — Distributes more requests to servers with fewer active

connections relative to their capacities. Capacity is indicated by a user-assigned weight, which is

then adjusted up or down by dynamic load information. The addition of weighting makes this

algorithm ideal when the real server pool contains hardware of varying capacity.

← Locality-Based Least-Connection Scheduling — Distributes more requests to servers with fewer

active connections relative to their destination IPs. This algorithm is for use in a proxy-cache server

cluster. It routes the packets for an IP address to the server for that address unless that server is

above its capacity and has a server in its half load, in which case it assigns the IP address to the

least loaded real server.

← Locality-Based Least-Connection Scheduling with Replication Scheduling — Distributes more

requests to servers with fewer active connections relative to their destination IPs. This algorithm is

also for use in a proxy-cache server cluster. It differs from Locality-Based Least-Connection

Scheduling by mapping the target IP address to a subset of real server nodes. Requests are then

routed to the server in this subset with the lowest number of connections. If all the nodes for the

destination IP are above capacity, it replicates a new server for that destination IP address by adding

the real server with the least connections from the overall pool of real servers to the subset of real

servers for that destination IP. The most-loaded node is then dropped from the real server subset to

prevent over-replication.

← Source Hash Scheduling — Distributes requests to the pool of real servers by looking up the source

IP in a static hash table. This algorithm is for LVS routers with multiple firewalls.

Also, the active LVS router dynamically monitors the overall health of the specific services on the real

servers through simple send/expect scripts. To aid in detecting the health of services that require dynamic

data, such as HTTPS or SSL, you can also call external executables. If a service on a real server malfunctions,

the active LVS router stops sending jobs to that server until it returns to normal operation.

The backup LVS router performs the role of a standby system. Periodically, the LVS routers exchange

heartbeat messages through the primary external public interface and, in a failover situation, the private

interface. Should the backup LVS router fail to receive a heartbeat message within an expected interval, it

initiates a failover and assumes the role of the active LVS router. During failover, the backup LVS router

takes over the VIP addresses serviced by the failed router using a technique known as ARP spoofing — where

the backup LVS router announces itself as the destination for IP packets addressed to the failed node. When

the failed node returns to active service, the backup LVS router assumes its backup role again.

The simple, two-tier configuration in Figure   1.20, “Two-Tier LVS Topology” is suited best for clusters serving

data that does not change very frequently — such as static web pages — because the individual real servers

do not automatically synchronize data among themselves.

[1] A virtual server is a service configured to listen on a specific virtual IP.

1.8.2. Three-Tier LVS Topology

Figure   1.21, “Three-Tier LVS Topology” shows a typical three-tier LVS configuration. In the example, the

active LVS router routes the requests from the public network (Internet) to the second tier — real servers.

Each real server then accesses a shared data source of a Red Hat cluster in the third tier over the private

network.

Three-Tier LVS Topology

Figure 1.21. Three-Tier LVS Topology

This topology is suited well for busy FTP servers, where accessible data is stored on a central, highly

available server and accessed by each real server via an exported NFS directory or Samba share. This

topology is also recommended for websites that access a central, high-availability database for transactions.

Additionally, using an active-active configuration with a Red Hat cluster, you can configure one high-

availability cluster to serve both of these roles simultaneously.

1.8.3. Routing Methods

You can use Network Address Translation (NAT) routing or direct routing with LVS. The following sections

briefly describe NAT routing and direct routing with LVS.

1.8.4. Persistence and Firewall Marks

In certain situations, it may be desirable for a client to reconnect repeatedly to the same real server, rather

than have an LVS load-balancing algorithm send that request to the best available server. Examples of such

situations include multi-screen web forms, cookies, SSL, and FTP connections. In those cases, a client may

not work properly unless the transactions are being handled by the same server to retain context. LVS

provides two different features to handle this: persistence and firewall marks.