Newsgroup: it.comp.lang.delphi
Titolo: Sincronizzazione DB

Ciao a tutti,
   causa recente disastro hardware (causa temporale sono saltati il server + 
pc dove alla sera si eseguivano i backup !) stavo pensando di implementare 
nel programma la possiblita' di eseguire un mirroring o una sincronizzazione 
delle tabelle su un'altro pc (in rete).
Questo perche', mentre dal server non si puo' fare niente, dal pc di backup 
qualcosa si e' recuperato ma e' parziale dato che i db (tutti, i miei + 
quelli del gestionale) sono aggiornati al giorno prima del fattaccio.
La societa' che gestisce l'hardware ha proposto come soluzione un backup 
completo di tutto il  server, in background, ad intervalli di 2 ore, pero' a 
livello personale (quindi per il mio programma) mi interessava approfondire 
l'idea della sincronizzazione.
 
Avete un punto di partenza ???
 
Io pensavo di raddoppiare tutto, ovvero il db di lavoro che fa tutto sul 
server e un db di mirroring in un'altro pc della rete dove si tengono le 
copie di riserva.
Non credo sia semplice, rapido ed indolore (il codice andrebbe riscritto 
aggiungendo le procedure sul secondo db per ogni operazione fatta in tutte 
le form/procedure del programma; un lavoraccio).
 
Poi per complicare le cose, pensavo anche ad una soluzione su cloud .... ma 
in questo caso si deve anche considerare la gestione della connessione e 
l'eventuale sincronizzazione (o copia brutale dei file ogni x ore).
 
Qualcuno ci e' gia' passato ???
Esperienza personale a parte, vale la pena affrontare questo tema ?? 
(tenendo presente che questa situazione e' capitata solo una volta in 15 
anni ..... ma ha fatto disastri !)
 
Grazie per le vostre considerazioni
 
Ciao
 
Daniele 
 

 Esperienza personale a parte, vale la pena affrontare questo tema ?? 
 
Ni, nel senso che è giusto affrontarla, ma non al livello applicativo. Posto
che non nomini il database che utilizzate, ogni RDBMS mette a disposizione più
o meno facilmente sistemi di replica dei dati su una seconda macchina oppure,
alla peggio, puoi usare le funzionalità di replica del sistema operativo. In
ogni caso, è un problema del sistemista, non (completamente) dello sviluppatore
 
Enrico

 sviluppatore
Il sistemista ha dato come soluzione l'aggiunta di una "scatola" con 2 
dischi che "allacciata" server ogni 2 ore fa, in background, il backup di 
tutto il server.
Ora cosa sia la "scatola" non ne ho idea !!!
Il server dev'essere ancora consegnato ed e' un fujitsu su cui girera' un 
windows server 2008 r2.
 
Grazie
 
ciao
 
Daniele 
 

 Daniele
 
Personalmente, da un mio cliente, si usa un sistema di backup in Locale/Cloud, con uno scatolotto che ha due dischi da 1 Tb ciascuno, collegato in rete con la possibilità di programmare i backup con la frequenza che vuoi e poi la notte (o quando vuoi tu) copia tutto in cloud, dove è stato acquistato uno spazio di 500 gb.
Il sistema di backup, come ti hanno già detto, deve essere a livello sistemistico e non di applicativo.
 
Ciao
 
Fabio

 Nel mio caso utilizzo il turbodb della dataweb 
 
