MySQL-database migreren van Amazon RDS naar DigitalOcean

In eerdere blogs (deel 1 en deel 2) hebben we besproken hoe u uw RDS-gegevens kunt migreren naar een EC2-instantie. Daarbij zijn we erin geslaagd om onze gegevens uit RDS te halen, maar we draaien nog steeds op AWS. Als u uw gegevens volledig uit Amazon Web Services wilt verwijderen, is er wat meer werk aan de winkel. In de blogpost van vandaag laten we je zien hoe het kan.

Omgeving Inleiding

De omgeving waarmee we zullen werken, lijkt behoorlijk op wat we eindigden in onze laatste post in de serie. Het enige verschil is dat er geen omschakeling heeft plaatsgevonden, aangezien we de EC2-instantie zullen gebruiken als tussenstap in het proces om uit AWS te stappen.

Het actieplan

In de vorige blog hebben we eerst onze gegevens gemigreerd van RDS naar een EC2-instantie waar we volledige toegang toe hebben. Omdat we MySQL al op onze EC2-instantie hebben draaien, hebben we meer opties om uit te kiezen met betrekking tot het kopiëren van onze gegevens naar een andere cloud. DigitalOcean wordt hier alleen gebruikt voor demo-doeleinden, het proces dat we hieronder beschrijven kan worden gebruikt om te migreren naar een andere hosting- of cloudprovider. Je hebt dan directe toegang tot de VPS-instances nodig. In dit proces zullen we xtrabackup gebruiken om de gegevens te kopiëren (hoewel het prima is om elke andere methode van binaire overdracht te gebruiken). We zouden een veilige verbinding tussen AWS en DigitalOcean moeten voorbereiden. Zodra we dat hebben gedaan, zullen we replicatie instellen van de EC2-instantie naar een DigitalOcean-druppel. De volgende stap zou zijn om een ​​cutover uit te voeren en applicaties te verplaatsen, maar we zullen het hier niet behandelen.

Beslissen over connectiviteitsmethode

Met Amazon Web Services kunt u uit veel verschillende manieren kiezen om een ​​verbinding met externe netwerken tot stand te brengen. Als je een hardwareapparaat hebt dat VPN-verbindingen ondersteunt, kun je het gebruiken om een ​​VPN-verbinding tot stand te brengen tussen je VPC in AWS en je lokale infrastructuur. Als je netwerkprovider je een peering-verbinding met het AWS-netwerk aanbiedt en je hebt een BGP-router, dan kun je via AWS Direct Connect een directe VLAN-verbinding krijgen tussen je netwerk en AWS. Als u meerdere, geïsoleerde netwerken heeft, kunt u deze met Amazon koppelen door gebruik te maken van AWS VPN CloudHub. Ten slotte, aangezien u EC2-instanties moet beheren, kunt u net zo goed een VPN instellen tussen die EC2-instantie en uw lokale netwerk met behulp van softwareoplossingen zoals OpenVPN.

Aangezien we het over databases hebben, kunt u ook besluiten om SSL-replicatie in te stellen tussen MySQL op EC2 (de master) en de slave die op DigitalOcean draait. - We moeten nog uitzoeken hoe we een eerste gegevensoverdracht naar de slaaf kunnen doen - een oplossing zou kunnen zijn om de uitvoer van xtrabackup te tarren, dat bestand te coderen en het ofwel via WAN (rsync) te verzenden of te uploaden naar S3-bucket en het vervolgens te downloaden vanaf daar. U kunt ook vertrouwen op SSH-codering en de gegevens gewoon scp (of zelfs rsync, met SSH) naar de nieuwe locatie.

Er zijn veel opties om uit te kiezen. We zullen echter een andere oplossing gebruiken - we gaan een SSH-tunnel opzetten tussen de EC2-instantie en onze DigitalOcean-druppel om een ​​veilig kanaal te vormen dat we zullen gebruiken om gegevens te repliceren. De eerste overdracht vindt plaats met rsync via de SSH-verbinding.

Gegevens kopiëren naar DigitalOcean

Zodra we MySQL 5.7 in gebruik hebben op de DigitalOcean-instantie, moeten we een back-up van de EC2-instantie maken en deze vervolgens overbrengen naar DO. Technisch gezien zou het mogelijk moeten zijn om een ​​directe streaming van xtrabackup-gegevens tussen de knooppunten uit te voeren, maar we kunnen het niet echt aanbevelen. WAN-links kunnen onbetrouwbaar zijn en het is beter om lokaal een back-up te maken en vervolgens rsync te gebruiken met de mogelijkheid om de overdracht opnieuw te proberen wanneer er iets niet klopt.

Laten we eerst een back-up maken op onze EC2-instantie:

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

Zodra het klaar is, moeten we het overbrengen naar het DigitalOcean-netwerk. Om dit op een veilige manier te doen, zullen we een nieuwe gebruiker maken op de DO-druppel, een SSH-sleutel genereren en deze gebruiker gebruiken om de gegevens te kopiëren. Natuurlijk kunt u net zo goed alle bestaande gebruikers gebruiken, het is niet verplicht om een ​​nieuwe aan te maken. Laten we dus een nieuwe gebruiker toevoegen. Er zijn veel manieren om dit te doen, we gebruiken het 'adduser'-commando.

