MySQL i skyen - Online migration fra Amazon RDS til EC2 Instance:Part One

I vores tidligere blog så vi, hvor nemt det er at komme i gang med RDS til MySQL. Det er en bekvem måde at implementere og bruge MySQL på uden at bekymre dig om driftsomkostninger. Afvejningen er dog reduceret kontrol, da brugere er helt afhængige af Amazon-personale i tilfælde af dårlig ydeevne eller driftsforstyrrelser. Ingen adgang til databiblioteket eller fysiske sikkerhedskopier gør det svært at flytte data ud af RDS. Dette kan være et stort problem, hvis din database vokser ud af RDS, og du beslutter dig for at migrere til en anden platform. Denne todelte blog viser dig, hvordan du laver en online migrering fra RDS til din egen MySQL-server.

Vi bruger EC2 til at køre vores egen MySQL-server. Det kan være et første skridt til mere komplekse migreringer til dine egne private datacentre. EC2 giver dig adgang til dine data, så xtrabackup kan bruges. EC2 giver dig også mulighed for at opsætte SSH-tunneler, og det fjerner kravet om opsætning af hardware VPN-forbindelser mellem din lokale infrastruktur og VPC.

Forudsætninger

Før vi starter, er vi nødt til at gøre et par antagelser - især omkring sikkerhed. Først og fremmest antager vi, at RDS-instansen ikke er tilgængelig uden for AWS. Vi forudsætter også, at du har en ansøgning i EC2. Dette indebærer, at enten RDS-instansen og resten af din infrastruktur deler en VPC, eller der er adgang konfigureret mellem dem, på den ene eller den anden måde. Kort sagt antager vi, at du kan oprette en ny EC2-instans, og den vil have adgang (eller den kan konfigureres til at have adgangen) til din MySQL RDS-instans.

Vi har konfigureret ClusterControl på applikationsværten. Vi bruger den til at administrere vores EC2 MySQL-instans.

Indledende opsætning

I vores tilfælde deler RDS-instansen den samme VPC med vores "applikation" (EC2-instans med IP 172.30.4.228) og vært, som vil være et mål for migreringsprocessen (EC2-instans med IP 172.30.4.238). Som applikation vil vi bruge tpcc-MySQL benchmark udført på følgende måde:

./tpcc_start -h rds2.cvsw8xpajw2b.us-east-1.rds.amazonaws.com -d tpcc1000 -u tpcc -p tpccpass -w 20 -r 60 -l 600 -i 10 -c 4

Oprindelig plan

Vi skal udføre en migrering ved at bruge følgende trin:

Opsæt vores målmiljø ved hjælp af ClusterControl - installer MySQL på 172.30.4.238
Installer derefter ProxySQL, som vi vil bruge til at administrere vores trafik på tidspunktet for failover
Dump dataene fra RDS-forekomsten
Indlæs dataene i vores målvært
Konfigurer replikering mellem RDS-instans og målvært
Skift trafik fra RDS til målvært

Forbered miljø ved hjælp af ClusterControl

