Migrera MySQL-databas från Amazon RDS till DigitalOcean

I tidigare bloggar (del 1 och del 2) diskuterade vi hur du migrerar dina RDS-data till en EC2-instans. Under processen lyckades vi flytta våra data från RDS, men vi kör fortfarande på AWS. Om du vill flytta dina data helt från Amazon Web Services finns det lite mer arbete att göra. I dagens blogginlägg kommer vi att visa dig hur det kan göras.

Miljöintroduktion

Miljön vi kommer att arbeta med är ganska lik den vi slutade med i vårt senaste inlägg i serien. Den enda skillnaden är att ingen cutover hände, eftersom vi kommer att använda EC2-instansen som ett mellansteg i processen att flytta ut från AWS.

Handlingsplanen

I den förra bloggen migrerade vi först vår data från RDS till en EC2-instans som vi har full tillgång till. Eftersom vi redan har MySQL igång på vår EC2-instans har vi fler alternativ att välja mellan när det gäller hur vi kopierar vår data till ett annat moln. DigitalOcean används endast för demo-ändamål här, processen vi beskriver nedan kan användas för att migrera till vilken annan värd- eller molnleverantör som helst. Du skulle behöva direktåtkomst till VPS-instanserna. I den här processen kommer vi att använda xtrabackup för att kopiera data (även om det är helt okej att använda någon annan metod för binär överföring). Vi skulle behöva förbereda en säker anslutning mellan AWS och DigitalOcean. När vi gör det kommer vi att ställa in replikering från EC2-instansen till en DigitalOcean-droppe. Nästa steg skulle vara att utföra en cutover och flytta applikationer, men vi kommer inte att täcka det här.

Bestämma anslutningsmetod

Amazon Web Services låter dig välja mellan många olika sätt att skapa en anslutning till externa nätverk. Om du har en hårdvaruenhet som stöder VPN-anslutningar kan du använda den för att skapa en VPN-anslutning mellan din VPC i AWS och din lokala infrastruktur. Om din nätverksleverantör erbjuder dig en peering-anslutning med AWS-nätverket och du har en BGP-router, kan du få en direkt VLAN-anslutning mellan ditt nätverk och AWS via AWS Direct Connect. Om du har flera isolerade nätverk kan du länka dem till Amazon genom att använda AWS VPN CloudHub. Slutligen, eftersom EC2-instanser är dina att hantera, kan du lika väl konfigurera ett VPN mellan den EC2-instansen och ditt lokala nätverk med hjälp av mjukvarulösningar som OpenVPN.

Eftersom vi pratar databaser kan du också välja att ställa in SSL-replikering mellan MySQL på EC2 (mastern) och slaven som körs på DigitalOcean. - Vi måste fortfarande ta reda på hur vi gör en första dataöverföring till slaven - en lösning kan vara att tar utdata från xtrabackup, kryptera den filen och antingen skicka den via WAN (rsync) eller ladda upp till S3-bucket och sedan ladda ner den därifrån. Du kan också lita på SSH-kryptering och bara scp (eller till och med rsync, med SSH) data till den nya platsen.

Det finns många alternativ att välja mellan. Vi kommer dock att använda en annan lösning - vi kommer att etablera en SSH-tunnel mellan EC2-instansen och vår DigitalOcean-droppe för att bilda en säker kanal som vi kommer att använda för att replikera data. Initial överföring kommer att göras med rsync över SSH-anslutningen.

Kopiera data till DigitalOcean

När vi har MySQL 5.7 igång på DigitalOcean-instansen måste vi göra en säkerhetskopia av EC2-instansen och sedan överföra den till DO. Tekniskt sett borde det vara möjligt att utföra en direktströmning av xtrabackup-data mellan noderna men vi kan inte riktigt rekommendera det. WAN-länkar kan vara opålitliga, och det skulle vara bättre att ta en säkerhetskopia lokalt och sedan använda rsync med dess förmåga att försöka överföringen igen när något inte står rätt till.

Låt oss först ta en säkerhetskopia av vår EC2-instans:

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

När det är klart måste vi överföra det till DigitalOcean-nätverket. För att göra det på ett säkert sätt kommer vi att skapa en ny användare på DO-droppen, generera en SSH-nyckel och använda denna användare för att kopiera data. Naturligtvis kan du likaväl använda vilken som helst av befintliga användare, det är inte ett krav att skapa en ny. Så låt oss lägga till en ny användare. Det finns många sätt att göra detta, vi använder kommandot "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