Quello che ti e` accaduto e` uno dei motivi principali per cui, da tempo, sconsiglio di usare Delphi e qualunque tecnologia collegata, per scrivere software. Dal momento che ti sei adagiato su una soluzione piu` o meno artigianale, ti conviene scrivere un processo che giri in background e sincronizzi un db slave, da un'altra parte.

 Il sistema di backup, come ti hanno già detto, deve essere a livello sistemistico e non di applicativo.
 
Qualunque DB moderno prevede meccanismi di replicazione.
 
 

 Qualunque DB moderno prevede meccanismi di replicazione.
Evidentemente non e' poi cosi' moderno :-))
Ho avuto uno scambio di email con gli sviluppatori della libreria e, come 
spesso accade, hanno risposto che e' in lista ma non e' una priorita'.
Tuttavia non e' poi cosi' scontato che i DB moderni hanno qualcosa per la 
replicazione, ho trovato ben poco in rete !
Interessante la libreria della TMS che prevede un meccanismo di updating 
bidirezionale su qualsiasi destinazione (in rete o web), pero' per le mie 
poche risorse tecniche .... la configurazione non sembra poi cosi' semplice.
 
Ciao
 
Daniele
 

> Nel mio caso utilizzo il turbodb della dataweb che non ha strumenti per la 
 
E' ora di cambiare.
 
A.

 la configurazione non sembra poi cosi' semplice.
 
Non capisco come mai lo sforzo per imparare come usare un prodotto del genere sia da preferire allo sforzo per imparare ad usare un database e fare un porting.
 
A.

 replicazione, ho trovato ben poco in rete !
 
Hai ragione, dovevo aggiungere "serio" a "db moderno".
Qualunque DB moderno *serio* ha meccanismi di replicazione. Vivi in un mondo in cui ormai tutto e` clusterizzato e destinato a lavorare su cloud. I meccanismi di HA/DR sono la regola.


Appunto, ti sembra a livello Applicativo ??? La replica del DB per me è un livello sistemistico (DB Administrator)...

 Appunto, ti sembra a livello Applicativo ??? La replica del DB per me è un livello sistemistico (DB Administrator)...
 
Non e` detto. Dipende dai database e dalle applicazioni. I sistemisti, in certe decisioni, possono entrarci poco. Ad esempio, se vuoi organizzare i tuoi dati con un database NoSQL, che e` di norma pensato per essere clusterizzato, entrano in gioco fattori molto piu` legati a come e` sviluppato l'applicativo che non semplicemente sistemistici. 
 

 fare un porting.
Interessante non significa necessariamente "lo sto utilizzando".
Sono passato da un link di google e tra le tante risposte c'e'ra anche 
quella.
Avendo fatto lo sforzo (semi)sovraumano per acquistare delphi seattle ed 
avendo le firedac, posso optare per fare un porting in uno dei db supportati 
da queste librerie.
Tuttavia, sicuramente e' una mia limitazione nella ricerca, sembra che solo 
sql server abbia la funzione di mirroring al suo interno ma dal sito 
microsoft dicono che presto verra' rimossa e di NON fare sviluppo 
utilizzando questa funzione.
Invece ci sono una discreta quantita' di software che fanno una 
sincronizzazione tra il server e una seconda destinazione ogni tot 
ore/minuti .... ma questo sembra piu' un backup che altro.
 
Sai quale DB ha questa capacita' ??
 
Sempre onorato per la tua disponibilita'.
 
Ciao
 
Daniele 
 

 sql server abbia la funzione di mirroring 
 
http://www.oracle.com/technetwork/database/features/data-integration/index.html
 
http://dev.mysql.com/doc/refman/5.7/en/replication.html
 
https://www.postgresql.org/docs/9.1/static/high-availability.html
 
 
eccetera eccetera eccetera

 legati a come e` sviluppato l'applicativo che non semplicemente sistemistici. 
 
Sì e no. Per capirci, se prendiamo in esame MongoDB, l'unico vincolo dato allo
sviluppatore, è definire la chiave di shard con cui la collezione verrà
splittata sui vari nodi del cluster
 
Enrico

 tutto il server.
 
In effetti con questi presupposti è l'unica cosa che può fare...
 
Enrico

 splittata sui vari nodi del cluster
 
Hai detto niente. E` proprio la shard key che determina in che modo si accedera` ai dati e dove verranno memorizzati con piu` frequenza. La shard key la decido io come sviluppatore, non il sistemista. Ed e` ancora piu` importante, quando viene utilizzata in tag-aware mode. Io potrei taggare le mie risorse sulla base della potenza di calcolo, per esempio, o su aree geografiche. I sistemisti, nel caso dei NoSQL, c'entrano forse ancora meno che con gli RDBMS.

 utilizzando questa funzione.
 
Secondo me hai un internet diversa dai comuni mortali oppure fai ricerche cinofalliche. Trovati in 2 secondi:
 
http://dev.mysql.com/doc/refman/5.7/en/replication-howto.html
 
http://www.ibm.com/developerworks/data/library/techarticle/dm-0405nikolopoulou/
 
https://mariadb.com/kb/en/mariadb/replication-cluster-multi-master/
 
