- Home
- Categorie
- Coding e Sistemistica
- PHP
- php - session - forzare una chiusura
-
php - session - forzare una chiusura
Ciao a tutti
Una domanda: è possibile terminare tutte le sessioni aperte su di un server WEB tramite php?
Mi spiego meglio con l'esposizione del problema reale:
Ho 2 server, un primario ed un backup, le scritture che effettuo sulle tabelle di un database MySQL presenti sul primario vengono replicate (tramite codice php) anche sul backup.
Se il primario cade viene attivato l'accesso al backup e il lavoro prosegue su questo server.
Se il primario torna in piedi (o viene ripristinato) e volessi far tornare tutti a lavorare sul primario dovrei (prima di far partire l'allineamento delle tabelle) scollegare tutti i client loggati sul server di backup.Tutto viene gestito tramite html/php, login, scritture di backup, allineamenti, controlli, tutto con codice php.
Le sessioni vengono gestite ovviamente con php e session_XXX
Ho la possibilità, con un comando o altro, ti terminare tutte le sessioni create dai client?
Esiste un session_destroy_ALL() ad esempio
da lanciare sul server web?Spero di essermi spiegato in modo decente.
Grazie a tutti
-
Ciao texv,
premettendo che forse sarebbe stato meglio gestire la cosa diversamente piuttosto che con php per tenere i server sincronizzati.
Con le sessioni native di php non mi risulta sia possibile farlo direttamente.
L'alternativa migliore dovrebbe essere gestire le sessioni su una tabella del database, ed in quel caso saresti in grado di fare ciò che hai indicato molto facilmente.
-
@Thedarkita said:
Ciao texv,
premettendo che forse sarebbe stato meglio gestire la cosa diversamente piuttosto che con php per tenere i server sincronizzati.
Con le sessioni native di php non mi risulta sia possibile farlo direttamente.
L'alternativa migliore dovrebbe essere gestire le sessioni su una tabella del database, ed in quel caso saresti in grado di fare ciò che hai indicato molto facilmente.Ciao
Eccola li.... l'ideuccia
quella di gestire le sessioni in modo autonomo senza usare le session è in effetti un bella idea, non percorribile in questo momento dato che l'uso della procedura è imminente ed è meglio non provare nuove funzionalità adesso.... ma in effetti..... Non ho voluto usare la funzionalità Master/client (è corretto?) del MySQL dato che voglio avere un controllo, per così dire, "estremo" sulle tabelle: ho letto che non è conveniente (e sconsigliato) creare 2 database Master/Master, almeno non sul MySQL standard;
devo comunque gestire il ripristino del server principale e sarebbe scomodo effettuare dei settaggi al volo, inoltre non sarò sempre presente ed è sempre meglio far fare dei "click" con il mouse su funzioni già testate e stra-testate.
Qualche idea da suggerire anche su questo lato???Grazie
-
Se proprio vuoi usare le sessioni, imposti una variabile che ti indica un qualcosa, e al successivo accesso dell'utente in caso usi session_destroy, potresti fare anche una pagina e gestirti con dei click la cosa volendo, non rimane sicuramente una via pulita e personalmente non userei, ma dipende dal progetto che stai sviluppando se è necessario aggire cosi.
Perchè non puoi usare un master ed uno slave? Che tipo di controllo sulle tabelle dovresti fare?
Anche perchè se il server 1 per qualsiasi ragione va offline poi come lo risincronizi? Sicuramente non riesci a risincronizzarlo con php.
-
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.