Vamos a ver que es una caché con un ejemplo muy ilustrativo que leí hace algún tiempo. Supongamos que estamos trabajando en una centralita que facilita números de teléfono de un pueblo relativamente pequeño; para ello, tenemos un listín telefónico común con todos los teléfonos del pais.

Cada vez que recibimos una llamada, cogemos el listín, realizamos la búsqueda y facilitamos el número encontrado al usuario. Al poco tiempo, nos damos cuenta que la gente suele pedir los teléfonos de los mismos restaurantes y comercios una y otra vez, así que cogemos una libreta pequeña y vamos anotando los números de teléfono que nos solicitan ordenados alfabéticamente para poder acceder a ellos de manera más rápida la próxima vez… felicidades, acabas de crear una caché!

Sin embargo, el uso de una caché tiene un pequeño handicap; imaginemos que nos llama un usuario y nos solicita el teléfono de un comercio. Cogeremos nuestra libreta, lo buscaremos y si no lo encontramos recurriremos al listín, realizaremos la búsqueda en él y facilitaremos el número al usuario. En este momento estamos aumentando ligeramente el tiempo de búsqueda de un número, por ese motivo, la información debe almacenarse en la caché de manera eficiente, y a partir de aquí hay mil teorías sobre como y cuando almacenar la información en una caché.

En resumen y dicho de una manera más técnica un sistema de caché es una zona de memoria en la que se almacenan copias de un objeto original pero al que es mucho más rápido acceder.

La Caché en la programación:

A la hora de construir una aplicación medianamente grande, se hace imprescindible el cachear cierta información para conseguir un rendimiento óptimo. Un sistema de caché correctamente implementado puede reducir el número de servidores y evitar la sobrecarga de las máquinas.

Se pueden utilizar diferentes tipos de caché en función del tipo de datos que queramos guardar. Centrándome en la programación web, podemos encontrar:

• Caché SQL: Para almacenar en memoria el resultado de ciertas consultas recurrentes y poder así descargar la base de datos. MySQL 5.0 Server tiene soporte nativo para este tipo de caché pero se debe activar expresamente.
• Cachéo de Objetos: En este tipo de caché podemos almacenar objetos, arrays, textos, resultados de funciones, resultados de base de datos… Podremos almacenar cualquier tipo de información soportada por el sistema de cacheo e indicarle el tiempo de expiración. Ejemplos de este sistema de caché para PHP son APC (Alternative PHP Cache) o Memcached.
• Cacheo de templates: Puede ser de gran utilidad el cachear los resultados HTML al invocar diferentes URL, por ejemplo, el sistema de templates Smarty integra un sistema de caché que permite devolver el HTML de manera eficiente.

Por qué no debo usar SQLCaché y APC o Memcached?

La caché implementada por MySQL tiene una política en la gestión de su caché muy estricta. Cada vez que hay una escritura en una tabla, elimina toda la caché asociada a dicha tabla y a partir de ese momento, se debe volver a regenerar, por tanto, la entrada de un registro en la tabla implica insertar el registro, regenerar los indices, cachear los datos y por último devolverlos (aumentamos el tiempo de la consulta). Dada esta premisa, podemos extraer la conclusión de que es interesante activar SQLCaché en una base de datos con muchas lecturas y pocas escrituras.

A su vez, implementando un sistema de cacheo como APC o Memcached para almacenar la información devuelta por la base de datos dada una consulta, reduce considerablemente el número de lecturas a base de datos.

Por ese motivo, el tener activados estos dos tipos de caché simultaneamente, no solo no mejora el rendimiento de nuestra aplicación sino que lo empeora.

Es contraproducente usar APC y Memcached de manera simultanea?

APC proporciona dos tipos de cacheo. Por un lado, evita el continuo compilado de un script PHP, pues a pesar de ser un lenguaje interpretado, PHP pasa todo script a un lenguaje entendible por la máquina antes de ejecutarlo ¿por qué recompilar cada vez el script si no ha cambiado desde la última ejecución? A partir de la versión 6 de PHP parece ser que APC estará activado de forma nativa. Por otra parte, podemos almacenar objetos con el uso de las funciones apc_add y apc_store.