https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling
 
 
Molla turbo db, passa ad un db come si deve e DIMENTICA gli accrocchi dal funzionamento incerto che sul momento sembrano risolvere il problema ma in realta' servono sono a rimandare l'inevitabile.
In questo modo INVESTI tempo e risorse su qualcosa di standard, riutilizzabile e rivendibile.
 
A.

 riutilizzabile e rivendibile.
Strada da intrapendere al piu' presto !!
 
Grazie
 
Ciao
 
Daniele 
 

 Probabilmente ho capito male
 
Non hai "capito male" ma "cercato male".
Ti sei fermato davanti al dito medio di zio billy dimenticando che ci sono altri database.
 
A.

 anche Firebird va bene
 
Dalla padella nella brace. Se proprio deve cambiare, tanto vale affidarsi o a Postgres o MariaDB.
 
 

 Dalla padella nella brace.
 
Sì e no. Il vero problema è che per Firebird trovi poca documentazione esterna,
ovvero è un prodotto di nicchia (purtroppo). Da questo punto di vista, il tuo
consiglio di passare a PostgreSQL o a MySQL (o a MariaDB) non è così sagliato.
Di contro, Firebird rimane comunque un database con un basso livello di
manutenzione, e da questo punto di vista potrebbe essere un buon motivo per
sceglierlo
 
Enrico

 RDBMS.
 
Seriamente, devi avere incontrato sistemisti particolarmente stronzi nel tuo
ambiente, se ogni volta che si nominano ti scaldi così tanto :)
 
Enrico

 ambiente, se ogni volta che si nominano ti scaldi così tanto :)
 
Ma io non mi "scaldo" affatto. Voi sistemisti tendete ad alzare la testa e mettere bocca dove non dovete e bisogna costantemente farvi stare al vostro posto. E` questo il punto.
 
 

 sceglierlo
 
Non esiste NESSUN buon motivo per scegliere Firebird. Sei un sistemista? Vedi il discorso nell'altro branch del thread: fai il sistemista, non dare consigli su quale tecnologia vada utilizzata. Firebird e` un sistema di nicchia, non usato da nessuno, per il quale non esiste ALCUN support, e di gran lunga inferiore, qualitativamente, a qualunque altro db mainstream presente in giro. Usarlo significa spararsi nei piedi.
 

Usarlo significa spararsi nei piedi.<
 
infatti i miei piedi sono come le Geox :-D
 