Nu är det dags att generera ett par ssh-nycklar att använda för anslutning:

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

Med SSH-nyckeln måste vi ställa in den på vår Digital Ocean-droppe. Vi måste skapa .ssh-katalogen och skapa en auktoriserad_keys-fil med korrekt åtkomstbehörighet.

[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

Sedan måste vi kopiera vår privata nyckel till EC2-instansen. När vi är redo med det kan vi kopiera våra data. Som vi nämnde tidigare kommer vi att använda rsync för det - det låter oss starta om överföringen om processen av någon anledning avbryts. I kombination med SSH har vi skapat en säker och robust metod för att kopiera data över WAN. Låt oss börja rsync på EC2-värden:

[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 ett tag, vilket kommer att bero på mängden data och överföringshastighet, bör vår säkerhetskopieringsdata bli tillgänglig på DigitalOcean-droppen. Det betyder att det är dags att förbereda det genom att använda InnoDB redo loggar och sedan kopiera det tillbaka till MySQL-datakatalogen. För det måste vi stoppa MySQL, ta bort den aktuella datakatalogen, kopiera tillbaka filerna med antingen innobackupex eller manuellt, och slutligen verifiera att ägare och grupp för nya filer är inställda på 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

Innan vi startar MySQL måste vi också se till att både server_id och UUID är olika. Den förra kan redigeras i my.cnf, den senare kan garanteras av:

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

Nu kan vi starta MySQL:

[email protected]:~# service mysql start

Ställa in replikering

Vi är redo att ställa in replikering mellan EC2 och DO, men först måste vi konfigurera en ssh-tunnel - vi skapar en extra ssh-nyckel för ubuntu-användare på EC2-instansen och kopierar den till DO-instansen. Sedan kommer vi att använda ubuntu-användaren för att skapa en tunnel som vi kommer att använda för replikeringen.

Låt oss börja med att skapa den nya ssh-nyckeln:

[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ästa steg - vi måste lägga till vår publika nyckel till filen authorized_keys på EC2-instansen, till vilken vi kommer att ansluta från DigitalOcean för att skapa en tunnel.

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

Vi behöver också en privat nyckel för att överföras till DO-droppen. Det kan göras på många sätt, men vi använder säker scp med rdscopy-användaren och nyckeln som vi skapade tidigare:

[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 är allt vi behöver - nu kan vi skapa SSH-tunneln. Vi vill att det ska vara tillgängligt hela tiden så vi kommer att använda skärmsession för det.

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

Vad vi gjorde här var att öppna en SSH-tunnel mellan localhost, port 3307 och fjärrvärd, 54.224.107.6, port 3306 med hjälp av "ubuntu"-användare och en nyckel som finns i /home/rdscopy/id_rsa_tunnel. Koppla bort skärmsessionen och fjärrvärden bör vara tillgänglig via 127.0.0.1:3307.

För att ställa in replikering behöver vi fortfarande lägga till n användare som vi kommer att använda för att ansluta till MySQL på EC2. Vi kommer att skapa den på EC2-värden och vi kommer att använda '127.0.0.1' som värd - anslutningar via SSH-tunneln kommer att se ut som om de kommer från 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)

Allt är redo att ställa in replikering, nu är det dags att följa en traditionell process för att skapa en slav baserad på xtrabackup-data. Vi måste använda data från xtrabackup_binlog_info för att identifiera huvudpositionen vid tidpunkten för säkerhetskopieringen. Denna position är vad vi vill använda i vårt CHANGE MASTER TO … kommando. Låt oss ta en titt på innehållet i filen xtrabackup_binlog_info:

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

Det här är den binära loggfilen och positionen vi kommer att använda i vår 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;

Det här är det - replikeringen borde nu vara igång och vår DigitalOcean-slav borde komma ikapp replikeringen. När den har kommit ikapp är vår databasnivå redo för övergång. Naturligtvis är det vanligtvis mer än bara en enda nod - du kommer troligen att behöva konfigurera flera slavar på DO innan infrastrukturen är redo att hantera produktionstrafik.

Bytet i sig är ett annat ämne - du måste utarbeta en plan för att minimera stilleståndstiden. I allmänhet bör trafik flyttas från gammal till ny plats, men hur det ska göras beror mest på din miljö. Det kan vara allt från en enkel ändring i DNS-posten, till komplexa skript som kommer att dra alla triggers i rätt ordning för att omdirigera trafiken. Oavsett vad är din databas nu redan på den nya platsen, redo att betjäna förfrågningar.