Posts encontrados en noviembre, 2007

nov 07 30

CordobaWeblogs festeja fin de año

Tiempo estimado de lectura: 0,35 minutos

CórdobaWeblogs organiza un Beers and Blog para cerrar el año. Será el jueves 13 de diciembre a las 20 hs en algún lugar a confirmar.

Es increíble la cantidad de blogs que se unieron en tan solo par de meses. Si bien me perdí la ultima reunión, creo ya los B&B no se componen de un puñado de geeks hablando de cosas como Mac vs PC, Estándares web, CSS, PHP.

La masificación de los blog hizo que estos se enriquecieran con una innumerable cantidad de temas e intereses. Periodismo, diseño, arte, literatura, actualidad son algunos de los temas que actualmente se pueden leer en la blogósfera cordobesa y que se agregaron a los tradicionales blogs tecnológicos y personales.

Bueno, me fui por las ramas, confirmá tu asistencia siguiendo ésta URL. Espero que esta vez nada me impida faltar.

nov 07 26

Replicación de bases de datos mysql (Parte 3)

Tiempo estimado de lectura: 3,24 minutos

A partir del mysql 5, es posible replicar servidores de bases de datos MySql, algo que no mucha gente usa por el hecho que no siempre se dispone del acceso a la administración de más de un servidor.

Esta serie de posts tiene como objetivos:

1) Dar a conocer esta extraordinaria funcionalidad de MySql
2) Comentar mi experiencia en un proyecto que utiliza 5 servidores de mysql replicados en diferentes ubicaciones geográficas.
3) Retomar este tipo de post didáctico que hace mucho abandoné por falta de tiempo.

Ver primero la parte 1: “Introducción a la replicación
O ver la parte 2: “Caso práctico de replicación de bases de datos

Soluciones a los problemas comunes de la replicación

Como ya les había comentado en los post anteriores de esta serie, el proyecto en el que trabajo utiliza 5 servidores de MySql replicados. Dos de esos servidores se encuentran alojados en Argentina y tres en Estados Unidos.

La replicación entre ellos es constante y caudalosa, sin embargo ésta suele fallar por diferentes motivos inherentes a los datos y a la estructura de ls bases de datos.

A continuación listaré un conjunto de fallas comunes que suelen tener las replicaciones y sus respectivas soluciones que hemos probado con éxito.

Por lo general, para corroborar el estado de una replicación, conviene realizar un chequeo en el servidor esclavo con el siguiente comando en la consola mysql:

SHOW SLAVE STATUS \G;

Esta acción mostrará un listado de parámetros que nos indican en que estado se encuentra la replicación; a continuación les comentaré brevemente los más importantes e indicativos de posibles problemas.

Slave_IO_State: Indica el estado del esclavo
Master_Log_File: Indica el archivo del del master que esta siendo leído
Read_Master_Log_Pos: Indica la ultima posición que el esclavo ya leyó del master
Relay_Log_File: Indica el archivo de log propio que el esclavo esta executando
Relay_Log_Pos: Indica la posición del log propio que el esclavo esta ejecutando
Relay_Master_Log_File: Indica el log del master que el esclavo esta ejecutando
Slave_IO_Running: Indica si esta conectado al servidor master
Skip_Counter: Indica si se ha salteado alguna posición
Exec_Master_Log_Pos: Indica la posición del log del maestro que esta siendo ejecutada
Seconds_Behind_Master: Parámetro de tiempo en que tardará el esclavo en llegar hasta la ultima posición del ultimo log del Master

Los primeros parametros que suelo fijarnme son el “Slave_IO_Running” ya que si está en “No”, es porque no está conectado con el master y el “seconds_behind_master” ya que si esta conectado lo ideal sería que tenga 0 segundos. Si no es cero, por lo gral ejecuto el show slave status \G; varias veces con cierto intevalo de tiempo para ver si se incrementa.

En caso que se incremente significa que el master guarda más resultados de lo que el slave está leyendo, entonces nos fijamos en el número del parámetro “Exec_Master_Log_Pos” Si no se mueve despues de un cierto tiempo, hay un problema.

Problemas comunes conocidos:

La consulta que el slave está ejecutando está trabada o tarda demasiado. Para esto por lo general sugiero parar la replicación del slave: “STOP SLAVE;” y adelantar posiciones en el los ejecutando: “SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 10;” (10 son las posiciones que nuestro log avanzará). Pueden probar de a uno si quieren, en mi caso que el sistema procesa más de 600,000 inserts por día no es demasiado problema un salto de 10 registros. Una vez avanzado, hay que iniciar nuevamente el slave: “START SLAVE;”

