Mysql: dubbio tra mysqldum e /var/lib/mysql

[AndDM]

Salve, ennesima discussione sul backup. Ho un dubbio sulle risorse da utilizzare e spero possiate darmi qualche suggerimento. La situazione consiste in due database replicati. Le scelte possibili sono due:

- mysqldump o mysqlhotcopy: la mia perplessità riguarda la politica dei backup full. Considerando che i database conterranno molti dati, una scelta di questo tipo, anche se fatta secondo orari studiati, non mi pare percorribile, considerando poi la necessità di avere una buona frequenza di backup.
Si potrebbe però attuare la politica dei backup incrementali con i log di mysql.
- backup di /var/lib/mysql con rdiff: mi pare che il backup della cartella sia la soluzione utilizzata anche da bacula, avevo pensato a questa soluzione perchè richiede tempo minore nei backup successivi al primo, mantenendo una frequenza giornaliera. Il dubbio mi sorge sull'integrità dei dati, fermo restando che verrà attuato in orari studiati, avevo in mente di usare "FLUSH TABLE WITH READ LOCK" per bloccare il database.

Quali sono le vostre esperienze in merito? e quali i vostri consigli?

Grazie.
Saluti.

[usu]

Dai un'occhiata a Percona XtraBackup for InnoDB and XtraDB Data - Percona Software fa tutto quello che ti serve

[guest]

- backup di /var/lib/mysql con rdiff: mi pare che il backup della cartella sia la soluzione utilizzata anche da bacula

No, bacula non adotta alcun politica di backup.
Bacula fa quello che gli viene detto di fare, può fare dei dump così come copia i dati. Di default, ad esempio, fa il dump del suo database interno, non ne copia i dati brutalmente.

Copiare brutalmente i dati da /var/lib/mysql è sicuramente una soluzione errata sotto ogni punto di vista. MySQL tiene le tabelle in ram, per quanto possibile, quindi se tu copi i file, non stai copiando l'ultima versione dei dati disponibili ma stai copiando la versione inerente l'ultimo flush. Inoltre, rischi di ritrovarti con le tabelle corrotte in fase di ripristino, perchè le avresti copiate da 'aperte'.

In sostanza, rischi di buttare via tutto o, nel migliore dei casi, avere una perdita di dati e qualche tabella corrotta.

[AndDM]

@usu: grazie, mi pare un ottimo link, studio la documentazione e faccio qualche test in locale.

@guest: dato che l'integrità dei dati viene prima di ogni altra cosa, l'unica soluzione è (oltre quella di usu che devo studiare) andare di dump o hotcopy?
Pensavo alla soluzione con il flush perchè lo equiparavo ad il lock che utilizzerebbero anche il dump ed hotcopy, e quindi mi dava le stesse garanzie.
Vista la probabile grande quantità di dati, meglio se mi appoggiassi ai log per dei backup incrementali giornalieri?

Grazie.
Saluti.

[guest]

@guest: dato che l'integrità dei dati viene prima di ogni altra cosa, l'unica soluzione è (oltre quella di usu che devo studiare) andare di dump o hotcopy?
Pensavo alla soluzione con il flush perchè lo equiparavo ad il lock che utilizzerebbero anche il dump ed hotcopy, e quindi mi dava le stesse garanzie.
Vista la probabile grande quantità di dati, meglio se mi appoggiassi ai log per dei backup incrementali giornalieri?

Se riesci a fare un flush con read lock dovresti essere in grado di fare uno snapshot lvm e backuppare quello con una discreta sicurezza.

ma se vuoi l'affidabilità al 100%, l'unica è fare il flush, read lock, dumpare il tutto e provare a ripristinare su un database di appoggio.

La copia brutale delle tabelle io la userei come disaster recovery, non come backup.

[AndDM]

Grazie per i consigli, studierò un pò le soluzioni.