Video Tutorial de Dropbox en español - Aprende a alojar y sincronizar tus archivos en Internet

Dropbox es un popular servicio de alojamiento y sincronización de archivos a través de Internet, que se convirtió en una de las herramientas más recomendadas gracias a su gran utilidad.

Les comparto un video-tutorial, creado por Polin, que te guiara paso a paso en el uso de esta fantástica herramienta.

Puedes verlo a continuación o descargarlo desde el enlace al final del post (Si aun no tienes Dropbox te invito a que lo descargues en el siguiente enlace: Abre tus archivos en cualquier lugar con Dropbox).

Elastix redundante, método fácil

Este manual describe como armar un cluster con dos elastix para tener redundancia en caso de que el principal falle. La operación nos dará mas disponibilidad del servicio, en condiciones normales si nuestra centralita falla el tiempo que estaremos sin comunicación será el que nos tome copiar las configuraciones en otro servidor, ó si ya lo tenemos listo, el tiempo que sea necesario para encenderlo y conectarlo.
La ventaja del sistema que se plantea en este manual es que las configuraciones se respaldan por red cada minuto, así en caso de fallas tendremos en un par de minutos un sistema casi idéntico al que estaba en producción antes del fallo.
El servidor Maestro copiará cada minuto sus archivos de configuración hacia el Esclavo.

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

Backups con rsync

Una pequeña guía que iré modificando para hacer respaldos con rsync

Rsync es una herramienta para sincronizar los ficheros y directorios que tenemos almacenados en un sitio en otro diferente minimizando la transferencia de datos. En realidad, rsync son dos cosas: unalgoritmo de delta compression para sincronizar dos ficheros similares y una utilidad que usa dicho algoritmo junto con otras técnicas para hacer mirroring de ficheros y directorios en otro sitio transfiriendo la mínima cantidad de datos posible.

A nivel de un árbol de directorios con sus ficheros, la idea es sencilla. rsync nos copiará esos ficheros y directorios tal y como estaban en el nuevo sitio pero sin copiar todo, sino sólo lo que ha cambiado en el origen respecto al destino. Hacer lo mismo copiando los ficheros y directorios, incluso en remoto usando una carpeta compartida, sería equivalente si nos fijamos únicamente en el resultado, pero tenemos que transferir mucha más información.

El listado de características especiales que nos da la página de man de rsync es:

• Soporte para copiar enlaces, ficheros de dispositivo, propietarios, grupos y permisos


• Opciones de exclusión (exclude y exclude-from) similares a las del GNU tar


• Modo CVS para ignorar los fichero que CVS ignoraría


• Se puede usar cualquier shell remota transparente, como ssh o rsh


• No es necesario ser root para usarlo


• pipelining de los ficheros transferidos para minimizar la latencia