Ciao da Enrico Giudici ( alias nessuno ) c/o Anthelios
 

 E` questo il punto.
 
No, il punto è che te non sai riconoscere dove finisce il tuo lavoro e dove
comincia quello del sistemista, e la prova è proprio questo discorso. L'"Alzare
la testa" di un sistemista (come la chiami te) spesso è l'unico "ostacolo" che
si frappone tra lo sviluppatore e il franamento del progetto
 
Enrico

 Usarlo significa spararsi nei piedi.
 
Usarlo significa accettare determinati compromessi, che vanno dal fatto che
per alcuni problemi non c'è soluzione (a causa del fatto che tu sei l'unico
a cui si presentano) al fatto che alcune soluzioni le trovi solo in russo. Ma
a parte questi estremi (che possono essere accettabili, così come possono
essere accettabili i vari ORA-0600 che ho visto in vita mia), è un ottimo
database
 
Enrico

 Daniele
 
 
...alla fine dopo aver letto tutte le cazzate sparate sopra avete capito 
perchè è meglio il COBOL con i suoi bei files?
...e se sapete di cosa sto parlando avete capito anche perchè sono 
meglio VSAM e DB2 ??????
 
-- 
Imparare è un'esperienza, tutto il resto è solo informazione.
L'immaginazione è più importante della conoscenza.
La mente intuitiva è un dono sacro e la mente razionale è un fedele 
servo. Noi abbiamo creato una società che onora il servo e ha 
dimenticato il dono.
(Albert Einstein)

 essere accettabili i vari ORA-0600 che ho visto in vita mia)
 
...su quello si che ci si "diverte"...
 
A.

 VSAM e DB2 ??????
Questi non li conosco.
 
Ho risposto solo per, non che fosse il caso, ricordare che un conto e' 
scrivere programmi di massa e far digerire la tecnologia usata alla 
(appunto) massa.
Ma cosa succede se parte della massa ha esigenze diverse dagli altri?
Come si pongono gli sviluppatori?
 
Ciao
 
Daniele
 
 

 poter leggere (in realtime) qui dati per me ritenuti importanti;
 
Per il discorso realtime, vedi se questo ti può essere utile:
http://www.firebirdsql.org/file/documentation/papers_presentations/Power_Firebird_events.pdf
 
 
Enrico


 
Mah.. io ho provato a usarli, proprio sulla base del paper che hai 
citato (altro materiale non se ne trova).
 
Ho avuto problemi con i client perchè la tecnologia si appoggia sui 
socket, e quindi dopo aver avuto un sacco di grattacapi per aprire dei 
socket sui firewall dei client vari: windows xp,vista, 7 nonchè sul 
server.. ho mollato e utilizzato delle tabelle di messaggistica.
Più facili da leggere (peccato per il polling) e tengo anche la business 
logic disaccoppiata.
 
Se ti leghi agli eventi, devi scrivere delle procedure sul database che 
hanno il side effect di spargere la business logic tra client e server, 
accoppiandoli.
 
Io sto usando firebird in produzione da 4 anni e non ho problemi di 
stabilità, tuttavia ho dovuto imparare a fare tutte quelle cose che un 
normale developer a volte non conosce: ricostruire il dabase con backup 
fatti con versioni diverse, compilare (e fixare bug) i sorgenti QT del 
driver e redistribuirlo a tutti i client. Smanettare con i tools command 
line di FB, ecc..
Inoltre, ho provato su una VM di sviluppo il passaggio alla versione 3 
dalla 2.5, e quando ho visto che il client non mi leggeva la nuova 
versione per via dell'ODS, e che avrei dovuta fare backup-restore e 
costringere tutti i client a fare upgrade, per prudenza ho lasciato 
perdere (non sono pagato per assumermi rischi di questo genere).
 
Purtroppo la verità è che essendo un DB di nicchia, nessuno ti aiuta e 
la conoscenza è poca e concentrata su poche fonti (molte sono russe, e 
se non conosci il cirillico..).
 
Non so se rifarei la scelta.
 
-- 
Morde

 
http://www.firebirdsql.org/file/documentation/papers_presentations/Power_Firebird_events.pdf
 
 
Scusa ... mi sono spiegato male .....
Dato che sono solo in lettura (mi guardo bene da andare a darmi la 
possibita' di variare anche solo un record di chissa' quale tabella del db) 
il real time di cui ho necessita' (e l'ho trovata con il gestionale nuovo) 
e' leggere adesso cosa e' stato fatto qualche minuto fa.
Con il gestionale vecchio dovevo dovevo esportare in file di testo, 
importare ecc... ecc... quindi i dati che leggevo erano, di fatto, gia' 
superati.
 
Ti devo dire che, dal mio lato, e' stata una semi rivoluzione in meglio.
 
Grazie e ciao
 
Daniele 
 

 in AQCobol con la sua bella base dati.
 
A PARTE CHE SI DICE ACUCOBOL
PER CUI DEDUCO CHE TU NON SAPPIA NEMMENO DI COSA STAI PARLANDO
al massimo hai visto qualche linea di codicce, non ci hai capito un 
cazzo e sei tornato a giocare


 Non so se rifarei la scelta.
 
ecco bravo, vuoi dire a questi 4 coglioni 4ndre4 in testa che NON SONO 
UN TROLL!
Grazie!


 e sei tornato a giocare
Appunto, dato che sei cosi' bravo e tecnicamente avanzato puoi illuminare 
questo ng su come leggere i file di acucobol ???
in Delphi (qui siamo in delphi) e, in alternativa, in RAD studio ?
Magari se sei cosi' bravo poi ti assumono alla MicroFocus (perche' loro non 
ci sono riusciti).
 
Ciao
 
Daniele 
 

 Non so se rifarei la scelta.
 
Lo so, il punto è che per come si è proposto l'OP, è forse il database più
indicato (che poi sia una scelta obbligata è un altro discorso)
 
Enrico


infatti non mi risulta che esista niente per acucobol.
l'unica interfaccia esterna che io conosco è una dll che legge i file 
vsam in area cics su mainframe(serie Z)



 
della IBM naturalmente
