Replicación en MySQL

Autores:

Jacqueline Gómez

Luis Morán

Edwin Urquilla

Conceptos:

MySQL

Es un sistema de gestión de bases de datos relacional, distribuido y multihilo. Es código abierto y el soporte es brindado por Oracle. La más reciente distribución es la 5.6.11 y fue lanzada el 25 de abril de 2013.

Replicación

Es el proceso de copiar y mantener objetos de las base de datos en múltiples bases de datos que forman un sistema de bases de datos distribuido. La replicación permite que los datos de un servidor de bases de datos (el maestro), sean replicados en uno o más servidores de bases de datos (los esclavos).

Replicación en MySQL.

Las características de MySQL soportan replicación asíncrona unidireccional: un servidor actúa como maestro y uno o más actúan como esclavos.

¿Cómo funciona la replicación?

El servidor maestro escribe actualizaciones en el fichero de log binario, y mantiene un índice de los ficheros para rastrear las rotaciones de logs. Estos logs sirven como registros de actualizaciones para enviar a los servidores esclavos. Cuando un esclavo se conecta al maestro, informa al maestro de la posición hasta la que el esclavo ha leído los logs en la última actualización satisfactoria. El esclavo recibe cualquier actualización que ha tenido lugar desde entonces, y se bloquea y espera para que el master le envíe nuevas actualizaciones.

Un esclavo servidor puede servir como maestro si quiere preparar una cadena de replicaciones de replicación.

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

Ventajas de la Replicación:

La replicación unidireccional tiene beneficios para la robustez, velocidad, y administración del sistema:

• La robustez se incrementa con un escenario maestro/esclavo. En caso de problemas con el maestro, puede cambiar al esclavo como copia de seguridad.
• Puede conseguirse un mejor tiempo de respuesta dividiendo la carga de consultas de clientes a procesar entre los servidores maestro y esclavo. Se puede enviar consultas SELECT al esclavo para reducir la carga de proceso de consultas del maestro. Sin embargo, las sentencias que modifican datos deben enviarse siempre al maestro, de forma que el maestro y el esclavo siempre estén sincronizados. Esta estrategia de balanceo de carga es efectiva si dominan consultas que no actualizan datos, pero este es el caso más habitual.
• Otro beneficio de usar replicación es que puede realizar copias de seguridad usando un servidor esclavo sin molestar al maestro. El maestro continúa procesando actualizaciones mientras se realiza la copia de seguridad

Desarrollo:

Se va a resolver un escenario en el cual se tiene un servidor de Bases de Datos actuando como Maestro o Master y un servidor de Bases de Datos actuando como Esclavo o Slave; en caso se pueden realizar la misma configuración para varios esclavos y la replicación seguirá funcionando de la misma manera. El escenario es el siguiente:

                                    

Las configuraciones se realizan bajo dos computadoras con Sistema Operativo Debian Wheezy 7.0.

Si aún no se tiene instalado el servidor MySQL se instalará en una Terminal con la línea de comando:

apt-get install mysql-server

SERVIDOR MAESTRO:

Una vez instalado el servidor MySQL se procederá a las configuraciones correspondientes; primeramente se realizará la configuración del servidor Maestro:

1.       Se modifica con vim, nano o cualquier editor de texto, el archivo my.cnf

# nano /etc/mysql/my.cnf

Y se modifican y/o agregan las siguientes líneas de código:

log-bin = /var/log/mysql/mysql-bin.log

binlog-do-db=DATABASE_TO_BE_REPLICATED

server-id=1

skip-host-cache

skip-name-resolve

Donde DATABASE_TO_BE_REPLICATED es el nombre de la base de datos que se va a replicar.

                                         

2.       Se reinicia el servicio mysql:

# /etc/init.d/mysql restart

3.       Se accede como root a mysql, pedirá la contraseña del servidor, ésta será la que se ha configurado en la instalación:

# mysql –u root –p

4.       Dentro de la consola de MySQL se creará una Base de Datos

mysql > CREATE DATABASE ReplicacionDB;

                     

5.       Se crean los privilegios para la Replicación:

mysql > GRANT REPLICATION SLAVE ON *.* TO 'USER'@'%' IDENTIFIED BY 'PASSWORD';

Donde

USER: Es el nombre del usuario del esclavo.

       % : Es la dirección donde está almacenado el esclavo, puede determinarse que la dirección sea

       cualquiera, ubicando el símbolo % en lugar de la dirección.

       PASSWORD: Es la contraseña del usuario esclavo.