Memcached proporciona un servicio web desacoplado y altamente escalable. El 95% del top ten y el 80% del top 50 de Alexa utiliza Memcached precisamente por la facilidad de implementación y de añadir nuevas máquinas para cachear información. APC tiene un rendimiento ligeramente superior, pero si tenemos un sistema con servidores balanceados no podemos compartir la caché entre todas las máquinas porque está vinculada al host, por ese motivo la balanza se ha ido decantando hacia el uso de Memcached.

Si bien, puede ser interesante utilizar una combinación de ambas, APC para el precompilado de nuestro código y Memcached para almacenar la información de base de datos y descargar así nuestro motor de bd.

Un compañero de trabajo que es un crack en temas de optimización de bases de datos me ha pasado la siguiente información. Cuando hacemos una consulta con un LIMIT x, y sobre una tabla con millones de registros, a medida que x aumenta, la consulta se va haciendo cada vez más lenta. Veamos un ejemplo:

SELECT version FROM car LIMIT 300,100; (100 results, 0.01 sec)

SELECT version FROM car LIMIT 3000000,100; (100 results, 2.5 sec)

Si además agregamos un par de JOINS a esta consulta, la complicamos un poco y le añadimos un ORDER BY, los problemas de rendimiento pueden llegar a causar un colapso en la base de datos.

¿Por qué pasa esto?

Para determinar el primer valor que tiene que seleccionar, MySQL debe recorrer desde el primer registro e ir contando hasta llegar al 300, a partir de ahí, cogerá 100. Obviamente, a medida que el valor de X va aumentando, la búsqueda del primer elemento es más lenta y como podemos ver en el ejemplo de arriba, llega a tardar 2,5 segundos en recorrer 3.000.000 de registros.

¿Cómo lo podemos solucionar?

Mi compañero propone hacer la búsqueda acotando a partir de primary key de la tabla, de este modo, al ser un campo indexado la búsqueda es realmente eficiente y nos evitamos cargar la máquina:

SELECT version FROM car WHERE id_car BETWEEN 3000000 AND 3000100; (~100 results, 0.01 sec)

Esta solución no nos sería válida a la hora de construir un paginador, porque en el caso de tener vehículos desactivados u eliminados, unas páginas contendrían 100 vehículos, otras quizá 74… sin embargo, si por ejemplo construimos un script que se recorra toda la tabla car esta es una buena manera de realizar la búsqueda.

Symfony integra Propel ORM por defecto, sin embargo, Doctrine está ganando puntos sobre su rival.

La principal ventaja de cada uno de ellos es:

Propel: Está completamente integrado con Symfony y decenas de plugins sólo funcionan para Propel.

Doctrine: Tiene muy buen rendimiento en ejecución y una forma muy concisa al escribir consultas complejas.

Si te has decidido a utilizar Doctrine en lugar de Propel y no sabes como integrarlo con Symfony, aquí te dejo los pasos para activarlo.

1. Lo primero que deberemos hacer es habilitar sfDoctrinePlugin y deshabilitar sfPropelPlugin, esto lo haremos editando el archivo config/ProjectConfiguration.class.php :

   public function setup()
   {
     $this->enablePlugins(array('sfDoctrinePlugin'));
     $this->disablePlugins(array('sfPropelPlugin'));
   }
   

   o si lo prefieres, puedes habilitar todos los plugins por defecto excepto los que no te interesen:

   public function setup()
   {
     $this->enableAllPluginsExcept(array('sfPropelPlugin'));
   }
   

2. Activado Doctrine, borraremos la caché para asegurarnos que se cargan nuestros cambios:
   symfony cc
3. Crearemos una carpeta doctrine dentro de config que contendrá nuestro archivo schema.yml y listo, ya tenemos a Symfony funcionando con Doctrine
4. Ahora sólo queda abrir el archivo config/databases.yml y cambiar “propel” por “doctrine” (respetando mayúsculas y minúsculas) y eliminar la linea “classname:  PropelPDO“.

Recordemos que a partir de ahora, deberemos utilizar la sintaxis Doctrine, tanto en nuestra definición del schema como en el modelo de nuestra aplicación. Si son tus primeros pasos con Doctrine, puedes ver su documentación original aquí.

Qué es un ORM?

