En el precedente articulo hemos visto como usar la replicación MySQL Master-Slave para la base de datos de Asterisk. Hoy veremos como utilizar la replicación MySQL Master-Master para la misma base de datos pero solamente para la tabla CDR. Que diferencia hay entra una replicación Maestro-Esclavo y una Maestro-Maestro?

En el primer caso tenemos una copia de todos los registros en otro servidor y podemos efectuar estadísticas usando el Esclavo sin sobrecargar el Maestro. En el segundo caso la configuración se utiliza para la alta disponibilidad en Asterisk. Dos servidores asterisk: A y B. Si A se cae B toma su lugar. Cuando A vuelve a funcionar, B vuelve a ser el servidor de respaldo. Como veremos en un próximo articulo, para la alta disponibilidad en Asterisk, además de la replicación Master-Master, necesitaremos configurar otros programa. Por ahora nos interesa configurar la replicación MySQL Master-Master.

Escenario:

ServidorA

IP 192.168.142.248

Base de datos a replicar: asterisk – Tabla: cdr

MasterA SlaveA

ServidorB

IP 192.168.146.90

Base de datos a replicar: asterisk – Tabla: cdr

MasterB SlaveB

La tabla CDR en el ServidorA ya existe y tiene unos cuantos datos registrados. El problema principal de la replicación Master-Master es el conflicto que se puede presentar en las entradas de la tabla. Ejemplo:

el servidorA se cae y toma su lugar el servidorB. Se registran unos cuantos datos en la tabla cdr del servidorB. Mientras el servidorA vuelve a funcionar y antes que el servidorB pueda actualizar los datos de la tabla CDR en el servidorA, este empieza a grabar nuevas entradas en la misma tabla. En este escenario se pueden generar conflictos entre los datos de las dos tablas y se genera un error de replicación porque los dos presentan entradas con el mismo ID en la clave primaria de la tabla (siendo progresivo).

Para solucionar este tipo de problema se usarán estos dos parámetros:

• auto_increment_increment
• auto_increment_offset

Mano a la obra.

ServidorA

La tabla CDR de la base de datos Asterisk no tiene un ID progresivo para cada entrada. Entramos en el cliente MySQL y miramos la fecha de las llamadas de la extension 2300:

mysql –u root –p

mysql> use asterisk

mysql> select calldate from cdr where dst=2300;

+---------------------+
| calldate            |
+---------------------+
| 2009-10-19 13:16:12 |
| 2009-10-19 13:16:12 |
| 2009-11-04 20:30:48 |
| 2009-11-04 20:30:48 |
| 2009-11-04 20:33:31 |
| 2009-11-04 20:33:31 |
| 2009-11-06 21:03:29 |
| 2009-11-06 21:03:29 |
| 2009-11-06 21:04:09 |
| 2009-11-06 21:04:09 |
| 2009-11-06 21:08:37 |
| 2009-11-06 21:08:37 |
| 2009-12-17 20:59:42 |
| 2009-12-17 20:59:42 |
+---------------------+
14 rows in set (0.01 sec)

Ahora añadimos un id progresivo en la estructura de la tabla:

mysql> ALTER TABLE cdr ADD ID int(11) NOT NULL AUTO_INCREMENT PRIMARY KEY;

Query OK, 2747 rows affected (0.01 sec)
Records: 2747  Duplicates: 0  Warnings: 0

Miramos el cambio:

mysql> select id,calldate from cdr where dst=2300;

+------+---------------------+
| id   | calldate            |
+------+---------------------+
|  610 | 2009-10-19 13:16:12 |
|  611 | 2009-10-19 13:16:12 |
| 1236 | 2009-11-04 20:30:48 |
| 1237 | 2009-11-04 20:30:48 |
| 1238 | 2009-11-04 20:33:31 |
| 1239 | 2009-11-04 20:33:31 |
| 1336 | 2009-11-06 21:03:29 |
| 1337 | 2009-11-06 21:03:29 |
| 1338 | 2009-11-06 21:04:09 |
| 1339 | 2009-11-06 21:04:09 |
| 1342 | 2009-11-06 21:08:37 |
| 1343 | 2009-11-06 21:08:37 |
| 1912 | 2009-12-17 20:59:42 |
| 1913 | 2009-12-17 20:59:42 |
+------+---------------------+
14 rows in set (0.00 sec)

Ahora cada entrada seleccionada tiene un ID que la identifica.

Creamos una carpeta donde guardar los Binary log de MySQL y cambiamos usuario y grupo que tiene los permisos en la carpeta creada:

mkdir /var/log/mysql

chown mysql:mysql /var/log/mysql

ls -l /var/log/my*

-rw-r----- 1 mysql mysql 41201 Feb 24 07:19 /var/log/mysqld.log

/var/log/mysql:
total 0