6.       Se establecen los privilegios:

mysql > FLUSH PRIVILEGES;

7.       Se obtiene la información del servidor maestro:

mysql > SHOW MASTER STATUS;

Este comando nos devolverá el archivo y la posición de la Base de Datos, es importante, tener presentes estos datos, ya que serán utilizados en la configuración del esclavo.

8.       Se accede a la base de datos:

mysql > USE ReplicacionDB;

9.       Se congelará la base de datos para poder obtener el respaldo de la misma y poder restaurarla en el servidor esclavo.

mysql > FLUSH TABLES WITH READ LOCK;

10.    Sale de mysql.

mysql > EXIT;

11.    Con mysqldump se va a crear un backup de la base de datos, para que luego sea restaurada en el servidor esclavo.

# mysqldump -u root -p DATABASE_TO_BE_REPLICATED > DATABASE_TO_BE_REPLICATED.sql

Donde DATABASE_TO_BE_REPLICATED es el nombre de la base de datos que se replicará.

Este comando generará un archivo .sql, el cual contendrá el backup de la base de datos, éste se almacenará en la dirección hacia la cual apunta la terminal.

12.    Luego se accede a la consola de mysql nuevamente para descongelar las tablas de la base de datos que replicamos:

# mysql –u root –p

mysql > USE ReplicacionDB;

mysql > UNLOCK TABLES;

mysql > EXIT;

                           

SERVIDOR ESCLAVO:

En el servidor esclavo, será necesario copiar el archivo .sql que fue generado, para restaurar la base de datos a partir de él, puede ser copiado a través de una memoria usb, transferencia punto a punto o por llaves SSH, tal cual es el ejemplo de la configuración aquí detallada:

1.       A través de claves SSH, se transfiere el archivo de la máquina que sirve como servidor maestro a la que sirve como servidor esclavo:

# scp DATABASE_TO_BE_REPLICATED.sql > user@direccionIP:/rutaAlmacenamiento

Donde:

DATABASE_TO_BE_REPLICATED.sql: Es el archivo que se generó con mysqldump en el servidor maestro.

user: Es el nombre del usuario de la computadora remota.

direccionIP: Es la dirección IP a la cual se copiará el archivo.

rutaAlmacenamiento: Es la ruta donde se almacenará el archivo.

                   

2.       Se crea la base de datos en el servidor esclavo, por medio del archivo que contiene el backup de la misma.

# mysql –u root –p DATABASE_TO_BE_REPLICATED < DATABASE_TO_BE_REPLICATED.sql

3.       Con un editor de texto, ya sea vim, nano o cualquier otro se abre el archivo de configuración my.cnf

# nano /etc/mysql/my.cnf

Y se modifican o agregan las líneas:

server-id=2

replicate-do-db=DATABASE_TO_BE_REPLICATED  

skip-host-cache

skip-name-resolve

       

4.       Se reiniciará el servicio mysql para poder aplicar los cambios.

# /etc/init.d/mysql restart

5.       Se accederá la consola de MySQL para configurar el esclavo:

# mysql –u root –p

6.       Se detienen los procesos del esclavo:

mysql > SLAVE STOP;

                           

7.       Luego se hará referencia al servidor maestro del cual obtendrá las actualizaciones el servidor esclavo:

mysql > CHANGE MASTER TO MASTER_HOST='192.168.56.1',

         -> MASTER_USER='user',

   -> MASTER_PASSWORD='password',

   -> MASTER_LOG_FILE='/var/log/mysql/mysql-bin.0000XX',

   -> MASTER_LOG_POS=XXX;

Dónde:

MASTER_HOST: Hace referencia a la dirección IP en la cual está el servidor maestro.

MASTER_USER: Usuario del servidor maestro con el cual se accede a MySQL.

MASTER_PASSWORD: Contraseña del servidor maestro con el cual se accede a MySQL.

MASTER_LOG_FILE: La dirección y el número que se obtuvo cuando se realizó el SHOW MASTER STATUS.

MASTER_LOG_POS: Posición de los logs, también obtenida con SHOW MASTER STATUS en el servidor maestro.

8.       Se inicia el servidor esclavo:

mysql > SLAVE START;

9.       Se verifica el estado del servidor esclavo:

mysql > SHOW SLAVE STATUS;

DEMOSTRACIÓN:

1.       En el servidor maestro se creará una Tabla llamada Alumno:

# mysql –u root –p

mysql > USE ReplicacionDB

mysql > CREATE TABLE Alumno (nombre VARCHAR(10));

Y luego verificamos las tablas con el comando:

mysql > SHOW TABLES;

Y se podrá comprobar que la tabla efectivamente ha sido creada:

                                                                           

2.       En el servidor esclavo, se accederá a MySQL y se verán reflejados los cambios de la tabla creada en el servidor maestro:

# mysql – u root –p

mysql > SHOW DATABASES;

mysql > USE ReplicacionDB;

mysql > SHOW TABLES;

Y se podrá ver que el cambio ha sido aplicado en la base de datos.

                                                

 Referencias:

·        Wallen J., Set up MySQL database replication to ensure up-to-date backups. Obtenida el 31 de abril de 2013 en http://www.techrepublic.com/blog/itdojo/set-up-mysql-database-replication-to-ensure-up-to-date-backups/3340?pg=1

·        Oracle MySQL, Capítulo 6. Replicación en MySQL. Obtenida el 3 de mayo de 2013 enhttp://dev.mysql.com/doc/refman/5.0/es/replication.html

·        Campos M., Flores C., Ortiz R., Zuniga C,. Replicación en MySQL. Obtenida el 5 de mayo de 2013 enhttp://basesdedatosues.blogspot.com/2012/06/replicacion-mysql-replicacion-en-mysq.html

Si deseas conocer más acerca de Replicación en MySQL puedes consultar el siguiente video tutorial:

Leer nota completa...

PostgreSQL Cluster con pgpool-II

Ve el documento en slideshare

Ve la demostracion en Youtube, no olvides ponerlo en HD

EQUIPO DE TRABAJO
Henry Ernesto Renderos Zaldaña	David Alberto García Cardona
rz07002@ues.edu.sv	gc07011@ues.edu.sv

PostgreSQL Cluster con PGPOOL-II

Henry Renderos, David García

Objetivos:

• Aprender los conceptos básicos sobre el manejo de un clúster utilizando PostgreSQL 9.1 y PGPOOL-II en Linux.
• Comprender el funcionamiento de un clúster.
• Establecer los parámetros de inicialización para el clúster.
• Realizar un escenario demostrativo sobre el uso de un clúster empleando replicación de bases de datos y sentencias SQL.
• Visualizar el comportamiento de la replicación en la red.

Conceptos:

¿Qué es un clúster?

Un clúster es simplemente una colección de componentes que se unen y trabajan como un solo componente para proveer alta disponibilidad. Cuando hablamos de clúster de bases de datos, nos referimos a una arquitectura en la que tenemos varios equipos con parte de los datos del usuario trabajando al unísono como un solo sistema. La arquitectura de un clúster de base de datos viene definida por la manera en que se almacenan los datos en cada nodo.

¿Qué es PostgreSQL?

PostgreSQL es un sistema de gestión de bases de datos objeto-relacional, distribuido bajo licencia BSD y con su código fuente disponible libremente. Es el sistema de gestión de bases de datos de código abierto más potente del mercado y en sus últimas versiones no tiene nada que envidiarle a otras bases de datos comerciales. PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en vez de multihilos para garantizar la estabilidad del sistema. Un fallo en uno de los procesos no afectará el resto y el sistema continuará funcionando.

¿Qué es PGPOOL-II?

pgpool-II es un middleware que se encuentra entre los servidores de PostgreSQL y un cliente de base de datos PostgreSQL. Ofrece las siguientes características: Agrupación de conexiones pgpool-II mantiene las conexiones establecidas a los servidores PostgreSQL, y los reutiliza cada vez que una nueva conexión con las mismas propiedades (es decir, nombre de usuario, bases de datos, la versión del protocolo) entra en juego reduce la sobrecarga de la conexión, y mejora el rendimiento global del sistema.

Replicación

pgpool-II puede gestionar múltiples servidores PostgreSQL. La activación de la función de replicación hace que sea posible la creación de una copia de seguridad en tiempo real en 2 o más grupos PostgreSQL, de manera que el servicio pueda continuar sin interrupción si uno de esos grupos falla.

Balanceo de carga

