Ahora, empecemos con la configuración desde cero de un slave en una nueva máquina (Ubuntu 8.10).

1. Accedemos, como hemos comentado antes, al archivo my.cnf para configurar en la nueva máquina el slave.
   
sudo gedit /etc/mysql/my.cnf
2. Añadimos las siguientes líneas en el apartado [mysqld] :
   server-id=2
master-host = ip/DNShost
master-user = usuarioslave
master-password = clave_acceso_slave
master-port= 3306
replicate-do-db=base_datos
   Comentamos las líneas de skip-networking y bind-address, como hemos dicho en el post anterior.
3. Reiniciamos el servidor MySQL
   
sudo /etc/init.d/mysql restart
4. Accedemos a la consola de MySQL como root:
   
mysql -u root -p
5. Miraremos el estado y configuración del slave, por si ya se hubiera inicializado automáticamente al arrancar MySql.
   
SHOW SLAVE STATUS \G;
   Y a continuación, aparecerá algo así:
   *************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: IP/DNS_host
Master_User: usuarioslave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 98
Relay_Log_File: mysqld-relay-bin.000021
Relay_Log_Pos: 235
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: base_datos
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 98
Relay_Log_Space: 235
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
1 row in set (0.00 sec)

   NOTA: Si no se muestran estas opciones del slave, iguales o parecidas, podemos estar frente dos casos:

   • Slave_IO_Running y Slave_SQL_Running estén a No, cuyo significado es que no están corriendo (no se ha producido un START SLAVE; o a fallado). Muchas veces se soluciona escribiendo dicha sentencia en la consola de MySQL.
   • Los datos referentes al master, que hemos especificado en el archivo de configuración del slave, no son los correctos. Esto podría pasar en el caso de que previamente tuviéramos unos datos del máster que por cualquier operación sobre él se hayan modificado. Esto se puede resolver con el uso de la instrucción RESET SLAVE; qué lo que hace es eliminar los datos anteriores a una modificación del master y vuelve a cargar los nuevos introducidos en el archivo my.cnf del slave. Otra opción, que he encontrado por Internet, es el uso de la siguiente sentencia indicando los nuevos atributos del master:
     STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='IP/DNSnueva', MASTER_USER='usuarioslave', MASTER_PASSWORD='clave_acceso_slave', MASTER_LOG_FILE='file_log_determinado' ;
START SLAVE;
     NOTA: Este último paso no lo hemos necesitado ya que, una vez inicializado el slave, ha conectado directamente con el master y ha recogido sus datos.

Con esto hemos acabado esta serie de post sobre la configuración de un master-slave en MySQL. Espero que os sirva de ayuda.

Esto es todo, por hoy, desde el zulo, pingüinos y manzanitas world!! (con el jefe perdido xD…)

NOTA: El sistema operativo sobre el cuál realizamos el montaje es Ubuntu 8.10.

Configuración del master

En este apartado os indicaré los pasos que hemos seguido para montar nuestro servidor master.

1. Como muchos de vosotros estaréis pensando, uno de los pasos necesarios para la configuración del sistema de MySQL es la edición de su archivo de configuración (valgase la redundancia). En este caso, efectivamente, lo primero que tendremos que hacer será editar my.cnf con privilegios de root; para ello, abriremos el terminal y escribiremos la siguiente línia (la ruta puede variar. Os dejo la ruta donde se encuentra mi archivo de configuración):
   
sudo gedit /etc/mysql/my.cnf

2. Introducir en el apartado [mysqld] los siguientes atributos:
   
