Asterisk y la replicación MySQL Master-Master en CentOS

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

Aqui pongo la fuente ya que una señorita corrió diciendo que me robe el post jaja casualmente yo envie un trackback, pero bueno dedicado a la señorita o señora Andrea Sannucci

FUENTE

Asterisk y la replicación MySQL Master-Slave en CentOS

En esta ocasión les traigo unos buenos post que hallé en voztovoice, se trata de la replicación de las BD's de los CDR en Asterisk, un agradecimiento por su gran esfuerzo.

Tenemos nuestro servidor Asterisk instalado y trabajando con los registros de las llamadas guardados en una base de datos MySQL. Queremos tener una copia de la base de datos actualizada en tiempo real para hacer frente a cualquier tipo de evento que pueda afectar la integridad de los registros de las llamadas. En este tipo de escenario tenemos a disposición una funcionalidad de MySQL; la posibilidad de replicar los datos en un servidor MySQL instalado en otro computador. Tenemos dos formas de replicar los datos:

• configurar una replicación master-slave (maestro-esclavo)


• configurar una replicación master-master (maestro-maestro)

En este primer articulo sobre el tema, veremos como crear una replicación MySQL master-slave. La replicación master-slave no es una copia de backup de la base de datos, de hecho si borramos una entrada en el MySQL maestro, automáticamente se borrará también en el esclavo. La idea es tener siempre una copia de backup y además crear la replicación maestro-esclavo.

Podemos usar el esclavo para consultas desde otros programas y de esta manera no cargar demasiado el Maestro. Un ejemplo puede ser cuando vamos a generar reportes mensuales de las llamadas. En vez de hacer las consultas en el maestro, las podemos hacer en el esclavo.

Es buena practica usar una conexión dedicada para el intercambio de datos entre el maestro y el esclavo para evitar que hayan retrasos considerables en la actualización de la base de datos.

¿Como funciona la replicación MySQL Master-slave?

• El Maestro registra los cambios en un registro binario (Binary log)


• El esclavo copia los eventos en un registro propio (Relay log)


• El esclavo lee y repite los eventos presentes en el Relay log en la base de datos

Una imagen que explica el funcionamiento:

El escenario que se va a presentar en este articulo es el siguiente:

ServidorA:

IP LAN: 192.168.142.248

Base de datos a replicar: asterisk

Master

ServidorB:

IP LAN: 192.168.146.90

Esclavo

Servidor A:

Creamos una carpeta donde guardar los Binary log:

mkdir /var/log/mysql

Cambiamos los permisos de modo que MySQL pueda escribir y leer en esa carpeta:

chown mysql:mysql /var/log/mysql

Entramos en el cliente mysql

mysql -u root -p

y creamos los privilegios de replicación para un nuevo usuario que luego configuraremos en el servidorB:

myslq> GRANT REPLICATION SLAVE ON *.* TO 'fulano'@'192.168.146.90' IDENTIFIED BY 'sesamo';

Actualizamos los privilegios y salimos del cliente MySQL:

mysql> flush privileges;

mysql> quit

Ahora modificamos el archivo de configuración de MySQL para configurar los parámetros necesarios para la replicación:

nano /etc/my.cnf

Bajo la etiqueta [mysqld] añadimos las siguientes línea:

server-id               = 10
log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M
binlog_do_db            = asterisk
sync_binlog=1

Una pequeña explicación de los parámetros:

• server-id: identifica el servidor MySQL.


• log_bin: nombre del archivo donde se guardará el Binary log


• expire_log_days: especifica que los archivos Binary log más viejos de 10 días se pueden borrar


• max_binlog_size: el tamaño máximo de un Binary log


• binlod_do_db: el nombre de la base de datos que queremos replicar


• sync_binlog=1: cada evento generado en el Master será escrito inmediatamente en el Binary log. Aumenta la carga del Master a cambio de una replicación más precisa

Guardamos los cambios y 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 servidor MySQL esclavo:

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 -psesamo asterisk > asteriskslave.sql

copiamos el archivo en el servidoB en la carpeta tmp:

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

Servidor B

Si no tenemos instalado MySQL, lo instalamos:

yum install mysql mysql-server mysql-devel

Lo iniciamos:

/etc/init.d/mysqld start

Creamos una contraseña para el usuario root:

mysqladmin –u root password sesamo

Modificamos el archivo de configuración de MySQL

nano /etc/my.cnf

bajo la etiqueta [mysqld] ponemos:

server-id=20
master-connect-retry=60
replicate-do-db=asterisk
skip_slave_start
read_only

Los parámetros:

• server-id: numero que identifica el servidor MySQL del servidorB


• master-connect-retry=60: si el esclavo pierde la conexión con el maestro, cada 60 segundos intentará restablecerla


• replicate-do-db: la base de datos que vamos a replicar


• skip_slave_start: evita que el esclavo se reinicie en el caso de un crash del servidor


• read_only: no permite a la mayoría de los usuarios del servidor MySQL esclavo cambiar las tablas

Guardamos los cambios y volvemos a arrancar MySQL:

/etc/init.d/mysqld restart

Creamos la base de datos asterisk:

mysqladmin -uroot -psesamo create asterisk

recuperamos tablas y datos de la copia que tenemos en la carpeta /tmp:

cd /tmp

mysql -u root -psesamo asterisk < asteriskslave.sql

Llegados a este punto creamos los datos de acceso al servidor MySQL Master:

mysql -u root -psesamo

mysql> CHANGE MASTER TO MASTER_HOST='192.168.142.248',
MASTER_USER='fulano',
MASTER_PASSWORD='sesamo',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=98;

En MASTER_LOG_FILE Y MASTER_LOG_POS, ponemos los datos del servidor MySQL A que habíamos apuntado.

Iniciamos el esclavo:

mysql> START SLAVE;

Controlamos el estado de la conexión con el Master:

mysql> SHOW SLAVE STATUS\G

*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.142.248
Master_User: fulano
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: asterisk
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)

Salimos del cliente:

mysql> quit

Ahora hacemos una llamada de prueba y miramos que pasa en el servidorA (captura de paquetes en el puerto 3306 con ngrep):

#
T +7.266866 192.168.142.248:3306 -> 192.168.146.90:58745 [AP]
:......~K.
...9.........
..............@.............std.......asterisk.INSERT INTO cdr (calldate,src,dst,dcontext,channel,lastapp,duration,billsec,disposition,amaflags,accountcode,uniqueid) VALUES ('2010-02-19 12:34:14','2100','97','phones','SIP/2100-00000001','Hangup','26','26','ANSWERED','3','2100','1266600854.1')
##

El servidorA 192.168.142.248:3306 envía un paquete al servidorB 192.168.146.90:58745 que contiene los datos de la llamada. El ServidorB guarda los datos en su Relay log y luego de leer el Relay log los guarda en la base de datos.

Esto es todo, un largo pero enriquecedor artículo