Backup MySql community edition

[Maurizio]

Noto molta differenza tra le Procedure di Backup in Delphi ma anche in
C#, rispetto a quelle ottenute da MySqlWorkBench 8

es: dataBase con circa 24.000 Record, la tabella interessata, con alcuni
Blob (1 Blob per le Immagini + 2 TynyBlob per i path)

da Codice ottengo una dimensione di circa 130.000Kb,
da MySqlWorkBench stessa tabella 76.000 Kb.

Sempre dump delle singole tabelle, per eviìtare problemi di restore.

Non e' un problema di nr.immagini, l'applicativo carica sempre 100
record Immagine (TinyBlob) alla volta dal Db, dove risiede solo la
diapositiva di 130 x 100 kb, l'immagine reale invece viene caricata da
Hd in base al path, quindi 100 o 100.000 Imnagini non fanno differenza.

La parte consistente (Blob) e' data dalla descrizione applicata alla
singola immagine ed e' qui che MySqlWorkBench fa la differenza nelle
dimensiomi.

MySql sicuramente affidabile, non ho esperienza con MariaDb e prestazioni.

Perche' provare altro ? perche' mysqldump inserisce righe che
MySqlWordkBench non fa (esame tabella con editor di testo), in entrambi
i casi uso l'ozione create database e create teble, in modo da ricreare
la struttura in caso di restore senza db.

Maurizio

^^^^^^^^^

a titolo indicativo la routine in Delphi 10.4

function Tfrm_Menu1.EseguiBackup: String;
var Path, Nome, Data, Ora, DataBck, OraBck, FileCmd: string;
iRes: Integer;
F: TextFile;
begin
//Backup
//mysqldump -u user -p db_da_copiare > backup.sql

{
If the return value of ShellExecute is greater than 32, the application
was executed successfully.
If its less than 33 then the function failed.
Here is a complete list of the possible return values of ShellExecute:
0 = The operating system is out of memory or resources.
2 = The specified file was not found
3 = The specified path was not found.
5 = Windows 95 only: The operating system denied access to the specified
file
8 = Windows 95 only: There was not enough memory to complete the operation.
10 = Wrong Windows version
11 = The .EXE file is invalid (non-Win32 .EXE or error in .EXE image)
12 = Application was designed for a different operating system
13 = Application was designed for MS-DOS 4.0
15 = Attempt to load a real-mode program
16 = Attempt to load a second instance of an application with
non-readonly data segments.
19 = Attempt to load a compressed application file.
20 = Dynamic-link library (DLL) file failure.
26 = A sharing violation occurred.
27 = The filename association is incomplete or invalid.
28 = The DDE transaction could not be completed because the request
timed out.
29 = The DDE transaction failed.
30 = The DDE transaction could not be completed because other DDE
transactions were being processed.
31 = There is no application associated with the given filename extension.
32 = Windows 95 only: The specified dynamic-link library was not found.
}

Path := ExtractFilePath(ParamStr(0));
Data := DateToStr(Now);
Ora := TimeToStr(Now);

//Rimuove caratteri /
DataBck := StringReplace(Data, '/', '', [rfReplaceAll, rfIgnoreCase]);

//Rimuove : da stringa
OraBck := StringReplace(Ora, ':', '', [rfReplaceAll, rfIgnoreCase]);

//Nome file Backup
Nome := Path + '\Backup\';

//Verifica esistenza
if not DirectoryExists(Nome) then CreateDir(Nome);

Nome := Nome + 'Dump_' + DataBck + '_' + OraBck + '.sql';
FileCmd := Path + 'comandi.bat';

{$I+}
AssignFile(F, FileCmd);
ReWrite(F);

