Da RDS a EC2: migrato un database MariaDB da 500 GB con 10 minuti di fermo

luroConnect, piattaforma di hosting gestito per Magento (Adobe Commerce), ha pubblicato sul blog ufficiale di MariaDB un resoconto dettagliato della migrazione di un database di produzione da oltre 500 GB da Amazon RDS a MariaDB self-managed su EC2. L'autore è Pradip Shah, e il pezzo è stato ripreso dal team MariaDB perché descrive passo per passo preparazione, cutover e piano di rollback, con le cifre di fatturazione reali.

Il caso riguarda uno store Magento con circa mille ordini al giorno. Secondo le fatture AWS citate nell'articolo, a giugno 2025 (mese "a regime") la spesa mensile per il solo database su RDS era di 13.313 dollari: un'istanza master db.r6i.12xlarge in Multi-AZ, una read replica db.r6i.4xlarge e 3.515 dollari di storage io2/gp3. A luglio la cifra era salita a 13.581 dollari. Ad agosto, durante la fase di convivenza dei due stack, RDS costava 9.269 dollari mentre il nuovo server database su EC2 ne costava 3.377, nello stesso mese.

Come è stata fatta la migrazione

La replica è stata costruita con mydumper/myloader per il dump iniziale e replicazione basata su GTID MariaDB lungo tutta la catena. Il nuovo server EC2 è stato prima agganciato come replica di RDS, poi è diventato a sua volta sorgente per una seconda replica EC2, mentre una nuova istanza RDS è stata configurata come replica dell'EC2, a scopo di rollback.

Il cutover vero e proprio, secondo l'articolo, ha richiesto meno di 10 minuti: promozione della replica EC2, switch del backend ProxySQL da RDS a EC2, test e uscita dalla modalità manutenzione. Nessuna modifica lato applicativo Magento, perché le connessioni passano attraverso ProxySQL e non direttamente al database.

Il piano di rollback

Il resoconto descrive due livelli di sicurezza: uno switch rapido via ProxySQL nei minuti successivi al cutover, e un'istanza RDS tenuta sincronizzata come replica dell'EC2 per settimane, promuovibile in caso di problemi di prestazioni emersi solo sotto carico reale prolungato.

Un incidente avvenuto durante il periodo su RDS, un thread di replica bloccato su una read replica che ha fatto accumulare binlog fino a saturare il volume condiviso con i dati, mandando giù il master, ha motivato la scelta progettuale su EC2 di separare il volume dei binlog da quello dei dati.

L'articolo originale è sul blog di luroConnect, ripreso su mariadb.org all'indirizzo indicato in fonte.