Un ORM o (Object Relation Mapper) es una técnica de programación que nos permite convertir datos entre el sistema de tipos utilizado en un lenguaje de programación orientado a objetos y el utilizado en una base de datos relacional, es decir, las tablas de nuestra base de datos pasan a ser clases y los registros objetos que podemos manejar con facilidad.

Utilizar un ORM tiene una serie de ventajas que nos facilitan enormemente tareas comúnes y de mantenimiento:

1. Reutilización: La principal ventaja que aporta un ORM es la reutilización permitiendo llamar a los métodos de un objeto de datos desde distintas partes de la aplicación e incluso desde diferentes aplicaciones.
2. Encapsulación: La capa ORM encapsula la lógica de los datos pudiendo hacer cambios que afectan a toda la aplicación únicamente modificando una función.
3. Portabilidad: Utilizar una capa de abstracción nos permite cambiar en mitad de un proyecto de una base de datos MySQL a una Oracle sin ningún tipo de complicación. Esto es debido a que no utilizamos una sintaxis MySQL, Oracle o SQLite para acceder a nuestro modelo, sino una sintaxis propia del ORM utilizado que es capaz de traducir a diferentes tipos de bases de datos.
4. Seguridad: Los ORM suelen implementar mecanísmos de seguridad que protegen nuestra aplicación de los ataques más comúnes como SQL Injections.
5. Mantenimiento del código: Gracias a la correcta ordenación de la capa de datos, modificar y mantener nuestro código es una tarea sencilla.

Qué es Doctrine?

Según la documentación oficial, Doctrine es un ORM para PHP 5.2.3 y posterior. Además de todas las ventajas que conlleva un ORM, uno de sus puntos fuertes es su lenguaje DQL (Doctrine Query Language) inspirado en el HQL de Hibernate.

Cuando trabajamos con Doctrine, necesitamos informar a su motor interno de cual es el modelo de nuestra aplicación, para ello podemos hacer ingeniería inversa de nuestra base de datos existente, o si empezamos la aplicación desde 0, crear el modelo en la sintaxis específica que nos propone Doctrine y luego generar toda la base de datos.

Para crear el modelo, doctrine nos da dos alternativas, hacer una clase por tabla e indicarle mediante PHP el tipo de datos que almacenaremos en él, un ejemplo:

// models/generated/BaseUser.php

class User extends BaseUser
{
    public function setTableDefinition()
    {
        $this->hasColumn('username', 'string', 255, array('default' => 'default username'));
        $this->hasColumn('name', 'string', 255, array('default' => 'default name'));
        $this->hasColumn('age', 'integer', 4, array('unsigned' => true));
        // ...
    }

    // ...
}

O crear un esquema en formato YAML (schema.yml) similar a XML, pero bastante más legible. El equivalente al ejemplo anterior en YAML sería:

# schema.yml

# ...
User:
# ...
  columns:
    username:
      type: string(255)
      default: default username
    name:
      type: string(255)
      default: default name
    age:
      type: integer(4)
      unsigned: true
    # ...

Además de definir los campos de cada tabla, también le indicamos las relaciones que tienen con las otras tablas y su tipo (many-to-many, one-to-many, one-to-one…), lo que deja perfectamente estructurada nuestro modelo de datos y su manera de acceder a los valores.

Más adelante seguiré escribiendo sobre las ventajas de Doctrine y añadiendo ejemplos que considere interesantes y/o útiles.

DBDesigner4 es una aplicación gratuita que integra diseño de bases de datos, modelado, creación y mantenimiento en un entorno único.

Instalar DBDesigner4 en Ubuntu y hacer que funcione es relativamente fácil, el problema viene cuando quieres hacer conexiones con la base de datos para hacer, por ejemplo, ingeniería inversa y obtener el modelo gráfico de las tablas.

Para que esto no nos suceda, aquí os dejo los pasos a seguir para que os funcione en vuestra Ubuntu a la primera.

1. Descargarnos las librerias que vamos a necesitar y el programa:

   cd /opt

   wget http://www.silcom.com.pe/soft/xlibs_6.8.2-77_all.deb

   wget http://www.silcom.com.pe/soft/kylixlibs3-borqt_3.0-1_i386.deb

   wget http://downloads.mysql.com/DBDesigner4/DBDesigner4.0.5.4.tar.gz

   wget http://crlab.com/dbx/dbxmda.tar.gz