WriteLn(F, 'C:');
WriteLn(F, 'CD\Program Files\MySQL\MySQL Server 8.0\bin\');

Write(F, 'mysqldump -u cremeria -pcremeria --opt --add-drop-database
--create-options --host 127.0.0.1 --databases db_cremeria > ' + Nome);

{
mysqldump -u cremeria -pcremeria --opt --add-drop-database
--create-options --host 127.0.0.1 --databases db_cremeria >
D:\Test\Dump_verifica.sql
}


CloseFile(F);
{I-}

iRes := ShellExecute(Handle, 'open', PChar(FileCmd), nil, nil,
SW_HIDE); //esegue senza visualizzare

if iRes > 32 then
begin
Result := Nome;

ShowMessage('Backup ' + Nome + #13 + 'eseguito correttamente');
end
else
ShowMessage('Backup ' + Nome + #13 + 'riscontrato errore ' +
IntToStr(iRes));

end;

[Alberto Salvati]

On Wednesday, June 22, 2022 at 4:46:17 PM UTC+2, Maurizio wrote:
> Noto molta differenza tra le Procedure di Backup in Delphi ma anche in
> C#, rispetto a quelle ottenute da MySqlWorkBench 8

Prima che aumenti il livello di confusione, è bene chiarire che la procedura di backup non è delphi, c#, java o quello che è.
Tu (giustamente!) non stai facendo altro che lanciare un batch che esegue MySqlDump!
Se si trattase di Oracle, lanceresti un bacth che eseguirebbe rman con opportuni parametri.
Idem dicasi per db2, postgres, interbase, firebird etc.


Assodato quindi che la tua domanda è formulata in modo errato e confuso, la domanda giusta è:

"come mai se io eseguo mysqldump ottengo un backup più grande di quello creato dalla workbrench?"

Ovviamente (ma non per tutti) tale domanda, con delphi (ma anche c# java php ....) non C'ENTRA UN KAZZEN e quindi sei OT.

Comunque...
1) hai già provato a cercare informazioni? Se si, hai trovato qualcosa? Se si, cosa?

2) Non è responsabilità di Workbrench eseguire il backup; anche essa userà MySqlDump. Non riesci da workbrench a VEDERE il comando usato per fare il backup?

3) hai dato un occhio alle opzioni di MySqlDump sull'ovvio sito di riferimento?

> MySql sicuramente affidabile, non ho esperienza con MariaDb e prestazioni.

Cosa c'entra questa tua affermazioni con il tuo problema? Non capisco.


> Perche' provare altro ?

Appunto: perchè?

> perche' mysqldump inserisce righe che
> MySqlWordkBench non fa (esame tabella con editor di testo)

Come docevp. questa domanda non ha alcun senso.
Non è workbrench che fa il backup: workbrench chiama MySqlDump!

A.

[Enrico Bianchi]

On 2022-06-22, Maurizio <lau...@mail.com> wrote:

> es: dataBase con circa 24.000 Record, la tabella interessata, con alcuni
> Blob (1 Blob per le Immagini + 2 TynyBlob per i path)

Sta cosa mi fa tanto orrore...

> Sempre dump delle singole tabelle, per eviìtare problemi di restore.

Questa è bruttina, nel senso che così rischi di perderti la referenziazione tra
le tabelle

> Non e' un problema di nr.immagini, l'applicativo carica sempre 100
> record Immagine (TinyBlob) alla volta dal Db, dove risiede solo la
> diapositiva di 130 x 100 kb, l'immagine reale invece viene caricata da
> Hd in base al path, quindi 100 o 100.000 Imnagini non fanno differenza.

Quindi di fatto hai un thumbnail su db? Perché? A livello di best practices è
una cosa assolutamente da evitare, in quanto penalizza eventuali sistemi di
cache (e.g. il salvataggio su file system di un blob è sempre più efficiente),
mentre di solito su db si salva il path del file

> MySql sicuramente affidabile, non ho esperienza con MariaDb e prestazioni.

Riguardo al tuo problema, non c'entra molto, poi personalmente ti consiglio di
evitare MariaDB, ma sono biased

> Perche' provare altro ? perche' mysqldump inserisce righe che
> MySqlWordkBench non fa (esame tabella con editor di testo), in entrambi
> i casi uso l'ozione create database e create teble, in modo da ricreare
> la struttura in caso di restore senza db.

Che tipo di righe inserisce mysqldump che mysql workbench non inserisce?

> mysqldump -u cremeria -pcremeria --opt --add-drop-database
> --create-options --host 127.0.0.1 --databases db_cremeria >
> D:\Test\Dump_verifica.sql

A queste opzioni, visto che stai facendo "cose brutte" con i blob, ti consiglio
di aggiungere --hex-blob

Enrico

[Alberto Salvati]

> cache (e.g. il salvataggio su file system di un blob è sempre più efficiente),

Se usi xLOB hai prima di tutto il vantaggio che, facendo un backup, ti porti dietro tutto senza doverti anche preoccupare di portarti dietro un pezzo di file system che deve comunque essere oggetto di backup...
Per contro, rischi di avere un backup bello grosso che potrebbe essere scomodo da spostare.

Ancora, la complessità di una eventuale ACL la tieni lato db, punto, mentre avendo un file system ti tocca, presumibilmente, gestire anche i grant sulle cartelle...
Certo, potresti tenere le immagini non su un file system "locale" ma su qualche storage tipo S3/ Glacier di AWS...
A quel punto non avresti problemi di backup e spazio, ma saresti vincolato ad una piattaforma cloud che sarebbe INACCESSIBILE in assenza di connettività, connettività che fin troppo spesso è data per scontata dal parco buoi....

Inoltre, usando il filesystem, devi gestire con molta molta cura il salvataggio dei path sul database , normalizzando in modo da evitare update massive qualora spostassi i file su path diversi...

> Riguardo al tuo problema, non c'entra molto, poi personalmente ti consiglio di
> evitare MariaDB, ma sono biased

..come, sconsigli un vero "database della madonna"..??? :-D
Seriamente, xche no? Io non ci ho mai avuto a che fare e sono curioso...

A.

[Enrico Bianchi]

On 2022-06-23, Alberto Salvati <zzz...@gmail.com> wrote:

> Per contro, rischi di avere un backup bello grosso che potrebbe essere
> scomodo da spostare.

Non è tanto questo, ma l'opportunità di avere dei BLOB dentro il database. Mi
spiego. Se stiamo archiviando roba (e.g. fatture in PDF) potrebbe avere senso
l'approccio che dici, perché comunque sono dati in sola lettura che potrebbero
avere un accesso poco frequente. Ma se stiamo parlando e.g. delle immagini di un
sito (e.g. un ecommerce), averle su file system permette di sfruttare il caching
del web server, che sicuramente è più testato di molte altre soluzioni fatte a
mano

> Ancora, la complessità di una eventuale ACL la tieni lato db, punto, mentre
> avendo un file system ti tocca, presumibilmente, gestire anche i grant sulle
> cartelle...

Dipende da come accedi a quei dati, ovvero potresti non dover gestire alcuna ACL
perché comunque è l'applicativo (che salva le ACL su DB) a preoccuparsene

> Certo, potresti tenere le immagini non su un file system "locale" ma su
> qualche storage tipo S3/ Glacier di AWS...
> A quel punto non avresti problemi di backup e spazio, ma saresti vincolato
> ad una piattaforma cloud che sarebbe INACCESSIBILE in assenza di
> connettività, connettività che fin troppo spesso è data per scontata dal
> parco buoi....

Tieni conto che esistono sistemi S3 100% compatibili ed installabili in locale,
tipo MinIO. Di fatto, l'unica differenza a livello applicativo è l'url dove
connettersi

> Inoltre, usando il filesystem, devi gestire con molta molta cura il
> salvataggio dei path sul database , normalizzando in modo da evitare update
> massive qualora spostassi i file su path diversi...

Senza offesa, ma mi sembra un problema triviale e facilmente gestibile

> ..come, sconsigli un vero "database della madonna"..??? :-D
> Seriamente, xche no? Io non ci ho mai avuto a che fare e sono curioso...

Per tre motivi:

- Il primo è tecnico. Rispetto a MySQL, MariaDB è sempre un po' indietro a
livello di funzionalità. Per fare un esempio, il supporto a JSON è stato
introdotto solo nel 2017, quando in MySQL era disponibile almeno dal 2015.
- Il secondo è di governance: il ciclo di release segue una numerazione tutta
loro. Per farmi capire, il supporto a JSON che citavo prima è stato
introdotto nella release 10.2.7, ovvero in una sottorelease della 10.2.
Personalmente non mi piace una gestione delle release del genere, ovvero il
supporto a JSON me lo sarei aspettato in 10.3.0 (considera che ora siamo a
10.2.44)
- Il terzo è più personale: tutte le volte che ho provato ad usarlo, non ci
sono mai riuscito (ovvero nemmeno mi partiva) e sono tornato a MySQL. Magari
sono stato sfigato io, ma se al primo tentativo MySQL mi parte e sono sulla
stessa macchina, forse non è proprio tutta colpa mia...

Devo ammettere che il secondo punto è nato mentre leggevo il changelog di JSON
su MariaDB, ma rimane comunque un punto valido a mio avviso

Enrico

[Alberto Salvati]

> Non è tanto questo, ma l'opportunità di avere dei BLOB dentro il database. Mi
> spiego. Se stiamo archiviando roba (e.g. fatture in PDF) potrebbe avere senso
> l'approccio che dici, perché comunque sono dati in sola lettura che potrebbero
> avere un accesso poco frequente. Ma se stiamo parlando e.g. delle immagini di un
> sito (e.g. un ecommerce), averle su file system permette di sfruttare il caching
> del web server, che sicuramente è più testato di molte altre soluzioni fatte a
> mano

Concordo.

> > salvataggio dei path sul database , normalizzando in modo da evitare update
> > massive qualora spostassi i file su path diversi...
> Senza offesa, ma mi sembra un problema triviale e facilmente gestibile

Ma ci mancherebbe!
Ho precisato questo punto a seguito di una brutta esperienza di anni fa...
I nomi dei file non erano normalizzati e includevano i path...
Spostando le cartelle successe un bel casino che dovetti poi sistemare IO....

> - Il primo è tecnico. Rispetto a MySQL, MariaDB è sempre un po' indietro a
> livello di funzionalità. Per fare un esempio, il supporto a JSON è stato
> introdotto solo nel 2017, quando in MySQL era disponibile almeno dal 2015.

...uhm....

> - Il secondo è di governance: il ciclo di release segue una numerazione tutta
> loro. Per farmi capire, il supporto a JSON che citavo prima è stato
> introdotto nella release 10.2.7, ovvero in una sottorelease della 10.2.
> Personalmente non mi piace una gestione delle release del genere, ovvero il
> supporto a JSON me lo sarei aspettato in 10.3.0 (considera che ora siamo a
> 10.2.44)

Io queste (il)logiche proprio non le comprendo...

> - Il terzo è più personale: tutte le volte che ho provato ad usarlo, non ci
> sono mai riuscito (ovvero nemmeno mi partiva)
> e sono tornato a MySQL. Magari
> sono stato sfigato io, ma se al primo tentativo MySQL mi parte e sono sulla
> stessa macchina, forse non è proprio tutta colpa mia...

Se vedo cose di questo tipo mollo subito.
Se ancor prima di iniziare tozzo, tremo al pensiero di cosa potrebbe succede DOPO.....

A.

[Maurizio]

Il 22/06/2022 16:46, Maurizio ha scritto:
>> Noto molta differenza tra le Procedure di Backup in Delphi ma anche in
>> C#, rispetto a quelle ottenute da MySqlWorkBench

anche se OT dico che ho capito da dove arriva la differenze di spazio
occupupto.

con mysqldump si ottiene una dimensione
con una Libreria .Net (MySqlBackup) lo spazio aumenta in modo notevole;
forse qualche parametro, ma direi preferibile mysqldump sempre allineato
con MySql.

quanto alle righe inserite, ad esclusione di alcuni commenti e righe
vuote , nell'intestazione del file , non c'e' altro.

quanto alla scelta di inserire thumbnail in un campo Blob, anziche' nel
filesystem, la scelta e' stata fatta dal cliente che gestisce archivi
fotografici in modo simile (per chi conosce) a quanto fa Adobe LightRoom.

[Alberto Salvati]

> con mysqldump si ottiene una dimensione
> con una Libreria .Net (MySqlBackup) lo spazio aumenta in modo notevole;
> forse qualche parametro,

Non credo proprio la libreria .Net si basi su qualcosa che NON sia mysqldump...

> ma direi preferibile mysqldump sempre allineato
> con MySql.

Onestamente, non ho capito...
Cosa vuol dire "preferibile"? Preferibile rispetto a COSA?
Cosa vuol dire "sempre allineato con Mysql"?

A.

[Maurizio]

Il 01/07/2022 17:06, Alberto Salvati ha scritto:
>>
>>> con mysqldump si ottiene una dimensione
>>> con una Libreria .Net (MySqlBackup) lo spazio aumenta in modo notevole;
>>> forse qualche parametro,
>>
>> Non credo proprio la libreria .Net si basi su qualcosa che NON sia mysqldump...
>>

per la certezza , bisognerebbe avere il sorgente.

>>
>>> ma direi preferibile mysqldump sempre allineato
>>> con MySql.
>>
>> Onestamente, non ho capito...
>> Cosa vuol dire "preferibile"? Preferibile rispetto a COSA?

soluzioni diverse da mysqldump, ad es. una soluzione su codice Php
(reperibile su GttHub), che replica le funzionalita' di mysqldump.

potenzialmente rischioso, quando a seguito upgrade Mysql server, quindi
su rel. diverse, il Restore non da mysqldump, causa perdita di record.

problema capitato 3 gg fa, il restore su file corposi extra mysqldump
causa un 1% di perdita sulle ultime righe, stessi file con mysqldump non
hanno problemi sul ripristino; eclusa quindi corruzione dei file backup.

su 320.000 record presenti ne recupara 316.800, palla passata al sistemista.

>> Cosa vuol dire "sempre allineato con Mysql"?
>>

che mysqldump segue le directory dove e' installato MySqlServer, ne
consegue che non si potra' (**) eseguire mysqldump di una rel. diversa
da quella installata.

(**) salvo il caso, in cui mysqldump sia stato spostato di proposito in
una directory esterna a MySqlServer.

[Alberto Salvati]

> soluzioni diverse da mysqldump, ad es. una soluzione su codice Php
> (reperibile su GttHub), che replica le funzionalita' di mysqldump.

FOLLIA, FOLLIA E ANCORA FOLLIA. Usarla è FOLLE, realizzarla è da coglioni, punto.

>
> potenzialmente rischioso, quando a seguito upgrade Mysql server, quindi
> su rel. diverse, il Restore non da mysqldump, causa perdita di record.

Ma guarda un po...

> che mysqldump segue le directory dove e' installato MySqlServer, ne
> consegue che non si potra' (**) eseguire mysqldump di una rel. diversa
> da quella installata.

E quindi?


A.