server-id=1
innodb_flush_log_at_trx_commit=1
sync_binlog=1
log-bin=mysql-bin
binlog-do-db=base_datos


   Vamos por partes:

   • El id del server, para definir un master, debe ser 1. Por eso indicamos que server-id=1.
   • innodb_flush_log_at_trx_commit=1 y sync_binlog=1 son dos atributos que colocamos en este caso (leer más en el artículo anterior) ya que decidímos que el master debería tener como motor de almacenamiento el InnoDB. Para más información, consultar la documentación de MySQL.
   • log-bin debe indicar en que archivo se escribirá el log del máster. En este caso, utilizamos el mismo que utiliza MySQL. Os dejo un tutorial en el que podréis ver que este archivo log puede destinarse en cualquier lugar.
   • binlog-do-db=base_datos , le indica al master sobre qué base de datos debe guardar la actividad.

   IMPORTANTE: Comentaremos las opciones de skip-networking y bind-address que se encuentran en ese mismo archivo de configuración, en el caso de que existan. Para comentar las líneas debemos situarnos al principio de la línea y añadir un símbolo #.

3. Reiniciar el servidor MySQL
   
sudo /etc/init.d/mysql restart

4. Acceder a la consola de MySQL, como root.
   
mysql -u root -p

   Dentro crearemos un usuario “slave” para que pueda ponerse en contacto con nuestro master y retendremos información del estado del máster para establecer un punto de inicio antes de comenzar el proceso de replicación con el slave.
   
GRANT REPLICATION SLAVE ON *.* TO 'usuarioslave'@'%' IDENTIFIED BY 'clave_acceso_slave';
FLUSH PRIVILEGES;
USE  base_datos;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
+----------------------------+------------+----------------------+---------------------------+
| File       | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------------------+-------------+----------------------+---------------------------+
| mysql-bin.000007 |       98 | base_datos    |                   |
+----------------------------+------------+----------------------+---------------------------+
UNLOCK TABLES;

   NOTA: ‘%’ puede substituirse también por una dirección IP o DNS concreta. Pero para hacer pruebas, este símbolo ya nos sirve.

5. NOTA2: En el caso en el que queramos más slaves, tendremos que darles permisos a cada uno de ellos, con la línea descrita “GRANT REPLICATION SLAVE ON *.* TO ‘usuarioslave’@'%’ IDENTIFIED BY ‘clave_acceso_slave’;” .
6. Una vez hecho todo esto, saldremos de la consola de MySQL con la sentencia:
   
exit;


NOTA DE LA AUTORA: A partir de aquí empezaría la configuración del slave. Deseo que tengáis paciencia, en breve la acabaré de redactar y la compartiré con vosotros. Si téneis cualquier duda o sugerencia, solo téneis que dejar un comentario . Muchas gracias!

Esto es todo, de momento, desde el zulo, pigüinos y manzaitas world! (aún, sin jefe… )

Intentamos trasladar la idea del Cluster y su montaje a un entorno EC2 de Amazon con su almacenamiento en nube (Elastic Compute Cloud) -más información sobre EC2 en los blogs de Santi y Xavi, o en la página oficial de Amazon EC2- y algo empezó a no cuadrar. Nos dimos cuenta, primeramente, que MySQL Cluster es un sistema cuyo uso es recomendado en redes locales que permitan una rápida velocidad y no es un sistema orientado a sistemas web; aún así, decidimos seguir adelante.

Otra piedra en el camino la encontramos unas horas más tarde, cuando leímos (en algún apartado de la documentación de MySQL Cluster) que la seguridad entre la comunicación de los nodos de datos dejaba bastante que desear ya que ésta no estaba encriptada y corrías el peligro de que pudieran interceptar informaciones del sistema. Es por eso que se recomendaba la proximidad entre nodos; nuestra idea era crear diferentes instancias en EC2 que sirvieran como nodos de datos independientes y Amazon no te garantiza ningún tipo de “proximidad” entre instancias (si es que puede hablarse de proximidad como una propiedad realmente física). Aún así, decidimos arriesgarnos a continuar con nuestra primera solución.

