MySQL w chmurze — migracja online z Amazon RDS do instancji EC2:część pierwsza

W naszym poprzednim blogu widzieliśmy, jak łatwo jest rozpocząć pracę z RDS dla MySQL. Jest to wygodny sposób na wdrożenie i używanie MySQL bez martwienia się o koszty operacyjne. Kompromisem jest jednak mniejsza kontrola, ponieważ użytkownicy są całkowicie zależni od personelu Amazon w przypadku słabej wydajności lub anomalii operacyjnych. Brak dostępu do katalogu danych lub fizycznych kopii zapasowych utrudnia przenoszenie danych z RDS. Może to stanowić poważny problem, jeśli Twoja baza danych przewyższa RDS i zdecydujesz się na migrację na inną platformę. Ten dwuczęściowy blog pokazuje, jak przeprowadzić migrację online z RDS na własny serwer MySQL.

Będziemy używać EC2 do uruchomienia własnego serwera MySQL. Może to być pierwszy krok do bardziej złożonych migracji do własnych prywatnych centrów danych. EC2 zapewnia dostęp do Twoich danych, dzięki czemu można korzystać z xtrabackup. EC2 umożliwia również konfigurację tuneli SSH i eliminuje konieczność konfigurowania sprzętowych połączeń VPN między infrastrukturą lokalną a VPC.

Założenia

Zanim zaczniemy, musimy poczynić kilka założeń - zwłaszcza dotyczących bezpieczeństwa. Przede wszystkim zakładamy, że instancja RDS nie jest dostępna spoza AWS. Zakładamy również, że masz aplikację w EC2. Oznacza to, że instancja RDS i reszta infrastruktury współdzielą VPC lub jest między nimi skonfigurowany dostęp w jedną lub drugą stronę. Krótko mówiąc, zakładamy, że możesz utworzyć nową instancję EC2 i będzie ona miała dostęp (lub można ją skonfigurować tak, aby miała dostęp) do Twojej instancji MySQL RDS.

Skonfigurowaliśmy ClusterControl na hoście aplikacji. Wykorzystamy go do zarządzania naszą instancją EC2 MySQL.

Wstępna konfiguracja

W naszym przypadku instancja RDS współdzieli ten sam VPC z naszą „aplikacją” (instancja EC2 o adresie IP 172.30.4.228) i hostem, który będzie celem procesu migracji (instancja EC2 o adresie IP 172.30.4.238). Jako aplikację wykorzystamy benchmark tpcc-MySQL wykonany w następujący sposób:

./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

Plan wstępny

Przeprowadzimy migrację, wykonując następujące czynności:

Skonfiguruj nasze środowisko docelowe za pomocą ClusterControl - zainstaluj MySQL na 172.30.4.238
Następnie zainstaluj ProxySQL, którego użyjemy do zarządzania naszym ruchem w czasie przełączania awaryjnego
Zrzuć dane z instancji RDS
Załaduj dane do naszego docelowego hosta
Skonfiguruj replikację między instancją RDS a hostem docelowym
Przełącz ruch z RDS na host docelowy

Przygotuj środowisko za pomocą ClusterControl

Zakładając, że mamy zainstalowany ClusterControl (jeśli nie, możesz go pobrać z:https://severalnines.com/download-clustercontrol-database-management-system), musimy skonfigurować nasz docelowy host. W tym celu użyjemy kreatora wdrażania z ClusterControl:

Wdrażanie klastra bazy danych w ClusterControl

Gdy to zrobisz, zobaczysz nowy klaster (w tym przypadku tylko jeden serwer) na liście klastrów:

Klaster baz danych w ClusterControl

Następnym krokiem będzie instalacja ProxySQL - począwszy od ClusterControl 1.4 możesz to zrobić łatwo z poziomu interfejsu użytkownika. Szczegółowo omówiliśmy ten proces w tym poście na blogu. Podczas instalacji wybraliśmy naszego hosta aplikacji (172.30.4.228) jako hosta, na którym ma zostać zainstalowany ProxySQL. Podczas instalacji musisz również wybrać hosta, do którego chcesz skierować ruch. Ponieważ w klastrze mamy tylko nasz host „docelowy”, możesz go dołączyć, ale wtedy potrzeba kilku zmian, aby przekierować ruch do instancji RDS.

Jeśli wybrałeś uwzględnienie hosta docelowego (w naszym przypadku był to 172.30.4.238) w konfiguracji ProxySQL, zobaczysz następujące wpisy w tabeli mysql_servers:

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 skonfigurował ProxySQL tak, aby używał grup hostów 10 i 20 do kierowania zapisów i odczytów do serwerów zaplecza. Będziemy musieli usunąć aktualnie skonfigurowany host z tych grup hostów i dodać tam instancję RDS. Najpierw jednak musimy upewnić się, że użytkownik monitora ProxySQL ma dostęp do instancji RDS.

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)

Musimy przyznać temu użytkownikowi dostęp do RDS. Jeśli potrzebujemy go do śledzenia opóźnienia replikacji, użytkownik musiałby mieć wtedy uprawnienie „KLIENT REPLIKACJI”. W naszym przypadku nie jest to potrzebne, ponieważ nie mamy podrzędnej instancji RDS - wystarczy „USAGE”.

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

Teraz czas na rekonfigurację ProxySQL. Zamierzamy dodać instancję RDS zarówno do grup hostów Writer (10), jak i Reader (20). Usuniemy również 172.30.4.238 z tych grup hostów – po prostu je wyedytujemy i dodamy 100 do każdej grupy hostów.

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)

Ostatnim krokiem wymaganym przed użyciem ProxySQL do przekierowania naszego ruchu jest dodanie użytkownika naszej aplikacji do 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)

Szybka uwaga - wykonaliśmy „ZAPISZ UŻYTKOWNIKÓW MYSQL W PAMIĘCI”; tylko po to, aby hasło było zahaszowane nie tylko w RUNTIME, ale także w buforze pamięci roboczej. Więcej szczegółów na temat mechanizmu haszowania haseł w ProxySQL można znaleźć w ich dokumentacji.

Możemy teraz przekierować nasz ruch do ProxySQL. Jak to zrobić, zależy od twojej konfiguracji, właśnie zrestartowaliśmy tpcc i wskazaliśmy go na ProxySQL.

Przekierowywanie ruchu za pomocą ProxySQL

W tym momencie zbudowaliśmy środowisko docelowe, do którego będziemy migrować. Przygotowaliśmy również ProxySQL i skonfigurowaliśmy go pod kątem naszej aplikacji. Mamy teraz dobrą podstawę do następnego kroku, czyli faktycznej migracji danych. W następnym poście pokażemy, jak skopiować dane z RDS do naszej własnej instancji MySQL (działającej na EC2). Pokażemy Ci również, jak przełączyć ruch na własną instancję, gdy aplikacje będą nadal obsługiwać użytkowników, bez przestojów.