[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 is het tijd om een ​​paar ssh-sleutels te genereren om te gebruiken voor connectiviteit:

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

Als we de SSH-sleutel hebben, moeten we deze instellen op onze Digital Ocean-druppel. We moeten een .ssh-map maken en het bestand Authorized_keys maken met de juiste toegangsrechten.

[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

Vervolgens moeten we onze privésleutel naar de EC2-instantie kopiëren. Als we er klaar voor zijn, kunnen we onze gegevens kopiëren. Zoals we eerder vermeldden, zullen we daarvoor rsync gebruiken - het stelt ons in staat om de overdracht opnieuw te starten als, om welke reden dan ook, het proces wordt onderbroken. In combinatie met SSH hebben we een veilige en robuuste methode ontwikkeld om de gegevens over WAN te kopiëren. Laten we beginnen met rsync op de EC2-host:

[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

Na een tijdje, afhankelijk van de hoeveelheid gegevens en overdrachtssnelheid, zouden onze back-upgegevens beschikbaar moeten komen op de DigitalOcean-druppel. Dit betekent dat het tijd is om het voor te bereiden door InnoDB redo-logs toe te passen en het vervolgens terug te kopiëren naar de MySQL-gegevensmap. Daarvoor moeten we MySQL stoppen, de huidige gegevensmap verwijderen, de bestanden terug kopiëren met innobackupex of handmatig, en ten slotte verifiëren dat de eigenaar en groep voor nieuwe bestanden is ingesteld op 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

Voordat we MySQL starten, moeten we er ook voor zorgen dat zowel server_id als UUID's verschillend zijn. De eerste kan worden bewerkt in my.cnf, de laatste kan worden verzekerd door:

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

Nu kunnen we MySQL starten:

[email protected]:~# service mysql start

Replicatie instellen

We zijn klaar om replicatie tussen EC2 en DO in te stellen, maar eerst moeten we een ssh-tunnel opzetten - we zullen een extra ssh-sleutel voor ubuntu-gebruiker op EC2-instantie maken en deze naar de DO-instantie kopiëren. Vervolgens zullen we de ubuntu-gebruiker gebruiken om een ​​tunnel te maken die we zullen gebruiken voor de replicatie.

Laten we beginnen met het maken van de nieuwe ssh-sleutel:

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

Volgende stap - we moeten onze openbare sleutel toevoegen aan het bestand Authorized_keys op de EC2-instantie, waarmee we verbinding maken vanuit DigitalOcean om een ​​tunnel te maken.

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

We hebben ook een privésleutel nodig om te worden overgedragen naar de DO-druppel. Het kan op veel manieren worden gedaan, maar we gebruiken beveiligde scp met behulp van de rdscopy-gebruiker en -sleutel die we eerder hebben gemaakt:

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

Dat is alles wat we nodig hebben - nu kunnen we de SSH-tunnel maken. We willen dat het altijd beschikbaar is, dus we zullen er schermsessie voor gebruiken.

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

Wat we hier deden, was een SSH-tunnel openen tussen localhost, poort 3307 en externe host, 54.224.107.6, poort 3306 met behulp van de "ubuntu" -gebruiker en een sleutel in /home/rdscopy/id_rsa_tunnel. Koppel de schermsessie los en de externe host zou beschikbaar moeten zijn via 127.0.0.1:3307.

Om replicatie in te stellen, moeten we nog een gebruiker toevoegen die we zullen gebruiken om verbinding te maken met MySQL op EC2. We zullen het op de EC2-host maken en we gebruiken '127.0.0.1' als host - verbindingen via de SSH-tunnel zien eruit alsof ze afkomstig zijn van 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)

Alles is klaar om replicatie in te stellen, het is nu tijd om een ​​traditioneel proces te volgen voor het maken van een slave op basis van xtrabackup-gegevens. We moeten gegevens van xtrabackup_binlog_info gebruiken om de hoofdpositie op het moment van de back-up te identificeren. Deze positie is wat we willen gebruiken in ons CHANGE MASTER TO ... commando. Laten we eens kijken naar de inhoud van het xtrabackup_binlog_info bestand:

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

Dit is het binaire logbestand en de positie die we zullen gebruiken in onze MASTER WIJZIGEN IN:

[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;

Dit is het - replicatie zou nu moeten werken en onze DigitalOcean-slave zou de replicatie moeten inhalen. Als het eenmaal is ingehaald, is onze databaselaag klaar voor omschakeling. Natuurlijk is het meestal meer dan slechts een enkele node - u zult hoogstwaarschijnlijk meerdere slaves op DO moeten instellen voordat de infrastructuur klaar is om productieverkeer te verwerken.

Overstappen zelf is een ander onderwerp - u zult een plan moeten bedenken om de uitvaltijd tot een minimum te beperken. Over het algemeen moet het verkeer van de oude naar de nieuwe locatie worden verplaatst, maar hoe dit moet gebeuren, hangt grotendeels af van uw omgeving. Het kan van alles zijn, van een eenvoudige wijziging in de DNS-invoer tot complexe scripts die alle triggers in de juiste volgorde overhalen om het verkeer om te leiden. Wat er ook gebeurt, uw database bevindt zich nu al op de nieuwe locatie, klaar om verzoeken te behandelen.