lunes, 20 de julio de 2015

Actualizar versión MySQL

Para actualizar la versión de MySQL


1. Habilitar el repositorio donde se encuentra la versión de MySQL
yum --enablerepo=remi,remi-test install mysql mysql-server
2. Si tenemos un monitoreo, hay que deshabilitarlo (como lo es Nagios).

3. Desinstalar los paquetes de MySQL ya instalados:
yum remove MySQL-client-community.x86_64
yum remove MySQL-community-debuginfo.x86_64
yum remove MySQL-devel-community.x86_64
yum remove MySQL-embedded-community.x86_64
yum remove MySQL-server-community.x86_64
yum remove MySQL-shared-community.x86_64
yum remove MySQL-shared-compat.x86_64
yum remove MySQL-test-community.x86_64

4. Instalar los paquetes con la nueva versión.
rpm -UK MySQL-client-5.5.41-1.linux2.6.x86_64.rpm
rpm -UK MySQL-devel-5.5.41-1.linux2.6.x86_64.rpm
rpm -UK MySQL-embedded-5.5.41-1.linux2.6.x86_64.rpm
rpm -UK MySQL-server-5.5.41-1.linux2.6.x86_64.rpm
rpm -UK MySQL-shared-5.5.41-1.linux2.6.x86_64.rpm
rpm -UK MySQL-shared-compat-5.5.41-1.linux2.6.x86_64.rpm
rpm -UK MySQL-test-5.5.41-1.linux2.6.x86_64.rpm
5. Reiniciar el servicio mysql.

6. Ejecutar el comando mysql_upgrade, para actualizar las tablas que son de sesión.

mysql_upgrade -u root -p
Las base de datos que ya estaban instaladas se pondrán en linea nuevamente, ya que no se elimina las base de datos de usuario.


Nota. Revisar que librerías que tenían dependencias se eliminaron como lo es el maatkit, o cualquier otra utilería.

jueves, 18 de junio de 2015

Configurar replicación Master-Master #MySQL

Configurando la replicación de master a master.

La replicación es un proceso de pasar la información de una base de datos de un servidor y se copia a otra base de datos a un segundo servidor.

Normalmente configuramos la replicación en espejo (master-slave), para tener un plan de contingencia ante una eventualidad donde podamos poner un servidor esclavo(slave) como master(maestro).

¿Para qué?

  • Permitir la escalibilidad de las aplicaciones.
  • Distribuir las cargas en dos servidores.
  • Redundancia e incrementar la eficiencia.


PASO 1: Instalar y configurar MySQL en el servidor 1

sudo apt-get install mysql-server mysql-client
Editar el archivo /etc/mysql/my.cnf y modificar los valores de las siguientes variables:
#server-id = 1
#log_bin = /var/log/mysql/mysql-bin.log #binlog_do_db = include_database_name bind-address = 127.0.0.1
server-id es un identificador único por servidor.
log_bin nombre de archivo donde se guardaran los logs.
bin_log_do_db nombre de la o las base de datos a replicar.
bind-address las ips donde se podrán o no conectar al servidor MySQL.

Debería quedar así:

server-id               = 1
log_bin                 = /var/log/mysql/mysql-bin.log
binlog_do_db            = basedatos_prueba
# bind-address            = 127.0.0.1
Ahora reiniciamos el servicio mysql.

sudo service mysql restart
Entramos a la consola con usuario root, nos pedirá la contraseña:

mysql -u root -p 
Ejecutaremos unas consultas, crearemos usuario para que se ejecute la replicación entre los servidores.

create user 'replicator'@'%' identified by 'password'; 
Otorgamos los derechos al usuario a las base de datos.

grant replication slave on *.* to 'replicator'@'%'; 
Finalmente obtener información del servidor configurado para despues ser utilizada (GUARDAR LOS DATOS EXTRAIDOS)

show master status; 
La salida similar a esta:

+------------------+----------+----------------+------------------+
| File             | Position | Binlog_Do_DB   | Binlog_Ignore_DB |
+------------------+----------+----------------+------------------+
| mysql-bin.000001 |      59 | basedatos_prueba|                  |
+------------------+----------+----------------+------------------+
1 row in set (0.00 sec)
PASO 2: Instalar y configurar MySQL en el servidor 2

