Mostrando entradas con la etiqueta MySQL. Mostrar todas las entradas
Mostrando entradas con la etiqueta MySQL. Mostrar todas las entradas

jueves, 30 de abril de 2020

[EN] DevOps roadmap

Hello!

Today I come with a roadmap that someone sent me a few days ago. It is a roadmap of what (according to how it is understood by who has drew it) a DevOps should know.



You can more or less agree with what is in it, but it has helped me to get to know some new technologies that could be very interesting to me.

What about you? What do you think? One thing amazing is that you can suggest your changes, but I am not sure they would take them into account. Anyway, I have at least two suggestions, that are
  • HOW COME Debian is not in purple???
  • I know there is no Load Balancing section but they should include it somehow


Source: roadmap.sh
You have a few more interesting roadmaps in that page

domingo, 25 de agosto de 2019

[EN] MySQL/MariaDB: filtering processlist query

Haven't seen you in a while... but today I bring you something really interesting I just found out


I'm pretty sure you already know about

mysql> show processlist;


that shows you all the threads that MySQL is running for your user (or all the users if you are root) in that very moment; the problem of that query is that you can't limit or filter it at all and sometimes you need to. 

The cool part is that you can run the same query using

mysql> SELECT * FROM information_schema.processlist;

and filter it as you need!!!!

mysql> SELECT * FROM information_schema.processlist where Host='remote_host';
mysql> SELECT * FROM information_schema.processlist where User='remote_user';

That really made my day! 
And yours?

lunes, 2 de mayo de 2016

Alta de usuarios en MySQL (|II)

Esta es una actualización de mi chuleta, y para el que lo necesite



A estas alturas ya sabemos que podemos definir los permisos que un usuario tiene a una base de datos (o tabla, o donde sea) usando GRANT; hay muchos tipos de privilegios pero los los más típicos que yo me encuentro son estos
  • SELECT: acceso sólo de lectura
  • INSERT: se permiten hacer inserts en la(s) tabla(s) seleccionada(s)
  • UPDATE: se permiten hacer updates en la(s) tabla(s) seleccionada(s)
  • DELETE: se permiten hacer delete de las filas que hay en la(s) tabla(s) seleccionada(s)
  • USAGE: no se permite nada, es un sinónimo para "sin privilegios".
  • ALL PRIVILEGES: todos los privilegios (no sólo incluye estos cuatro; aquí podéis encontrar un listado más completo)
Y para qué todo esto? Pues porque quiero actualizar ms notas

Esto es suficiente para dar de alta un nuevo usuario

 GRANT xxxxx on database.table to 'user'@'host' identified by 'password';

donde xxxxx son los permisos de los que os hablaba arriba.
Si además, queremos limitar el número de conexiones de ese usuario, añadimos al final la limitación, y quedaría de esta manera

 GRANT xxxxx ON database.table TO 'user'@'host' IDENTIFIED BY 'password' WITH MAX_USER_CONNECTIONS #;

El cambio de contraseña para un usuario, queda así

SET PASSWORD FOR 'user'@'host' = PASSWORD('yyyyyyyyyyyy');

Y qué hago si quiero saber qué privilegios tiene un usario, sobre qué y cómo esan definidos? Pues con este comando, que últimamente estoy utilizando bastante

SHOW GRANT FOR 'user'@'host';

que nos devolverá todos los permisos de ese usuario concreto; si  no le pasas el usuario (sólo "SHOW GRANT") te devolverá los privilegios del usuario con el que estás conectado.

sábado, 21 de noviembre de 2015

Píldora: MySQL Replicación Maestro - esclavo



Hola! hoy te traigo mi receta para montar una replicación M/s MySQL
Espero que te sea tan útil como me resulta a mí!



Ten en cuenta que está basada en distribuciones RHEL, pero se puede adaptar a cualquier otra
[ (M): ejecutar en Master ]
[ (s): ejecutar en slave]

# Actualizar sistema en (M) y (s)


sudo yum update

# Añadir a los repositorios los oficiales de Percona en (M) y (s)