2. Instalamos...

   sudo apt-get install xkeyboard-config

   sudo dpkg -i xlibs_6.8.2-77_all.deb

   sudo dpkg -i kylixlibs3-borqt_3.0-1_i386.deb

   sudo tar xvfz DBDesigner4.0.5.4.tar.gz

   sudo tar xvfz dbxmda.tar.gz

   sudo mv DbxMda/libsqlmda.so.3.20 /usr/lib/

   sudo ldconfig

3. Hacemos unos cuantos enlaces simbólicos:

   sudo ln -s /usr/lib/kylix3/libborqt-6.9-qt2.3.so /usr/lib/libborqt-6.9-qt2.3.so

   sudo ldconfig

   sudo ln -s /usr/lib/kylix3/libborqt-6.9.0-qt2.3.so /lib/libborqt-6.9-qt2.3.so

4. Por último, sólo nos queda iniciar el programa

   /opt/DBDesigner4/DBDesigner4 &

Si todo ha ido bien, el programa iniciará normalmente mostrándonos el entorno de modelado de base de datos. El siguiente paso será configurar la conexión a base de datos:

1. Click en el menú superior en “Database > Connect to Database” y nos aparecerá una ventana como la que siguie:
2. Click en el botón “New Database Connect” y rellenamos la información:
   • Connection Name: Nombre para la conexión
   • Driver: En nuestro caso, será MySQL pero se pueden elegir varios (Oracle, SQLLite…)
   • Hostname: Donde está localizada la base de datos (generalmente localhost)
   • Database Name: Nombre de la base de datos a la que queremos conectar
   • Username: Nombre de usuario para conectar a dicha base de datos
   • Password: Password de acceso
3. Click en la pestaña “Advanced” y rellenamos los valores como muestra la imágen excepto los campos User Name y Database que deberán contener los de tu conexión:

Ahora ya estás en disposición de conectar el programa con tu base de datos y hacer ingeniería inversa de tus tablas existentes.

Explain es una potente herramienta que MySQL pone a nuestra disposición para orientarnos sobre como está ejecutando una consulta el motor de la base de datos.

Esto nos es de mucha utilidad cuando creamos una consulta nueva, pues nos indica que índices va a utilizar, de que tipo son, como de efectiva será la respuesta al usar esos índices… por lo tanto, podemos detectar rápidamente, por ejemplo, de que nuestra consulta no está bien formada o que nos falta un índice en algún campo concreto.

Si ejecutamos la siguiente consulta:

EXPLAIN SELECT *
FROM user u
INNER JOIN user_profile up ON u.id = up.user_id

Obtendremos una respuesta como esta:

Pero, ¿qué quieren decir estas columnas? ¿qué información nos dan?

1. Table: Nos informa de la tabla a la que nos estamos refiriendo.
2. Type: El tipo de unión que se está usando. Desde la mejor hasta la peor, los tipos de uniones son system, const, eq_ref, ref, range, index, y ALL.
   • System: Tabla con una única fila, por tanto, la respuesta es inmediata.
   • Const: En la tabla coincide una única fila con los criterios indicados. Al sólo haber una fila, el optimizador toma este valor como constante, por este motivo este tipo de tablas son muy rápidas.
   • Eq_ref: Una fila de la tabla 1 será leída por cada combinación de filas de la tabla 2. Este tipo es usado cuando todas las partes de un índice se usan en la consulta y el índice es UNIQUE o PRIMARY KEY.
   • Ref: Todas las filas con valores en el índice que coincidan serán leídos desde esta tabla por cada combinación de filas de las tablas previas. Similar a eq_ref, pero usado cuando usa sólo un prefijo más a la izquierda de la clave o si la clave no es UNIQUE o PRIMARY KEY. Si la clave que es usada coincide sólo con pocas filas, esta union es buena.
   • Range: Sólo serán recuperadas las filas que estén en un rango dado, usando un índice para seleccionar las filas. La columna key indica cual índice es usado, y el valor key_len contiene la parte más grande de la clave que fue usada. La columna ref será NULL para este tipo.
   • Index: Escaneo completo de la tabla para cada combinación de filas de las tablas previas, revisando únicamente el índice.
   • ALL: Escaneo completo de la tabla para cada combinación de filas. Es el peor caso ya que revisará todas las filas para cada combinación.