Si se replica una base de datos (ya que se ejecuta en el modo replicación o modo maestro / esclavo), la realización de una consulta SELECT en cualquier servidor devolverá el mismo resultado. pgpool-II se aprovecha de la función de replicación con el fin de reducir la carga en cada servidor PostgreSQL. Lo hace mediante la distribución de las consultas SELECT entre los servidores disponibles, mejorando el rendimiento global del sistema. En un escenario ideal, el rendimiento de lectura podría mejorar proporcionalmente al número de servidores PostgreSQL. El equilibrio de carga funciona mejor en un escenario donde hay una gran cantidad de usuarios que ejecutan muchas consultas de sólo lectura al mismo tiempo. Limitar el exceso de conexiones Hay un límite en el número máximo de conexiones simultáneas con PostgreSQL, y nuevas conexiones son rechazados cuando se alcanza este número. Al aumentar este número máximo de conexiones, sin embargo, aumenta el consumo de recursos y tiene un impacto negativo en el rendimiento general del sistema. pgpool-II también tiene un límite en el número máximo de conexiones, pero las conexiones adicionales se pondrán en cola en lugar de devolver un error de inmediato.

Consultas en paralelo

Con la función de consultas en paralelo, los datos se pueden dividir entre varios servidores, por lo que una consulta se puede ejecutar en todos los servidores al mismo tiempo, reduciendo el tiempo de ejecución total. La consulta paralela es la que funciona mejor en la búsqueda de datos a gran escala. pgpool-II habla backend de PostgreSQL y el protocolo de interfaz, y transmite mensajes entre un backend y un frontend. Por lo tanto, una aplicación de base de datos (frontend) piensa que pgpool-II es el servidor PostgreSQL actual, y el servidor (backend) ve a pgpool-II como uno de sus clientes. Debido a que pgpool-II es transparente para el servidor y el cliente, una aplicación de base de datos existente se puede utilizar con pgpool-II casi sin un cambio en su código fuente.

Desarrollo:

INSTALACIÓN

1. Utilidades para la gestión y el mantenimiento del clúster.

# apt-get install ntp openssl file psmisc sysstat bzip2 unzip nmap dstat rsync wget ccze tcpdump pciutils dnsutils host

2. Configuraremos dos archivos del sistema de Debian, esto nos facilitará hacer referencias a nombres de host y no a direcciones IP.

# nano /etc/hostname

Acá le colocaremos el nombre de pgsql1 en el nodo 1 y pgsql2 en el nodo 2.

# nano /etc/hosts

Acá agregaremos los nombres de host pertenecientes al clúster con sus respectivas direcciones IP.



En este momento tenemos configurados los nodos del clúster de la siguiente forma, luego de esto debemos reiniciar los nodos: Nodo 1 Hostname: pgsql1 Dirección IP: 192.168.1.7 Nodo 2 Hostname: pgsql2 Dirección IP: 192.168.1.4 Máscara de red de 24 bits. Dirección IP del enrutador: 192.168.1.1

3. Comenzaremos a configurar PostgreSQL en ambos nodos pero pgpool-II solo en el nodo pgsql1. Los comandos deberán ejecutarse como root (#) o como el usuario postgres ($).
4. Instalaremos las cabeceras de la librería de PostgreSQL, el paquete de desarrollo de PostgreSQL y las utilidades de compilación de GNU)

# apt-get install libpq-dev postgresql-server-dev-9.1 bison build-essential

5. Una vez instalado, instalaremos PostgreSQL en ambos nodos del clúster:

# apt-get install postgresql-9.1 postgresql-contrib-9.1 postgresl-doc-9.1 uuid libdbd-pg-perl

6. Finalmente instalamos pgpool-II en el nodo identificado como pgsql1

# apt-get install pgpool2 libpgpool0

CONFIGURACIÓN DE POSTGRESQL

Los siguientes pasos se aplican a las instancias de PosgreSQL en los nodos pgsql1 y pgsql2.

1. Comenzaremos, como usuario postgres, añadiendo el usuario de base de datos (role) pgpool2, sin contraseña:

# su – postgres $ createuser –superuser pgpool2

2. Editamos ahora el fichero /etc/postgresql/9.1/main/pg_hba.conf y añadimos el acceso para todos los usuarios desde cualquier dirección IP. (NOTA: esto se hace por motivos de enseñanza, el acceso sólo debe permitirse para el usuario pgpool2 desde la dirección IP en donde está instalado.)

# nano /etc/postgresql/9.1/main/pg_hba.conf

El fichero deberá quedarnos de la siguiente manera:

