<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>MySQL on Ivan Luminaria</title><link>https://ivanluminaria.com/es/posts/mysql/</link><description>Recent content in MySQL on Ivan Luminaria</description><generator>Hugo</generator><language>es</language><lastBuildDate>Tue, 31 Mar 2026 08:03:00 +0100</lastBuildDate><atom:link href="https://ivanluminaria.com/es/posts/mysql/index.xml" rel="self" type="application/rss+xml"/><item><title>Binary log en MySQL: qué son, cómo gestionarlos y cuándo puedes borrarlos</title><link>https://ivanluminaria.com/es/posts/mysql/binary-log-mysql/</link><pubDate>Tue, 31 Mar 2026 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/es/posts/mysql/binary-log-mysql/</guid><description>&lt;p&gt;El mensaje en el canal de Slack del equipo de infraestructura era de esos que te hacen levantar la cabeza de la pantalla: &amp;ldquo;Disco al 95% en el db de producción. ¿Alguien puede mirar?&amp;rdquo;&lt;/p&gt;
&lt;p&gt;El servidor era un MySQL 8.0 sobre Rocky Linux, un sistema de gestión usado por un centenar de usuarios. La base de datos en sí ocupaba unos 40 GB — nada extraordinario. Pero en el directorio de datos había 180 GB de binary logs. Seis meses de binlog que nadie había pensado en gestionar.&lt;/p&gt;</description></item><item><title>Galera Cluster con 3 nodos: cómo resolví un problema de disponibilidad en MySQL</title><link>https://ivanluminaria.com/es/posts/mysql/galera-cluster-3-nodi/</link><pubDate>Tue, 17 Feb 2026 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/es/posts/mysql/galera-cluster-3-nodi/</guid><description>&lt;p&gt;El ticket era lacónico, como suele pasar cuando el problema es grave: &amp;ldquo;La base de datos se cayó otra vez. La aplicación está parada. Tercera vez en dos meses.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;El cliente tenía un MariaDB en un único servidor Linux — una aplicación de gestión empresarial usada por unos doscientos usuarios internos, con picos de carga durante los cierres contables de fin de mes. Cada vez que el servidor tenía un problema — un disco que se ralentizaba, una actualización del sistema que requería reinicio, un proceso que consumía toda la RAM — la base de datos caía y con ella toda la operatividad empresarial.&lt;/p&gt;</description></item><item><title>Usuarios MySQL: por qué 'mario' y 'mario'@'localhost' no son la misma persona</title><link>https://ivanluminaria.com/es/posts/mysql/mysql-users-and-hosts/</link><pubDate>Tue, 13 Jan 2026 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/es/posts/mysql/mysql-users-and-hosts/</guid><description>&lt;p&gt;Hace unas semanas un cliente me llama. Tono pragmático, petición aparentemente banal:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&amp;ldquo;Necesito crear un usuario en MySQL para una aplicación que debe acceder a una base de datos. ¿Puedes encargarte?&amp;rdquo;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Claro. &lt;code&gt;CREATE USER&lt;/code&gt;, &lt;span class="glossary-tip" tabindex="0" data-glossary-desc="Comando SQL para asignar privilegios específicos a un usuario o rol sobre bases de datos, tablas o columnas. En MySQL 8 ya no crea usuarios implícitamente." data-glossary-url="https://ivanluminaria.com/es/glossary/grant/" data-glossary-more="Leer más →"&gt;`GRANT`&lt;/span&gt;
, siguiente.&lt;/p&gt;
&lt;p&gt;Solo que después añade: &amp;ldquo;La aplicación corre en dos servidores diferentes. Y a veces también nos conectaremos en local para mantenimiento.&amp;rdquo;&lt;/p&gt;</description></item><item><title>MySQL multi-instancia: un ticket, un CSV y el muro de secure-file-priv</title><link>https://ivanluminaria.com/es/posts/mysql/mysql-multi-istanza-secure-file-priv/</link><pubDate>Tue, 04 Nov 2025 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/es/posts/mysql/mysql-multi-istanza-secure-file-priv/</guid><description>&lt;p&gt;El ticket decía: &amp;ldquo;Necesitamos un export CSV de la tabla de pedidos del gestional. Antes de las 14:00.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;Eran las 11. Tres horas para un SELECT con INTO OUTFILE — cosa de cinco minutos, pensé. Después abrí la VPN, me conecté al servidor y entendí que cinco minutos no iban a alcanzar.&lt;/p&gt;
&lt;p&gt;El servidor era una máquina CentOS 7 con cuatro instancias MySQL. Cuatro. En el mismo host, con cuatro servicios &lt;span class="glossary-tip" tabindex="0" data-glossary-desc="Sistema de inicio y gestor de servicios en Linux, usado para gestionar múltiples instancias MySQL/MariaDB en el mismo servidor mediante unit files separados." data-glossary-url="https://ivanluminaria.com/es/glossary/systemd/" data-glossary-more="Leer más →"&gt;systemd&lt;/span&gt;
 distintos, cuatro puertos distintos, cuatro sockets Unix distintos, cuatro directorios de datos distintos. Un setup que alguien había montado años atrás — probablemente para ahorrarse un segundo servidor — y que desde entonces nadie había tocado ni documentado.&lt;/p&gt;</description></item><item><title>Disco lleno en un cluster MySQL: binary logs, Group Replication y una migración que no admite errores</title><link>https://ivanluminaria.com/es/posts/mysql/mysql-group-replication-binlog-migration/</link><pubDate>Tue, 14 Oct 2025 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/es/posts/mysql/mysql-group-replication-binlog-migration/</guid><description>&lt;p&gt;La alerta llegó un lunes por la mañana, entre tres reuniones y un café todavía caliente. &amp;ldquo;Filesystem /mysql al 85% en el nodo primario.&amp;rdquo; En otro nodo estaba al 66%, en el tercero al 25%. En un cluster, cuando los números no cuadran entre los nodos, siempre hay algo debajo.&lt;/p&gt;
&lt;p&gt;La primera pregunta que te viene a la cabeza es &amp;ldquo;¿cuánto espacio necesitamos?&amp;rdquo;. Pero es la pregunta equivocada. La correcta es: &amp;ldquo;¿por qué se está llenando?&amp;rdquo;&lt;/p&gt;</description></item></channel></rss>