Migrering af MySQL-database fra Amazon RDS til DigitalOcean

I tidligere blogs (del 1 og del 2) diskuterede vi, hvordan du migrerer dine RDS-data til en EC2-instans. I processen lykkedes det os at flytte vores data ud af RDS, men vi kører stadig på AWS. Hvis du gerne vil flytte dine data helt ud af Amazon Web Services, er der lidt mere arbejde at gøre. I dagens blogindlæg viser vi dig, hvordan det kan gøres.

Introduktion til miljø

Det miljø, vi kommer til at arbejde med, er ret lig det, vi endte med på vores sidste indlæg i serien. Den eneste forskel er, at der ikke skete nogen cutover, da vi vil bruge EC2-instansen som et mellemtrin i processen med at flytte ud af AWS.

Handlingsplanen

I den forrige blog migrerede vi først vores data fra RDS til en EC2-instans, som vi har fuld adgang til. Da vi allerede har MySQL kørende på vores EC2-instans, har vi flere muligheder at vælge imellem med hensyn til, hvordan vi kopierer vores data til en anden sky. DigitalOcean bruges kun til demoformål her, den proces, vi beskriver nedenfor, kan bruges til at migrere til enhver anden hosting- eller cloududbyder. Du skal have direkte adgang til VPS-instanserne. I denne proces vil vi bruge xtrabackup til at kopiere dataene (selvom det er helt fint at bruge enhver anden metode til binær overførsel). Vi bliver nødt til at forberede en sikker forbindelse mellem AWS og DigitalOcean. Når vi har gjort det, opsætter vi replikering fra EC2-instansen til en DigitalOcean-dråbe. Det næste trin ville være at udføre en cutover og flytte applikationer, men vi vil ikke dække det her.

Beslutning om forbindelsesmetode

Amazon Web Services giver dig mulighed for at vælge mellem mange forskellige måder at oprette forbindelse til eksterne netværk på. Hvis du har en hardwareenhed, der understøtter VPN-forbindelser, kan du bruge den til at danne en VPN-forbindelse mellem din VPC i AWS og din lokale infrastruktur. Hvis din netværksudbyder tilbyder dig en peering-forbindelse med AWS-netværket, og du har en BGP-router, kan du få en direkte VLAN-forbindelse mellem dit netværk og AWS via AWS Direct Connect. Hvis du har flere, isolerede netværk, kan du linke dem sammen med Amazon ved at bruge AWS VPN CloudHub. Endelig, da EC2-instanser er dine at administrere, kan du lige så godt konfigurere en VPN mellem den EC2-instans og dit lokale netværk ved hjælp af softwareløsninger som OpenVPN.

Da vi taler om databaser, kan du også beslutte at opsætte SSL-replikering mellem MySQL på EC2 (masteren) og slaven, der kører på DigitalOcean. - Vi mangler stadig at finde ud af, hvordan vi laver en indledende dataoverførsel til slaven - en løsning kunne være at tjære outputtet af xtrabackup, kryptere den fil og enten sende den via WAN (rsync) eller uploade til S3 bucket og derefter downloade den derfra. Du kan også stole på SSH-kryptering og bare scp (eller endda rsync, ved hjælp af SSH) dataene til den nye placering.

Der er mange muligheder at vælge imellem. Vi vil dog bruge en anden løsning - vi vil etablere en SSH-tunnel mellem EC2-instansen og vores DigitalOcean-dråbe for at danne en sikker kanal, som vi vil bruge til at replikere data. Den første overførsel vil blive foretaget ved hjælp af rsync over SSH-forbindelsen.

Kopiering af data til DigitalOcean

Når vi har MySQL 5.7 oppe og køre på DigitalOcean-instansen, skal vi udføre en backup af EC2-instansen og derefter overføre den til DO. Teknisk set burde det være muligt at udføre en direkte streaming af xtrabackup-data mellem noderne, men vi kan ikke rigtig anbefale det. WAN-links kan være upålidelige, og det ville være bedre at tage en sikkerhedskopi lokalt og derefter bruge rsync med dets evne til at prøve overførslen igen, når noget er galt.

Lad os først tage en sikkerhedskopi af vores EC2-instans:

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

Når den er klar, skal vi overføre den til DigitalOcean-netværket. For at gøre det på en sikker måde, vil vi oprette en ny bruger på DO-dråben, generere en SSH-nøgle og bruge denne bruger til at kopiere dataene. Selvfølgelig kan du lige så godt bruge enhver af eksisterende brugere, det er ikke nødvendigt at oprette en ny. Så lad os tilføje en ny bruger. Der er mange måder at gøre dette på, vi bruger 'adduser'-kommandoen.

