<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Replication on Ivan Luminaria</title><link>https://ivanluminaria.com/ro/tags/replication/</link><description>Recent content in Replication on Ivan Luminaria</description><generator>Hugo</generator><language>ro</language><lastBuildDate>Tue, 31 Mar 2026 08:03:00 +0100</lastBuildDate><atom:link href="https://ivanluminaria.com/ro/tags/replication/index.xml" rel="self" type="application/rss+xml"/><item><title>Binary log în MySQL: ce sunt, cum le gestionezi și când le poți șterge</title><link>https://ivanluminaria.com/ro/posts/mysql/binary-log-mysql/</link><pubDate>Tue, 31 Mar 2026 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/ro/posts/mysql/binary-log-mysql/</guid><description>&lt;p&gt;Mesajul pe canalul Slack al echipei de infrastructură era din acelea care te fac să ridici capul de la ecran: &amp;ldquo;Disc la 95% pe db-ul de producție. Cine poate să se uite?&amp;rdquo;&lt;/p&gt;
&lt;p&gt;Serverul era un MySQL 8.0 pe Rocky Linux, un sistem de gestiune folosit de aproximativ o sută de utilizatori. Baza de date în sine ocupa circa 40 GB — nimic extraordinar. Dar în directorul de date se aflau 180 GB de binary log. Șase luni de binlog pe care nimeni nu se gândise să le gestioneze.&lt;/p&gt;</description></item><item><title>Galera Cluster cu 3 noduri: cum am rezolvat o problemă de disponibilitate pe MySQL</title><link>https://ivanluminaria.com/ro/posts/mysql/galera-cluster-3-nodi/</link><pubDate>Tue, 17 Feb 2026 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/ro/posts/mysql/galera-cluster-3-nodi/</guid><description>&lt;p&gt;Tichetul era laconic, cum se întâmplă adesea când problema e gravă: &amp;ldquo;Baza de date a căzut din nou. Aplicația e oprită. A treia oară în două luni.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;Clientul avea un MariaDB pe un singur server Linux — o aplicație de gestiune de afaceri folosită de aproximativ două sute de utilizatori interni, cu vârfuri de încărcare în timpul închiderilor contabile de sfârșit de lună. De fiecare dată când serverul avea o problemă — un disc care se încetinea, o actualizare de sistem care necesita restart, un proces care consuma toată memoria RAM — baza de date cădea și cu ea întreaga operativitate a companiei.&lt;/p&gt;</description></item></channel></rss>