sudo apt-get install mysql-server mysql-client
Editar el archivo /etc/mysql/my.cnf y AHORA cambiaremos el id, por otro numero único:
#server-id = 1
#log_bin = /var/log/mysql/mysql-bin.log #binlog_do_db = include_database_name bind-address = 127.0.0.1
Debería quedar así:

server-id               = 2
log_bin                 = /var/log/mysql/mysql-bin.log
binlog_do_db            = basedatos_prueba
# bind-address            = 127.0.0.1
Después de cambiar el archivo reiniciamos el servicio mysql.

sudo service mysql restart
Entramos a la consola con usuario root, nos pedirá la contraseña:

mysql -u root -p 
Crearemos usuario para que se ejecute la replicación entre los servidores.

create user 'replicator'@'%' identified by 'password'; 
Creamos la base de datos que queremos replicar, si ya existe se omite el paso.

create database basedatos_prueba; 
Otorgamos los derechos al usuario a las base de datos.

grant replication slave on *.* to 'replicator'@'%'; 
El siguiente paso permitirá comenzar con la replica de los datos, detenemos el espejo, configuramos con la información que extrajimos con anterioridad con el comando "show master status"

slave stop; 
CHANGE MASTER TO MASTER_HOST = '3.3.3.3', MASTER_USER = 'replicator', MASTER_PASSWORD = 'password', MASTER_LOG_FILE = 'mysql-bin.000001', MASTER_LOG_POS = 54; 
slave start; 
Necesitamos remplazar la contraseña por la que elegimos anteriormente cuando se creo el usuario y se dio derechos.


Lo ultimo que tenemos que realizar es obtener los datos del master (segundo servidor) para realizar la sincronización en el sentido contrario.

SHOW MASTER STATUS; 
La salida será similar a esta:

+------------------+----------+-----------------+------------------+
| File             | Position | Binlog_Do_DB    | Binlog_Ignore_DB |
+------------------+----------+-----------------+------------------+
| mysql-bin.000004 |      125 | basedatos_prueba|                  |
+------------------+----------+-----------------+------------------+
1 row in set (0.00 sec)
Guardamos los datos nuevamente, para aplicarlos en el primer servidor y que la replicación sea en ambos sentidos.

PASO 3:  Configuración del regreso de la replicación

En el primer servidor, ejecutar lo siguiente en la linea de comandos.

 
slave stop; 
CHANGE MASTER TO MASTER_HOST = '4.4.4.4', MASTER_USER = 'replicator', MASTER_PASSWORD = 'password', MASTER_LOG_FILE = 'mysql-bin.000004', MASTER_LOG_POS = 125; 
slave start; 
PASO 4: Probar la replicación

Si no existiera la base de datos configurada:

create database basedatos_prueba; 
Se crea la tabla en el primer servidor.

CREATE TABLE basedatos_prueba.ejemplo (`id` integer(10)); 
Revisamos en el segundo servidor que exista la tabla (comprobar que se replico):

SHOW TABLES IN basedatos_prueba; 
En ese mismo segundo servidor eliminamos la tabla:

DROP TABLE basedatos_prueba.ejemplo; 
Y comprobamos que no exista en el primer servidor.




Nota: Tener cuidado al realizar este tipo de replicación cuando se tengan estructuras de tabla donde existan campos que sean auto_increment.
















miércoles, 21 de enero de 2015

Plugins MySQL


INSTALACION DE PLUGIN:

Los plugins deben ser reconocidos por el servidor antes de ser usado. Esto se logra con diferentes métodos.

Normalmente el plugin se activa al reiniciar el servicio MySQL

*Buit-in plugins:
Es un plugin construido dentro del servidor que es reconocido automáticamente. Puede cambiarse el valor si se usa la opción --plugin_name.

*Registrando el plugin en la tabla mysql.plugin:
El servidor normalmente habilita cada plugin listado en la tabla al iniciar el servicio, sin embargo puede ser cambiado con la opción --plugin_name. Si el servicio de MySQL se inicia con la opción --skip-grant-tables, esta opción no consulta la tabla y no carga los plugins.