sudo yum install http://www.percona.com/downloads/percona-release/redhat/0.1-
3/percona-release-0.1-3.noarch.rpm

# Instalamos, levantamos y securizamos MySQL en (M) y (s)

sudo yum install Percona-Server-server-55
sudo service mysql start
sudo mysql_secure_installation

(tendremos que introducir los datos que nos solicite)

# Abro puertos de comunicación de MySQL en (M) y (s)

sudo firewall-cmd --zone= --add-service=mysql
iptables -L -n # y compruebo que ya aparece el servicio mysql

# Configurar en (M)

sudo vi /etc/my.cnf

# y añado en [mysql]
------
log-bin=mysql-bin
server-id=1
------
guardo, salgo y ejecuto

sudo service mysql restart

y en (s) hago casi lo mismo

sudo vi /etc/my.cnf

# y añado en [mysql]
------
server-id=2
------
sudo service mysql restart

# Configurar usuarios de replicación (M)

mysql -p -u root
mysql > CREATE USER 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass123';
mysql > GRANT REPLICATION SLAVE ON *.* TO 'repl';
mysql > FLUSH TABLES WITH READ LOCK;
mysql > SHOW MASTER STATUS;

En el último paso, guardamos los datos File y Position para seguir en la provisión
Seguimos en (s)

mysql -p -u rootmysql >  CHANGE MASTER TO MASTER_HOST="Master_Host",
MASTER_USER="repl", MASTER_PASSWORD="slavepass123";,
MASTER_LOG_FILE=";mysql-bin.000001", MASTER_LOG_POS=551;

Como prueba creo una BD y compruebo que se crea automáticamente en el otro servidor
Después vuelco una BD pequeña y compruebo que se crea igualmente en el otro servidor

miércoles, 6 de mayo de 2015

Píldora: Activar logs de MySQL sin reiniciar

Queréis habilitar/deshabilitar los de las slow queries de MySQL pero no podéis reiniciar el servicio MySQL?
Venga, puedes hacerlo fácilmente. Entra en la shell de MySQL y haz

 
SHOW VARIABLES;
SET GLOBAL slow_query_log = 'ON';  
FLUSH LOGS; 

  
En el caso de querer deshabilitar los logs (u otras funciones), lo ponemos en OFF
Recuerda que cuando reinicies el servicio, la configuración que prevalece es la del my.cnf. Este cambio es temporal.

jueves, 20 de marzo de 2014

Cambio de la URL de Magento

Esta es otra de esas entradas autodirigida a mí, para acordarme la próxima vez que clone/mueva un Magento y tenga que cambiar la URL. También está dirigida a vosotros, si lo que buscáis es cómo modificar la {base_url} de un Magento dado.

Yo lo suelo hacer a las bravas, sabiendo que hay una manera de hacerlo a través del panel de administración, pero como nunca tenemos el acceso al panel, ni me molesto. Prefiero modificar el parámetro en el MySQL correspondiente; el campo que tengo que modificar es el 'path' de la tabla 'core_config_data', de la manera siguiente:

update core_config_data set value='http://nueva_url/' where path like '%base_url';

donde la nueva URL tiene que tener el formato

http://xxx.dominio.tld/

La barra final es muy importante, no la olvides.
Si ves que de esta manera, aún te redirige a la URL antigua, limpia la caché de tu navegador y de Magento [en var/cache] , y purga los logs [en var/log]  de la aplicación.

miércoles, 26 de febrero de 2014

Alta de usuarios en MySQL (II)

Hola de nuevo!

Esta entrada está dirigida, principalmente, a mí. Esta es mi chuleta desde hace tiempo para dar de alta bases de datos MySQL y usuarios con permisos sobre esa base de datos. Sé que publiqué una entrada hace tiempo, pero dejé de utilizar ese mecanismo hace también mucho tiempo. El caso es que siempre se me olvida algún paso, así que lo dejaré aquí, bien definido por si alguien más quiere utilizarlo, y que me sirva para no tener que andar buscando entre documentos durante media hora antes de darme cuenta que me ha faltado una comilla simple o un punto y coma.