Algunos dicen que nuestro sistema, en papel, está muy bien organizado y una vez implementado la mitad de los elementos que aparecen en el modelo de datos desaparecen. Otros dicen que no es necesario el uso de Foreign Keys (claves foráneas) en el momento real de la implementación. Aún así, nosotros estamos en la convicción de que si que lo son y por eso queríamos que nuestro sistema de base de datos las tuviera en cuenta; no importa que digáis que esta es una reflexión demasiado metódica, somos estudiantes en su último año de carrera y apostamos por un sistema bien hecho desde el principio. Por esto, cuando vimos que el motor del Cluster (ndbcluster) no soportaba claves foráneas decidimos no jugar más con dicha estructura.

Nos estuvimos peleando durante varias horas barajando diferentes motores e información diversa de sistemas de bases de datos y finalmente nos dimos cuenta que el propio MySQL tiene un sistema de replicación master-slave que permite el uso de diferentes motores para el master y para el slave. Concretamente, podíamos tener en el master el motor de MySQL InnoDb que si que soporta el uso de claves foráneas (tan importantes en nuestro sistema) y utilizar el motor MyIsam para los slaves. Este sistema se puede montar fácilmente en un entorno EC2, guardando todos los datos en un volumen EBS y utilizando las instancias para montar el master-slave sin contener datos propios. Esta es la última deducción, ya veremos si finalmente es la acertada.

En los próximos días publicaremos las pruebas que vayamos haciendo en su construcción en EC2.

Esto es todo por hoy desde el zulo, pingüinos y manzanitas world! (hoy sin jefe…)

Instalación

Primero, y fundamental, es tener instalados los paquetes de mysql en el sistema. Para saber si los tenemos o no, podemos ir al Gestor de Paquetes Synaptic de Ubuntu (System>Administration>Synaptic Package Manager) y se nos abrirá una pantalla como esta después de haber introducido la contraseña de root. Introduciremos la palabra “mysql” en el buscador para que nos muestre todos los paquetes relacionados.

Aquellos paquetes que se acompañen con un recuadro verde son los que están instalados en el sistema. Dicho paquete mysql contiene, al menos en sus versiones para Ubuntu 8.10, soporte para MySQL Cluster por lo que no hemos de descargar ningún otro archivo para poder utilizarlo.

Creación y modificación de archivos de configuración

Hemos de tener en cuenta que Ubuntu utiliza unos directorios concretos cuando se le delega la instalación de dichos paquetes, por defecto. Consultando la documentación oficial de MySQL Cluster nos hemos dado cuenta de que la localización de los archivos de configuración que se expresa son diferentes a la de nuestro sistema. La siguientes línias determinarán nuestro propio proceso de configuración y arranque del sistema de cluster y no el que se indica en dicha documentación (un tanto diferente).

Dicho todo esto, vamos a por el primer paso. La instalación de MySQL en Ubuntu repercute en una serie de carpetas del sistema:

• /etc/ donde el sistema añade un directorio mysql que, podríamos decir, guarda la información relacionada con su motor y arranque. Aquí es donde encontraremos el archivo que necesitaremos más adelante, my.cnf.
• /var/lib/ donde el sistema añade tantas carpetas como sean necesarias para describir su “contenido”. Aquí encontraremos un directorio llamado mysql-cluster que es donde crearemos su archivo de configuración, config.ini.

Pero, vayamos por partes.

1. Archivo de configuración config.ini para la configuración de MySQL-Cluster.
   Abrimos la consola (Applications>Accessories>Terminal), e insertamos la siguiente línia:
   
cd /var/lib/mysql-cluster
Una vez en el directorio tendremos que crear el archivo de configuración. Como root escribiremos la siguiente línia:
   
sudo gedit config.ini
E introduciremos la contraseña de root que tengamos. Nos abrirá el gedit es un programa de edición de texto muy sencillo. Al detectar que dicho archivo no existe en el directorio escogido, lo crea automáticamente. Una vez abierto, copiaremos las siguientes línias :
   
