ufratetoto ha scritto:
Ehm....era ciò che volevo indicare nel primo post effettivamente! Proverò a dilungarmi meno:
Ho un DB1 usato per trasmettere audio in streaming, DB che viene aggiornato quotidianamente.
Questo DB1 è a disposizione di chi quotidianamente attinge ai contenuti e occasionalmente effettua alcune modifiche.
Piuttosto che far operare chiunque sullo stesso DB1, vorrei che questo venisse replicato su un DB2 così che chi ne dovrà quotidianamente fare uso trovi SEMPRE tutte le modifiche da me apportate sul DB1 e che, nel caso voglia aggiungere nuovi contenuti, tali modifiche vengano applicate SOLO al DB2 replicato.
In pratica vorrei capire se questa tecnologia, seppur pensata per altri scopi, possa o meno risolvere il mio problema in maniera del tutto automatica, trasparente, indolore e soprattutto costante.
Spero di aver reso l'idea meglio che nel primo post!
La risposta è: boh.
La replicazione nasce come metodo bruto, proprio idiota, per copiare i dati da un master a N slave.
Ma come avviene questo? Nei "tempi antichi" tenendo un elenco dei comandi che vengono svolti dal master (proprio i comandi SQL), che poi vengono inviati (solo i comandi) agli slave, i quali li eseguono a loro volta.
Quindi gli slave essenzialmente ripercorrono il log del master, e quando il master ci mette, per banalizzare, "delete from tabella where qualcosa" allora gli slave dicono "che culo, c'è un nuovo comando, eseguiamo anche noi il delete".
Fermo il pippone sulle varie tipologie di log binari (statement, row, mucchio selvaggio), perchè nel corso dei decenni ci sono state implementazioni sempre più "incasinate" al fine di gestire il dramma degli statement non sicuri in replicazione.
Infatti NON in tutti i casi è banale, e deterministico, che gli slave siano in grado di riprodurre esattamente cosa fa il master, sia per motivi vari (latenza), sia per drammi (cancellazioni a cascate, ad esempio), sia per possibili differenze tra le versioni dei programmi, addirittura degli engine.
Potresti avere tabelle master innodb e slave myisam (che poi la cosa sia suicida è un aspetto marginale, diciamo che puoi farlo).
=========
Quindi, tralasciando pipponi e spiegoni titanici, PUOI benissimo alterare il contenuto dello slave "a tradimento", MA senza avere una conoscenza perfetta di cosa succede nell'applicazione, non puoi predirre cosa accadrà.
Facciamo l'esempio più classico: un campo autoincrementante (tralascio lo spiegone su dove e perchè comunque possano essere unsafe e così via).
Se nel master hai una tabella pippo con un campo autoincrementante al valore 27, che viene usato come chiave vera e propria, nella tabella pippo dello slave vorresti avere sempre il valore 27.
Se, a tradimento, inserisci una riga nello slave (questo è quello che vuoi fare, se ho ben capito), allora diventerà la 28.
Ma, quando inserirai una riga nel master, avrai UNA DIVERSA riga con chiave 28.
Questo è male? Se la replicazione non è a statement di sicuro, se è a statement, probabilmente sì, in ogni caso, perchè andrai a "incasinare" tutte le relazioni.
============
Si può evitare questo "imputtanamento" (chiedo venia per il termine molto tecnico)?
Sì, sia facendo un'applicazione che sia in grado di gestire queste situazioni (tipicamente sono tecniche che si usano per la concorrenza loose, cioè quando i link cadono deve funzionare lo stesso), sia una configurazione del tutto diversa, cioè master-master.
Che però ha una caterva di altri effetti collaterali negativi, più o meno sottili, e "imputtanamenti" di ogni genere.
============
In sostanza la replicazione master-slave nasce, per myqsl, come un "giocattolo" (cioè un progetto hobbistico) che tipicamente ti consente di scalare (uno scrive, tanti leggono), avere un "muletto" su cui fare i backup di ogni genere (cioè avere sia un backup, sia poter dumpare dal backup), o le analisi datamart, degli indicizzatori sphinx, lucene o quello che vuoi, senza caricare il master.
Infine un sistema più o meno veloce per avere una copia locale (replicazione a statement) di database remoti giganteschi, su cui fare in sostanza test, sviluppi e assistenza.
Stop
=============
Quindi nel tuo caso... o fai un'applicazione "furba" che impedisce che i client facciano disastri, e quindi logghi tutto quello che fanno, e/o attivi un bel log binario che ti consenta, alla peggio, di fare un ripristino.
Magari pure frequenti dump, snapshot (se li puoi fare) e chi più ne ha ne metta.
Nulla però ti vieta di fare DUE tabelle (se possibile), la TUA e quella degli "schiavi", mettendo in UNION i risultati, se proprio vuoi impedire agli "schiavi" di modificare i TUOI dati.
Puoi fare la stessa cosa, più pulitamente, usando un identificatore del client (sulle righe), magari delle viste (per i client), sicchè "pensino" di aver modificato la tabella principale, senza in realtà farlo.
Poi puoi andare di ogni tipo di sharding orizzontale (se hai carichi elevatissimi, a non credo proprio)
Se dettagli cosa fanno esattamente i client magari posso entrare più nei particolari