Situaciones que me han pasado toda la vida de DBA y personal que me han ayudado...
jueves, 28 de enero de 2016
jueves, 7 de enero de 2016
lunes, 14 de septiembre de 2015
MySQL autoincrement en replicación Master-Master
Un detalle que se nos presenta al momento de la replicación de Master-Master es con respecto a los campos que definimos como auto_increment dentro de la estructura de nuestras tablas.
La solución que se nos ofrece en este tipo de situaciones, sonara como una "Mexicanada".
Tenemos dos parámetros configurables: auto_increment_increment y auto_increment_offset.
Para configurar estas opciones lo podemos realizar al iniciar el servicio MySQL.
donde:
N = Número de servidores que trabajaran con esta configuración.
# = Número entre 1 y N, cada servidor usara un diferente offset.
Ó mediante variables:
auto_increment_increment; es el numero en que el servidor incrementara cada vez que un valor sea incrementado. El default es 1, es decir que incrementara de 1 en 1, ejemplo 1, 2, 3, 4, 5, etc. Si el valor es un 2, incrementara en 2, ejemplo 1, 3, 5, 7, 9, etc. Si el valor es 3 incrementara, 1, 4, 7, 10, etc.
auto_increment_offset: No puede ser un valor mayor al de auto_increment_increment, este permite decirle cual sera el valor del servidor, si es par o non, si es 1 sera 1, 3, 5 y si es "2" entonces seran los valores 2, 4, 6, 8, No importa cual sea el valor actual del auto_increment, si es 132, continuara con 134, 136, etc.
También podemos declararlos de la siguiente manera:
Al detalle:
La solución que se nos ofrece en este tipo de situaciones, sonara como una "Mexicanada".
Tenemos dos parámetros configurables: auto_increment_increment y auto_increment_offset.
Para configurar estas opciones lo podemos realizar al iniciar el servicio MySQL.
--auto_increment_increment= N --auto_increment_offset=#
donde:
N = Número de servidores que trabajaran con esta configuración.
# = Número entre 1 y N, cada servidor usara un diferente offset.
Ó mediante variables:
SET @@auto_increment_increment = N;
SET @@auto_increment_offset = #;
auto_increment_increment; es el numero en que el servidor incrementara cada vez que un valor sea incrementado. El default es 1, es decir que incrementara de 1 en 1, ejemplo 1, 2, 3, 4, 5, etc. Si el valor es un 2, incrementara en 2, ejemplo 1, 3, 5, 7, 9, etc. Si el valor es 3 incrementara, 1, 4, 7, 10, etc.
auto_increment_offset: No puede ser un valor mayor al de auto_increment_increment, este permite decirle cual sera el valor del servidor, si es par o non, si es 1 sera 1, 3, 5 y si es "2" entonces seran los valores 2, 4, 6, 8, No importa cual sea el valor actual del auto_increment, si es 132, continuara con 134, 136, etc.
También podemos declararlos de la siguiente manera:
Al detalle:
Configuraciones:
En servidor 1:
auto_increment_increment = 2 # Cantidad de servidors
auto_increment_offset = 1 # El número a incrementar (es non)
En servidor 2:
auto_increment_increment = 2 # Cantidad de servidores.
auto_increment_offset = 2 # El número a incrementar (es inpar)
De un inicio en cuanto activamos una replicación las tablas contaran con la misma información. Una vez que se configura como anteriormente se menciono, y se realizan insert sobre dichas tablas (con auto_increment) se insertaran algunos registros en servidor 1, y otros se insertaran en el servidor 2, todo con respecto a la configuración anterior. En un momento dado tendrán información diferente, pero al ejecutarse la replicación, ambos servidores contaran con la misma información.
jueves, 20 de agosto de 2015
Variables para Optimizar MysQL
Variables para optimizar MySQL
En servidores dedicados se recomienda un 50% a 80% de la RAM.
innodb_log_file_size: Se debe incrementar esta variables para para mejorar el rendimiento.
innodb_flush_method: Cuando se usa controladores de RAID, es mejor usar la opción O_DIRECT. Esto previene "doble buffer", cuando no se tienen estos RAIDS es
mejor no usarlo.
innodb_flush_neighbors: Es mejor dejar el parámetro deshabilitado (0) en discos SSD, los cuales no tienen ninguna ventaja con IO secuencial.
innodb_io_capacity y innodb_io_capacity_max: Estas variables influencian cuantos trabajos background por segundo pueden haber.
innodb_lru_scan_depth: Si incrementas innodb_io_capacity, tambien se debe incrementar esta variable.
Replicación.
log-bin: Activarlo, te permite recuperar cierta información que se haya perdido, ante un daño de la base de datos.expire-logs-days: Por default los logs duran para siempre, lo recomendado seria mantenerlos de 1 a 10 dias.
server-id: Id único que se le da al servidor.
Misc.
timezone=GMT: Cambiar el timezone a un default, por lo general se usa el GMT
sql-mode: Variable para configurar algunas propiedades que le queramos dejar a la entidad. Como,
STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,
NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,
NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,
NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY.
skip-name-resolve: Con esta variable podemos desahabilitar la reversa de los nombres de las conexiones.
max_connect_errors: Maximo de errores al conectarse para bloquear la conexión.
max-connections: El default es 151, pero yo por lo general uno 500 usuarios simultáneos.
martes, 18 de agosto de 2015
Mensajes de Nagios al Whatsapp
Aquí dejo los pasos para poder configurar nuestro Nagios, para que nos envíe alertas a nuestro Whatsapp. Cabe mencionar que el numero de celular que se configure para ser quien se envíe correo, no podría ser utilizado en el celular.
Instalar librerías de Python.
Después ejecutamos
Probar el envío de Whatsapp, con nagios:
Copiamos la carpeta donde configuramos todo a la ruta donde quedara:
Probamos que no tengamos configuraciones erroneas en Nagios:
Instalar librerías de Python.
yum install python python-dateutil python-argparse python-dev python-setuptoolsClonamos yowsup,
yum install python-devel.x86_64
git clone https://github.com/tgalal/yowsupNos cambiamos al directorio:
cd yowsupCambiamos los derechos:
chmod +x setup.pyEjecutamos
python setup.py installCambiamos los derechos:
chmod +x yowsup-cliProbamos que funcione:
./yowsup-cli
Available commands:===================demos, registration, version
Después ejecutamos
./yowsup-cli registration --requestcode sms --phone XXXXXXXXXXXX --cc 52 --mcc 334 --mnc 020
La salida sera:
INFO:yowsup.common.http.warequest:{"status":"sent","length":6,"method":"sms","retry_after":1805}
status: sent
retry_after: 1805
length: 6
method: sms
./yowsup-cli registration --register 185-317 --phone XXXXXXXXXXXX --cc 52La salida será:
INFO:yowsup.common.http.warequest:{"status":"ok","login":"XXXXXXXXXXXX","pw":"YYYYYYYYYYYYYYYYYY","type":"existing","expiration":1464632128,"kind":"free","price":"$13.00","cost":"13.00","currency":"MXN","price_expiration":1442951212}Crearemos un archivo, vim yowup-cli.conf y copiaremos la información siguiente:
status: ok
kind: free
pw: YYYYYYYYYYYYYYYYYY
price: $13.00
price_expiration: 1442951212
currency: MXN
cost: 13.00
expiration: 1464632128
login: 5216677919425
type: existing
cc=52 #Your country code
phone=XXXXXXXXXXXX #Your phone number
id= #This is where you insert your IMEI number (not needed)
password= YYYYYYYYYYYYYYYYYY #your password which you got from registration command
Probar el envío de Whatsapp, con nagios:
./yowsup-cli demos -c yowsup-cli.config -s NUM_TELEFONO_ENVIAR “this is a test”CONFIGURACION DE NAGIOS
Copiamos la carpeta donde configuramos todo a la ruta donde quedara:
cp yowsup/ /usr/local/nagios/libexec/
Despues, irnos a "cd /usr/local/nagios/etc/objects/" y sacar un respaldo del archivo de configuración de los comandos,
cp commands.cfg commands.cfg.old
Lo editamos y agregaremos 2 comandos nuevos,
- notify-host-by-whatsapp
$USER1$/yowsup/yowsup-cli -c $USER1$/yowsup/yowsup-cli.config -s $_CONTACTWHATSAPP$ “$NOTIFICATIONTYPE$ Host : $HOSTNAME$ - Service : $SERVICEDESC$ is $SERVICESTATE$ @ $LONGDATETIME$”
- notify-service-by-whatsapp
$USER1$/yowsup/yowsup-cli -c $USER1$/yowsup/yowsup-cli.config -s $_CONTACTWHATSAPP$ “$NOTIFICATIONTYPE$ Host : $HOSTNAME$ is $HOSTSTATE$ @ $LONGDATETIME$”
Quedando asi:
define command{
command_name notify-service-by-whatsapp
command_line $USER1$/yowsup/yowsup-cli -c $USER1$/yowsup/yowsup-cli.config -s $_CONTACTWHATSAPP$ ?$NOTIFICATIONTYPE$ Host : $HOSTNAME$ - Service : $SERVICEDESC$ is $SERVICESTATE$ @ $LONGDATETIME$?
}
define command{
command_name notify-host-by-whatsapp
command_line $USER1$/yowsup/yowsup-cli -c $USER1$/yowsup/yowsup-cli.config -s $_CONTACTWHATSAPP$ ?$NOTIFICATIONTYPE$ Host : $HOSTNAME$ is $HOSTSTATE$ @ $LONGDAT ETIME$?
}
Probamos que no tengamos configuraciones erroneas en Nagios:
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
Si todo funciona bien, reiniciamos Nagios:
service nagios restart
viernes, 24 de julio de 2015
Migrar MySQL 5.1 a 5.5
Cuando vamos a migrar MySQL a otra versión tenemos que tomar en cuenta los cambios de sintaxis, variables que son descontinuadas y configuraciones que cambian.
Algunos puntos importantes al migrar de MySQL 5.1 a 5.5 son los siguientes:
= [v5.5.32] En las tablas de sistema, los campos "url" se crean tipo Text, pero en la migración no se cambian, se tiene que hacer a pie:
= [v5.5.3] No se permite "FLUSH TABLES", cuando existe un bloqueo de tabla activo. Para esto se tiene que ejecutar:
Esto permite que se pueda hacer flush a la tabla y bloquearse al mismo tiempo. Por lo tanto aplicaciones que usen esto:
fallaran.
= [v5.5.7] Nueva tabla proxies_priv, marcara error de que no existe,
"Table 'mysql.proxies_priv' doesn't exist"
cuando se inicie mysql se le tendrá que usar "--skip-grant-tables" y después se correrá mysql_upgrade. ejemplo:
Tendremos que detener y reiniciar el servicio mysql.
Si requerieramos de opciones adicionales, como seleccionar el archivo de configuración personalizado o por default:
Tener cuidado por que con el parámetro "--skip-grant-tables" cualquiera podrá entrar al servidor, para seguridad adicional
agregar "--skip-networking" para que usuarios remotos se conecten.
= [v5.5.7] No se permite mas "TRUNCATE TABLE", devolverá error, se tiene que cambiar a DELETE FROM, la técnica de borrado
es un DROP Y CREATE.
= [v5.5.6] Por problemas en la replicación, cuando se guarda en el binario para ser replicado, cuando se hace uso de la sentencia
CREATE TABLE IF NOT EXISTS ... SELECT, cuando la tabla que se va a crear si existe manda un mensaje de error y en el servidor
"master" si se insertan los registros pero en el servidor "slave" no. Es decir:
- Si la tabla no existe, se guarda en el log tal cual.
- Si la tabla existe,
= [v5.5.6] Si truena cuando inicia el full-text stopword, se debe reparar la tabla:
= [v5.5.5] Existe la manera de activar que nos envie un error (ER_DATA_OUT_OF_RANGE), cuando se quiera insertar un valor fuera de rango,
o que en su defecto le ponga el valor máximo de dicho numero. Variable global @@sql_mode , valores numéricos.
= Revisar los campos timestamp ya no permiten el campo "n" timestamp(n).
- Para corregirlo, en el archivo dump, se debe quitar el parametro (n)
- Antes de respaldar la base de datos, alterar dichas columnas.
= El parámetro "--languages" se remplazo por las variables del sistema: "lc_messages_dir" y "lc_messages".
= Las tablas particionadas se deben de alterar
De esta manera se podra reparar cualquier tabla con los comandos:
De esta manera no se replicaran las optimizaciones o reparaciones que se hagan en los objetos de la base de datos y no se replicarían.
Finalmente regresaremos las configuraciones a su estado original, para comenzar a ponerlo nuevamente a replicarse.
Si usamos anteriormente set sql_log_bin a 0, se ejecuta SET sql_log_bin = 1.
Si usamos el otro método solo reiniciamos el esclavo, sin la opción "--skip-slave-start".
service mysqld stop
wget http://dev.mysql.com/get/mysql-community-release-el6-5.noarch.rpm
rpm --force -Uvh mysql-community-release-el6-5.noarch.rpm
rm mysql-community-release-el6-5.noarch.rpm
yum install --disablerepo=* --enablerepo=mysql55-community mysql-community-server
chkconfig mysqld on
service mysqld start
mysql_upgrade
Algunos puntos importantes al migrar de MySQL 5.1 a 5.5 son los siguientes:
= [v5.5.32] En las tablas de sistema, los campos "url" se crean tipo Text, pero en la migración no se cambian, se tiene que hacer a pie:
ALTER TABLE mysql.help_category MODIFY url TEXT NOT NULL;
ALTER TABLE mysql.help_topic MODIFY url TEXT NOT NULL;
= [v5.5.3] No se permite "FLUSH TABLES", cuando existe un bloqueo de tabla activo. Para esto se tiene que ejecutar:
FLUSH TABLES tbl_list WITH READ LOCK
Esto permite que se pueda hacer flush a la tabla y bloquearse al mismo tiempo. Por lo tanto aplicaciones que usen esto:
LOCK TABLES tbl_list READ;
FLUSH TABLES tbl_list;
fallaran.
= [v5.5.7] Nueva tabla proxies_priv, marcara error de que no existe,
"Table 'mysql.proxies_priv' doesn't exist"
cuando se inicie mysql se le tendrá que usar "--skip-grant-tables" y después se correrá mysql_upgrade. ejemplo:
shell> mysqld --skip-grant-tables &
shell> mysql_upgrade
Tendremos que detener y reiniciar el servicio mysql.
Si requerieramos de opciones adicionales, como seleccionar el archivo de configuración personalizado o por default:
shell> mysqld --defaults-file=/usr/local/mysql/etc/my.cnf
--skip-grant-tables &
shell> mysql_upgrade
Tener cuidado por que con el parámetro "--skip-grant-tables" cualquiera podrá entrar al servidor, para seguridad adicional
agregar "--skip-networking" para que usuarios remotos se conecten.
= [v5.5.7] No se permite mas "TRUNCATE TABLE", devolverá error, se tiene que cambiar a DELETE FROM, la técnica de borrado
es un DROP Y CREATE.
= [v5.5.6] Por problemas en la replicación, cuando se guarda en el binario para ser replicado, cuando se hace uso de la sentencia
CREATE TABLE IF NOT EXISTS ... SELECT, cuando la tabla que se va a crear si existe manda un mensaje de error y en el servidor
"master" si se insertan los registros pero en el servidor "slave" no. Es decir:
- Si la tabla no existe, se guarda en el log tal cual.
- Si la tabla existe,
= [v5.5.6] Si truena cuando inicia el full-text stopword, se debe reparar la tabla:
REPAIR TABLE tbl_name QUICK;
= [v5.5.5] Existe la manera de activar que nos envie un error (ER_DATA_OUT_OF_RANGE), cuando se quiera insertar un valor fuera de rango,
o que en su defecto le ponga el valor máximo de dicho numero. Variable global @@sql_mode , valores numéricos.
= Revisar los campos timestamp ya no permiten el campo "n" timestamp(n).
- Para corregirlo, en el archivo dump, se debe quitar el parametro (n)
- Antes de respaldar la base de datos, alterar dichas columnas.
= El parámetro "--languages" se remplazo por las variables del sistema: "lc_messages_dir" y "lc_messages".
= Las tablas particionadas se deben de alterar
Actualizar primero los espejos:
Detenemos la replicación en todos los espejos y los actualizamos. Los reiniciamos con la opción "--skip-slave-start", para que no se conecten al servidor maestro.De esta manera se podra reparar cualquier tabla con los comandos:
REPAIR TABLE or ALTER TABLEDesahabilitar el log binario en el maestro.
SET sql_log_bin = 0También se puede hacer reiniciado el master, y configurando la opción de "--log-bin", en el my.cnf, aprovechando esto, pudieras desahabilitar la conexión de los clientes TCP/IP, con la opción "--skip-networking".
De esta manera no se replicaran las optimizaciones o reparaciones que se hagan en los objetos de la base de datos y no se replicarían.
Finalmente regresaremos las configuraciones a su estado original, para comenzar a ponerlo nuevamente a replicarse.
Si usamos anteriormente set sql_log_bin a 0, se ejecuta SET sql_log_bin = 1.
Si usamos el otro método solo reiniciamos el esclavo, sin la opción "--skip-slave-start".
service mysqld stop
wget http://dev.mysql.com/get/mysql-community-release-el6-5.noarch.rpm
rpm --force -Uvh mysql-community-release-el6-5.noarch.rpm
rm mysql-community-release-el6-5.noarch.rpm
yum install --disablerepo=* --enablerepo=mysql55-community mysql-community-server
chkconfig mysqld on
service mysqld start
mysql_upgrade
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
3. Desinstalar los paquetes de MySQL ya instalados:
4. Instalar los paquetes con la nueva versión.
6. Ejecutar el comando mysql_upgrade, para actualizar las tablas que son de sesión.
Nota. Revisar que librerías que tenían dependencias se eliminaron como lo es el maatkit, o cualquier otra utilería.
1. Habilitar el repositorio donde se encuentra la versión de MySQL
yum --enablerepo=remi,remi-test install mysql mysql-server2. 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.rpm5. Reiniciar el servicio mysql.
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
6. Ejecutar el comando mysql_upgrade, para actualizar las tablas que son de sesión.
mysql_upgrade -u root -pLas 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.
Suscribirse a:
Entradas (Atom)