--- Citazione da: nomorelogic - Dicembre 02, 2021, 06:38:36 pm ---E' successo che un ns cliente aveva una replicazione con MsSql su una sede distaccata. Il log lo tiene il server per ogni slave sottoscrittore finché il sottoscrittore non si collega e lo scarica per applicare le transazioni per se stesso.
Fatto sta che un giorno dismettono il server sulla sede distaccata dove stava il sottoscrittore ma non ci dicono nulla... Il server master ha incrementato i log fino a saturare l'HD.
--- Termina citazione ---
A questo si può ovviare monitorando lo spazio su disco, o ancora meglio le "frequenze" di connessione .... Io quando ho qualcosa (anche di terze parti come un DB un Datat Logger o altro) che scrive su disco inserisco sempre un monitoraggio, non si sà mai ....
--- Citazione da: nomorelogic - Dicembre 02, 2021, 06:38:36 pm ---Senza contare che il sistema dei log si basa sul fatto che, dopo la sincronizzazione iniziale, lo slave non abbia alterato i record per conto suo. Nel qual caso si verifica il disallineamento.
--- Termina citazione ---
Bhè questa è storia. I DB replicati vengono usati per backup o per visualizzazioni o ricerche, non certo per lavorarci sopra :o .
Però effettivamente, direi che usando un tool che legge i log del DB Master, eseguire una replica su un database diverso non dovrebbe essere estremamente complesso (fatto salvo la transcodifica ....). Quello che vedo apparentemente più complesso è tutta l'elaborazione di milioni di record in un tempo relativamente "stretto" e tramite TCP/IP.
Anche ammettendo di fare un trasferimento di 10K record al secondo, per 10kk record servono 1000 secondi, oltre 15 minuti. Poi magari mi sbaglio nelle prestazioni, magari si riescono a traferire 1kk record al secondo o anche più.
Ciao ciao.
DragoRosso:
Questi sono dei tools a pagamento per maneggiare il log di un MSSQL:
--- Citazione da: DragoRosso - Dicembre 02, 2021, 07:04:09 pm --- --- Citazione da: nomorelogic - Dicembre 02, 2021, 06:38:36 pm ---E' successo che un ns cliente aveva una replicazione con MsSql su una sede distaccata. Il log lo tiene il server per ogni slave sottoscrittore finché il sottoscrittore non si collega e lo scarica per applicare le transazioni per se stesso.
Fatto sta che un giorno dismettono il server sulla sede distaccata dove stava il sottoscrittore ma non ci dicono nulla... Il server master ha incrementato i log fino a saturare l'HD.
--- Termina citazione ---
A questo si può ovviare monitorando lo spazio su disco, o ancora meglio le "frequenze" di connessione .... Io quando ho qualcosa (anche di terze parti come un DB un Datat Logger o altro) che scrive su disco inserisco sempre un monitoraggio, non si sà mai ....
--- Citazione da: nomorelogic - Dicembre 02, 2021, 06:38:36 pm ---Senza contare che il sistema dei log si basa sul fatto che, dopo la sincronizzazione iniziale, lo slave non abbia alterato i record per conto suo. Nel qual caso si verifica il disallineamento.
--- Termina citazione ---
Bhè questa è storia. I DB replicati vengono usati per backup o per visualizzazioni o ricerche, non certo per lavorarci sopra :o .
Però effettivamente, direi che usando un tool che legge i log del DB Master, eseguire una replica su un database diverso non dovrebbe essere estremamente complesso (fatto salvo la transcodifica ....). Quello che vedo apparentemente più complesso è tutta l'elaborazione di milioni di record in un tempo relativamente "stretto" e tramite TCP/IP.
Anche ammettendo di fare un trasferimento di 10K record al secondo, per 10kk record servono 1000 secondi, oltre 15 minuti. Poi magari mi sbaglio nelle prestazioni, magari si riescono a traferire 1kk record al secondo o anche più.
Ciao ciao.
--- Termina citazione ---
chiaramente non conta la prima volta ma le differenziali