Una de nuestras tablas MyIsam esta dañada: Para esto se deberá parar la replicación: “STOP SLAVE;” y ejecutar desde consola de MySQL el comando “REPAIR TABLE nombredetabla;”. Si esto no lo solucionó, se puede hacer desde afuera del motro mysql con el comando “myisamchk –safe-recover nombredetabla.MYI” (repito: fuera de mysql, en el shel de linux y dentro de la carpeta de los archivos binarios de los datos de mysql)

Muchas veces se requiere hacer consultas grandes que sólo queremos hacerlo en el master pero no queremos que se replique, casos muy comunes de este tipo son el OPTIMIZE o el REPAIR ambas consultas quedarían logueadas y pasarían al esclavo trabando considerablemente el flujo de la información. Para solucionar esto sólo hay que agregar: NO_WRITE_TO_BINLOG inmediatamente despues del comando. EJ: “OPTIMIZE NO_WRITE_TO_BINLOG TABLES nombredetabla;”

Espero que esta serie de posts pueda serles de utilidad algún día. La replicación hasta 4 servidores de MySql, como ya mensioné en el primer post, es la forma de escalabilidad más económica que puede tener un sistema a nivel de bases de datos. Además puede ser de gran utilidad poara mantener backups sincronizados de forma permanente.

Creo haber cumplido con todos los objetivos propuestos y creo también que fue una buena forma de retomar con este blog un tanto olvidado.

nov 07 20

Replicación de bases de datos mysql (Parte 2)

Tiempo estimado de lectura: 3,50 minutos

A partir del mysql 5, es posible replicar servidores de bases de datos MySql, algo que no mucha gente usa por el hecho que no siempre se dispone del acceso a la administración de más de un servidor.

Esta serie de posts tiene como objetivos:

1) Dar a conocer esta extraordinaria funcionalidad de MySql
2) Comentar mi experiencia en un proyecto que utiliza 5 servidores de mysql replicados en diferentes ubicaciones geográficas.
3) Retomar este tipo de post didáctico que hace mucho abandoné por falta de tiempo.

Ver primero la parte 1: “Introducción a la replicación” o ve como solucionar problemas de replicación de mysql

Caso Práctico de replicación de bases de datos

Imaginemos que tenemos sistema requiere de dos servidores de base de datos que tengan la misma información. Pero como nuestro sistema tiene un módulo de estadísticas, necesitamos que uno de ellos mantenga históricamente todos los registros mientras que el otro sólo mantenga los últimos 30 días para que las consultas sean mucho más rápidas ya que es información que se vuelve obsoleta y por lo tanto innecesaria fuera del módulo de estadísticas.

Realizar dos conexiones a dos bases de datos distintas para ejecutar nuestros inserts/updates es poco eficiente y poco seguro, sería común ver inconsistencias. Para este caso, entonces, nada mejor que realizar una replicación.

Configuraremos entonces para que que el servidor maestro replique hacia el slave todos los inserts y updates que se ejecuten en éste y se configurará un cron en el esclavo que borre diariamente todos los listings anteriores a 30 días. De esta forma cada insert o update que se realice en el maestro se realizará también en el esclavo que, además, borrará los registros viejos todos los días.

Esto es mucho más seguro, porque todos los inserts/updates son logueados y controlados. Podemos saber y corregir en todo momento cual es la inconsistencia si la hubiese entre ambos servidores.

A continuación les presento un ejemplo de cómo configurar esta funcionalidad en ambos servidores para que cumplan su papel.

Configurar el servidor Maestro (Master)

1) Como primer paso, debemos decirle al servidor Master dónde va a loguear toda su actividad; qué va a loguear, es decir que base de datos queremos que loguee y además le asignaremos un identificador. Para esto debemos editar el my.cnf de mysql agregando líneas como éstas:

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

También debemos decir que permita el acceso remoto, no sólo el acceso desde el localhost; por lo que debemos comentar estos parámetros en caso de que existan.

#bind-address
#skip-networking

2) Reiniciamos el servidor de mysql desde la consola de linux y nos logueamos por consola al mysql con acceso root

# /etc/init.d/mysql restart
# mysql -u root -p

3) Como próximo paso, debemos crear un usuario con acceso a la replicación. Este usuario es el que usará el Slave para identificarse. En la consola MySql y con acceso root, podrán crear el usuario de esta forma (también pueden usar phpMyAdmin para crearlo)

GRANT REPLICATION SLAVE ON *.* TO 'slave1'@'%' IDENTIFIED BY 'slave_password';
FLUSH PRIVILEGES;

slave1: será el nombre de usuario
slave_password: será el password de ese usuario

4) Ahora necesitamos saber la información del log para configurar el servidor slave, lo podremos hacer con el siguiente comando tambien en la consola MySql:

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

Les aparecerá una tabla con la el nombre del log, la posición, la base, etc. Copien esa info a algun archivo de texto a menos que tengan mucha memoria fotográfica.