create user USUARIO;     # Creamos el usuario USUARIO
create schema BBDD;     # Creamos la base de datos BBDD
grant all on BBDD.* to 'USUARIO'@'localhost';     # Damos permisos 'all' para USUARIO desde localhost
set password for 'USUARIO'@'localhost' = password('PWD');     # Asignamos la contraseña PWD a USUARIO cuando accede desde localhost
grant all on BBDD.* to 'USUARIO'@'%';    # Damos permisos 'all' para USUARIO desde fuera
set password for 'USUARIO'@'%' = password('PWD');    # Asignamos la contraseña PWD a USUARIO cuando accede desde fuera
flush privileges;    # Cargamos los  cambios que hemos hecho

viernes, 11 de noviembre de 2011

Reducir o truncar el ibdata1 de MySQL

Si estáis utilizando la configuración por defecto del motor de almacenamiento InnoDB para vuestras tablas MySQL, seguramente os habréis encontrado con un problema bastante molesto: el archivo 'ibdata1', que contiene todos los datos de la instancia MySQL (no es bien bien un log de transacciones) y que crece descontroladamente. Al principio pesa 10Mb, pero eso va creciendo y no se puede partir o cortar de ninguna manera. Ni siquiera con DELETE, TRUNCATE o DROPs a los datos almacenados en la BBDD harán que el archivo sea más pequeño. De hecho, cuando se libera espacio, el sistema lo marca como libre dentro del archivo y se puede reutilizar más adelante. Vamos, que podría llegar a ocupar todo el espacio libre en la partición. Y con lo crítico que es, este parámetro no viene preconfigurado en una instalación por defecto.

Bueno, el caso es que una vez configuras una BBDD para trabajar con InnoDB, pocas cosas puedes hacer con ella, una vez te has encontrado con el problema. Así que hay que empezar de nuevo, y para que no nos pase, vamos a intentar limitar estos parámetros y que no crezca de manera descontrolada.

Éste es el método que he utilizado en varias ocasiones. Al final tenéis el enlace al texto original, donde se comentan otras dos maneras de truncar el ibdata1. Yo utilizaré la más intuitiva.

Antes de nada, haced un backup completo de la BBDD. Es más, si puedes también parar el MySQL y copiar los binarios a otro directorio, mejor. Ya lo borrarás cuando puedas. Así tienes todos los backups habidos y por haber.

Yo mi backup completo lo hago con una query del estilo:

/usr/bin/mysqldump ––extended-insert ––all-databases ––add-drop-database ––disable-keys ––flush-privileges ––quick ––routines ––triggers > /root/all-databases.sql

Tarda, tarda bastante, pero es completo.

Una vez tengo hecho mi backup, paro el servidor MySQL y entonces me dedico a mover o a borrar el directorio de datos MySQL. Yo, en mi caso, siempre me gusta guardar el directorio por si hay que hacer un rollback, y es recomendable que lo hagáis. Si no podéis por problemas de espacio o algo, al menos esperad a comprobar que el proceso funciona.

Nos habíamos quedado en que tenéis que mover lo que hay en el directorio de datos de MySQL si queréis mantener el path (por defecto en Debian es /var/lib/mysql); otra opción es crear una carpeta nueva, por ejemplo si queréis mover el directorio de datos de filesystem a uno más grande. En ese caso, recordad configurar los mismos permisos

mkdir /path/to/mysql
chown mysql:mysql /path/to/mysql
chmod 770 /path/to/mysql


Ya casi estamos. Ahora toca reconfigurar el MySQL; por defecto el archivo en Debian es /etc/mysql/my.cnf pero en algunos sistemas es /etc/my.cnf; sólo tendréis que localizarlo y realizar las modificaciones que consideréis pertinentes. Yo, en mi última configuración, añadí estos parámetros

innodb_log_file_size    = 800M
innodb_buffer_pool_size = 1024M
innodb_file_per_table = 1
innodb_data_file_path=ibdata1:1024M


