WWW.RADIOMACONDO.FM: ¿Qué se aprobó en el proyecto de Ley 201?

WWW.RADIOMACONDO.FM: ¿Qué se aprobó en el proyecto de Ley 201?: Dos días antes de que el presidente de los Estados Unidos, Barack Obama, pise suelo colombiano, tanto el Senado como la Cámara de Representa...

solucionar problemas de sonido en gateway 3522gz en linux

como solucionar problemas de sonido en gateway 3522gz
en linux ubuntu

Fecha: 2012-abril-9

problema:
no hay sonido.

Detalle del problema:
La versión de  ubuntu es oneiric 11.10
el driver esta instalado y el hardware de la tarjeta de sonido son detectados.
No aparecen errores en dmesg o errores al reproducir un sonido.

solución:
Al parecer la instalación por defecto del driver hace que quede activada una opción que no se usa en la configuración de sonido de Ubuntu y esto ocasiona que el sonido este muteado.

Lo que se debe hacer es instalar el programa de configuración de la tarjeta y despues configurarla.

Primero se debe instalar gnome-alsamixer, aplicación que muestra opciones extendidas de configuración de la tarjeta de sonido.

sudo apt-get install gnome-alsamixer

Al iniciar este programa se debe desactivar la casilla que indica "External Amplifier".

si esto no funciona, verificar que exista algun nivel de audio en el canal master, en PCM y en stereo.

Si esto no llegara a funcionar, probar seleccionando y deseleccionando las casillas mostradas una por una.

Replicación en MySQL

INTRO

Aunque he trabajado con MYSQL desde hace más de 8 años, no había tenido la oportunidad de usar en forma la bien conocida característica de replicación en MYSQL. Esta característica permite duplicar en línea los datos de un servidor a otro y es altamente configurable. Lamentablemente o afortunadamente, he tenido unos tropiezos para configurar los servidores y ajustarlos de la manera en que los necesito. En este escrito resumo la configuración de una replicación de dos servidores maestro-esclavo.

HISTORIA

Inicialmente había la necesidad de disminuir la carga de un servidor cuyas actualizaciones e inserciones eran frecuentes y que esporádicamente se consultaba. El problema consistía en que cuando los registros pasaban del millón, las consultas se hacían supremamente lentas y lo peor del caso era que las consultas hacían que algunos procesos de inserción abortaran por timeout. Al no poder crecer en hardware lo que se hizo fuépensar inmediatamente en alguna forma de copia de la BD a otro servidor. Sin embargo la Base de datos es bastante grande por lo que esto se descartó. Se pensó entonces en usar el sistema de replicación nativa de Mysql y ver como se comportaba.

Replicación remota

Basicamente se hizo todo el proceso desde cero:

• Se configuró el servidor maestro
• Se bloqueó la BD para no permitir escritura
• Se hizo un Dump de la BD
• Se copió la BD remotamente. Esta parte fue algo demorada.
• Se desbloqueo la BD
• Se hizo el import al nuevo servidor
• Se activó la replicación en el servidor esclavo

Luego de un tiempo se hizo una revisión del servidor esclavo y apareció inicialmente con errores de consultas SQL. Poco tiempo después al poder resolver el problema también aparecía con otro tipo de errores y había que “saltar” ciertas consultas leidas con errores para que continuara la replicación.

El caso es que después de varios saltos hechos manualmente a las consultas y a los logs, la replicación ya no se pudo recuperar y toco empezar de cero la copia y volver a replicar. Despues de varios intentos fallidos con la replicación remota se decidió por cambiar la forma de copiar la información local.

Replicación Local

La conclusión a la que se llegó es que como la replicación se hacía a través de equipos que pertenecen a redes remotas, y como el número de transacciones por segundo es alto, hay una gran probabilidad de que la replicación falle en algún punto. Es decir, la replicación configurada no sirve para redes con pérdida considerable de paquetes de datos.

El método de replicación que funcionó fue dejar el servidor de replica dentro de la misma máquina, aunque supongo que debería funcionar dentro de una LAN, o una red lo suficientemente rápida que permita el transporte confiable de datos.

Se instaló en el mismo equipo un servidor MYSQL en un puerto alterno que serviría como esclavo. A continuación explico la configuraciones paso a paso para complatar la replicación.

PASOS DE CONFIGURACION

Se configura el maestro para que permita la conexión del servidor esclavo:

log-bin = /var/log/mysql/mysql-bin.log
binlog-do-db=exampledb
server-id=1

GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY ''; (reemplace con el password real)
FLUSH PRIVILEGES;

Desde una consola del Maestro se ejecuta el comando siguiente para bloquear la escritura de tablas:

USE exampledb;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

Lo que muestra una información parecida a:

+---------------+----------+--------------+------------------+
| File          | Position | Binlog_do_db | Binlog_ignore_db |
+---------------+----------+--------------+------------------+
| mysql-bin.006 | 183      | exampledb    |                  |
+---------------+----------+--------------+------------------+
1 row in set (0.00 sec)

Con este comando se verifica el estado de los logs y la posición. Esta información se usará mas tarde.Esta conexión se deja abierta mientras termina el proceso de replicación.

En otra consola, se hace el respectivo backup de la base o bases de datos a replicar:

mysqldump -u root -p --opt exampledb > exampledb.sql (Reemplace con el password real de MySQL)

En el mysql esclavo se ejecuta el siguiente comando para realizar el import de la bd

mysql -u root -p
Enter password:
CREATE DATABASE exampledb;
quit;

mysql -u root -p exampledb < /path/to/exampledb.sql

La consola del maestro inicial se puede cerrar en este momento. Ejecutar en la linea de comandos de mysql:

mysql> UNLOCK TABLES;

Se debe editar el archivo de configuracion/etc/mysql.cnf en el esclavo para activar la replicación:

server-id=2
master-host=192.168.0.100
master-user=slave_user
master-password=secret
master-connect-retry=60
replicate-do-db=exampledb

y después reiniciar el MySQL.

Luego se abre una consola de mysql en el esclavo y se ejecuta este comando con los datos de posición del archivo copiados antes:

STOP SLAVE;

CHANGE MASTER TO MASTER_HOST='192.168.0.100', MASTER_USER='slave_user', MASTER_PASSWORD='', MASTER_LOG_FILE='mysql-bin.006', MASTER_LOG_POS=183;

START SLAVE;

Para verificar el estado de la replicación se ejecuta el sgte comando:

SHOW SLAVE STATUS\G

Entre las cosas mas importantes a verificar en esta salida es verificar que estas dos líneas estén en Yes:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Referencias:

http://www.howtoforge.com/mysql_database_replication

http://www.howtoforge.com/how-to-set-up-database-replication-in-mysql-on-ubuntu-9.10

http://dev.mysql.com/doc/refman/5.0/en/replication-howto.html