<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>High-Availability on Ivan Luminaria</title><link>https://ivanluminaria.com/es/tags/high-availability/</link><description>Recent content in High-Availability on Ivan Luminaria</description><generator>Hugo</generator><language>es</language><lastBuildDate>Tue, 17 Feb 2026 08:03:00 +0100</lastBuildDate><atom:link href="https://ivanluminaria.com/es/tags/high-availability/index.xml" rel="self" type="application/rss+xml"/><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>De single instance a Data Guard: el día en que el CEO entendió el DR</title><link>https://ivanluminaria.com/es/posts/oracle/oracle-data-guard/</link><pubDate>Tue, 16 Dec 2025 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/es/posts/oracle/oracle-data-guard/</guid><description>&lt;p&gt;El cliente era una empresa mediana del sector asegurador. Trescientos empleados, un aplicativo de gestión interno sobre Oracle 19c, un solo servidor físico en la sala de máquinas de la planta baja. Sin réplica. Sin standby. Sin plan de disaster recovery.&lt;/p&gt;
&lt;p&gt;Durante cinco años todo había funcionado. Y cuando las cosas funcionan, nadie quiere gastar dinero protegiéndose de problemas que nunca han ocurrido.&lt;/p&gt;
&lt;h2 id="el-día-en-que-todo-se-paró" class="relative group"&gt;El día en que todo se paró &lt;span class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100"&gt;&lt;a class="group-hover:text-primary-300 dark:group-hover:text-neutral-700" style="text-decoration-line: none !important;" href="#el-d%c3%ada-en-que-todo-se-par%c3%b3" aria-label="Ancla"&gt;#&lt;/a&gt;&lt;/span&gt;&lt;/h2&gt;&lt;p&gt;Un miércoles de noviembre por la mañana, a las 8:47, el disco del grupo de datos principal sufrió un fallo físico. No un error lógico, no una corrupción recuperable. Un fallo hardware. La controladora RAID perdió dos discos simultáneamente — uno llevaba semanas degradado sin que nadie se diera cuenta, el otro cedió de golpe.&lt;/p&gt;</description></item></channel></rss>