La migrazione del database a un nuovo data center può essere un processo ad alto rischio e dispendioso in termini di tempo. Un database contiene lo stato e può essere molto più difficile da migrare rispetto a server Web, code o server cache.
In questo post del blog, ti forniremo alcuni suggerimenti su come migrare i tuoi dati da un fornitore di servizi a un altro. Il processo è in qualche modo simile al nostro precedente post su come aggiornare MySQL, ma ci sono un paio di differenze importanti.
Replica MySQL o Cluster Galera?
Passare a un altro fornitore di servizi (ad es., passare da AWS a Rackspace o da server in colocation al cloud) molto spesso significa costruire un'infrastruttura nuova di zecca in parallelo, sincronizzarla con la vecchia infrastruttura e quindi passare ad essa. Per connetterli e sincronizzarli, potresti voler sfruttare la replica MySQL.
Se stai utilizzando Galera Cluster, potrebbe essere più semplice spostare i tuoi nodi Galera in un data center diverso. Tuttavia, si noti che l'intero cluster deve ancora essere trattato come un unico database. Ciò significa che il tuo sito di produzione potrebbe soffrire della latenza aggiuntiva introdotta durante l'estensione di Galera Cluster sulla WAN. È possibile ridurre al minimo l'impatto ottimizzando le impostazioni di rete sia in Galera che nel sistema operativo, ma l'impatto non può essere completamente eliminato. È anche possibile impostare invece la replica asincrona MySQL tra il vecchio e il nuovo cluster, se l'impatto sulla latenza non è accettabile.
Configurazione di una connettività sicura
MySQL Replication non è crittografato e quindi non è sicuro da usare sulla WAN. Esistono numerosi modi per garantire che i tuoi dati vengano trasferiti in modo sicuro. Dovresti indagare se è possibile stabilire una connessione VPN tra la tua infrastruttura attuale e il tuo nuovo fornitore di servizi. La maggior parte dei provider (ad esempio sia Rackspace che AWS) fornisce tale servizio:puoi connettere la tua parte "nuvolosa" al tuo data center esistente tramite una rete privata virtuale.
Se, per qualche motivo, questa soluzione non funziona per te (forse richiede hardware a cui non hai accesso), puoi utilizzare il software per creare una VPN:una di queste sarà OpenVPN. Questo strumento funzionerà bene per configurare connessioni crittografate tra i tuoi data center.
Se OpenVPN non è un'opzione, ci sono più modi per garantire che la replica venga crittografata. Ad esempio, puoi utilizzare SSH per creare un tunnel tra datacenter vecchi e nuovi e inoltrare la porta 3306 dall'attuale slave (o master) MySQL al nuovo nodo. Può essere fatto in un modo molto semplice purché tu abbia la connettività SSH tra gli host:
$ ssh -L local_port:old_dc_host:mysql_port_in_old_dc [email protected]_dc_host -N &Ad esempio:
$ ssh -L 3307:10.0.0.201:3306 [email protected] -N &Ora puoi connetterti al server remoto utilizzando 127.0.0.1:3307
$ mysql -P3307 -h 127.0.0.1Funzionerà in modo simile per la replica, ricorda solo di usare 127.0.0.1 per master_host e 3307 per master_port
Ultimo ma non meno importante, puoi crittografare la tua replica utilizzando SSL. Questo post del blog precedente spiega come può essere fatto e che tipo di impatto potrebbe avere sulle prestazioni di replica.
Se hai deciso di utilizzare la replica Galera su entrambi i data center, i suggerimenti precedenti si applicano anche qui. Quando si tratta di SSL, in precedenza abbiamo scritto sul blog come crittografare il traffico di replica di Galera. Per una soluzione più completa, potresti voler crittografare tutte le connessioni al database dalle applicazioni client e da qualsiasi infrastruttura di gestione/monitoraggio.
Impostazione della nuova infrastruttura
Una volta ottenuta la connettività, è necessario iniziare a costruire la nuova infrastruttura. Per questo, probabilmente utilizzerai xtrabackup o mariabackup. Potrebbe essere allettante combinare la migrazione con l'aggiornamento di MySQL, dopotutto si sta configurando un ambiente completamente nuovo nella nuova posizione. Non consigliamo di farlo. La migrazione a una nuova infrastruttura è di per sé abbastanza significativa, quindi combinarla con un altro cambiamento importante aumenta la complessità e il rischio. Questo vale anche per altre cose:vuoi adottare un approccio graduale ai cambiamenti. Solo modificando le cose una alla volta puoi comprendere i risultati delle modifiche e in che modo influiscono sul tuo carico di lavoro:se hai apportato più di una modifica alla volta, non puoi essere sicuro di quale sia responsabile di un determinato (nuovo ) comportamento che hai osservato.
Quando hai una nuova istanza MySQL attiva e funzionante nel nuovo datacenter, devi disattivarla dal nodo nel vecchio datacenter, per assicurarti che i dati in entrambi i datacenter rimangano sincronizzati. Questo diventerà utile mentre ti prepari per il cutover finale. È anche un bel modo per garantire che il nuovo ambiente possa gestire il carico di scrittura.
Il prossimo passo sarà costruire un'infrastruttura di staging completa nella nuova posizione ed eseguire test e benchmark. Questo è un passaggio molto importante che non dovrebbe essere saltato:il problema qui è che tu, come DBA, devi comprendere la capacità della tua infrastruttura. Quando cambi provider, cambiano anche le cose. I nuovi hardware/VM sono più veloci o più lenti. C'è più o meno memoria per istanza. È necessario comprendere di nuovo come si adatterà il carico di lavoro all'hardware che si intende utilizzare. Per questo probabilmente utilizzerai Percona Playback o pt-log-player per riprodurre alcune delle query della vita reale sul sistema di staging. Ti consigliamo di testare le prestazioni e assicurarti che siano a un livello accettabile per te. Vuoi anche eseguire tutti i test di accettazione standard che esegui sulle tue nuove versioni, solo per confermare che tutto sia attivo e funzionante. In generale, tutte le applicazioni dovrebbero essere costruite in modo da non basarsi sulla configurazione hardware e su una configurazione corrente. Ma qualcosa potrebbe essere sfuggito e la tua app potrebbe dipendere da alcune modifiche alla configurazione o soluzioni hardware che non hai nel nuovo ambiente.
Infine, una volta che sei soddisfatto dei tuoi test, ti consigliamo di creare un'infrastruttura pronta per la produzione. Al termine, potresti voler eseguire alcuni test di sola lettura per la verifica finale. Questo sarebbe l'ultimo passaggio prima del cutover.
Ritaglio
Dopo che tutti questi test sono stati eseguiti e dopo che l'infrastruttura è stata considerata pronta per la produzione, l'ultimo passaggio consiste nel tagliare il traffico dalla vecchia infrastruttura.
A livello globale, questo è un processo complesso, ma quando osserviamo il livello di database, è più o meno la stessa cosa del failover standard, cosa che potresti aver fatto più volte in passato. Ne abbiamo parlato in dettaglio in un post precedente, in breve i passaggi sono:fermare il traffico, assicurarsi che sia interrotto, attendere mentre l'applicazione viene spostata nel nuovo datacenter (modifica dei record DNS o altro), eseguire alcuni test di fumo per assicurarsi tutto sembra a posto, vai in diretta, monitora attentamente per un po'.
Questo cutover richiederà dei tempi di inattività, come possiamo vedere. Il problema è assicurarsi di avere uno stato coerente nel vecchio sito e in quello nuovo. Se vogliamo farlo senza tempi di inattività, allora dovremmo impostare la replica master-master. Il motivo è che quando aggiorniamo il DNS e spostiamo le sessioni dal vecchio sito a quello nuovo, entrambi i sistemi saranno in uso contemporaneamente, fino a quando tutte le sessioni non verranno reindirizzate al nuovo sito. Nel frattempo, tutte le modifiche apportate al nuovo sito devono riflettersi sul vecchio sito.
L'utilizzo di Galera Cluster, come descritto in questo post del blog, può anche essere un modo per mantenere sincronizzati i dati tra i due siti.
Siamo consapevoli che questa è una descrizione molto breve del processo di migrazione dei dati. Si spera che sia sufficiente per indicarti una buona direzione e aiutarti a identificare quali informazioni aggiuntive devi cercare.
