Rubén Ortiz » Software

Zabbix – reducir tamaño base de datos

Rubén Ortiz — Mon, 16 Jan 2012 08:09:38 +0000

A continuación un comentario breve sobre la base de datos de Zabbix y su peso, comentar que el tema es la tabla history pero con estos tips podemos aligerar el tema. No lo toméis al pie de la letra.

1
2
3
4
5
6
7
8

-bash-3.2# du -hs *
105M ibdata1
65M ib_logfile0
65M ib_logfile1
768K mysql
0 mysql.sock
4.0K test
46G zabbix

Paramos el servidor de Zabbix

1	# /etc/init.d/zabbix_server stop

Optimizamos los datos con mysqlcheck (hay que tener innodb-file-per-table en la configuración)

1	# mysqlcheck -uuser -ppassword -o --all-databases

Después de la optimización de espacio realizada con el optimize vemos la reducción importante de espacio de la bbdd.

1
2
3
4
5
6
7
8

-bash-3.2# du -hs *
105M ibdata1
65M ib_logfile0
65M ib_logfile1
768K mysql
0 mysql.sock
4.0K test
37G zabbix

Entonces, realizamos un dump con mysqldump de la misma base de datos, pues vamos a mover la base de datos a una instancia MySQL donde se ejecutará aislada. Volcamos el dump y comprobamos el tamaño final después del proceso:

1
2
3
4
5
6
7
8

-bash-3.2# du -hs *
1.6G ibdata1
5.1M ib_logfile0
5.1M ib_logfile1
900K mysql
0 mysql.sock
1016K test
19G zabbix

Resumen del proceso:

1. Paramos Zabbix Server
2. Optimización
3. Dump
4. Volcado
5. 69% menos de peso en la base de datos

Varnish & WordPress – Ips y comentarios

Rubén Ortiz — Tue, 10 Jan 2012 11:50:40 +0000

Hace unos meses publiqué un tip sobre WP & Varnish, por un tema concreto, el registro correcto de ips en nuestro sistema instalando un módulo, el Rpaf. Es un módulo útil cuando tenemos algún tipo de proxy, o caché, como en este caso varnish.

Hace poco he tenido un “problema” con un cliente. Al hacer el split de su backend y frontend, akismet plugin comenzó a filtrar todos los comentarios como spam. Yo no me acordaba de este detalle, el de las variables:

REMOTE_ADDR
X_FORWARDER_FOR

Para arreglar esto hemos de seguir una serie de pasos explicados aquí Y adicionalmente, para el tema de los comentarios de WP, hemos de editar (y si alguien sabe otra manera que la diga ) los archivos:

wp-includes/comment.php
wp-content/plugins/akismet/akismet.php

tendremos que editar estos dos archivos buscando la variable

REMOTE_ADDR

y editando por

HTTP_X_FORWARDED_FOR

Faltará reiniciar Varnish y ya lo tenemos.

Links
http://mclear.co.uk/2010/12/03/wordpress-and-varnish-comment-ips/

Prestashop – habilitar modo debug

Rubén Ortiz — Thu, 05 Jan 2012 10:43:59 +0000

Útil para cuando queremos investigar errores en Prestashop. En config/config.inc.php modificar estas lineas

1 2	@ini_set('display_errors', 'off'); define('_PS_DEBUG_SQL_', false);

por estas otras

1 2	@ini_set('display_errors', 'on'); define('_PS_DEBUG_SQL_', true);

Percona Server cotejamiento

Rubén Ortiz — Fri, 11 Nov 2011 11:55:32 +0000

Estos días trabajamos en Rsystem (ITnet Consulting) el lanzamiento de un proyecto (start-up). El proyecto requería una base de datos MySQL. De inicio montamos Percona Server e hicimos la importación de la base de datos suya de su entorno viejo al nuestro actual. Y es ahí donde nos avisaron del problema. Por defecto, el cotejamiento de Percona Servers es latin. Vamos a cambiarlo a utf para que los carácteres especiales se guarden bien.

Comprobamos que valores tenemos antes de todo

1
2
3
4
5

