Il backup di un database MySQL in Git è una buona idea?

Prima di perdere dati, lascia che provi a introdurre una prospettiva di amministratore di sistema su questa domanda.

C'è una sola ragione per la quale creiamo i backup: per rendere possibile il ripristino quando qualcosa va storto, dato che invariabilmente lo farà. Pertanto, un adeguato sistema di backup ha requisiti che vanno ben oltre ciò che Git può ragionevolmente gestire.

Ecco alcuni dei problemi che posso prevedere con il tentativo di eseguire il backup del database in git:

• Il repository crescerà notevolmente con ogni "backup". Poiché git memorizza interi oggetti (anche se compressi) e quindi li inserisce successivamente (ad esempio quando esegui git gc ) e conserva la cronologia per sempre , avere una quantità molto grande di dati memorizzati che non è effettivamente necessario o addirittura desiderare. Potrebbe essere necessario limitare l'importo o il periodo di conservazione dei backup eseguiti per risparmiare spazio sul disco o per motivi legali, ma è difficile rimuovi vecchie revisioni da un repository git senza molti danni collaterali.
• Il ripristino è limitato ai punti nel tempo che sono stati memorizzati nel repository e, poiché i dati sono così grandi, è possibile che la risalita più di una semplice quantità di tempo sia lenta. Un sistema di backup progettato per lo scopo limita la quantità di dati archiviati fornendo potenzialmente maggiore granularità e offre ripristini più rapidi, riducendo i tempi di fermo in caso di disastro. Le soluzioni di backup basate sul database ( example ) possono anche fornire un backup continuo , garantendo che non si perde una singola transazione.
• È probabile che anche i commit siano lenti e rallentano man mano che il database cresce. Ricorda che git è essenzialmente un archivio dati di valori-chiave mappato su un filesystem , e quindi è soggetto alle caratteristiche di prestazione del filesystem sottostante. È possibile che questo intervallo di tempo finisca per superare l'intervallo di backup e, a quel punto, non è più possibile soddisfare lo SLA. Anche i sistemi di backup corretti richiedono più tempo per il backup man mano che i dati crescono, ma non così drasticamente, dal momento che gestiranno automaticamente le proprie dimensioni in base al criterio di conservazione che sarà stato configurato.

Nonostante ci siano apparentemente diverse cose interessanti che puoi fare con un dump del database se lo metti in git, nel complesso non posso raccomandarlo allo scopo di mantenere i backup. Soprattutto perché i sistemi di backup sono ampiamente disponibili (e molti sono addirittura open source) e funzionano molto meglio per mantenere i tuoi dati al sicuro e fare è possibile recuperare il più rapidamente possibile.

I miei due centesimi: non penso sia una buona idea. GIT fa qualcosa come "memorizzare istantanee di un set di file in diversi momenti nel tempo", quindi può utilizzare perfettamente GIT per qualcosa di simile, ma ciò non significa che dovrebbe em>. GIT è progettato per memorizzare il codice sorgente, quindi ti mancherebbe la maggior parte delle sue funzionalità e tratteresti un sacco di prestazioni solo per un po 'di convenienza.

Supponiamo che il motivo principale per cui stai pensando a questo è "mantenere una copia dei dati e il codice in sincrono", e questo significa che sei preoccupato che la versione 2.0 del tuo codice abbia bisogno di uno schema di database differente rispetto alla versione 1.0. Una soluzione più semplice sarebbe quella di memorizzare lo schema del database, come un insieme di script SQL con dichiarazioni CREATE , lungo il codice sorgente nel repository Git. Quindi, una parte della procedura di installazione sarebbe quella di eseguire tali script su un server database precedentemente installato.

Gli attuali contenuti di quelle appena CREATE -d tabelle non hanno nulla a che fare con la versione del tuo codice sorgente. Immagina di installare il tuo software, versione 1.0, sul server A e sul server B, che vengono utilizzati in diverse società da diversi team. Dopo alcune settimane, il contenuto delle tabelle sarà molto diverso, anche se gli schemi sono esattamente gli stessi.

Poiché vuoi eseguire il backup dei contenuti del database, ti suggerisco di utilizzare uno script di backup che tag il dump di backup con la versione corrente del software a cui appartiene il dump . Lo script dovrebbe essere nel repository GIT (in modo che abbia accesso alla stringa della versione del codice sorgente), ma i dump stessi non appartengono a un sistema di controllo della versione.