3. Possible_keys: Posibles indices que utilizará la consulta.
4. Key: Índice utilizado para ejecutar la consulta. Si indica el valor NULL, no se ha escogido ningún índice.
5. Key_len: Cuanto más pequeño sea este valor, más rápida será la consulta, pues nos indica la longitud del índice usado.
6. Ref: Las columnas del índice que se está usando, o una constante si esta es posible.
7. Rows: Número de filas que MySQL debe analizar para devolver los datos solicitados.
8. Extra: Información complementaria sobre como MySQL ejecutará la consulta. Los posibles valores en este campo pueden ser:
   • Distinct: MySQL ha encontrado una fila coincidente con los filtros indicados y no necesita seguir analizando.
   • Not exists: MySQL fue capaz de hacer una optimización LEFT JOIN sobre la consulta y no examinará más filas en la tabla para la combinación de filas previa después de que encuentre una fila que coincida con el criterio LEFT JOIN.
   • Range checked for each record: No se encontró un índice válido. Para cada combinación de filas se hará un chequeo para determinar que indice utilizar y en caso de encontrar alguno válido, lo utilizará.
   • Using filesort: Este valor indica que MySQL necesita hacer un paso extra para encontrar la forma de ordenar las filas. Este tipo de consultas debe ser optimizada.
   • Using index: Recupera la información solicitada utilizando únicamente la información del índice. Esto sucede cuando todas las columnas requeridas forman parte del índice.
   • Using temporary: Para resolver esta consulta, MySQL creará una tabla temporal. Uno de los casos típicos en los que devuelve este valor es cuando usamos un ORDER BY sobre un conjunto de columnas diferentes a las indicadas en la clausula GROUP BY. Este tipo de consultas debe ser optimizada.
   • Where used: Se usará una clausula WHERE para determinar que filas serán comparadas con otra tabla. Si no deseamos regresar todas las filas desde la tabla, y el join es del tipo ALL o index, es muy probable que hayamos escrito algo mal en la consulta.

   Una respuesta en este campo del tipo “Using filesort” o “Using temporary” es susceptible de ser una consulta a optimizar.

Si analizamos la consulta ejecutada anteriormente,vemos que para la tabla con alias ‘up’ está utilizando el tipo de unión `ALL` debido a que no existe ningun filtro en la clausula WHERE (en este caso, es normal ya que queremos devolver todos los valores). Se podría utilizar el índice existente `user_id_idx` pero al no haber ningún filtro, no es necesario usarlo. Para devolver esta consulta MySQL analizará 13 filas.

La segunda fila hace referencia a la tabla con alias ‘u’. Utiliza un tipo de unión `eq_ref` ya que devolverá una fila para cada fila de la tabla `up` pudiendo usar y usando el índice primario de la tabla que tiene una longitud de 4 (muy pequeño). Se está utilizando la columna `user_id` del índice de la tabla `up` y de la base de datos `futbol` analizando una única fila para cada fila de la tabla contigua.

Todos los valores son correctos y podemos asegurar que esta consulta está optimizada!!

Supongamos un escenario real de producción en el que tenemos dos servidores. Una de las máquinas contiene un servidor http y una base de datos MySQL que usamos para abserver el tráfico web; la otra la utilizamos para otras tareas necesarias. Sería magnífico poder utilizar la segunda máquina como backup de nuestro MySQL por si hay algún problema grave en la primera ¿no? En este artículo os explico como hacerlo.

La replicación en MySQL funciona de la siguiente manera, el servidor maestro escribe todas las actualizaciones en un fichero de log binario, y mantiene un índice de los ficheros para rastrear las rotaciones de logs. A su vez, el servidor esclavo, que mantiene una conexión abierta contínua con el maestro, es informado cuando sucede algún cambio en el log binario del maestro, y ejecutan estos cambios en sus tablas.

Configuración de la replica asíncrona unidireccional

1) Localizaremos el fichero de configuración de MySQL de la máquina que hará de maestro. Generalmente lo podemos encontrar en la ruta /etc/mysql/my.cnf y descomentamos las líneas:

log_bin=/var/log/mysql/mysql-bin.log
server-id = 1

Buscamos la misma línea en el servidor que hará las veces de esclavo y descomentamos la línea log_bin y server-id modificando el valor a uno diferente del de master:

log_bin=/var/log/mysql/mysql-bin.log
server-id = 2

Ahora podemos arrancar los dos servidores MySQL para empezar a enseñarles a replicar.

2) Una vez arrancados ambos servidores, nos ponemos en el que hará de master y creamos la base de datos y el volcado de los datos en las tablas. En mi caso haré una importación de un fichero sql:

mysql -u [DBUSER-MASTER] -p -e "CREATE DATABASE `myBaseDeDatos`"
mysql -u [DBUSER-MASTER] -p myBaseDeDatos < myBaseDeDatos.sql

3) Ahora crearemos una cuenta de usuario con permisos de replicación, para autorizar, en el servidor maestro, al nuevo usuario a realizar replicas:

mysql> GRANT REPLICATION SLAVE ON *.* TO '[DBUSER-REPLICATOR]'@'[IP-SERVER-SLAVE]' IDENTIFIED BY '[DBPASS-REPLICATOR]';
mysql> flush privileges;
mysql> exit


4) Finalmente, consultamos el nombre del archivo de log binario y la posición de compensación, datos necesarios para configurar el esclavo:

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000    | 103      |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

5) Una vez hecho esto, volcaremos la base de datos en el servidor esclavo tal y como hicimos con el maestro. Ejecutaré el mismo archivo sql:

mysql -u [DBUSER-SLAVE] -p -e "CREATE DATABASE `myBaseDeDatos`"
mysql -u [DBUSER-SLAVE] -p myBaseDeDatos < myBaseDeDatos.sql

6) Y una vez que el esclavo tenga generada la base de datos, lo configuramos para que esté posicionado con respecto al maestro:

mysql> CHANGE MASTER TO MASTER_HOST = '[IP-SERVER-MASTER]';
mysql> CHANGE MASTER TO MASTER_USER = '[DBUSER-REPLICATOR]';
mysql> CHANGE MASTER TO MASTER_PASSWORD = '[DBPASS-REPLICATOR]';
mysql> CHANGE MASTER TO MASTER_LOG_FILE = 'mysql-bin.0001';
mysql> CHANGE MASTER TO MASTER_LOG_POS = 103;
mysql> start slave;

Y con esto ya queda configurado el servidor esclavo y alineado con el master. Desde este momento comenzará la replicación con el maestro.

Para comprobar que realmente está replicando, podemos ejecutar el siguiente comando en el servidor esclavo:

mysql> show slave status

Eso muestra:

*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: [IP-SERVER-MASTER]
Master_User: [DBUSER-REPLICATOR]
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.0001
Read_Master_Log_Pos: 103
Relay_Log_File: esclavo-relay-bin.000001
Relay_Log_Pos: 103
Relay_Master_Log_File: mysql-bin.0001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: myBaseDeDatos
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: 103
Relay_Log_Space: 103
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)

En Read_Master_Log_Pos y Relay_Log_Pos podemos ver que ambos valores están correctamente alineados. La variable Seconds_Behind_Master nos indica el desfase de actualización entre maestro y esclavo, si todo está bien, mostrará un valor 0.

Para los que no esteis al caso, según su propia web, Monit es una utilidad gratuita de código abierto para la gestión y vigilancia de procesos, archivos, directorios y sistemas de ficheros en un sistema UNIX.

Configurado correctamente, Monit es capaz de realizar el mantenimiento y la reparación de los servicios, procesos… incluso ejecutar acciones programadas para situaciones de error.

Por poner un ejemplo, un uso común que se le suele dar es que vaya controlando si apache está funcionando correctamente, en caso de estar caido o saturado, Monit lo levantará automáticamente y nos enviará un mail informando del problema solventado.

Instalación de Monit

1) Descargamos la última versión estable de Monit (en mi caso la 5.0.1) de la página oficial, como lo instalaré en una debian, voy a la distribución en concreto, y me descargo el paquete deb para la arquitectura de mi máquina i386:

wget http://ftp.uk.debian.org/debian/pool/main/m/monit/monit_4.10.1-4_i386.deb

2) Y lo instalamos con el comando dpkg:

sudo dpkg -i monit_4.10.1-4_i386.deb

Si todo ha ido bien, obtendremos un resultado como este:

Selecting previously deselected package monit.
(Reading database ... 195390 files and directories currently installed.)
Unpacking monit (from monit_4.10.1-4_i386.deb) ...
Setting up monit (1:4.10.1-4) ...
Starting daemon monitor: monit won't be started/stopped
	unless it it's configured
	please configure monit and then edit /etc/default/monit
	and set the "startup" variable to 1 in order to allow
	monit to start

Llegados a este punto, ya tenemos instalado Monit en nuestro servidor Debian, ¿sencillo no?

Un último paso en la instalación antes de pasar a la configuración (sólo aplica si tienes apache instalado y deseas monitorizarlo con monit):

Localiza el directorio root document del servidor Apache que queramos monitorizar y dentro de él crear una carpeta llamada monit que contenga un archivo llamado token (el contenido de este archivo es irrelevante)

mkdir -p /PATH_TO_ROOT_FOLDER/monit/
touch /PATH_TO_ROOT_FOLDER/monit/token

Comprobaremos que todo ha ido bien visitando http://[IP_SERVER]/monit/token. Si no hay un error, es que apache ha podido leer correctamente el archivo /monit/token, en caso de error asegúrate de que has creado el archivo en la ubicación correcta y que apache puede leerlo.

Configuración de Alertas Monit

El fichero de configuración de Monit se encuentra en la ruta /etc/monit/monitrc, por defecto trae una serie de configuraciones definidas y comentadas que podremos utilizar para tener lista una configuración básica, con un poco de tiempo y paciencia, podeis ir añadiendo diferentes chequeos.

sudo vi /etc/monit/monitrc

Primero modificaremos la información de las alertas vía mail (recordad que debeis tener configurado en vuestro servidor un servidor de correo).

Añadimos la siguiente información en la sección Global Sectio modificando miMail@hotmail.com por el mail en el que queremos recibir las visitas y monit@myServer.com por el mail del que queremos que provenga, por ejemplo, monit@mi-dominio.com:

Configuración de control de Apache

Añadimos la siguiente información al final de la sección Services

NOTA!! Debemos modificar la ruta del fichero pid de apache a donde lo tengamos alojado. En Debian suele ser /var/run/apache2.pid y los valores que he colocado entre [] por los de nuestro servidor.

Explicado de un modo rápido, le estamos indicando que reinicie el servidor Apache si el servidor presenta uno de los siguientes sintomas:

• No responde al visitar la url http://[IP_SERVER]/monit/token
• Apache ocupa más del 80% de la CPU durante 5 ciclos de Monit
• La memoria utilizada por Apache es superior a 400MB durante 5 ciclos de Monit
• El proceso tiene más de 250 hijos

Que nos envíe un mail (siempre que tengamos configurado un servidor de correo) en caso de que:

• Haya detectado uno de los problemas mencionados anteriormente
• Apache ocupa más del 60% de la CPU durante 3 ciclos de Monit

Y parará el servidor en caso de error crítico avisandonos vía email.

Configuración de control de MySQL

Para configurar un chequeo del servidor MySQL, añadimos la siguiente información después del bloque configurado anteriormente:

NOTA!! Debemos modificar la ruta del fichero pid de mysql a donde lo tengamos alojado. En Debian suele ser /var/run/mysqld/mysqld.pid.

Configuración de control de OpenSsh

Para acabar este tutorial, configuraremos un control del servidor SSH, punto importante, pues si no podemos acceder físicamente a nuestro servidor y no podemos acceder mediante SSH porque este servicio ha caido, tenemos un pequeño problema .

Añadiremos el siguiente trozo de código acordandonos de cambiar la ruta al fichero sshd.pid a la correspondiente en nuestro servidor:

Cabe remarcar la importancia de tener monitorizaciones cruzadas desde diferentes servidores, pues si, por poner un ejemplo, se corta la conexión en nuestro servidor de producción monitorizado desde la mísma máquina, a pesar de que monit lo detectará, intentará enviar emails que no llegarán (pues no tiene conexión). Para evitar esto y tenemos la suerte de disponer de varios servidores, podemos indicar al server1 que monitorice los servicios de server2 y en caso de fallar, que nos alerte vía mail para poder actuar en consecuencia.

Pues bien, otro post provocado por una necesidad del curro… esa necesidad me ha obligado a googlear un ratito y por último, he aquí el resultado.