*Mandando llamar el plugins con la opción --plugin-load:
Es una librería que se carga al iniciar el servicio MySQL, con la opción --plugin-load. Pero puede ser cambiado si se usa la opción --plugin_name.

Esta opción usa un listado separado por punto y coma de los plugins con la siguiente sintaxis, name=plugin_library, donde "name" es el nombre del plugin y "plugin_library" es el nombre de la librería compartida que contiene el código. Las librerías deberán estar alojadas en el directorio que refiera la variable "plugin_dir". Esta opción no registra en la tabla mysql.plugin. Para reinicios subsecuentes, el servidor carga de nuevo los plugins SOLO con la opción --plugin-load.

*Instalar plugin con "INSTALL PLUGIN":
Cuando un plugin esta localizado en el archivo de la librería puede ser cargada en tiempo de ejecución con "INSTALL PLUGIN". Ademas registra el plugin en la tabla mysql.plugin, lo cual
causa que cuando se reinicie el servicio MySQL se recarguen los plugins. 

Si utiliza las dos opciones para registrar un plugin, "INSTALL PLUGIN" y --plugin-load, el servicio reiniciara pero mandame mensajes de que el plugin ya existe.

ejemplo:
con "--plugin-load":
[mysqld]
plugin-load=myplugin=somepluglib.so

Con sentencia:
mysql> INSTALL PLUGIN myplugin SONAME 'somepluglib.so';

CONTROLAR ACTIVAR PLUGINS
Se puede activar o desahabilitar un plugin al gusto sin importar si esta configurado con algunas de las opcinoes anteriores con:
--plugin_name=OFF       : Desahabilita el plugin
--plugin_name[=ON]      : Habilita el plugin, pero si marca error de todas formas inicia el servicio.
--plugin_name=FORCE  : Inicia el servicio siempre y cuando no exista error.
--plugin_name=FORCE_PLUS_PERMANENT : Inicia el servicio siempre y cuando no exista error pero aparte previene  de que se desahabiliten plugins en tiempo de ejecución, marcaria error.

El estado de los plugins activos pueden ser visto en information_schema.plugins.load_option.

Ejemplo: Tenemos 3 plugins, donde "csv" no es extremadamente importante que inicie si llega a fallar en el inicio, pero "blackhole" debe iniciar si o si y el plugin "archive" esta desahabilitado.

[mysqld]
csv=ON
blackhole=FORCE
archive=OFF


DESINSTALAR UN PLUGIN
* Sentencia "UNINSTALL PLUGIN", daría de baja el plugin y eliminaría el registro de la tabla mysql.plugin
-No puede desahabilitar plugins que son construidos en el servicio MySQL.
-No puede bajar plugins donde el servicio fue iniciado con --plugin-name=FORCE_PLUS_PERMANENT.


Información de los Plugin MySQL

*Cada registro de la tabla INFORMATION_SCHEMA.PLUGINS contiene información de cada plugin cargado.

SELECT * FROM information_schema.PLUGINS\G

Dentro de este resultado, todo lo que tenga en PLUGIN_LIBRARY = NULL, son plugins internos y no pueden ser descargados.


* SHOW PLUGINS\G
Muestra un registro por cada plugin cargado.

*La tabla mysql.plugin muestra los plugins registrador con "INSTALL PLUGINS".




No me a tocado a mi hacer uso de ellos, al menos no configurarlos yo, pero lo guardo como nota por si los requiero.








martes, 2 de diciembre de 2014

Extraer una tabla de un respaldo.

Para no tener que levantar todo el respaldo de una base de datos para solo extraer una tabla, hice el siguiente script:

   #! /bin/bash

   if test -z "$1"
   then
       echo First parameter will be "table"
       exit
   else
       TABLE=$1
   fi
  
  echo Table name: $1.
  echo File in to search: $2.
  echo File out: $3.
  sed -n -e '/CREATE TABLE.*'$TABLE'/,/CREATE TABLE/p' $2 > $3.dump
  echo Need to edit file $3.dump
  echo and extract just what you need.
  echo Lucky

 Se manda de parámetro el nombre de la tabla, el archivo del .dump y el nombre del archivo de salida.