# 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= localhost
[NDBD]
HostName= localhost
DataDir= /var/lib/mysql-cluster
[MYSQLD]
[MYSQLD]
[MYSQLD]

   Nota: HostName de NDB_MGM (nodo administración) y NDBD (nodo datos) y DataDir dependerán de cada proyecto, pero el ejemplo que se muestra funciona para la prueba rápida en un mismo ordenador. No olvidemos, que en un sistema corriendo de forma real tendríamos diferentes máquinas para los diferentes procesos de administración y almacenamiento de datos, y por tanto sus HostsName serán unos en concreto para cada máquina.
2. Activar motor de almacenamiento ndbcluster.
   Accedemos, mediante consola, al siguiente directorio:
   
cd /etc/mysql/

   Y abriremos el archivo my.cnf para poder activar el motor de almacenamiento. Ésto no es más que añadir la siguiente línea al código:
   
[mysqld]
ndbcluster

   Y más o menos, tendremos una parte del documento que será de la siguiente manera;
   
...
[mysqld]
#
# * Basic Settings
#
ndbcluster
#
# * IMPORTANT
# If you make changes to these settings and your system uses apparmor, you may
# also need to also adjust /etc/apparmor.d/usr.sbin.mysqld.
#
...

   Una vez hecho esto podremos crear los nuevos nodos.
3. Arrancamos el nodo de administración y el nodo de datos
   Volvemos a colocarnos en el directorio /var/lib/mysql-cluster :
   
cd /var/lib/mysql-cluster

   Con privilegios de root, arrancamos el nodo administrador:
   
sudo ndb_mgmd

   Y a continuación, arrancamos un nodo de datos:
   
sudo ndbd --initial

4. Reiniciar el servidor MySQL y comprovar que funciona el NDBCLUSTER
   Una vez llegado este punto, es hora de reiniciar el servidor mysql que tengamos. Para ello es necesario que lo hagamos con permisos de root:
   
sudo /etc/init.d/mysql stop
sudo /etc/init.d/mysql start

   o
   
sudo /etc/init.d/mysql restart

   Si no ha aparecido ningún error, ya estamos preparados para arrancar el cluster.
5. Arrancar mysql con el cluster
   Inicializaremos mysql desde la consola:
   
mysql -u root -p

   Y nos pedirá la contraseña que hayamos definido para el sistema mysql. La introducimos y nos aparecerá algo parecido a ésto:
   
   Welcome to the MySQL monitor. Commands end with ; or g.
   Your MySQL connection id is 64
   Server version: 5.0.67-0ubuntu6 (Ubuntu)

   Type 'help;' or 'h' for help. Type 'c' to clear the buffer.

   mysql>

   Introducimos una sentencia que nos permita ver de qué se compone nuestro sistema mysql
   
mysql> show engines;

   y nos debería aparecer una tabla que contenga varías filas. Entre ellas, debería aparecer una como esta:
   
| ndbcluster | YES | Clustered, fault-tolerant, memory-based tables

   A veces es posible que aparezca DEFAULT en vez de YES. Si no aparece ninguna de estas dos es que algo no ha salido bien. Intenta revisar todos los pasos anteriores aquí descritos.

   Ahora jugaremos con alguna base de datos que tengamos en el sistema. Si no tienes ninguna, puedes crearla facilmente con Navicat o cualquier otra aplicación gestora de mysql. Pensemos en que la tenemos.
   
mysql> use db_usuaris;

   y una vez en la base de datos que hemos escogido, vamos a crear una table que utilice el engine del cluster:
   
mysql> create table ctest (i INT) engine=ndbcluster;

   Una vez la hemos creado, vamos a ver sus propiedades
   
mysql> show create table ctest G;

   y debería salir algo, tal que así:
   
*************************** 1. row ***************************
Table: ctest
Create Table: CREATE TABLE `ctest` (
`i` int(11) default NULL
) ENGINE=ndbcluster DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

   Finalizamos sesión en mysql escribiendo:
   
mysql> exit;