• Soporte para usuarios anónimos o autentificados usando el demonio de rsync (ideal para hacer mirroring

NOTA IMPORTANTE:

La barra al final de los nombres de directorio

Respecto a cómo pasarle los nombres de los directorios, hay que tener una especial atención respecto a si ponemos una barra al final del nombre del directorio o no, ya que significan cosas distintas:

You can think of a trailing / on a source as meaning “copy the contents of this directory” as opposed to “copy the directory by name”, but in both cases the attributes of the containing directory are transferred to the containing directory on the destination. In other words, each of the following commands copies the files in the same way, including their setting of the attributes of /dest/foo:

rsync -av /src/foo /dest

rsync -av /src/foo/ /dest/foo

Efectivamente, /path/foo significa “el directorio foo“, mientras que /path/foo/ significa “lo que hay dentro de foo“.













RSYNC remoto

En la máquina destino es posible usar el propio proceso rsync funcionando como demonio y escuchando por defecto en el puerto 873 para recibir estas conexiones, pero es mucho más cómodo y fácil hacerlo por SSH, algo para lo que rsync ya está preparado por defecto.

Para esto es conveniente configurar el cliente y el servidor de SSH involucrados para entrar de forma transparente usando autentificación por clave pública para evitar tener que introducir la contraseña cada vez, aunque no es estrictamente necesario.

Autentificación trasparente por clave pública/privada con OpenSSH

El primer paso es generar la pareja de claves pública/privada en el cliente con el comando ssh-keygen:

$ ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/home/supercoco/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/supercoco/.ssh/id_rsa.

Your public key has been saved in /home/supercoco/.ssh/id_rsa.pub.

The key fingerprint is:

5c:7b:3d:44:21:09:84:a1:e6:8b:42:4e:ec:39:d6:92 supercoco@cliente

Si no le especificamos opciones, el comando crea una clave RSA de 2048 bits, pero podemos cambiar este comportamiento. Por ejemplo, para clave DSA de 1024 bits, sería:

$ ssh-keygen -t dsa -b 1024

Generating public/private dsa key pair.

Enter file in which to save the key (/home/supercoco/.ssh/id_dsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/supercoco/.ssh/id_dsa.

Your public key has been saved in /home/supercoco/.ssh/id_dsa.pub.

The key fingerprint is:

91:84:38:fd:03:b4:74:5a:1c:ad:48:c4:da:57:3b:cc supercoco@cliente

Hay que tener en cuenta que si le especificamos una passphrase, tendremos que introducirla manualmente cada vez que queramos usar la clave privada, por lo que la autentificación no será transparente. Por ello, aunque no sea lo más seguro, para nuestro propósito es necesario dejarla en blanco.

Y ahora sólo tenemos que copiar el contenido el fichero id_dsa.pub o del id_rsa.pub en el fichero authorized_keys del directorio $HOME/.ssh/ del usuario del sistema con servidor SSH al que queremos acceder.

Por ejemplo, si queremos entrar en el servidor SSH con el usuario ranagustavo, tendríamos que añadir el contenido de los ficheros/home/supercoco/.ssh/id_dsa.pub o /home/supercoco/.ssh/id_rsa.pub del cliente de SSH al fichero /home/supercoco/.ssh/authorized_keys del servidor de SSH.

Si tenemos la contraseña para entrar, podríamos incluso hacerlo desde el cliente con un par de comandos:

$ scp $HOME/.ssh/id_dsa.pub ranagustavo@servidor:id_dsa.pub.supercoco.cliente

Password:

id_dsa.pub

$ ssh ranagustavo@servidor 'cat id_dsa.pub.supercoco.cliente >> .ssh/authorized_keys'

y ya podemos entrar sin introducir la contraseña:

$ ssh ranagustavo@servidor

Linux servidor 2.6.22 #2 SMP Sun Dec 9 19:33:44 CET 2007 x86_64

The programs included with the Debian GNU/Linux system are free software;

the exact distribution terms for each program are described in the

individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.

No mail.

Last login: Sun Jan 13 22:12:58 2008 from cliente

ranagustavo@servidor ~ $

Una vez que esté configurado correctamente, podemos incluso querer configurar el servidor de SSH para que no acepte clientes que quieran entrar por el método estándar, la contraseña. Para ello, partiendo de la configuración estándar de Debian (con otras configuraciones base, puede ser necesario hacer más cosas), sólo tenemos que cambiar los parámetros ChallengeResponseAuthentication y PasswordAuthentication del fichero /etc/ssh/sshd_config a “no“:

# Change to yes to enable challenge-response passwords (beware issues with

# some PAM modules and threads)

ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords

PasswordAuthentication no

Ademas de agregar

AllowUsers usuario_que_tu_decidas

No permitir que root se pueda conectar
PermitRootLogin no

Con un “/etc/init.d/ssh reload” conseguiremos que el sshd relea la configuración.

Agregamos en el .bashrc del usuario:

#eval `ssh-agent`

#ssh-add

eval `ssh-agent`

ssh-add

CONFIGURACIÓN DE RSYNC

Please use the script code below (modify as needed), as it will only sync to “touched” files.

#!/bin/bash
rsync -avz –size-only -e “ssh -i /root/rsync-key” /etc/asterisk/extensions.confroot@192.168.1.3:/etc/asterisk/extensions.conf
rsync -avz –size-only -e “ssh -i /root/rsync-key” /etc/asterisk/voicemail.confroot@192.168.1.3:/etc/asterisk/voicemail.conf
rsync -avz –size-only -e “ssh -i /root/rsync-key” /etc/asterisk/queues.confroot@192.168.1.3:/etc/asterisk/queues.conf
rsync -avz –size-only -e “ssh -i /root/rsync-key” /etc/asterisk/sip.confroot@192.168.1.3:/etc/asterisk/sip.conf
rsync -avzr –size-only -e “ssh -i /root/rsync-key” /var/spool/asterisk/voicemailroot@192.168.1.3:/var/spool/asterisk
rsync -avzr –size-only -e “ssh -i /root/rsync-key” /var/lib/asterisk/mohroot@192.168.1.3:/var/lib/asterisk/moh
rsync -avzr –size-only -e “ssh -i /root/rsync-key” /var/lib/asterisk/soundsroot@192.168.1.3:/var/lib/asterisk
rsync -avzr –size-only -e “ssh -i /root/rsync-key” /home/PlcmSpIproot@192.168.1.3:/home
rsync -avzr –size-only -e “ssh -i /root/rsync-key” /var/www/html/root@192.168.1.3:/var/www