3. Por último indicaremos a PostgreSQL que escuche en todas las interfaces pues, por defecto, sólo lo hace en el localhost. Editamos el fichero /etc/postgresql/9.1/main/postgresql.conf y cambiamos la siguiente directiva.

listen_addresses = ‘*’

También podemos restringirlo a que solo escuche peticiones provenientes de la dirección IP en donde se encuentra pgpool-II

4. Reiniciamos PostgreSQL para activa los cambios.

# service postgresql restart

CONFIGURACIÓN DE PGPOOL-II

La configuración de pgpool-II la realizaremos únicamente en el nodo pgsql1, pues sólo ese host lo posee.

1. Editaremos el archivo /etc/pgpool2/pgpool.conf

Deberemos editar el archivo para configurarlo a nuestra medida. Se configurarán: Pool de conexiones Replicación Balanceo de carga Las únicas directivas que modificaremos se muestran a continuación, las demás las dejaremos intactas:

listen_addresses = ‘*’
port = 9999
backend_hostname0 = ‘pgsql1’
backend_port0 = ‘5432’
backend_weight0 = 1
backend_hostname1= ‘pgsql2’
backend_port1 = ‘5432’
backend_weight1 = 1
replication_mode = true
load_balance_mode = true
replicate_select = true
pgpool2_hostname = ‘pgsql1’


2. Para arrancar pgpool-II lo haremos con el siguiente comando (start o restart):

# service pgpool2 start

3. Si queremos arrancar pgpool-II en modo de depuración primero lo detendremos con el comando “service pgpool2 stop” y lo arrancaremos en modo debug con de la siguiente manera:

# pgpool –n –d –f /etc/pgpool2/pgpool.conf

4. En otra pestaña o ventana de la terminal probaremos conectarnos a través de pgpool-II con el siguiente comando:

# psql –h pgsql1 –p 9999 –U pgpool2 –d postgres

El significado del comando anterior se detalla a continuación: -h es el nombre del host al que nos vamos a conectar y en donde está instalado pgpool-II. -p es el puerto que definimos en el archivo /etc/pgpool2/pgpool.conf -U es el usuario que creamos en los dos nodos del clúster. -d es la base de datos a la que nos vamos a conectar Si todo va bien podremos ver que en la terminal se nos muestra algo como sigue:

postgres=#

Lo que nos indica que nos hemos podido conectar a través de pgpool-II

PRUEBAS DE REPLICACIÓN

1. Crearemos una base de datos que será replicada a través de pgpool-II de la siguiente forma:

# createdb –h pgsql1 –p 9999 –U pgpool2 basesdedatosues

2. Si nos loggeamos como usuario postgres en los dos nodos del clúster (su – postgres) y ejecutamos el siguiente comando para visualizar las bases de datos, nos debería de aparecer en cada nodo la base de datos que creamos en el paso anterior:

$ psql -l

POSTGRESQL Y PGPOOL-II EN LA RED

A continuación se muestran algunas capturas de lo que sucede en la red al momento de que se realiza una sentencia SQL a través de pgpool-II en los nodos pertenecientes al clúster.

1. Instalaremos el sniffer wireshark y luego lo ejecutaremos:

2. # apt-get install wireshark
   # wireshark &

3. Seleccionaremos la interfaz eth0 y capturaremos algunos paquetes, realizaremos una consulta insert a través de pgpool-II y observaremos que aparecerán los siguientes paquetes en nuestra escucha:

4. Observaremos con más detenimiento el paquete 874 y veremos que al momento de la replicación lo que se transporta a través de la red son las sentencias SQL. La query que fue introducida en el nodo pgsql1 a través de pgpool-II fue “insert into usuario values (‘Base’,’Pass’); y efectivamente vemos en el paquete que esa sentencia es la replicada en el nodo pgsql2 con dirección IP 192.168.1.4.

Referencias:

• Jaume Sabater (2008). Replicación y alta disponibilidad de PostgreSQL con pgpool-II. (1 Nov – 2008) http://linuxsilo.net/articles/postgresql-pgpool.html
• pgpool Global Development Group (2003 – 2011). Pgpool-II user manual http://pgpool.projects.pgfoundry.org/pgpool-II/doc/pgpool-en.html

Leer nota completa...

Bases de datos distribuidas con Mysql

Una Base De Datos Distribuida (BDD) es un conjunto de múltiples bases de datos lógicamente relacionadas las cuales se encuentran distribuidas en diferentes espacios lógicos e interconectados por una red de comunicaciones, tienen la capacidad de realizar procesamientos autónomos y globales (replicarse).