Para terminar con el servidor Maestro sólo resta desbloquear las tablas bloqueadas en el paso anterior desde la consola MySql:

UNLOCK TABLES;
quit;
Configurar el servidor esclavo

1) Suponiendo que ya creamos la base de datos con el mismo nombre que la del Maestro, vamos directamente a editar la configuración del archivo my.cnf de mysql agregando/editando estas líneas:

# Servirá como identificador
server-id=2
# El ip del servidor Master
master-host=190.17.9.105
# El monbre de usuario que configuramos en el master
master-user=slave_user
# El password del usuario que configuramos en el master
master-password=slave_password
# Segundos antes de reintentar conectarse
master-connect-retry=60
# Base de datos a replicar
replicate-do-db=nuestra_DB

2) Reiniciamos entonces el servidor esclavo para que tome la nueva configuración:

# /etc/init.d/mysql restart

3) Nos logueamos como root al MySql y le decimos al esclavo que carge la info que exista en la DB del maestro para tener como punto de partida:

#mysql -u root -p
# Enter password:

LOAD DATA FROM MASTER;

4) En este paso, le vamos a tener que proveer a nuestro slave, la info que guardamos en el txt acerca del log del master parando la replicación (estos valores son de ejemplo, cambienlo por el que tienen ustedes):

SLAVE STOP;

CHANGE MASTER TO MASTER_HOST='190.17.9.105', MASTER_USER='slave_user',
MASTER_PASSWORD='slave_password',
MASTER_LOG_FILE='mysql-bin.002',
MASTER_LOG_POS=4;

5) Reiniciamos el servicio esclavo y ya tenemos nuestra replicación andando:

START SLAVE;
quit;

Para saber si la replicación está andando sólo basta con poner el siguiente comando en la consola MySql

SHOW SLAVE STATUS G;

Esto fue todo en cuanto a la configuración de los servidores, espero que puedan seguir los pasos sin mayores inconvenientes.

Para el próximo y último post de esta serie, voy a comentar mi experiencia con esta funcionalidad y voy a dejar varias soluciones a problemas que surgieron en el proyecto que administraba y que sin duda les será útil si esto alguna vez les falla.

nov 07 18

Crealo tu mismo

Tiempo estimado de lectura: 0,27 minutos

Según su autor, crealotumismo.com Es un sitio basado en la práctica DIY (Do It Yourself), que se refiere a la fabricación o reparación de cosas por uno mismo, de modo que se ahorra dinero, se entretiene y se aprende al mismo tiempo.

Me resultó interesante y bastante práctico. Apenas disponga del tiempo y los materiales necesarios quiero poner en práctica el ventilador USB. También me gustó, aunque menos útil, el Rifle Gauss y cómo convertir un lápiz en una linterna provisoria

Para llamar la atención de la gente curiosa también hay estanterías invisibles

Útil, entretenido y un blog made in Córdoba.

nov 07 15

Replicación de bases de datos mysql (Parte 1)

Tiempo estimado de lectura: 2,22 minutos

A partir del mysql 5, es posible replicar servidores de bases de datos MySql, algo que no mucha gente usa por el hecho que no siempre se dispone del acceso a la administración de más de un servidor.

Esta serie de posts tiene como objetivos:

1) Dar a conocer esta extraordinaria funcionalidad de MySql
2) Comentar mi experiencia en un proyecto que utiliza 5 servidores de mysql replicados en diferentes ubicaciones geográficas.
3) Retomar este tipo de post didáctico que hace mucho abandoné por falta de tiempo.

Si ya leiste esta introducción o tenés conocimientos acerca de que se trata visita: “Caso práctico de replicación de bases de datos“ o “Solución de problemas comunes de replicación de BD MySql

Introducción a la replicación

La replicación de bases de datos es una funcionalidad que permite que toda acción realizada a un servidor de base de datos se replique automáticamente en otro servidor. Bajo este concepto, cualquier insert, update, delete, optimize o cualquier otra consulta que modifique la base de datos en cuestión, se ejecutará de la misma forma en el servidor replicado.

Es extremadamente útil cuando se trabaja con servidores en distintas ubicaciones geograficas y forman parte de un mismo sistema. También para realizar backups automáticamente y tener las mismas bases de datos disponibles todo el tiempo en diferentes servidores.

Esta funcionalidad se basa en un sistema cliente-servidor aunque mysql lo llama esclavo-maestro (slave-master). Funcionalmente es el servidor esclavo quien lee y ejecuta todas las instrucciones que un maestro ejecutó. Estas instrucciones son registradas en un log binario en el maestro y el esclavo mantiene un log de las posiciones que ya leyó y ejecutó del maestro.

