Cavoletti.... certo che lo risincronizzo... e che cavolo.... mica ci vuole molto.

• Ogni insert o update è duplicata sul server di backup
• Quando il primario cade permetto il login sul backup.
• Dopo un po sistemo il primario
• blocco l'accesso al backup
• lancio la mia routine per la sincronizzazione
• chiudo il backup e permetto l'accesso al primario

Ho un paio di procedure che si occupano del confronto delle tabelle (indici come matrici, $i e $j) e una procedura che mi sincronizza la tabella che scelgo (fa un drop e poi ripopola con i dati aggiornati).

La questione della disconnessione forzata delle sessioni era proprio per gestire correttamente la fase transitoria del passaggio/allineamento backup --> primario.
Tutti gli insert o update che vengono preparati dal php vengono poi passati ad un solo file che si occupa della scrittura effettiva in tabella. Implementerò un controllo prima della scrittura in modo da verificare se è abilitata o meno l'operazione.

Se penso poi che è una funzionalità che spero di non utilizzare mai.....

Ciao

Se su una tabella devi inserire 100.000 record passando da php sai quanto tempo perdi? Tutto tempo che rimani praticamente con il servizio non funzionante visto che il server di backup lo blocchi.
Lanciare un comando da ssh per ripristinare un database intero impiegherebbe massimo 5 secondi.

@Thedarkita said:

[..]

Da quello che ho letto la sincronizzazione avviene solo nel verso master --> slave e non viceversa

Se il mio master cade lo slave continua a funzionare, va avanti e si aggiorna, se poi torna in piedi il master che faccio???
Dovrei cambiare il master in slave e lo slave in master, aspettare che si risincronizzi il tutto e poi reimpostare il tutto come era in origine.
Credo sia molto più macchinosa la cosa.

Altra cosa (correggimi se dico cavolate) la sincronizzazione master --> slave non è a comando, si dovrebbe sincronizzare velocemente ma non so in quanto tempo, in genere secondi? Io ho bisogno di tempi certi.

No, dal server 2 fai un backup, il server 1 lo scarica e lancia il comando diretto per l'import intero. Hai impiegato 30 secondi a farlo.
Con php a seconda delle dimensioni del database perdi varie ore, e se ci provi a farlo in php vedrai che avevo ragione io visto che sfortunatamente una volta mi è toccato farlo, che non avevo scelta.

@Thedarkita said:

Se su una tabella devi inserire 100.000 record passando da php sai quanto tempo perdi? Tutto tempo che rimani praticamente con il servizio non funzionante visto che il server di backup lo blocchi.
Lanciare un comando da ssh per ripristinare un database intero impiegherebbe massimo 5 secondi.

vero ma la mie tabelle hanno un numero che è al di sotto (e di parecchio) della misura da te citata: diciamo che 2000 record per le tabelle più grosse ci sto gia largo dentro.

ogni comando di ricostruzione se va male finisce in 4 o 5 secondi.

Certo che ora il test su una creazione di una tabella da 100.000 record e il suo successivo passaggio su altro server tramite php lo devo fare, tanto per vedere quanto tempo impiega

@Thedarkita said:

No, dal server 2 fai un backup, il server 1 lo scarica e lancia il comando diretto per l'import intero. Hai impiegato 30 secondi a farlo.
Con php a seconda delle dimensioni del database perdi varie ore, e se ci provi a farlo in php vedrai che avevo ragione io visto che sfortunatamente una volta mi è toccato farlo, che non avevo scelta.

umh... vero... però devo essere presente io (dato che tutto il resto della ciurma non può farlo) o posso farlo fare a php o a qualche script?

Come potresti automatizzare la cosa non lo sò, ma per cose del genere è sempre comunque meglio ci sia qualcuno competente a farle, non si sà mai che complicazioni possono nascere.
Supponevo fosse una cosa più grande viste le necessità dei 2 server.

@Thedarkita said:

[...]

Quando lavori nel settore pubblico trovi poche persone competenti e disposte a lavorare al di fuori dell'orario di lavoro (io sono un fesso praticamente)

I 2 server sono virtuali, non è che avevo molti soldi da buttare.

Copia di una tabella con 1.000 record di 10 campi (int) da un VPS ad un altro:
37 secondi circa (media su 5 esecuzioni)

In effetti copiare 100.000 record con la mia routine di allineamento impiegherebbe varie ore (dato che non è lineare come le 6 righe di codice scritte appositamente per un test) e sarebbe una soluzione da scartare.

Se pensi che la tabella possa diventare molto più popolata di ora ti conviene pensare qualche altra soluzione, altrimenti 37 secondi penso possano essere accettabili.

@Thedarkita said:

[...]

No, non sarà popolata oltre.
Si lavora di update e non di insert.

In effetti implemento solo la parte del controllo durante la scrittura nel database (eventualmente effettuo un session_destroy se il server deve essere off) e per sabato sono a posto (si parte sabato con l'uso)

Ciao, grazie per l'interessamento

Enzo

Figurati.