Como podemos ver, latin1 es el _set_server. Vamos a editar my.cnf.

1
2
3

# vim /etc/my.cnf
character_set_server = utf8
collation_server = utf8_general_ci

Sólo queda entonces rebotar el servicio y volver a comprobar

1
2
3
4
5
6
7
8
9

CACTI – monitorizar memcached

Rubén Ortiz — Wed, 17 Aug 2011 13:28:41 +0000

Documento fácil y rápido para monitorizar Memcached a través de Cacti.

1
2
3
4

# yum install python-setuptools
# wget ftp://ftp.tummy.com/pub/python-memcached/python-memcached-latest.tar.gz
# tar xzf python-memcached-<ver>.tar.gz
# python setup.py install

1
2
3
4

# wget http://s1.dlnws.com/dealnews/developers/cacti-memcached-1.0.tar.gz
# tar xf cacti-memcached-1.0.tar.gz
# cd cacti-memcached-1.0
# cp memcached.py /path/to/cacti/scripts/.

Comprobamos que funciona

1	# python /scripts/memcached.py

ahora, abrimos Cacti y vamos a Import Templates e importamos el xml. En este punto, sólo quedará añadir los gráficos a los dispositivos ya creados o bien, añadir dispositivos de 0 con este template.

Resultado:

Links
http://dealnews.com/developers/cacti/memcached.html

MySQL replicación Master a Slave

Rubén Ortiz — Fri, 08 Jul 2011 08:42:04 +0000

Uno de los motivos de implementar replicación de MySQL Master-Slave, puede ser por ejemplo el disponer de una instancia de MySQL Server de nuestra base de datos, que sólo sirva para el acceso a lecturas (SELECT) para diversos fines (estadísticas, backups, repartir lecturas y liberar de carga al MASTER). Vamos a ver como implementarlo en MySQL 5.0.

Metas y Límites de la replicación

Distribución de datos
Balanceo de carga
Backup
HA y failover
Testear upgrades de MySQL

Una instancia de MySQL SLAVE puede tener sólo un MySQL MASTER
Cada SLAVE debe tener un único ID server
Un MASTER puede manejar varios SLAVES
Un SLAVE puede propagar cambios desde su MASTER y ser a su vez el MASTER de otros SLAVES si habilitas log_slave_updates

Pasos (BREVE)

Configurar cuentas de replicación en ambos servidores
Configurar master y esclavo (editar my.cnf)
Configurar esclavo para conectar y replicar desde el master

Escenario

MASTER = 10.0.0.1, server id 100

SLAVE = 10.0.0.2, server id 101

Asumimos que partimos de un MASTER en servicio, es decir, el SLAVE y MASTER no parten ambos desde cero

1. Setup en MASTER

1.1 Creamos una cuenta de replicación con permisos en la BD master

1
2
3

# mysql -uroot -p
# mysql>; use mysql;
# mysql>; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@’10.0.0.1%’ IDENTIFIED BY ‘replpassword’;

1.2. Habilitar binary login and server ID (editar my.cnf)

1
2
3
4
5
6

# vim /etc/my.cnf

# Replication Master Server (default)
# binary logging is required for replication
log-bin=mysql-bin
server_id=100

1.3. Reiniciar MYSQL

1	service mysqld restart

1.4. Comprobar estado Master

1
2
3
4
5
6
7

Si obtenemos algo como esto es que el archivo de log binario se ha creado correctamente.

2. Setup SLAVE

2.1 Creamos una cuenta de replicación con permisos en la BD master

1
2
3

# mysql -uroot -p
# mysql> use mysql;
# mysql>; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@’10.0.0.2%’ IDENTIFIED BY ‘replpassword’;

*** NOTA: realmente, el usuario de replicación sólo necesita privilegios REPLICATION SLAVE en el MASTER y no necesita REPLICATION CLIENT, pero para este tutorial, seguiremos estos pasos

2.2. Editamos my.cnf

1
2
3
4
5
6
7

# vim /etc/my.cnf

log-bin=mysql-bin
server_id=101
relay_log=mysql-relay-bin
log_slave_updates=1
read_only=1