sábado, 29 de noviembre de 2014

Leer fichero mysql-bin

Este archivo se genera a partir de que se tiene activo que se guarde el log de toda modificación en la base de datos, este archivo es leído por el servidor espejo, lo lee y toma los cambios y se ejecutan, para mantener la integridad de datos en los servidores.

¿Como leer este fichero binario?

Por fortuna contamos con el comando mysqlbinlog, con los parámetros correctos, podemos extraer la información para posteriormente ser leída y procesada.

 mysqlbinlog binlog.000046 > archivo.out
Y con algunos parámetros
mysqlbinlog --start-datetime="2008-05-28 16:41:00" --stop-datetime="2008-05-28 16:43:00" > archivo.out
Ya es cuestión de jugar con sus parámetros.

mas información aquí

Muy útil hasta para recuperar información.

viernes, 21 de noviembre de 2014

Se me lleno el disco de Base de Datos (ESPEJO uff!!)

Caso curioso...

Caso:
El servidor espejo( de mi productivo)  lleno el disco duro donde se encontraba la partición de mi base de datos, 100%, y como buena Ley de Murphy, el monitoreo que le tenia activado no estaba activado para esa unidad de disco, motivo por el cual no me di cuenta antes de que sucediera.

Síntoma:
El servicio de MySQL por obvias razones dejo de funcionar, no permitía accesar al servicio MySQL.

Causa:
Un descuido de una opción del sistema, comenzó a grabar mucha información en pocas horas inserto mas de 4millones de registros con mucha información de por medio.

Solución:
Una puede ser, depurar información en producción, dar mantenimiento en la base de datos productiva, respaldar nuevamente y restaurar y iniciar el espejo nuevamente ya con menos información.

Otra, liberar espacio en la unidad que se lleno copiando toda la carpeta de una de las base de datos a otro disco ó otro servidor, para levantar esa base de datos en ese otro disco.






Conectarse sin batallar a servidor Linux (Protocolo ssh)

Conectarse sin batallar a servidor Linux (Protocolo #ssh)

Cuando no queremos batallar al conectarnos a un servidor, podemos generar credenciales que nos autentifiquen con el servidor, y no nos pida contraseñas que por lo general(por seguridad) son muy complicadas. (Esto en servidores Linux).

En el home del usuario de nuestra PC (Linux) ejecutamos:

ssh-keygen -t rsa -b 1024

Este comando nos pedira que pongamos el nombre de un archivo:
id_rsa_xxx

y luego nos pedira una palabra (contraseña) que podamos recordar, ya que sera la que estaremos tecleando de ahora en adelante cada vez que nos queramos conectar a los servidores, en vez de la contraseña complicada.

No genera dos archivos:
id_rsa_xxx
id_rsa_xxx.pub

El archivo id_rsa_xxx.pub lo vamos a copiar al servidor donde queremos estarnos logueando con certificado y su contenido servidoragregara a 
al archivo, del usuario del servidor que se encuentra en la siguiente ruta: /home/usuario/.ssh/authorized_keys lo podemos hacer de la siguiente
manera:

cat /home/usuario/id_rsa_xxx.pub >> authorized_keys

Una vez hecho esto, ya no ocuparemos el archivo id_rsa_xxx.pub, es mejor borrarlo.

rm -f /home/usuario/id_rsa_xxx.pub

Por ultimo nos logueamos al servidor

ssh usuario@hostservidor

Nos pedirá la contraseña que le dimos en el proceso de creación del archivo id_rsa_xxx.pub, esto solo la primera vez que reniciamos la pc, después ya no será necesario.

Notese que al loguearse por ssh, escribimos el usuario, este usuario debe ser al que agreamos el contenido del archivo id_rsa_xxx.pub y se lo agregamos
a su archivo authorized_keys. Si queremos que a los "n" usuarios del servidor sea igual, tenemos que entrar a todos los "n" usuarios del servidor y agregarle el contenido de id_rsa_xxx.pub al authorized_keys