<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Mydumper on Ivan Luminaria</title><link>https://ivanluminaria.com/ro/tags/mydumper/</link><description>Recent content in Mydumper on Ivan Luminaria</description><generator>Hugo</generator><language>ro</language><lastBuildDate>Tue, 14 Apr 2026 08:03:00 +0100</lastBuildDate><atom:link href="https://ivanluminaria.com/ro/tags/mydumper/index.xml" rel="self" type="application/rss+xml"/><item><title>mysqldump vs mysqlpump vs mydumper: backup-ul care nu te lasă să dormi</title><link>https://ivanluminaria.com/ro/posts/mysql/mysqldump-mysqlpump-mydumper/</link><pubDate>Tue, 14 Apr 2026 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/ro/posts/mysql/mysqldump-mysqlpump-mydumper/</guid><description>&lt;p&gt;Apelul a venit într-o vineri după-amiază — pentru că aceste lucruri se întâmplă întotdeauna vinerea. DBA-ul unui client din sectorul logistic îmi scrie pe Teams: &amp;ldquo;Backup-ul de aseară a durat trei ore și jumătate. Dimineață utilizatorii au găsit aplicația lentă la 8. Putem discuta?&amp;rdquo;&lt;/p&gt;
&lt;p&gt;Puteam discuta, da. De fapt, ar fi trebuit să discutăm demult.&lt;/p&gt;
&lt;p&gt;Setup-ul era un clasic: MySQL 8.0 pe Rocky Linux, bază de date de aproximativ 60 GB, un gestional cu vreo treizeci de tabele InnoDB din care patru sau cinci erau cu adevărat mari — tabela comenzilor, cea a mișcărilor de depozit, istoricul de tracking. Backup-ul se făcea în fiecare noapte cu un mysqldump lansat de cron la 2:00. Funcționase ani de zile. Problema era că baza de date între timp crescuse.&lt;/p&gt;</description></item></channel></rss>