Volvemos al cliente MySQl y creamos los privilegios de replicación para un nuevo usuario:

mysql –u root –p

mysql> GRANT REPLICATION SLAVE ON *.* TO 'masterb'@'192.168.146.90' IDENTIFIED BY 'sesamo'; 

mysql> flush privileges;

mysql> quit

Ahora modificamos el archivo de configuración de MySQL:

nano /etc/my.cnf

bajo la etiqueta [mysqld] ponemos:

server-id               = 10
auto_increment_increment = 10
auto_increment_offset    =  1
log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M
replicate-do-table      =asterisk.cdr
sync_binlog             =1

Los parámetros:

Con auto_increment_increment a 10 cada entrada en la tabla cdr tendrá un ID progresivo que irá de 10 en 10

Con auto_increment_offset a 1 cada entrada usará el entero 1

En el caso de tres entradas en la tabla el resultado será:

ID 1

ID 11

ID 21

Con replicate-do-table definimos que la replicación es solamente para la tabla cdr de la base de datos Asterisk

Reiniciamos mysql:

/etc/init.d/mysql restart

Considerando que nuestro servidor Asterisk tiene tiempo trabajando tenemos que crear una copia de la base de datos para luego importarla en el servidorB:

mysql -u root -p

Primero seleccionamos la base de datos asterisk:

mysql> use asterisk

Segundo bloqueamos la lectura de todas las tablas de todas las bases de datos:

mysql> FLUSH TABLES WITH READ LOCK;

Por ultimo miramos el estado del Master:

mysql> SHOW MASTER STATUS;

Aparecerá algo por el estilo:

+------------------+----------+--------------+------------------+
| File                    | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |       98 | asterisk            |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

Apuntamos los datos que aparecen en la columna File (mysql-bin.000001) y en la columna Position (98)

Sin cerrar esta ventana, abrimos otra ventana terminal o otra conexión al servidor Linux y creamos una copia de la base de datos asterisk:

cd /tmp

mysqldump -u root -p asterisk cdr > cdr.sql

copiamos el archivo en el servidorB en la carpeta tmp:

scp cdr.sql root@192.168.146.90:/tmp

Cerramos esta ventana y volvemos a la primera:

desbloqueamos las tablas:

mysql> UNLOCK TABLES;

y salimos del cliente:

mysql> quit

ServidorB

Creamos la carpeta para guardar los Bynary log con los permisos para el usuario mysql:

mkdir /var/log/mysql

chown mysql:mysql /var/log/mysql

Entramos en el cliente mysql y creamos la base de datos asterisk:

mysql -u root –p

mysql> create database asterisk;

mysql> quit

Importamos la tabal cdr:

cd /tmp

mysql -u root -p asterisk < cdr.sql

Y averiguamos que efectivamente las tabla y los datos presentes se han guardado:

mysql -u root –p

mysql> use asterisk

mysql> select id,calldate from cdr where dst=2300;

+------+---------------------+
| id   | calldate            |
+------+---------------------+
|  610 | 2009-10-19 13:16:12 |
|  611 | 2009-10-19 13:16:12 |
| 1236 | 2009-11-04 20:30:48 |
| 1237 | 2009-11-04 20:30:48 |
| 1238 | 2009-11-04 20:33:31 |
| 1239 | 2009-11-04 20:33:31 |
| 1336 | 2009-11-06 21:03:29 |
| 1337 | 2009-11-06 21:03:29 |
| 1338 | 2009-11-06 21:04:09 |
| 1339 | 2009-11-06 21:04:09 |
| 1342 | 2009-11-06 21:08:37 |
| 1343 | 2009-11-06 21:08:37 |
| 1912 | 2009-12-17 20:59:42 |
| 1913 | 2009-12-17 20:59:42 |
+------+---------------------+
14 rows in set (0.01 sec)

Creamos un nuevo usuarios con los permisos de replicación

mysql> GRANT REPLICATION SLAVE ON *.* TO 'mastera'@'192.168.142.248' IDENTIFIED BY 'sesamo';

mysql> flush privileges;

mysql> quit

Ahora modificamos el archivo de configuración de MySQL:

nano /etc/my.cnf

bajo la etiqueta [mysqld] ponemos:

server-id               = 20
auto_increment_increment = 10
auto_increment_offset    =  2
log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M
replicate-do-table      =asterisk.cdr
sync_binlog             =1

El auto_increment_offset es igual a 2. En el caso de tres entradas el ID sería:

ID 2

ID 12

ID 22

Como pueden ver, de esta forma no se presentarán conflictos en las entradas de la tabla CDR

Reiniciamos Mysql:

/etc/init.d/mysqld restart

Y ahora como para el servidorA miramos el Binary log y apuntamos los datos:

mysql -u root -p