Forudsat at vi har ClusterControl installeret (hvis du ikke gør det, kan du hente det fra:https://severalnines.com/download-clustercontrol-database-management-system), skal vi konfigurere vores målvært. Vi vil bruge installationsguiden fra ClusterControl til det:

Implementering af en databaseklynge i ClusterControl

Når dette er gjort, vil du se en ny klynge (i dette tilfælde kun din enkelte server) på klyngelisten:

Databaseklynge i ClusterControl

Næste trin vil være at installere ProxySQL - startende fra ClusterControl 1.4 kan du nemt gøre det fra brugergrænsefladen. Vi dækkede denne proces i detaljer i dette blogindlæg. Da vi installerede det, valgte vi vores applikationsvært (172.30.4.228) som værten til at installere ProxySQL på. Når du installerer, skal du også vælge en vært at dirigere din trafik til. Da vi kun har vores "destination"-vært i klyngen, kan du inkludere den, men så skal der nogle ændringer til for at omdirigere trafik til RDS-forekomsten.

Hvis du har valgt at inkludere destinationsvært (i vores tilfælde var det 172.30.4.238) i ProxySQL-opsætningen, vil du se følgende poster i mysql_servers-tabellen:

mysql> select * from mysql_servers\G
*************************** 1. row ***************************
       hostgroup_id: 20
           hostname: 172.30.4.238
               port: 3306
             status: ONLINE
             weight: 1
        compression: 0
    max_connections: 100
max_replication_lag: 10
            use_ssl: 0
     max_latency_ms: 0
            comment: read server
*************************** 2. row ***************************
       hostgroup_id: 10
           hostname: 172.30.4.238
               port: 3306
             status: ONLINE
             weight: 1
        compression: 0
    max_connections: 100
max_replication_lag: 10
            use_ssl: 0
     max_latency_ms: 0
            comment: read and write server
2 rows in set (0.00 sec)

ClusterControl konfigurerede ProxySQL til at bruge værtsgruppe 10 og 20 til at dirigere skrivninger og læsninger til backend-serverne. Vi bliver nødt til at fjerne den aktuelt konfigurerede vært fra disse værtsgrupper og tilføje RDS-instansen der. Først skal vi dog sikre, at ProxySQL's monitorbruger kan få adgang til RDS-instansen.

mysql> SHOW VARIABLES LIKE 'mysql-monitor_username';
+------------------------+------------------+
| Variable_name          | Value            |
+------------------------+------------------+
| mysql-monitor_username | proxysql-monitor |
+------------------------+------------------+
1 row in set (0.00 sec)

mysql> SHOW VARIABLES LIKE 'mysql-monitor_password';
+------------------------+---------+
| Variable_name          | Value   |
+------------------------+---------+
| mysql-monitor_password | monpass |
+------------------------+---------+
1 row in set (0.00 sec)

Vi skal give denne bruger adgang til RDS. Hvis vi har brug for det til at spore replikeringsforsinkelse, skal brugeren have privilegiet "REPLICATION CLIENT". I vores tilfælde er det ikke nødvendigt, da vi ikke har slave RDS-instanser - 'USAGE' vil være nok.

[email protected]:~# mysql -ppassword -h rds2.cvsw8xpajw2b.us-east-1.rds.amazonaws.com
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 210
Server version: 5.7.16-log MySQL Community Server (GPL)

Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> CREATE USER 'proxysql-monitor'@172.30.4.228 IDENTIFIED BY 'monpass';
Query OK, 0 rows affected (0.06 sec)

Nu er det tid til at omkonfigurere ProxySQL. Vi vil tilføje RDS-instansen til både forfatter- (10) og læser- (20) værtsgrupper. Vi vil også fjerne 172.30.4.238 fra disse værtsgrupper - vi vil bare redigere dem og tilføje 100 til hver værtsgruppe.

mysql> INSERT INTO mysql_servers (hostgroup_id, hostname, max_connections, max_replication_lag) VALUES (10, 'rds2.cvsw8xpajw2b.us-east-1.rds.amazonaws.com', 100, 10);
Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO mysql_servers (hostgroup_id, hostname, max_connections, max_replication_lag) VALUES (20, 'rds2.cvsw8xpajw2b.us-east-1.rds.amazonaws.com', 100, 10);
Query OK, 1 row affected (0.00 sec)

mysql> UPDATE mysql_servers SET hostgroup_id=110 WHERE hostname='172.30.4.238' AND hostgroup_id=10;
Query OK, 1 row affected (0.00 sec)

mysql> UPDATE mysql_servers SET hostgroup_id=120 WHERE hostname='172.30.4.238' AND hostgroup_id=20;
Query OK, 1 row affected (0.00 sec)

mysql> LOAD MYSQL SERVERS TO RUNTIME;
Query OK, 0 rows affected (0.01 sec)

mysql> SAVE MYSQL SERVERS TO DISK;
Query OK, 0 rows affected (0.07 sec)

Sidste trin, der kræves, før vi kan bruge ProxySQL til at omdirigere vores trafik, er at tilføje vores applikationsbruger til ProxySQL.

mysql> INSERT INTO mysql_users (username, password, active, default_hostgroup) VALUES ('tpcc', 'tpccpass', 1, 10);
Query OK, 1 row affected (0.00 sec)

mysql> LOAD MYSQL USERS TO RUNTIME; SAVE MYSQL USERS TO DISK; SAVE MYSQL USERS TO MEMORY;
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.05 sec)

Query OK, 0 rows affected (0.00 sec)

mysql> SELECT username, password FROM mysql_users WHERE username='tpcc';
+----------+-------------------------------------------+
| username | password                                  |
+----------+-------------------------------------------+
| tpcc     | *8C446904FFE784865DF49B29DABEF3B2A6D232FC |
+----------+-------------------------------------------+
1 row in set (0.00 sec)

Hurtig note - vi udførte "GEM MYSQL-BRUGERE TIL HUKOMMELSE;" kun for at få hashed adgangskode ikke kun i RUNTIME, men også i arbejdshukommelsesbufferen. Du kan finde flere detaljer om ProxySQLs hashing-mekanisme for adgangskode i deres dokumentation.

Vi kan nu omdirigere vores trafik til ProxySQL. Hvordan man gør det afhænger af din opsætning, vi har lige genstartet tpcc og pegede den til ProxySQL.

Omdirigere trafik med ProxySQL

På dette tidspunkt har vi bygget et målmiljø, som vi vil migrere til. Vi forberedte også ProxySQL og konfigurerede det til vores applikation. Vi har nu et godt grundlag for det næste trin, som er selve datamigreringen. I det næste indlæg vil vi vise dig, hvordan du kopierer dataene ud af RDS til vores egen MySQL-instans (kører på EC2). Vi vil også vise dig, hvordan du skifter trafik til din egen instans, mens applikationer fortsætter med at betjene brugere uden nedetid.