[Linuxtrent] Re: RISOLTO: OT: Spostare fisicamente database MySql
- From: "Roberto A. Foglietta" <roberto.foglietta@xxxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Sun, 19 Jan 2014 22:42:09 +0100
Il 19/gen/2014 19:33 "Matteo Ragni" <nirvana1289@xxxxxxxxx> ha scritto:
>>
>> Giusto per fare i precisini-ini-ini perchè in pratica sappiamo tutti e
tre che quello di Matteo non è il modo con cui si opera ma probabilmente è
dettato dal solo fatto che nuovo e vecchio server sono lo stesso a meno di
hd/usb.
>
>
> Ovvero come bisognerebbe fare? (mi preparo alla 5 versione)
>
Installi il server da zero e trasferisci i servizi senza fare nessun dump
delle partizioni. Dipende ovviamente da quanti e quali servizi hai a bordo
e per il mysql io ho usato i due link che ho inviato.
Anche perché ci sono casi in cui il dump delle partizioni non é una pratica
ragionevole (macchine fisicamente non raggiungibili). In genere per clonare
un server usi la lista dei pacchetti e le configurazioni in /etc a parte
quelle di rete e rsa/ca specifiche dell'altro server. Poi seguono le parti
proprietarie, dati a cominciare da quelli che cambiano solo per dev/sysop
deployment e poi db. Ma é una regola del pollice e le eccezioni ci sono.
Appena un servizio funziona con dati aggiornati fai la direzione del front
end su quello invece che sul vecchio. Ad esempio il web funziona ma usa il
db del server precedente (salvo casi in cui per questione di prestazioni il
db e app devono comunicare via IPC).
Un servizio alla volta migri oppure ci fai un cluster di due server. Ma non
é sempre ragionevole fare cluster per migrare infatti anche nelle
farm/cluster con molti server le persistenze le gestiscono a livello di
load balancing e non di cluster. Anzi direi che per come si fanno oggi le
applicazione la HA non é salvare la sessione: se un server cade gli utenti
che si erano collegati a quello dovranno riautenticarsi, il cestino della
spesa si può salvare nei cookie non con il session-id solamente ma anche
una lista di codici merceologici di backup in caso di sessione persa. Ma
questi sono dettagli ma giusto per dire che anche per come funziona
un'applicazione si fa la migrazione:perdere il cestino é grave mentre la
riautenticazione é tollerata.
In realtà a parte aggiungere un server in una farm la migrazione richiede
sempre un stop temporaneo del servizio, il bello é trovare il modo di
ridurlo al minimo accettabile senza trovarsi con due db disallineati ma
entrambi in production, per esempio.
Nel tuo caso direi (fatta la debita preparazione) un mysqldump con opzione
transazione pipe ssh mysql sull'altro server; mysql stop sul primo;
application config reload per istruirla a usare il db sul nuovo server. Poi
migri l'applicazione (che potrebbe essere anche solo applicazione stop sul
primo; ssh applicazione start sul secondo).
Tutto quanto salvo errori, omissioni e tastiera android del mobile
permettendo. Così se ho scritto una boiata e non rileggo poi
responsabilizzo il T9 e Lele si imbestialisce come un lupo mannaro ;-)
Other related posts:
