Migrazione del database MySQL da Amazon RDS a DigitalOcean

Nei blog precedenti (parte 1 e parte 2), abbiamo discusso di come migrare i dati RDS in un'istanza EC2. Nel processo, siamo riusciti a spostare i nostri dati fuori da RDS, ma stiamo ancora girando su AWS. Se desideri spostare completamente i tuoi dati da Amazon Web Services, c'è ancora un po' di lavoro da fare. Nel post del blog di oggi, ti mostreremo come farlo.

Introduzione all'ambiente

L'ambiente con cui lavoreremo è abbastanza simile a quello con cui siamo finiti nel nostro ultimo post della serie. L'unica differenza è che non si è verificato alcun cutover, poiché utilizzeremo l'istanza EC2 come passaggio intermedio nel processo di uscita da AWS.

Il piano d'azione

Nel blog precedente, abbiamo prima migrato i nostri dati da RDS a un'istanza EC2 a cui abbiamo pieno accesso. Poiché abbiamo già MySQL in esecuzione sulla nostra istanza EC2, abbiamo più opzioni tra cui scegliere su come copiare i nostri dati su un altro cloud. DigitalOcean viene utilizzato solo a scopo dimostrativo qui, il processo che descriviamo di seguito può essere utilizzato per migrare a qualsiasi altro provider di hosting o cloud. Avresti bisogno dell'accesso diretto alle istanze VPS. In questo processo, utilizzeremo xtrabackup per copiare i dati (sebbene sia perfettamente corretto utilizzare qualsiasi altro metodo di trasferimento binario). Avremmo bisogno di preparare una connessione sicura tra AWS e DigitalOcean. Una volta fatto, configureremo la replica dall'istanza EC2 in una gocciolina DigitalOcean. Il passaggio successivo sarebbe eseguire un cutover e spostare le applicazioni, ma non lo tratteremo qui.

Decidere il metodo di connettività

Amazon Web Services ti consente di scegliere tra molti modi diversi per creare una connessione a reti esterne. Se disponi di un'appliance hardware che supporta le connessioni VPN, puoi utilizzarla per creare una connessione VPN tra il tuo VPC in AWS e la tua infrastruttura locale. Se il tuo provider di rete ti offre una connessione peering con la rete AWS e disponi di un router BGP, puoi ottenere una connessione VLAN diretta tra la tua rete e AWS tramite AWS Direct Connect. Se disponi di più reti isolate, puoi collegarle insieme ad Amazon utilizzando AWS VPN CloudHub. Infine, poiché le istanze EC2 sono tue da gestire, puoi anche configurare una VPN tra quell'istanza EC2 e la tua rete locale utilizzando soluzioni software come OpenVPN.

Trattandosi di database, puoi anche decidere di impostare la replica SSL tra MySQL su EC2 (il master) e lo slave in esecuzione su DigitalOcean. - Dobbiamo ancora capire come eseguire un trasferimento dati iniziale allo slave:una soluzione potrebbe essere quella di tarre l'output di xtrabackup, crittografare quel file e inviarlo tramite WAN (rsync) o caricarlo nel bucket S3 e quindi scaricarlo da li. Potresti anche fare affidamento sulla crittografia SSH e semplicemente scp (o anche rsync, usando SSH) i dati nella nuova posizione.

Ci sono molte opzioni tra cui scegliere. Utilizzeremo però un'altra soluzione:stabiliremo un tunnel SSH tra l'istanza EC2 e il nostro droplet DigitalOcean per formare un canale sicuro che utilizzeremo per replicare i dati. Il trasferimento iniziale verrà effettuato utilizzando rsync sulla connessione SSH.

Copiare dati su DigitalOcean

Una volta che MySQL 5.7 è attivo e funzionante sull'istanza DigitalOcean, è necessario eseguire un backup dell'istanza EC2 e quindi trasferirlo in DO. Tecnicamente, dovrebbe essere possibile eseguire uno streaming diretto di dati di xtrabackup tra i nodi, ma non possiamo davvero consigliarlo. I collegamenti WAN possono essere inaffidabili e sarebbe meglio eseguire un backup in locale e quindi utilizzare rsync con la sua capacità di riprovare il trasferimento ogni volta che qualcosa non va.

Innanzitutto, eseguiamo un backup sulla nostra istanza EC2:

[email protected]:~# innobackupex --user=tpcc --password=tpccpass /tmp/backup

Una volta pronto, dobbiamo trasferirlo sulla rete DigitalOcean. Per farlo in modo sicuro, creeremo un nuovo utente sul droplet DO, genereremo una chiave SSH e useremo questo utente per copiare i dati. Naturalmente, puoi anche utilizzare uno qualsiasi degli utenti esistenti, non è necessario crearne uno nuovo. Quindi, aggiungiamo un nuovo utente. Ci sono molti modi per farlo, useremo il comando 'adduser'.

[email protected]:~# adduser rdscopy
Adding user `rdscopy' ...
Adding new group `rdscopy' (1001) ...
Adding new user `rdscopy' (1001) with group `rdscopy' ...
Creating home directory `/home/rdscopy' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for rdscopy
Enter the new value, or press ENTER for the default
    Full Name []:
    Room Number []:
    Work Phone []:
    Home Phone []:
    Other []:
Is the information correct? [Y/n] y

Ora è il momento di generare una coppia di chiavi ssh da utilizzare per la connettività:

[email protected]:~# ssh-keygen -C 'rdscopy' -f id_rsa_rdscopy -t rsa -b 4096
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa_rdscopy.
Your public key has been saved in id_rsa_rdscopy.pub.
The key fingerprint is:
3a:b0:d2:80:5b:b8:60:1b:17:58:bd:8e:74:c9:56:b3 rdscopy
The key's randomart image is:
+--[ RSA 4096]----+
|   ..            |
|  o  . o         |
| . .. + o        |
| o ..* E         |
|+o+.*   S        |
|o+++ + .         |
|o.. o o          |
|   .   .         |
|                 |
+-----------------+

Avendo la chiave SSH, dobbiamo configurarla sulla nostra gocciolina Digital Ocean. Dobbiamo creare una directory .ssh e creare un file authorized_keys con i permessi di accesso appropriati.

[email protected]:~# mkdir /home/rdscopy/.ssh
[email protected]:~# cat id_rsa_rdscopy.pub > /home/rdscopy/.ssh/authorized_keys
[email protected]:~# chown rdscopy.rdscopy /home/rdscopy/.ssh/authorized_keys
[email protected]:~# chmod 600 /home/rdscopy/.ssh/authorized_keys

Quindi, dobbiamo copiare la nostra chiave privata nell'istanza EC2. Quando siamo pronti, possiamo copiare i nostri dati. Come accennato in precedenza, utilizzeremo rsync per questo:ci consentirà di riavviare il trasferimento se, per qualsiasi motivo, il processo viene interrotto. In combinazione con SSH, abbiamo creato un metodo sicuro e robusto per copiare i dati su WAN. Iniziamo la rsync sull'host EC2:

[email protected]:~# rsync -avz -e "ssh -i id_rsa_rdscopy -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" --progress /tmp/backup/2017-02-20_16-34-18/ [email protected]:/home/rdscopy

Dopo un po', che dipenderà dalla quantità di dati e dalla velocità di trasferimento, i nostri dati di backup dovrebbero essere disponibili sul droplet di DigitalOcean. Ciò significa che è ora di prepararlo applicando i registri di ripristino di InnoDB e quindi copiandolo di nuovo nella directory dei dati di MySQL. Per questo dobbiamo fermare MySQL, rimuovere la directory dei dati corrente, copiare nuovamente i file usando innobackupex o manualmente e  infine, verificare che il proprietario e il gruppo per i nuovi file siano impostati su mysql:

[email protected]:~# innobackupex --apply-log /home/rdscopy/
[email protected]:~# service mysql stop
[email protected]:~# rm -rf /var/lib/mysql/*
[email protected]:~# innobackupex --copy-back /home/rdscopy/
[email protected]:~# chown -R mysql.mysql /var/lib/mysql

Prima di avviare MySQL, dobbiamo anche assicurarci che sia server_id che UUID siano diversi. Il primo può essere modificato in my.cnf, il secondo può essere assicurato da:

[email protected]:~# rm /var/lib/mysql/auto.cnf

Ora possiamo avviare MySQL:

[email protected]:~# service mysql start

Configurazione della replica

Siamo pronti per configurare la replica tra EC2 e DO, ma prima dobbiamo configurare un tunnel ssh:creeremo una chiave ssh aggiuntiva per l'utente Ubuntu sull'istanza EC2 e la copieremo nell'istanza DO. Quindi utilizzeremo l'utente Ubuntu per creare un tunnel che utilizzeremo per la replica.

Iniziamo creando la nuova chiave ssh:

[email protected]:~# ssh-keygen -C 'tunnel' -f id_rsa_tunnel -t rsa -b 4096
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa_tunnel.
Your public key has been saved in id_rsa_tunnel.pub.
The key fingerprint is:
c4:44:79:39:9c:c6:ce:45:bb:13:e5:6f:c5:d9:8c:14 tunnel
The key's randomart image is:
+--[ RSA 4096]----+
|       .o+ +. E. |
|       o. O .= +o|
|        o= oo o.=|
|       .  o  o ..|
|        S   o   o|
|             . . |
|                 |
|                 |
|                 |
+-----------------+

Passaggio successivo:dobbiamo aggiungere la nostra chiave pubblica al file authorized_keys sull'istanza EC2, a cui ci collegheremo da DigitalOcean per creare un tunnel.

[email protected]:~# cat id_rsa_tunnel.pub >> /home/ubuntu/.ssh/authorized_keys

Abbiamo anche bisogno di una chiave privata da trasferire al droplet DO. Può essere fatto in molti modi, ma useremo secure scp usando l'utente e la chiave rdscopy che abbiamo creato in precedenza:

[email protected]:~# scp -i id_rsa_rdscopy id_rsa_tunnel [email protected]:/home/rdscopy
id_rsa_tunnel                                                                                                                                                                    100% 3247     3.2KB/s   00:00

Questo è tutto ciò di cui abbiamo bisogno:ora possiamo creare il tunnel SSH. Vogliamo che sia sempre disponibile, quindi utilizzeremo la sessione dello schermo per questo.

[email protected]:~# screen -S tunnel
[email protected]:~# ssh -L 3307:localhost:3306 [email protected] -i /home/rdscopy/id_rsa_tunnel

Quello che abbiamo fatto qui è stato aprire un tunnel SSH tra localhost, porta 3307 e host remoto, 54.224.107.6, porta 3306 usando l'utente "ubuntu" e una chiave situata in /home/rdscopy/id_rsa_tunnel. Stacca la sessione dello schermo e l'host remoto dovrebbe essere disponibile tramite 127.0.0.1:3307.

Per configurare la replica, dobbiamo ancora aggiungere n utente che useremo per connetterci a MySQL su EC2. Lo creeremo sull'host EC2 e useremo "127.0.0.1" come host - le connessioni tramite tunnel SSH sembreranno provenire da localhost:

mysql> CREATE USER [email protected] IDENTIFIED BY 'rds_rpl_pass';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO [email protected];
Query OK, 0 rows affected (0.00 sec)

Tutto è pronto per configurare la replica, ora è il momento di seguire un processo tradizionale di creazione di uno slave basato sui dati di xtrabackup. Dobbiamo utilizzare i dati di xtrabackup_binlog_info per identificare la posizione principale al momento del backup. Questa posizione è ciò che vogliamo usare nel nostro comando CAMBIA MASTER TO …. Diamo un'occhiata al contenuto del file xtrabackup_binlog_info:

[email protected]:~# cat /home/rdscopy/xtrabackup_binlog_info
binlog.000052    896957365

Questo è il file di log binario e la posizione che useremo nel nostro CHANGE MASTER TO:

[email protected]:~# mysql -u root -ppass

mysql> CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_PORT=3307, MASTER_USER='rds_rpl', MASTER_PASSWORD='rds_rpl_pass', MASTER_LOG_FILE='binlog.000052', MASTER_LOG_POS=896957365; START SLAVE;

Questo è tutto:la replica dovrebbe essere ora attiva e funzionante e il nostro slave DigitalOcean dovrebbe recuperare il ritardo sulla replica. Una volta raggiunto, il nostro livello di database è pronto per il passaggio. Naturalmente, di solito è più di un singolo nodo:molto probabilmente dovrai configurare più slave su DO prima che l'infrastruttura sia pronta per gestire il traffico di produzione.

Il passaggio stesso è un argomento diverso:dovrai escogitare un piano per ridurre al minimo i tempi di inattività. In generale, il traffico dovrebbe essere spostato dalla vecchia posizione alla nuova posizione, ma il modo in cui dovrebbe essere eseguito dipende principalmente dall'ambiente. Può essere qualsiasi cosa, da una semplice modifica nella voce DNS, a script complessi che tireranno tutti i trigger nell'ordine corretto per reindirizzare il traffico. In ogni caso, il tuo database ora è già nella nuova posizione, pronto a soddisfare le richieste.