relay_log: precisa la ruta y nombre del fichero de log relay

read _only: evita las writes en el esclavo

log_slave_updates: guarda los eventos del esclavo en un log

2.3 Reiniciamos esclavo

1	service mysqld restart

3. Iniciar replicación

Necesitamos tres cosas para sincronizar un SLAVE con su MASTER:

Un snapshot de los datos del maestro en algún punto concreto de tiempo
El archivo de log actual del master y el byte offset con el log en el punto de tiempo exacto en el que tomaste el snapshot. Nos referiremos a estos dos valores como coordenadas del archivo log porque juntas identifican la posición del archivo de log binario. Puedes encontrar las coordenadas del archivo log del master con el comando SHOW MASTER STATUS.
Los archivos logs binarios del master desde ese momento hasta el presente.

Hay muchas formas de aplicar la copia de los datos: cold copy, warm copy, mysqldump, lvm snapshot, etc. En este tutorial cubriremos esta:

Coldcopy: parar el master, hacer un trasvase de los archivos físicos del master hacia el slave. Levantar el MASTER otra vez, lo que comenzará un nuevo archivo de log binario y utilizar CHANGE MASTER TO para iniciar el SLAVE al principio del archivo de log binario.

Esta forma tiene un inconveniente MUY CLARO, hay que parar el MASTER en algún momento. Siguiendo la info de http://dev.mysql.com/doc/refman/5.1/en/replication-howto-masterstatus.html tenemos explicado lo mismo de otra forma, vamos a seguir estos pasos:

3.1 Parada de servicio en MASTER y copia de datos
Inicia el cliente de MySQL y haz flush de todas las tablas bloqueando los writes ejecutando. No abandonar la consola de MySQL:

1	mysql>FLUSH TABLES WITH READ LOCK;

Las tablas INNODB también bloquean las operaciones de COMMIT.

Warning: Leave the client from which you issued the FLUSH TABLES statement
running so that the read lock remains in effect. If you exit the client, the lock is released.

A continuación, en la misma consola, obtenemos la posición de nuestro MASTER después del bloqueo de las tablas:

1
2
3
4
5
6

La columna FILE muestra el nombre del archivo de log y la posición muestra el offset del archivo. En este ejemplo, el archivo de log binario es mysql-bin.003 y el offset es el 73. Graba esos valores. Tu necesitarás esto más tarde cuando configures el slave. Esto representa las coordenadas del archivo log en las cuales el slave comenzara a procesar las nuevas actualizaciones desde el master.

En otra sesión, empeazamos el volcado de datos a un archivo físico con mysqldump

1	shell> mysqldump --all-databases --lock-all-tables > dbdump.sql

Cuando el proceso finaliza, desbloqueamos las tablas en la primera sesión abierta en los pasos anteriores

1	mysql>UNLOCK TABLES;

De nuevo en el SLAVE, deberemos importar y configurar

1	shell> mysql -uuser -ppassword < dbdump.sql

Una vez hecho esto, configuramos el SLAVE y comenzamos la replicación. Recuperamos los datos que guardamos previamente en el MASTER cuando hicimos el SHOW MASTER STATUS (punto 3).

1 2	mysql> CHANGE MASTER TO MASTER_HOST='10.0.0.1', MASTER_USER='repl', MASTER_PASSWORD='replpassword', MASTER_LOG_FILE='mysql-bin.000001 ', MASTER_LOG_POS='103874 '; mysql> START SLAVE;

Actualización 30/8/2011: en la parte de esta query, MASTER_LOG_POS=nnnnn, no se ponen comillas, si las ponemos nos devuelve un error

Revisamos el estado de nuestro SLAVE

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host:10.0.0.1
Master_User: slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 951
Relay_Log_File: mysqld-relay-bin.000001
Relay_Log_Pos: 251
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
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: 951
Relay_Log_Space: 407
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: 382
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
1 row in set (0.00 sec)

A partir de este momento, los “Second Behind Master” disminuirán progresivamenet hasta 0.

Links

Varnish – dirección IP cliente

Rubén Ortiz — Fri, 01 Jul 2011 10:37:38 +0000