mysql> FLUSH TABLES WITH READ LOCK;

mysql> SHOW MASTER STATUS;

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |       98 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

mysql> quit

Ahora conectamos el servidorB al servidorA:

mysql -u root –p

mysql> CHANGE MASTER TO MASTER_HOST='192.168.142.248',
       MASTER_USER='masterb',
       MASTER_PASSWORD='sesamo',
       MASTER_LOG_FILE='mysql-bin.000001',
       MASTER_LOG_POS=98;
Query OK, 0 rows affected (0.00 sec)

Iniciamos el esclavo:

mysql> START SLAVE;
Query OK, 0 rows affected (0.00 sec)

y miramos el resultado:

mysql> SHOW SLAVE STATUS\G

*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 192.168.142.248
                Master_User: masterb
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000001
        Read_Master_Log_Pos: 98
             Relay_Log_File: mysqld-relay-bin.000002
              Relay_Log_Pos: 235
      Relay_Master_Log_File: mysql-bin.000001
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB:
        Replicate_Ignore_DB:
         Replicate_Do_Table: asterisk.cdr
     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)

Seguimos el mismo procedimiento para el ServidorA:

mysql –u root –p

mysql> CHANGE MASTER TO MASTER_HOST='192.168.146.90',
        MASTER_USER='mastera',
        MASTER_PASSWORD='sesamo',
        MASTER_LOG_FILE='mysql-bin.000001',
        MASTER_LOG_POS=98;
Query OK, 0 rows affected (0.10 sec)

mysql> START SLAVE;

mysql> SHOW SLAVE STATUS\G

*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 192.168.146.90
                Master_User: mastera
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000001
        Read_Master_Log_Pos: 98
             Relay_Log_File: mysqld-relay-bin.000002
              Relay_Log_Pos: 235
      Relay_Master_Log_File: mysql-bin.000001
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB:
        Replicate_Ignore_DB:
         Replicate_Do_Table: asterisk.cdr
     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)

Ahora la prueba.

Paramos el MySQL del servidorB y hacemos dos llamadas al buzón de voz con asterisk activo en el servidorA

El resultado en la base de datos:

mysql -u root -p

mysql> use asterisk

mysql> select id,calldate from cdr where dst=97;

| 2736 | 2010-02-23 13:06:56 |
| 2737 | 2010-02-23 13:06:56 |
| 2738 | 2010-02-24 06:05:53 |
| 2739 | 2010-02-24 06:05:53 |
| 2791 | 2010-02-24 09:48:44 |
| 2801 | 2010-02-24 09:49:00 |
+------+---------------------+
207 rows in set (0.00 sec)

Mientras antes el ID era progresivo, las ultimas dos entradas tienen un salto de 10 y cada una termina con el numero 1

Terminada la operación, paramos MySQL en el servidorA y iniciamos MySQL en el servidorB haciendo dos llamadas al buzón de voz usando el Asterisk del servidorB

El resultado en la base de datos:

mysql -u root -p

mysql> use asterisk

mysql> select id,calldate from cdr where dst=97;

| 2736 | 2010-02-23 13:06:56 |
| 2737 | 2010-02-23 13:06:56 |
| 2738 | 2010-02-24 06:05:53 |
| 2739 | 2010-02-24 06:05:53 |
| 2752 | 2010-02-24 09:55:07 |
| 2762 | 2010-02-24 09:57:17 |
+------+---------------------+
207 rows in set (0.01 sec)

El ID progresivo en el servidorB cambia con saltos de 10 y cada entrada termina con el numero 2

Ahora iniciamos MySQL en el servidorA y miramos que pasa en los dos servidores:

ServidorA:

mysql -u root –p

mysql> use asterisk

mysql> select id,calldate from cdr where dst=97;

| 2737 | 2010-02-23 13:06:56 |
| 2738 | 2010-02-24 06:05:53 |
| 2739 | 2010-02-24 06:05:53 |
| 2752 | 2010-02-24 09:55:07 |
| 2762 | 2010-02-24 09:57:17 |
| 2791 | 2010-02-24 09:48:44 |
| 2801 | 2010-02-24 09:49:00 |
+------+---------------------+
209 rows in set (0.00 sec)

ServidorB

mysql -u root –p

mysql> use asterisk

mysql> select id,calldate from cdr where dst=97;

| 2739 | 2010-02-24 06:05:53 |
| 2752 | 2010-02-24 09:55:07 |
| 2762 | 2010-02-24 09:57:17 |
| 2791 | 2010-02-24 09:48:44 |
| 2801 | 2010-02-24 09:49:00 |
+------+---------------------+
209 rows in set (0.01 sec)

Los datos se han replicado y no hubo ningún tipo de conflicto en la tabla cdr gracias al uso de:

auto_increment_increment
auto_increment_offset

Eso es todo.