[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

Nu er det tid til at generere et par ssh-nøgler til brug for tilslutning:

[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          |
|   .   .         |
|                 |
+-----------------+

Når vi har SSH-nøglen, skal vi konfigurere den på vores Digital Ocean-dråbe. Vi skal oprette en .ssh-mappe og oprette en authorized_keys-fil med de rigtige adgangstilladelser.

[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

Derefter skal vi kopiere vores private nøgle til EC2-instansen. Når vi er klar med det, kan vi kopiere vores data. Som vi nævnte tidligere, vil vi bruge rsync til det - det vil lade os genstarte overførslen, hvis processen af ​​en eller anden grund bliver afbrudt. Kombineret med SSH har vi skabt en sikker og robust metode til at kopiere data over WAN. Lad os starte rsync på EC2-værten:

[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

Efter et stykke tid, hvilket vil afhænge af mængden af ​​data og overførselshastighed, skulle vores backupdata blive tilgængelige på DigitalOcean-dråben. Dette betyder, at det er tid til at forberede det ved at anvende InnoDB-redo-logfiler og derefter kopiere det tilbage til MySQL-databiblioteket. Til det er vi nødt til at stoppe MySQL, fjerne den aktuelle datamappe, kopiere filerne tilbage ved hjælp af enten innobackupex eller manuelt, og  til sidst bekræfte, at ejer og gruppe for nye filer er indstillet til 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

Før vi starter MySQL, skal vi også sikre, at både server_id og UUID er forskellige. Førstnævnte kan redigeres i my.cnf, sidstnævnte kan sikres ved:

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

Nu kan vi starte MySQL:

[email protected]:~# service mysql start

Opsætning af replikering

Vi er klar til at konfigurere replikering mellem EC2 og DO, men først skal vi konfigurere en ssh-tunnel - vi opretter en ekstra ssh-nøgle til ubuntu-brugeren på EC2-instansen og kopierer den til DO-instansen. Så vil vi bruge ubuntu-brugeren til at oprette en tunnel, som vi vil bruge til replikeringen.

Lad os starte med at oprette den nye ssh-nøgle:

[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|
|             . . |
|                 |
|                 |
|                 |
+-----------------+

Næste trin - vi skal tilføje vores offentlige nøgle til filen authorized_keys på EC2-instansen, som vi vil oprette forbindelse til fra DigitalOcean for at skabe en tunnel.

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

Vi har også brug for en privat nøgle, der skal overføres til DO-dråben. Det kan gøres på mange måder, men vi bruger sikker scp ved hjælp af rdscopy-bruger og nøgle, som vi oprettede tidligere:

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

Det er alt, hvad vi har brug for - nu kan vi skabe SSH-tunnelen. Vi ønsker, at det skal være tilgængeligt hele tiden, så vi vil bruge skærmsession til det.

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

Det, vi gjorde her, var at åbne en SSH-tunnel mellem localhost, port 3307 og fjernvært, 54.224.107.6, port 3306 ved hjælp af "ubuntu"-bruger og en nøgle placeret i /home/rdscopy/id_rsa_tunnel. Frakobl skærmsessionen, og fjernværten skulle være tilgængelig via 127.0.0.1:3307.

For at konfigurere replikering skal vi stadig tilføje n bruger, som vi vil bruge til at oprette forbindelse til MySQL på EC2. Vi vil oprette det på EC2-værten, og vi bruger '127.0.0.1' som vært - forbindelser via SSH-tunnel vil se ud som om de kommer fra 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)

Alt er klar til at konfigurere replikering, det er nu tid til at følge en traditionel proces med at skabe en slave baseret på xtrabackup-data. Vi skal bruge data fra xtrabackup_binlog_info til at identificere masterpositionen på tidspunktet for sikkerhedskopieringen. Denne position vil vi bruge i vores CHANGE MASTER TO … kommando. Lad os tage et kig på indholdet af xtrabackup_binlog_info-filen:

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

Dette er den binære logfil og position, vi vil bruge i vores 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;

Dette er det - replikering skulle nu være oppe at køre, og vores DigitalOcean-slave burde indhente replikationen. Når den har indhentet, er vores database-tier klar til omstilling. Selvfølgelig er det normalt mere end blot en enkelt node - du skal højst sandsynligt konfigurere flere slaver på DO, før infrastrukturen er klar til at håndtere produktionstrafik.

Selve overgangen er et andet emne - du bliver nødt til at udarbejde en plan for at minimere nedetiden. Generelt bør trafik flyttes fra gammelt til nyt sted, men hvordan det skal gøres afhænger mest af dit miljø. Det kan være alt fra en simpel ændring i DNS-indtastning til komplekse scripts, som vil trække alle triggere i en korrekt rækkefølge for at omdirigere trafikken. Uanset hvad, er din database nu allerede på den nye placering, klar til at betjene anmodninger.