Por defecto, sino modificamos nada del comportamiento de Varnish, podemos tener algún problemilla, con el tema del acceso de las IPs. Hacemos una petición a la IP del servidor Varnish, Varnish la transmite al backend y la devuelve. Pero en los logs del backend, sino lo tenemos bien configurado, veremos como que la IP registrada no es la nuestra, sino la del propio varnish server. O más sencillo, si trabajamos por ejemplo con un backend con PHP veremos que la variable REMOTE_ADDR nos devuelve la IP del servidor Varnish, no la IP del cliente original. Si trabajamos con Apache, nos será fácil corregir esto con el mod_rpaf. Además, hay que editar el archivo de VCL para modificar este comportamiento.

Si leemos la documentación de Varnish, esto ya pertenece a la categoría de FAQs.

“We will need to add the IP address to a header used for the backend request, and configure the backend to log the content of this header instead of the address of the connecting client (which is the varnish server).”

La parte del log no la veremos de momento. El entorno en el que trabajaremos es Varnish + Apache. Primero, probaremos a utilizar los consejos de las FAQs de Varnish. Editamos el fichero de VCL y reiniciamos el servicio para ver que cambios se producen. Para eso subiremos un archivo a web, para que podamos comprobar rápido los cambios.

1. Editamos el fichero VCL

1	# vim /etc/varnish/default.vlc

1
2
3
4
5
6

sub vcl_recv {
# Configuramos un header unico que contiene la direccion del cliente
remove req.http.X-Forwarded-For;
set req.http.X-Forwarded-For = client.ip;
# [...]
}

2. Reiniciamos y comprobamos la variable PHP(es una opción). Podemos subir este código para ver los cambios

1
2
3
4
5
6
7
8
9
10
11
12
13

$clientip = $_SERVER['HTTP_CLIENT_IP'];
$remoteaddr = $_SERVER['REMOTE_ADDR'];
$xforwardedfor = $_SERVER['HTTP_X_FORWARDED_FOR'];
echo "

HTTP_CLIENT_IP: $clientip

\n";
echo "

REMOTE_ADDR: $remoteaddr

\n";
echo "

HTTP_X_FORWARDED_FOR: $xforwardedfor

\n";
?>

3. Casi seguro que, aún a pesar de haber modificado correctamente nuestro fichero VCL, no conseguimos ver correctamente nuestra IP. El “problema” como vemos está a caballo entre Apache y Varnish. Necesitamos un paso más, si queremos seguir utilizando la caché de Varnish conjuntamente con nuestro Apache. Se trata de instalar el mod Rpaf.

1
2
3
4
5
6
7
8
9
10
11
12

# cd /root/
# wget http://www.stderr.net/apache/rpaf/download/mod_rpaf-0.6.tar.gz
# tar zxvf mod_rpaf-0.6.tar.gz
# cd mod_rpaf-0.6
# sed -i 's/APXS2=\$(shell which $apxs2$)/APXS2=\$(shell which apxs)/' Makefile
# make rpaf-2.0 && make install-2.0
# echo "LoadModule rpaf_module modules/mod_rpaf-2.0.so" >> /etc/httpd/conf.d/mod_rpaf.conf
# echo "RPAFenable On" >> /etc/httpd/conf.d/mod_rpaf.conf
# echo "RPAFsethostname On" >> /etc/httpd/conf.d/mod_rpaf.conf
# echo "RPAFproxy_ips 127.0.0.1" >> /etc/httpd/conf.d/mod_rpaf.conf
# echo "RPAFheader X-Forwarded-For" >> /etc/httpd/conf.d/mod_rpaf.conf
# service httpd restart

4. Ahora deberíamos poder reiniciar Varnish y al comprobar de nuevo el código, observar que ya nos muestra la IP correcta.

Links

Varnish – mostrar configuracion

Rubén Ortiz — Tue, 28 Jun 2011 10:43:23 +0000

Para saber la configuración actual de nuestro Varnish, ejecutaremos:

telnet

Escape character is ‘^]’.
—————————–
Varnish Cache CLI 1.0
—————————–
Linux,-sfile,-hcritbit

Type ‘help’ for command list.
Type ‘quit’ to close CLI session.

param.show

y así nos printará por pantalla, la configuración actual de nuestro Varnish

PHP – APC tunning

Rubén Ortiz — Thu, 23 Jun 2011 10:23:40 +0000

Recientemente, en una despliegue de infraestructura, he configurado APC como caché de PHP. En un primer momento, no le presté mucha atención. Más tarde, comprobé que no tenía un funcionamiento correcto. Con el paquete de APC, viene el fichero apc.php, un fichero que genera estadísticas en tiempo real sobre el rendimiento de la caché. Lo que vi fue esto…

Salta a la vista, el pésimo rendimiento por entonces de la caché. Básicamente, se trataba de un site con bastante tráfico y la configuración por defecto es de

apc.shm_size => 32M => 32M

lo cual se quedó corto y comenzó a afectar a la fragmentación de la caché en memoria. El único remedio que conseguí aplicar y que funcionó fue aumentar el tamaño de la caché asignada

apc.shm_size => 32M => 256M

A partir de entonces, después del reinicio del servidor web, la caché presentaba este aspecto, mucho más saludable.

1
2
3
4
5
6
7
8
9
10

# cat /etc/php.d/apc.ini
extension=apc.so
[APC]
apc.enabled = 1
apc.shm_segments = 1
apc.shm_size = 256M
apc.optimization = 0
apc.ttl = 7200
apc.user_ttl = 7200
apc.num_files_hint = 1000

Links

MySQL 5.5

Rubén Ortiz — Tue, 24 May 2011 11:56:58 +0000

En otro post, trataremos la instalación de MySQL 5.5 en CentOS, que por cierto, la primera vez no es sencilla. MySQL 5.5 se convirtió en estable el 15 de diciembre de 2010. Ahora descubro que GA es Generally Available , vaya tela… En definitiva, algunos patchs de google incorporados a la suite 5.5, hacen más que probable que 5.5 tenga un rendimiento bastante superior a otras versiones. Lo digo sin todavía haber hecho los pertinentes test. Pero tiene buenta pinta.

Características principales

El lanzamiento de MySQL 5.5 aporta mejoras en la personalización y escalabilidad.

Escalabilidad y mejora del rendimiento: MySQL Database y motor de almacenamiento InnoDB han sido mejorados para aportar un óptimo rendimiento y escalabilidad para aprovechar los últimos avances en plataformas multi-CPU y multi-core (SMP).

En los entornos que soporten esta característica, se utilizan instrucciones atómicas de la CPU para mejorar el rendimiento de los RW-locks(mutex que permite múltiples lectores). Hay una variable de estado de MySQL que permite conocer si esta característica se soporta en nuestro sistema o instalación.

1
2
3
4
5
6
7

Nuevas variables a configurar para mejorar el rendimiento en base a múltiples threads de lectura y de escritura

1
2
3
4
5
6
7
8

Disponemos de innodb_io_capacity, otro patch de google, que permite configurar el número de operaciones de entrada/salida por segundos. Anteriormente, limitada por defecto a 100, ahora aumentada a 200.

1
2
3
4
5
6
7

mysql>

InnoDB motor por defecto: Ahora, desde la versión MySQL 5.5, InnoDB es el motor de almacenamiento por defecto de la base de datos MySQL, entrega de transacciones ACID, integridad referencial y sistema de recuperación de desastres.

Alta-Disponibilidad: nueva replicación semi-sincrona, se supone que el sistema de replicación es ahora más eficaz y consistente

Usabilidad mejorada: índices mejorados y particionamiento de tablas, soporte SIGNAL/RESIGNAL y diagnósticos mejorados, incluyendo un nuevo PERFORMANCE_SCHEMA, mejorada la administración de MySQL 5.5.

Mejoras en el rendimiento
Teóricamente, la suite MySQL 5.5 ofrece mejoras en el rendimiento versus la suite 5.1. Hasta un 360 % de ganancia en operaciones Read/Write y hasta 200 % de mejoras sólo en Read Only.

Links