Toda esta operación se realiza de forma asíncrona. Es decir, no hace falta que la conexión entre el esclavo y el maestro este constantemente activa ya que el maestro sigue logueando en su log y el esclavo lo leerá y ejecutará desde la última posición registrada cuando detecte nuevamente la conexión. Claro está que si se da esta asincronía, el esclavo no este siempre actualizado, sino sólo después de leer la ultima posición del master. Si la conexión es permanente, los datos serán los mismos ya que la replicación es inmediata.

replicacion mysql

Podemos realizar tantas conexiones slave-master como sean necesario siempre y cuando un mismo slave no tenga 2 masters, esto generaría inconsistencias. Incluso es posible, aunque no recomendado si no se esta completamente seguro, que dos servidores sean slave-master entre ellos y viceversa siempre y cuando se filtren los datos a replicar, es decir, que lo que se replique desde el master al slave, no regrese. Si esto ocurriese, tendríamos una recursividad sin final pasando datos a diestra y siniestra.

Hablando desde mi experiencia, creo que la replicación es una forma muy fácil, rápida y económica de incrementar la escalabilidad de un sistema ya que si bien no funciona como cluster, podemos balancear la carga entre los n servidores que disponemos. Hay que aclarar que el número mínimo de servidores para un cluster es de 4 y que el cambio es significativamente grande ya que utiliza otro tipo de estructura MySql.
En los próximos posts, hablare de cómo configurar diferentes sistemas replicados con casos prácticos.

Disculpen si el artículo no salió claro y preciso, necesito retomar la práctica de redactar este tipo de post que suelen aportar algo a la comunidad.

nov 07 09

Radiohead responde sobre las estadísticas de In Rainbows

Tiempo estimado de lectura: 0,48 minutos

Al final, y como era sospechado, las estadísticas que hace un tiempo se publicaron en todos lados acerca de la venta online del trabajo In Rainbows de Radiohead eran totalmente imprecisas ya que se basaron en algunas pocas personas (y no en la mayoría).

Esta es la respuesta de la banda:

“In response to purely speculative figures announced in the press regarding the number of downloads and the price paid for the album, the group’s representatives would like to remind people that… it is impossible for outside organisations to have accurate figures on sales.

However, they can confirm that the figures quoted by the company comScore Inc are wholly inaccurate and in no way reflect definitive market intelligence or, indeed, the true success of the project.”

Visto en mathewingram.com

A partir de que la web forma parte de las fuentes de los medios de comunicación masivos, la información publicada corre un alto riesgo de ser falsa, imprecisa y tendenciosa.

Desde este humilde espacio, les pido a los medios de comunicación que verifiquen sus fuentes o, en todo caso, si existen dudas de la veracidad redáctenla como tal o van a quedar como perfectos idiotas!

nov 07 08

Prohibido demostrar afecto en público

Tiempo estimado de lectura: 0,32 minutos

Los que tuvieron la oportunidad de leer a George Orwell en su gran libro 1984, se acordarán que escribía acerca de un estado le prohibía a sus ciudadanos tener sentimientos basándose en la premisa que la debilidad y la decadencia del hombre es el sentimiento.

Parece un tanto ridículo pensar que algo así pueda ser puesto en práctica en nuestros días de libertades y virtudes. Si, es ridículo, pero pasa.

Una chica de 13 años fue detenida, en Illinois, porque abrazó a un par de amigos; esto viola la ley escolar que prohibe demostrar afecto en público (WTF?) (MSNBC). Hace unos días atrás comentaba que estaba prohibido alimentar a la gente sin hogar, ¿Qué le pasa a esta gente? No lo entiendo.

¿Algunos de ustedes lo entiende?

nov 07 06

Radiohead In Rainbows – Críticas a su revolución musical

Tiempo estimado de lectura: 0,46 minutos

Creo que la pregunta del millón fue “¿Les será rentable publicar su trabajo en internet?” Y la mayoría de las respuestas eran “Ojalá que sí, es una gran, gran, idea”. Ahora leo en Clarín que aparentemente no fue tan buena idea y lo que se suponía un éxito no lo fue. Pero creo que Clarín se olvidó de analizar algunos detalles:

  1. Difusión: Un millón de descargas en un mes… WOW! (¿Cuándo RadioHead podría haber logrado un millón de copias tan sólo el primer mes?).
  2. 38% de los usuarios pagaron: Esto es más de 380.000 “ventas” en un mes no es poco, y menos teniendo en cuenta que algunos fans pagaron MUCHO dinero por la descarga
  3. Todo el dinero va para ellos: No hay gastos de distribución (salvo hosting y ancho de banda)
  4. Merchandise extra
  5. Marketing viral “gratuito”: Todo el mundo habla de Radiohead

Y esto es el principio… No, creo que tan mal no le fue. Tambien creo que Clarín no debiera basarse sólo en los números.

Fabio opinó del tema haciendo un análisis mucho más detallado.