pero en el último algo andaría mal, porque el sistema ha pasado de mí. Lástima que lo vi cuando ya era demasiado tarde (era demasiado tarde porque había puesto la BBDD en producción y si me 'cargo' el ibdata1, me cargo la BBDD... y queda feo). Si habéis cambiado el path del directorio de datos, recordad que tenéis que modificar la variable 'datadir' y actualizarla.

Ahora que he hecho las modificaciones, inicializo la BBDD. Esto es que como no tengo nada, sólo un directorio vacío, vamos a crear la estructura de datos para que el MySQL pueda arrancar sin nada. Ya me encargaré después de cargarle los datos. Para ello, desde la línea de comandos ejecuto

sudo -u mysqld mysql_install_db
(si estoy como root sólo  mysql_install_db)


Y ya estará inicializada. Comprobad que no devuelva otro error, pero si todo va bien, ya tenéis la BBDD.

Ahora levanto el MySQL. En Debian da 'problemas' con el usuario debian-sys-maint, que es el que Debian utiliza para cualquier tarea de mantenimiento, como comprobar el estado de las tablas al arrancar el proceso. Nada, que da error porque el usuario no existe, así que no le hagáis mucho caso al amigo. Cuando importéis la BBDD y el usuario se cree, se resolverá el problema. El caso es que el servicio se levanta y podréis entrar al MySQL. Dentro de la consola ejecutar

SET FOREIGN_KEY_CHECKS=0;
SOURCE /path/to/backup-databases.sql;
SET FOREIGN_KEY_CHECKS=1;


El segundo paso importará la base de datos, y su duración dependerá de lo grande que sea ésta. Puede durar horas. No desesperéis.

Cuando por fin haya acabado, reiniciad el MySQL para que coja todos los cambios que habéis hecho al importar la base de datos. Comprobad que levanta bien y que todo funciona correctamente.

En el caso que tuviérais que volver atrás porque no ha salido bien y no tenéis tiempo de repetir el proceso, todo es tan sencillo como

1 - parar el MySQL
2 - editar /etc/mysql/my.cnf y deshacer los cambios
En mi caso sería eliminar las líneas añadidas y volver a poner /var/lib/mysql en el 'datadir'
3 - arrancar el MySQL de nuevo. Comprueba que todo funciona correctamente


El proceso sólo requiere mucho tiempo, siempre en función del tamaño de la BBDD, no es tan difícil como puede parecer antes de hacerlo

Y ya está!!



lunes, 22 de agosto de 2011

Quitar un servidor MySQL de la replicación

No sé si os ha llegado a pasar alguna vez: para poner dos BBDD MySQL en replicación hay información para parar un tren, pero para quitarlas, yo no he localizado tanta...

Aquí dejo mi pequeña receta.

Hasta hace nada tenía tres servidores MySQL, uno de maestro y dos esclavos que se replicaban automáticamente contra el maestro. Pero llegó el momento que necesité sacarlos y esto es lo que hice:

  1. Editar el /etc/mysql/my.conf (cambiará según distribución, pero en esencia es el archivo de configuración del MySQL) y comentamos las siguientes líneas:
    #server-id = 6
    #log_bin = /var/log/mysql/mysql-bin.log
  2. Movemos (por si hay que recuperarlo) el archivo master.info que se ubica donde se guardan los binarios del MySQL (por defecto en muchos casos es /var/lib/mysql/) y lo guardamos con otro nombre
  3. Reiniciamos la BBDD

La comprobación de que todo ha ido bien y que ya no está vinculado a ningún maestro la podéis hacer consultando el estado del slave: show slave status. Ya veréis como no dice nada!

lunes, 31 de marzo de 2008

MySQL, cuando el cliente o el servidor están obsoletos

O no llego, o me paso.

O no posteo en semanas, o me repito en un día. Pero hay días que te encuentras con cosas curiosas que acabas encontrando la solución, y no voy a dejar de postear por eso mismo...

Aquí va la segunda entrada de hoy.

Intentando conectar desde un cliente MySQL (5.0x) a un servidor (3.x, aunque esto sirve para versiones anteriores a 4.1.1), me devolvía este error:

Client does not support authentication protocol requested by server; consider upgrading MySQL client

La gracia es que no podía actualizar el cliente porque está en una máquina poco estable, obsoleta pero que de momento aguanta (y aquí nos guiamos muchas veces por eso de "si funciona, no lo toques"), así que he tenido que buscar otra solución. Googleando por ahí, he visto que el problema es debido a la diferencia de versiones, y que a partir de la 4.1.1, las contraseñas se encriptan de otra manera, por lo que no se puede validar. La idea es que, para los usuarios que se tienen que conectar entre estas dos máquinas, vamos a poner el formato antiguo de la contraseña. Y lo hacemos de la siguiente manera:

root@Tuxxxy:~# /var/log/mysql# mysql -p -h localhost -u root
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 29
Server version: 5.0.32-Debian_7etch5-log Debian etch distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> use mysql;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> set password for 'user'@'host' = OLD_PASSWORD('mysql');
Query OK, 0 rows affected (0.00 sec)

donde password es la contraseña de ese usuario, user el usuario y host el servidor remoto desde el que te conectas.
Después un

mysql> flush privileges;
y arreando, que es gerundio!

lunes, 18 de febrero de 2008

Alta de usuarios en MySQL

La verdad es que esto no tiene mucha complicación, pero en su momento me acuerdo que me costó un poco encontrar cómo hacerlo de manera clara, sencilla y sin muchas tonterías. Por eso me parece una buena idea postearlo aquí.

Poned atención, que va a ser rápido e indoloro
Tuxxxy:~$ mysql -u root mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 5.0.38-Ubuntu_0ubuntu1.2-log Ubuntu 7.04 distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>

Con esto lo que hacéis es acceder. Es probable que necesitéis poner la contraseña de vuestro usuario root (en este caso no tiene); si tenéis password, deberéis ejecutar

Tuxxxy:~$ mysql -u root-p mysql
Welcome to the MySQL monitor. Commands end with ; or \g.

Bueno, una vez estoy usando la tabla MySQL, doy de alta los usuarios con

GRANT ALL PRIVILEGES on database to 'user'@'localhost' [ 'user'@'IP_server' ] identified by 'password' with grant option;

Después, la tabla Db enlaza usuarios y las bases de datos correspondientes. Lo que tenemos que hacer es añadir el enlace entre el usuario que tenemos y la base (o bases) de datos que queremos que vea. Es simplemente añadir la entrada correspondiente en la tabla Bd, así que yo, para no liarme, lo hago a mano. Para MySQL 4.x lo hago así

insert into db values ('%','database','user','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y');
insert into db values ('localhost','database','user','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y');

Para MySQL 5.x hay más campos, así que tendréis que mirar cómo están. Haciendo

select * from db;


ya podéis ver todos los datos que hay en la tabla, y ver qué estructura tiene y dar de alta una nueva fila siguiendo cómo está hecho.

miércoles, 6 de febrero de 2008

MySQL : "Can't open file: 'TableName.MYD'. (errno: 145)"

Postear una solución a este problemilla creo que ha sido un poco lo que me ha hecho tomar la decisión final de crear este bLog.

La primera vez que me encontré con este problema, en seguida localicé la siguiente solución:

REPAIR TABLE TableName;

pero la verdad es que de poco me sirvió: el error de mi tabla era lo suficientemente grave como para no poder hacer un repair de una manera tan alegre. Así que después de poner de vuelta y media a la pobre tabla, a la base de datos, al MySQL (genéricamente) y a la máquina donde está alojada, seguí buscando y testeando opciones de la propia orden repair, y di con la siguiente solución:

REPAIR TABLE TableName use_frm;

De esta manera lanzo el repair tan felizmente, pero le digo que para hacer la reparación de la tabla, utilice el archivo TableName.frm correspondiente.

Oye, y mano de santo... ¿eh?