La cosa está en que me han pasado unos archivos en formato dbf y para poder hacer el tratamiento necesario necesitaba poderlos importar a MySQL. La solucion está en dbf2mysql, programa que de una manera bastante sencilla se encarga de hacer la importación a la base de datos MySQL.

Los flags más importantes que nos ofrece dbf2mysql són los siguientes:

• -h indica server donde conectarse
• -U usuario MySql
• -P password MySql
• -d base de datos donde se insertaran los datos
• -t tabla donde se insertarán los datos
• -c crea la tabla si no existe
• -cc crea la tabla, pero no inserta registros
• -f traduce los nombres de campo a minúsculas
• -n no se agrega ‘NOT NULL’ en las sentencias de creación de tabla
• -o exporta solo los campos listados (Ej. -o field1,field2…)
• -s substituye permite cambiar nombres de campos (Ej. -s oldName1=newName1,oldName1=newName1)
• -i lista de campos a indexar. Genera UN indice por campo (Ej. -i field1,field2…)
• -r quita espacios antes y después de datos alfanuméricos
• -v muestra detalles de la conversión
• -vv muestra más detalles
• -vvv incluye informe de progreso

Los pasos que he siguido para hacer la importacion són:

1) Instalo dbf2mysql, en mi caso desde Ubuntu:

sudo apt-get install dbf2mysql

En cualquier caso, nos podemos bajar el programa para sistemas Unix de Source Forge

2) Creo una base de datos MySQL vacia:

mysql -u [DBUSER] -p -e "CREATE DATABASE `[DBNAME]`"

3) Por último lanzamos el siguiente comando para indicarle que importe el archivo dbf a la base de datos local, en la tabla [DBTABLE] de la base de datos [DBNAME], entrando con el usuario [DBUSER] y el password [DBPASS]. Mediante el flag -c forzamos a que cree la tabla si no existe y con -f le indicamos que traduzca los nombres de los campos a minusculas:

dbf2mysql -h localhost -U [DBUSER] -P [DBPASS] -d [DBNAME] -t [DBTABLE] -c -f /path/to/file/miTabla.dbf

Es importante tener en cuenta que esta importación no tendra en cuenta algunos atributos importantes de la tabla como, por ejemplo, los campos autoincrementales. Si tenemos algun problema de este estilo, es recomendable crear la estructura de la tabla antes de realizar la importación.

Hace algún tiempo que tenía ganas de migrar una base de datos de ISO-8859-1 a UTF-8, pero cuando tienes un proyecto funcionando, hacer un cambio de este estilo es algo delicado y por lo tanto, uno intenta postergarlo. En cualquier caso, finalmente decidí liarme la manta a la cabeza y tirarlo adelante.

Por desgracia, no existe una sentencia SQL que haga algo similar de manera sencilla, sin embargo, podemos conseguirlo utilizando el comando de Linux recode (evolución bastante más inteligente del antiguo iconv), os dejo detallados los pasos que seguí para hacer el cambio:

1) Exportamos la base de datos mediante el comando mysqldump:

mysqldump -u  -p -f --single-transaction --opt -hlocalhost --all-databases | gzip -9 -c > [FICHERO_EXPORTACION_BD]

2) Recodificamos el archivo dump mediante el comando recode:

recode iso-8859-15..utf8 < [FICHERO_EXPORTACION_BD] > [FICHERO_EXPORTACION_BD].utf8

3) Editamos el archivo y reemplazamos “latin1″ por “utf8″

4) Creamos la nueva base de datos con el encoding utf8:

mysql -u [USER] -p [DBNAME] -e "CREATE DATABASE `[DBNAME]` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;"

5) Por último, importamos la base de datos de la siguiente manera:

mysql -u [USER] -p [DBNAME] < [FICHERO_EXPORTACION_BD].utf8

NOTA!! En mi caso concreto, la aplicación PHP seguía mostrando errores al visualizar la información que provenía de base de datos a pesar de haber cambiado convenientemente los metas del html resultante. En mi caso era debido a que la conexión a la base de datos estaba forzada a leer en ISO. Esto lo solventé añadiendo justo después de la conexión:

@mysql_query("SET character_set_results='utf8'");

o si nuestra version de PHP es superior o igual a la 5.2.3, tambien podemos hacer:

@mysql_set_charset("utf8", $link_identifier);