EDIT :

Dopo aver letto il post originale che ha motivato la domanda , trovo questo ancora più dubbio idea. Il punto chiave è che il comando mysqldump trasforma lo stato corrente di un DB in una serie di istruzioni SQL INSERT , e GIT può differire per ottenere solo le righe della tabella aggiornate.

La parte mysqldump è sana, poiché questo è uno dei metodi di backup elencato nella documentazione di MySQL. La parte GIT è dove l'autore non riesce a notare che i server di database conservano un registro delle transazioni per poter recuperare dagli arresti anomali, includendo MySQL . È che utilizza questo registro , non GIT, che dovresti creare backup incrementali per il tuo database. Questo ha, prima di tutto, il vantaggio di poter ruotare o svuotare i log dopo il ripristino, invece di gonfiare un repository GIT all'infinito e oltre ...

Personalmente, non penso che sia una buona idea usare un sistema di versione del controllo sorgente per archiviare i file di backup, perché il controllo della versione GIT è progettato per file di dati, non per file binari o dump come un file di backup di backup MySQL . Il fatto che puoi farlo non significa automaticamente che dovrebbe farlo. Inoltre, il repository, considerando un nuovo backup del database per ogni nuovo commit, crescerà notevolmente, utilizzando un sacco di spazio su disco e le prestazioni di GIT ne risentiranno, risultando in un lento sistema di controllo del codice sorgente. Per me va bene eseguire una strategia di backup e avere sempre pronto un file di backup quando è necessario ripristinare il database quando qualcosa nel codice va storto, ma gli strumenti di controllo del codice sorgente non vengono creati per memorizzare dati binari.

Per questi motivi, non vedo alcuna utilità nell'archiviazione dei file di backup per il giorno 1 e per il giorno 2, quindi vedo le differenze tra i due file di backup. Richiederà molto lavoro extra e inutile. Invece di utilizzare GIT per archiviare i backup del database quando si esegue il commit di nuovo codice, archiviare i backup del database in un percorso diverso, separati da data e ora e inserire nel codice qualche riferimento ai nuovi backup del database creati per ciascuna versione, utilizzando i tag, come qualcuno ha già suggerito.

La mia nota finale sui backup del database e GIT : un amministratore del database, quando ha bisogno di ripristinare un database perché alcuni dati sono andati persi, non ha bisogno di controllare le differenze tra il file di backup per il primo giorno e il file di backup per il secondo giorno, ha solo bisogno di sapere quale è l'ultimo file di backup che gli consentirà di ripristinare il database, senza errori e perdite di dati, riducendo i tempi di fermo. In effetti, il compito di un amministratore di database è di rendere i dati disponibili per il ripristino il più presto possibile, quando il sistema, per alcuni motivi, fallisce. Se si archiviano i backup del database in GIT, collegati ai propri commit, non si consente all'amministratore del database di ripristinare rapidamente i dati, poiché i backup sono limitati ai punti nel tempo memorizzati nel repository GIT e per ridurre il tempo di inattività del sistema, perché le prestazioni del tuo repository GIT saranno drasticamente ridotte con molti dati da archiviare.

Quindi, non è consigliabile archiviare i backup utilizzando GIT, utilizzare invece una buona soluzione software di backup (ce ne sono alcuni qui ), che fornirà più granularità e ti consentirà di mantenere i tuoi dati al sicuro e al sicuro e di rendere il ripristino dei dati semplice e veloce in caso di disastri.

Non dovresti memorizzare dati binari in Git, specialmente nel database.
Le modifiche al codice e le modifiche al DML del database sono cose completamente diverse.

MySQL e Oracle possono scrivere registri di archivio allo scopo di essere ripristinati in qualsiasi momento. Basta salvare questi registri in un posto sicuro e andrà tutto bene.

Utilizzare Git per eseguire il backup di questi "registri di archivio" non ha senso. I registri di archiviazione negli ambienti di produzione sono piuttosto pesanti e devono essere rimossi dopo aver eseguito regolarmente backup completi. Inoltre è inutile metterli in git - quelli sono già un repository in un certo senso.