Es un sistema de base de datos almacenado en varios servidores y que es vista por el cliente como una sola, esto con el objetivo de mantener redundancia, balanceo de carga, etc.

 “Ante el usuario, un sistema distribuido debe lucir exactamente igual que un sistema que no es distribuido”

La replicación en MySql se puede dar de forma síncrona (clustering) o asíncrona, para el primero se utiliza MySql clúster mientras que para el segundo, un gestor de base de datos Mysql común. En nuestro caso la versión 5.5.8. Actualmente (Junio-2011), mysql clúster existe solamente para plataformas Linux.

La replicación copia y mantiene los objetos de las bases de datos en las múltiples bases de datos que levantan un sistema distribuido. La replicación puede mejorar el funcionamiento y proteger la disponibilidad de las aplicaciones, por que alterna opciones de acceso de los datos existentes.

Ahora bien, se explicaran las ventajas y desventajas de poseer una base de datos distribuida con mysql de forma asíncrona.     

VENTAJAS

• Disponibilidad: un fallo en una parte del sistema solo afectará a un fragmento, en lugar de a toda la base de datos, el sistema sigue funcionando aún en caso de caída de uno de los nodos.
• Aumento del paralelismo: Varios nodos pueden realizar consultas en paralelo sobre la misma tabla.
• Aumento de la sobrecarga en las actualizaciones: El sistema debe asegurar que todas las réplicas de la tabla sean consistentes. Cuando se realiza una actualización sobre una de ellas, los cambios deben propagarse a todas a lo largo del sistema distribuido.
• Rendimiento: Los sistemas trabajan en paralelo, lo cual permite balancear la carga en los servidores, se hacen todas las consultas SELECT a un servidor esclavo, mientras las actualizaciones se realizan en el maestro. 
• Modularidad: se pueden modificar, agregar o quitar sistemas de la base de datos distribuida sin afectar a los demás sistemas (módulos).

DESVENTAJAS

• Complejidad: Se debe asegurar que la base de datos sea transparente, se debe lidiar con varios sistemas diferentes que pueden presentar dificultades únicas. El diseño de la base de datos se tiene que trabajar tomando en cuenta su naturaleza distribuida, por lo cual no podemos pensar en hacer consultas JOIN que afecten varios sistemas.
• Seguridad: se debe trabajar en la seguridad de la infraestructura así como cada uno de los sistemas. 
• Carencia de estándares: aún no existen herramientas o metodologías que ayuden a los usuarios a convertir un DBMS (Sistema de Administración de Base de Datos) centralizado en un DBMS distribuido. 
• Mayor probabilidad de errores: Como los nodos que constituyen el sistema funcionan en paralelo, es más difícil asegurar el funcionamiento correcto de los algoritmos, así como de los procedimientos de recuperación de fallos del sistema. 

¿COMO CONFIGURARLO?

Recursos:

• Dos pc’s, una que desempeñará el papel de maestro y la otra de esclavo.
• Software de Mysql instalado (Descargar mysql 5.5.8.rar) 
• Conexión física y configuraciones de red entre ambos equipos.
•           Base de datos “Agenda” (Descargar base de datos).

Procedimiento:

Configurando el servidor Maestro

• Editar el archivo "C:\Program Files\MySQL\MySQL Server 5.5\my.ini" con los siguientes datos:

[mysqld]

# Id del servidor de BD, no se debe de repetir entre ellos.
server-id=3

#Archivo log, en él se guardarán las actualizaciones y se utilizará para sincronización y

#replicación. Si no existe, crearlo en cualquier ruta con un Notepad.

log-bin="C:\Mysql\mysql_log.bin"

#Base de Datos a vincular y replicar entre ambos servidores.

binlog-do-db=agenda

replicate-do-db=agenda

• Reiniciar el servicio de Mysql.

• Acceder a la consola Mysql (colocando los datos correctos en donde aparecen corchetes): 

C:\>mysql –u [usuario] -p

Si no reconoce el comando, ejecutarlo en la ruta:

C:\Program Files\MySQL\MySQL Server 5.5\bin> mysql –u [usuario] –p

• Crear usuario para replicación:

Mysql> grant replication slave on *.* to ‘usuario’@’dominio’ identified by 'password';