6. Para finalizar, ver si los nodos se han inicializado correctamente
   Para ello vamos a arrancar el nodo administración de la siguiente manera:
   
sudo ndb_mgm

   Ya simplemente nos queda mirar un reporte de los nodos que se han creado, y ya habremos terminado con este proceso:
   
ndb>show;

   y si todo ha ido bien, aparecerá algo tal que así:
   Cluster Configuration
   ---------------------
   [ndbd(NDB)] 1 node(s)
   id=2 @127.0.0.1 (Version: 3.5.3, Nodegroup: 0, Master)

   [ndb_mgmd(MGM)] 1 node(s)
   id=1 @127.0.0.1 (Version: 3.5.3)

   [mysqld(API)] 3 node(s)
id=3 @127.0.0.1 (Version: 3.5.3)
id=4 (not connected, accepting connect from any host)
id=5 (not connected, accepting connect from any host)


Llegados a este punto, ya podemos dar por finalizada la tarea de este post. Hemos conseguido inicializar correctamente un cluster MySQL y ya podemos guardar información en las tablas creadas con esta tecnología.
Otro día, más.

Saludos desde el zulo, pingüinos y manzanitas world!

]]> http://www.lauraberdasco.com/2009/02/primeros-pasos-con-mysql-cluster-instalacion-configuracion-y-arrancada/feed/ 15 http://www.lauraberdasco.com/2009/02/conceptos-de-mysql-cluster/ http://www.lauraberdasco.com/2009/02/conceptos-de-mysql-cluster/#comments Fri, 20 Feb 2009 11:30:45 +0000 laura http://www.lauraberdasco.com/?p=23 leer más]]> El proyecto que estamos desarrollando nos obliga a explorar nuevos conceptos y nueva tecnologías. En este blog, y en los afines a éste (ixavi.com y nowaynoback.com), iremos publicando regularmente estos pequeños estudios que llevamos a cabo cada día.

Hoy es el turno de MySQL Cluster, y voy a hacer un primer post introductorio a algunos puntos importantes sobre esta tecnología.

¿Por qué MySQL Cluster y no una base de datos normal y corriente? Podemos decir que nuestro proyecto mantiene unas necesidades que no se cubren con un sistema de bases de datos corriente. Nuestro principal problema reside en la respuesta a un gran nombre de consultas al sistema que estamos desarrollando; para que ésto sea eficiente necesitamos una tecnología que nos permita la distribución de estas peticiones para tener un tiempo de respuesta menor. Por esta razón pensamos en MySQL Cluster como una buena y fácil solución.

Características generales de MySQL Cluster

MySQL Cluster está formado por un motor NDB, que es un motor de almacenamiento en memoria caracterizado por la persistencia de los datos. Cada parte del cluster se denomina nodo y podemos encontrar de diferentes tipos:

- El nodo administrador tiene la función principal de administrar otros nodos dentro del cluster. Además, ofrece datos sobre la configuración de cada uno, inicializa o detiene su funcionamiento o permite ejecutar copias de seguridad. Es muy importante, por contener la configuración de los otros nodos, que sea el primero en ser arrancado.

- El nodo de datos es el nodo que almacena los datos del cluster. Tendremos tantos nodos de este estilo como réplicas de la información que necesitemos para el sistema.

- El nodo SQL es el nodo que accede a los datos del cluster. En un MySQL Cluster, el nodo cliente es un servidor MySQL tradicional con motor NDB Cluster.

Con esta estructura obtenemos que la configuración del sistema de cluster reside en la configuración de sus nodos y en la comunicación que establecemos entre ellos. Debemos tener en cuenta que se trata de un proceso centralizado en el nodo de administración por lo que es necesario tenerlo arrancado antes de empezar la creación de los nodos de datos.

Esquema básico cluster

En el próximo post explicaré como realizar un montaje rápido de este sistema sobre la distribución Ubuntu que utilizo normalmente, la 8.10.

Saludos desde el zulo, pingüinos y manzanitas world!