W poprzednich blogach (część 1 i część 2) omawialiśmy, jak przenieść dane RDS do instancji EC2. W trakcie tego procesu udało nam się przenieść nasze dane z RDS, ale nadal działamy na AWS. Jeśli chcesz całkowicie przenieść swoje dane z Amazon Web Services, jest jeszcze trochę do zrobienia. W dzisiejszym poście na blogu pokażemy, jak można to zrobić.
Wprowadzenie do środowiska
Środowisko, z którym będziemy pracować, jest dość podobne do tego, z jakim mieliśmy do czynienia w naszym ostatnim poście z serii. Jedyna różnica polega na tym, że nie nastąpiło żadne przełączenie, ponieważ wykorzystamy instancję EC2 jako etap pośredni w procesie wychodzenia z AWS.
Wstępna konfiguracja infrastruktury Plan działania
Powiązane zasoby MySQL w chmurze — migracja online z Amazon RDS do instancji EC2 (część 1) MySQL w chmurze — migracja online z Amazon RDS na własny serwer (część 2) MySQL w chmurze — zalety i wady usługi Amazon RDSW poprzednim blogu najpierw przenieśliśmy nasze dane z RDS do instancji EC2, do której mamy pełny dostęp. Ponieważ mamy już MySQL działający na naszej instancji EC2, mamy do wyboru więcej opcji dotyczących sposobu kopiowania naszych danych do innej chmury. DigitalOcean jest tutaj używany tylko do celów demonstracyjnych, proces, który opisujemy poniżej, może zostać wykorzystany do migracji do dowolnego innego dostawcy hostingu lub chmury. Potrzebujesz bezpośredniego dostępu do instancji VPS. W tym procesie użyjemy xtrabackup do skopiowania danych (chociaż doskonale jest użyć dowolnej innej metody transferu binarnego). Musielibyśmy przygotować bezpieczne połączenie między AWS a DigitalOcean. Gdy to zrobimy, skonfigurujemy replikację z instancji EC2 do dropletu DigitalOcean. Następnym krokiem byłoby wykonanie przełączenia i przeniesienie aplikacji, ale nie będziemy tego tutaj omawiać.
Decydowanie o metodzie łączności
Amazon Web Services pozwala wybierać spośród wielu różnych sposobów tworzenia połączenia z sieciami zewnętrznymi. Jeśli masz urządzenie sprzętowe, które obsługuje połączenia VPN, możesz użyć go do utworzenia połączenia VPN między VPC w AWS a infrastrukturą lokalną. Jeśli Twój dostawca sieci oferuje Ci połączenie równorzędne z siecią AWS i masz router BGP, możesz uzyskać bezpośrednie połączenie VLAN między Twoją siecią a AWS za pośrednictwem AWS Direct Connect. Jeśli masz wiele odizolowanych sieci, możesz połączyć je z Amazon za pomocą AWS VPN CloudHub. Wreszcie, ponieważ instancjami EC2 zarządzasz, możesz równie dobrze skonfigurować VPN między tą instancją EC2 a siecią lokalną za pomocą oprogramowania, takiego jak OpenVPN.
Ponieważ mówimy o bazach danych, możesz również zdecydować się na ustawienie replikacji SSL między MySQL na EC2 (master) a slave działającym na DigitalOcean. - Nadal musimy wymyślić, jak wykonać wstępny transfer danych do urządzenia podrzędnego - jednym z rozwiązań może być tarowanie danych wyjściowych xtrabackup, zaszyfrowanie tego pliku i przesłanie go przez WAN (rsync) lub przesłanie do wiadra S3, a następnie pobranie go stamtąd. Możesz także polegać na szyfrowaniu SSH i po prostu scp (lub nawet rsync, używając SSH) dane do nowej lokalizacji.
Do wyboru jest wiele opcji. Skorzystamy jednak z innego rozwiązania - zamierzamy ustanowić tunel SSH między instancją EC2 a naszym dropletem DigitalOcean, aby utworzyć bezpieczny kanał, który wykorzystamy do replikacji danych. Początkowy transfer zostanie wykonany za pomocą rsync przez połączenie SSH.
Manynines DevOps Przewodnik po zarządzaniu bazami danychDowiedz się, co musisz wiedzieć, aby zautomatyzować i zarządzać bazami danych typu open sourcePobierz za darmoKopiowanie danych do DigitalOcean
Po uruchomieniu MySQL 5.7 na instancji DigitalOcean musimy wykonać kopię zapasową instancji EC2, a następnie przenieść ją do DO. Z technicznego punktu widzenia powinno być możliwe wykonanie bezpośredniego przesyłania strumieniowego danych xtrabackup między węzłami, ale tak naprawdę nie możemy tego polecić. Łącza WAN mogą być zawodne i lepiej byłoby wykonać kopię zapasową lokalnie, a następnie użyć rsync z możliwością ponowienia transferu, gdy coś jest nie tak.
Najpierw zróbmy kopię zapasową na naszej instancji EC2:
[email protected]:~# innobackupex --user=tpcc --password=tpccpass /tmp/backupGdy będzie gotowy, musimy przenieść go do sieci DigitalOcean. Aby zrobić to w bezpieczny sposób, utworzymy nowego użytkownika na droplecie DO, wygenerujemy klucz SSH i użyjemy tego użytkownika do skopiowania danych. Oczywiście możesz równie dobrze korzystać z dowolnego z istniejących użytkowników, nie jest to wymagane do utworzenia nowego. Dodajmy więc nowego użytkownika. Można to zrobić na wiele sposobów, użyjemy polecenia „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] yTeraz nadszedł czas, aby wygenerować parę kluczy ssh, które będą używane do łączności:
[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 |
| . . |
| |
+-----------------+Mając klucz SSH, musimy ustawić go na naszej droplecie Digital Ocean. Musimy utworzyć katalog .ssh i utworzyć plik Author_keys z odpowiednimi uprawnieniami dostępu.
[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_keysNastępnie musimy skopiować nasz klucz prywatny do instancji EC2. Kiedy będziemy z tym gotowi, możemy skopiować nasze dane. Jak wspomnieliśmy wcześniej, użyjemy do tego rsync - pozwoli nam to ponownie uruchomić transfer, jeśli z jakiegoś powodu proces zostanie przerwany. W połączeniu z SSH stworzyliśmy bezpieczną i solidną metodę kopiowania danych przez WAN. Zacznijmy rsync na hoście EC2:
[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/rdscopyPo pewnym czasie, który będzie zależeć od ilości danych i szybkości transferu, nasze dane kopii zapasowej powinny stać się dostępne na droplecie DigitalOcean. Oznacza to, że nadszedł czas, aby go przygotować poprzez zastosowanie logów przeróbek InnoDB, a następnie skopiowanie go z powrotem do katalogu danych MySQL. W tym celu musimy zatrzymać MySQL, usunąć bieżący katalog danych, skopiować pliki z powrotem za pomocą innobackupex lub ręcznie, a na koniec sprawdzić, czy właściciel i grupa dla nowych plików są ustawione na 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/mysqlZanim uruchomimy MySQL, musimy również upewnić się, że zarówno identyfikator_serwera, jak i identyfikator UUID są różne. To pierwsze można edytować w my.cnf, drugie można zapewnić przez:
[email protected]:~# rm /var/lib/mysql/auto.cnfTeraz możemy uruchomić MySQL:
[email protected]:~# service mysql startKonfigurowanie replikacji
Jesteśmy gotowi do skonfigurowania replikacji między EC2 i DO, ale najpierw musimy ustawić tunel ssh - utworzymy dodatkowy klucz ssh dla użytkownika ubuntu na instancji EC2 i skopiujemy go do instancji DO. Następnie użyjemy użytkownika ubuntu do utworzenia tunelu, którego użyjemy do replikacji.
Zacznijmy od utworzenia nowego klucza ssh:
[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|
| . . |
| |
| |
| |
+-----------------+Kolejny krok - musimy dodać nasz klucz publiczny do pliku Author_keys na instancji EC2, do którego połączymy się z DigitalOcean w celu utworzenia tunelu.
[email protected]:~# cat id_rsa_tunnel.pub >> /home/ubuntu/.ssh/authorized_keysPotrzebujemy również klucza prywatnego do przeniesienia do kropli DO. Można to zrobić na wiele sposobów, ale użyjemy bezpiecznego scp za pomocą użytkownika i klucza rdscopy, który stworzyliśmy wcześniej:
[email protected]:~# scp -i id_rsa_rdscopy id_rsa_tunnel [email protected]:/home/rdscopy
id_rsa_tunnel 100% 3247 3.2KB/s 00:00To wszystko, czego potrzebujemy - teraz możemy stworzyć tunel SSH. Chcemy, aby był dostępny przez cały czas, więc użyjemy do tego sesji screen.
[email protected]:~# screen -S tunnel
[email protected]:~# ssh -L 3307:localhost:3306 [email protected] -i /home/rdscopy/id_rsa_tunnelTo, co tutaj zrobiliśmy, to otwarcie tunelu SSH między hostem lokalnym, port 3307 i hostem zdalnym, 54.224.107.6, port 3306 przy użyciu użytkownika „ubuntu” i klucza znajdującego się w /home/rdscopy/id_rsa_tunnel. Odłącz sesję screena, a zdalny host powinien być dostępny przez 127.0.0.1:3307.
Aby skonfigurować replikację, nadal musimy dodać n użytkowników, których będziemy używać do łączenia się z MySQL na EC2. Utworzymy go na hoście EC2 i użyjemy „127.0.0.1” jako hosta - połączenia przez tunel SSH będą wyglądały tak, jakby pochodziły z hosta lokalnego:
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)Wszystko gotowe do skonfigurowania replikacji, nadszedł czas na tradycyjny proces tworzenia urządzenia podrzędnego w oparciu o dane xtrabackup. Musimy użyć danych z xtrabackup_binlog_info do zidentyfikowania pozycji głównej w czasie tworzenia kopii zapasowej. Ta pozycja jest tym, czego chcemy użyć w naszym poleceniu ZMIEŃ MISTRZA NA…. Rzućmy okiem na zawartość pliku xtrabackup_binlog_info:
[email protected]:~# cat /home/rdscopy/xtrabackup_binlog_info
binlog.000052 896957365To jest binarny plik dziennika i pozycja, których użyjemy w naszej ZMIEŃ MASTER NA:
[email protected]:~# mysql -u root -ppassmysql> 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;To jest to — replikacja powinna już działać, a nasze urządzenie podrzędne DigitalOcean powinno nadrobić zaległości w zakresie replikacji. Gdy nadrobi zaległości, nasza warstwa bazy danych jest gotowa do przełączenia. Oczywiście zwykle jest to więcej niż pojedynczy węzeł — najprawdopodobniej będziesz musiał ustawić wiele urządzeń podrzędnych na DO, zanim infrastruktura będzie gotowa do obsługi ruchu produkcyjnego.
Sama zmiana to inny temat - będziesz musiał opracować plan minimalizacji przestojów. Ogólnie rzecz biorąc, ruch powinien zostać przeniesiony ze starej do nowej lokalizacji, ale sposób, w jaki należy to zrobić, zależy głównie od Twojego środowiska. Może to być wszystko, od prostej zmiany wpisu DNS do złożonych skryptów, które będą uruchamiać wszystkie wyzwalacze we właściwej kolejności, aby przekierować ruch. Bez względu na wszystko, Twoja baza danych jest już w nowej lokalizacji, gotowa do obsługi żądań.