El dominio puede ser la IP de la pc esclavo, o sustituirlo por el porcentaje ‘%’. Se puede crear un usuario de forma gráfica, se detallará más adelante. 

• Otorgar privilegios

Mysql>flush privileges;

Mysql>use agenda;

Mysql>flush tables with read lock;

• Parámetros de configuración

Mysql>show master status;

Anotar los parámetros mostrados en la tabla, ya que se utilizarán para configurar el esclavo.

• Hacer un back up de la base de datos “agenda” para crearla en el servidor esclavo. 

C:\>mysqldump –u root –p --opt agenda > agenda.sql

Configurando el servidor Esclavo

• Editar el archivo my.ini, agregando la misma configuración que en el maestro.

• Reiniciar el servicio de mysql.

• Crear la base de datos (desde la consola de mysql):

Mysql> create database agenda;

Mysql> exit;

C:\> mysql –u root –p agenda < c:\agenda.sql

Esto suponiendo que el archivo .sql se ha colocado en C:\

• Sincronización de maestro y esclavo para replicación, supondremos la ip:192.168.1.2 para el servidor maestro y haremos uso de los datos de la figura anterior: 

Mysql> slave stop;

Mysql> change master to mater_host=’192.168.1.2’, master_user=’wil’, master_password=’p123’, master_log_file=’mysql_log.000026’, master_log_pos=107;

Mysql> start slave;

• Para verificar el estado de la replicación, podremos ejecutar el siguiente comando: 

Mysql> show slave status;

Ahora solo nos queda probar la replicación agregando/editando registros en un servidor y comprobándolos en el otro.

Recordemos que con esta configuración solamente se ha creado replicación en una dirección, es decir, hay solo un maestro y un esclavo que replica en él los cambios del maestro, mas no en sentido contrario. Para tener una configuración maestro-maestro y que los cambios en cualquier servidor se vean reflejados en el otro, es necesario hacer ambos servidores maestro y esclavo a la vez con la configuración antes mencionada.

CREANDO USUARIOS Y RESTAURANDO BD DE FORMA GRÁFICA

Se aconseja utilizar Mysql Workbench, ya que se encuentra disponible en el sitio web de mysql.

Para la creación del usuario es igual de sencillo que en la consola de mysql, en la ventana principal de mysql elegir la opción Manage Security.

La ventana siguiente nos muestra las opciones de administración de seguridad que mysql workbench nos ofrece para nuestros esquemas.

En la parte de usuarios y privilegios, dar clic en Agregar Cuenta, luego agregamos los datos correspondientes para crear el usuario, recordando que el símbolo % significa “cualquier host” y posteriormente aplicar los cambios. En la pestaña de Roles Administrativos se conceden los permisos que se deseen al usuario. Con esto, se crea de forma diferente un usuario para replicación.

Para Exportar o importar bases de datos, accedemos a "Exportar y Extraer datos" en "Administración de Seguridad" o "Manage Security". 

Para exportar una base de datos y guardarla en un archivo *.sql, seleccionar la pestaña "Exportar en disco".

En las opciones, seleccionamos la base o bases de datos a exportar, seguido en "Exportar autocontenido a archivo" indicamos la ruta y nombre del archivo donde se guardará la base de datos. Como siguiente paso nada mas nos queda comenzar a exportar.

Para restaurar una base de datos basta con dar clic en la pestaña "Importar desde archivo" :

Se nos presentan diversas opciones para restaurar una base de datos, clic en la opción "Importar auto-contenido desde archivo" y elegimos la ruta del archivo *.sql.

Finalmente damos clic en "comenzar a importar" y ya tendremos cargada la base de datos en nuestro sistema.

Hemos tratado de presentar una opción para mantener nuestras bases de datos a prueba de fallos de hardware principalmente, sin embargo resulta necesario aplicar técnicas más avanzadas de seguridad si queremos tener integridad en nuestros datos.

Esperamos este post sea de utilidad, cualquier comentario u observación no duden en contribuir.

------------------- o -------------------------------- o ---------------------------------- o

by...

Verónica Esmeralda Mejía Quintanilla (vmq1986@hotmail.com)

Nelson Arnoldo Jiménez Martínez (jmnel_mar@hotmail.com)

Mauricio Armando Canizález Ramírez. (macr_n3d@hotmail.com)

William Ernesto Alfaro Avila (alfarowil@hotmail.com)

-------------------- o ------------------------------ o ----------------------------------- o

Leer nota completa...