Newsgroup: it.comp.lang.perl
Titolo: File Locking o qualcosa di simile

Ciao a Tutti,
Ho un'infrastruttura di questo tipo:
1  Master
16 Slave
Sul Master gira un processo perl che:
1- Controlla che un DB sia cambiato (facendo il checksum dello stesso
e confrontandolo con quello precedente)
2- Qualora il DB cambia lo invia in scp, utilizzando il modulo
SCP::Expect ai 16 slave.
Sugli slave gira un'altro processo perl:
1- Verifica la presenza di un file in un particolare percorso (e.g. /
db/dump)
2- Qualora trovi questo file fa la move del file  e lo utilizza.
Ora mi chiedo, supponiamo che il Master stia copiando tale file sugli
slave, lo slave si accorge della presenza del file prima ancora che la
copia sia terminata ne fa la move e lo utilizza. Il file non ancora
completamente copiato risulterebbe non integro e l'operazione non
andrebbe a buon fine.
Come fare per essere sicuri che il Master abbia completato la copia?
E se lo slave fa la move del file mentre il master ha iniziato una
nuova copia, come risolverlo?
Grazie a tutti!!
Ciao,
Andrea

Andrea wrote:

Questa è una sequenza race condition-free:
1. Il master copia (via scp) sugli slave il file:
dump.tmp
2. Terminata la copia, il *master* esegue sullo slave (via ssh):
mv dump.tmp dump
Lo slave legge "dump" quando vuole senza precauzioni: se aveva aperto il 
file prima della mv, continua a leggere la vecchia versione non 
aggiornata; se lo apre dopo, legge la nuova versione aggiornata dal master.
Non ci sono conflitti e tutto funziona, in quanto la mv è atomica.
Tuttavia permangono alcune fragilità (che sarebbe troppo lungo 
disaminare ora). Considerando inoltre che ci sono soluzioni più robuste 
praticamente a costo zero, non vedo perché non adottarle.
Esempi:
A. server svn sul master: il master fa la commit di dump e gli slave 
fanno la update quando vogliono (per Perl c'è SVN::Client - oppure basta 
una banale system).
B. ... OK, neanche la scrivo perché sarebbe più lunga e costosa della A 
(e lo stesso dicasi per la C ;-)
Se ci sono particolari vincoli per cui non puoi usare la soluzione A, 
esponili pure che eventualmente passiamo alle lettere successive).
Ciao,
Emanuele.

Sul master non posso installare un svn (componente server) sono
sistemi in esercizio Sun Solaris 5.9
Mi interesserebbero anche le altre opzioni :) grazie!
ciao,
Andrea
On 16 Apr, 13:58, Emanuele Zeppieri


 Andrea
Ciao
Roberto
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Mi interesserebbero anche le altre opzioni :) grazie!
Allora, il server svn puoi installarlo anche su una macchina terza,
anche su uno degli slave, o eventualmente su tutti gli slave:
l'importante è che il master committi e gli slave facciano le update.
Le altre soluzioni, come diceva anche Roberto, per essere *veramente*
robuste, comportano l'implementazione di un sistema client-server che si
passa il file di dump e si sincronizza.
Altrimenti, in subordine, potresti adottare una delle classiche
strategie relative al paradigma producer-consumer: fondamentalmente deve 
essere lo slave (consumer) che /sveglia/ il master (ad es. via ssh) per 
dirgli di scrivere il file di dump, e poi deve essere il master 
(producer) che quando ha finito di scrivere sveglia/lancia lo script 
sullo slave per la lettura.
Ma ci vuole attenzione per implementare le cose in maniera da evitare
deadlock e altri problemi...
Senza contare che hai una serie di inefficienze e/o problemi col file di
dump: si tratta dell'intero db o di differenze incrementali?
Nel primo caso sarebbe inefficiente, nel secondo caso diverrebbe
complicato calcolare e gestire le differenze giuste per ogni slave
(anche in questo il server svn aiuta).
Quando è capitato a me, in realtà ho sempre optato per una soluzione
completamente diversa: uno script (schedulato) che si collega *via DBI*
ai due DBMS (master e slave) e provvede ad effettuare le necessarie
sincronizzazioni tabella per tabella: in questo modo puoi contare sul
supporto transazionale offerto dai DBMS ed hai anche la massima
efficienza, dovendo trasferire solo i record cambiati/aggiunti (lo stato
delle sincronizzazioni puoi mantenerlo in tabelle agiuntive o in db
esterno).
Se stiamo parlando di DBMS (interfacciabili con DBI), suggerisco questa
soluzione.
C'è anche un modulo CPAN da cui puoi trarre ispirazione (o usarlo
direttamente):
http://search.cpan.org/dist/Data-Sync/
(se vuoi vedere la documentazione vai sulla versioni precedenti (0.6),
che CPAN ha fatto casino con l'indicizzazione dei moduli).
Ciao,
Emanuele.