В предишни блогове (част 1 и част 2) обсъдихме как да мигрирате вашите RDS данни в EC2 екземпляр. В процеса успяхме да преместим данните си извън RDS, но все още работим на AWS. Ако искате да преместите данните си изцяло от Amazon Web Services, има още малко работа за вършене. В днешната публикация в блога ще ви покажем как може да се направи.
Въведение в околната среда
Средата, с която ще работим, е доста подобна на тази, с която завършихме в последната ни публикация от поредицата. Единствената разлика е, че не се е случило прекъсване, тъй като ще използваме екземпляра EC2 като междинна стъпка в процеса на излизане от AWS.
Първоначална настройка на инфраструктурата Планът за действие
Свързани ресурси MySQL в облака – Онлайн миграция от Amazon RDS към EC2 екземпляр (част 1) MySQL в облака – Онлайн миграция от Amazon RDS към вашия собствен сървър (част 2) MySQL в облака – Плюсове и минуси на Amazon RDSВ предишния блог първо мигрирахме нашите данни от RDS към EC2 екземпляр, до който имаме пълен достъп. Тъй като вече имаме MySQL, работещ на нашия EC2 екземпляр, имаме повече опции за избор по отношение на това как да копираме нашите данни в друг облак. DigitalOcean се използва само за демонстрационни цели тук, процесът, който описваме по-долу, може да се използва за мигриране към всеки друг хостинг или облачен доставчик. Ще ви е необходим директен достъп до екземплярите на VPS. В този процес ще използваме xtrabackup за копиране на данните (въпреки че е напълно добре да използвате всеки друг метод за двоичен трансфер). Ще трябва да подготвим безопасна връзка между AWS и DigitalOcean. След като направим това, ще настроим репликация от екземпляра EC2 в капчица DigitalOcean. Следващата стъпка би била да извършим преместване и преместване на приложения, но няма да го разглеждаме тук.
Вземане на решение за метод на свързване
Amazon Web Services ви позволява да избирате от много различни начини за създаване на връзка с външни мрежи. Ако имате хардуерен уред, който поддържа VPN връзки, можете да го използвате, за да формирате VPN връзка между вашия VPC в AWS и вашата локална инфраструктура. Ако вашият мрежов доставчик ви предлага пирингова връзка с мрежата на AWS и имате BGP рутер, можете да получите директна VLAN връзка между вашата мрежа и AWS чрез AWS Direct Connect. Ако имате множество изолирани мрежи, можете да ги свържете заедно с Amazon, като използвате AWS VPN CloudHub. И накрая, тъй като EC2 екземпляри са ваши за управление, можете също да настроите VPN между този EC2 екземпляр и вашата локална мрежа, като използвате софтуерни решения като OpenVPN.
Тъй като говорим за бази данни, можете също да решите да настроите SSL репликация между MySQL на EC2 (главният) и подчинения, работещ на DigitalOcean. - Все още трябва да разберем как да направим първоначално прехвърляне на данни към подчинения - едно от решенията може да бъде да тарираме изхода на xtrabackup, криптираме този файл и или да го изпратим чрез WAN (rsync) или да го качим в S3 bucket и след това да го изтеглим оттам. Можете също да разчитате на SSH криптиране и просто scp (или дори rsync, използвайки SSH) данните до новото местоположение.
Има много опции за избор. Ние обаче ще използваме друго решение - ще установим SSH тунел между EC2 инстанцията и нашата капчица DigitalOcean, за да образуваме защитен канал, който ще използваме за репликиране на данни. Първоначално прехвърляне ще се извърши с помощта на rsync през SSH връзката.
Severalnines DevOps Ръководство за управление на бази данни Научете какво трябва да знаете, за да автоматизирате и управлявате своите бази данни с отворен код Изтеглете безплатноКопиране на данни в DigitalOcean
След като стартираме MySQL 5.7 на екземпляра DigitalOcean, трябва да направим резервно копие на екземпляра EC2 и след това да го прехвърлим в DO. Технически би трябвало да е възможно да се извършва директно поточно предаване на xtrabackup данни между възлите, но не можем наистина да го препоръчаме. WAN връзките могат да бъдат ненадеждни и би било по-добре да направите резервно копие локално и след това да използвате rsync с неговата способност да опита отново прехвърлянето, когато нещо не е наред.
Първо, нека направим резервно копие на нашия EC2 екземпляр:
[email protected]:~# innobackupex --user=tpcc --password=tpccpass /tmp/backupСлед като е готов, трябва да го прехвърлим в мрежата на DigitalOcean. За да го направим по безопасен начин, ще създадем нов потребител на капката DO, ще генерираме SSH ключ и ще използваме този потребител за копиране на данните. Разбира се, можете да използвате и всеки от съществуващите потребители, не е задължително да създавате нов. И така, нека добавим нов потребител. Има много начини да направите това, ще използваме командата „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Сега е време да генерирате чифт ssh ключове, които да използвате за свързване:
[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 |
| . . |
| |
+-----------------+Като имаме SSH ключа, трябва да го настроим на нашата капчица Digital Ocean. Трябва да създадем .ssh директория и да създадем файл authorized_keys с подходящи разрешения за достъп.
[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След това трябва да копираме нашия частен ключ в екземпляра EC2. Когато сме готови с него, можем да копираме данните си. Както споменахме по-рано, ще използваме rsync за това - той ще ни позволи да рестартираме трансфера, ако по някаква причина процесът бъде прекъснат. В комбинация с SSH, ние създадохме безопасен и стабилен метод за копиране на данните през WAN. Нека започнем rsync на хоста 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/rdscopyСлед известно време, което ще зависи от количеството данни и скоростта на трансфер, нашите архивни данни трябва да станат достъпни на капката DigitalOcean. Това означава, че е време да го подготвите, като приложите InnoDB регистрационни файлове за повторение и след това го копирате обратно в директорията с данни на MySQL. За това трябва да спрем MySQL, да премахнем текущата директория с данни, да копираме обратно файловете с помощта на innobackupex или ръчно и най-накрая да проверим дали собственикът и групата за нови файлове са зададени на 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Преди да стартираме MySQL, ние също трябва да се уверим, че и server_id, и UUID са различни. Първият може да се редактира в my.cnf, а вторият може да бъде осигурен от:
[email protected]:~# rm /var/lib/mysql/auto.cnfСега можем да стартираме MySQL:
[email protected]:~# service mysql startНастройване на репликация
Готови сме да настроим репликация между EC2 и DO, но първо трябва да настроим ssh тунел - ще създадем допълнителен ssh ключ за потребител на ubuntu на EC2 инстанция и ще го копираме в DO инстанцията. След това ще използваме потребителя на ubuntu, за да създадем тунел, който ще използваме за репликацията.
Нека започнем със създаване на новия 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|
| . . |
| |
| |
| |
+-----------------+Следваща стъпка – трябва да добавим нашия публичен ключ към файла authorized_keys на екземпляра EC2, към който ще се свържем от DigitalOcean, за да създадем тунел.
[email protected]:~# cat id_rsa_tunnel.pub >> /home/ubuntu/.ssh/authorized_keysСъщо така се нуждаем от частен ключ, който да бъде прехвърлен към капката DO. Може да се направи по много начини, но ще използваме защитен scp, използвайки потребител и ключ на rdscopy, които създадохме по-рано:
[email protected]:~# scp -i id_rsa_rdscopy id_rsa_tunnel [email protected]:/home/rdscopy
id_rsa_tunnel 100% 3247 3.2KB/s 00:00Това е всичко, от което се нуждаем - сега можем да създадем SSH тунела. Искаме той да е наличен през цялото време, така че ще използваме екранна сесия за него.
[email protected]:~# screen -S tunnel
[email protected]:~# ssh -L 3307:localhost:3306 [email protected] -i /home/rdscopy/id_rsa_tunnelТова, което направихме тук, беше да отворим SSH тунел между localhost, порт 3307 и отдалечен хост, 54.224.107.6, порт 3306, използвайки потребител „ubuntu“ и ключ, разположен в /home/rdscopy/id_rsa_tunnel. Отделете екранната сесия и отдалеченият хост трябва да е достъпен чрез 127.0.0.1:3307.
За да настроим репликацията, все още трябва да добавим n потребител, който ще използваме за свързване с MySQL на EC2. Ще го създадем на хоста EC2 и ще използваме „127.0.0.1“ като хост - връзките през SSH тунел ще изглеждат така, сякаш идват от 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)Всичко е готово за настройка на репликация, сега е време да следвате традиционен процес на създаване на подчинен, базиран на xtrabackup данни. Трябва да използваме данни от xtrabackup_binlog_info, за да идентифицираме главната позиция в момента на архивирането. Тази позиция е това, което искаме да използваме в нашата команда CHANGE MASTER TO .... Нека да разгледаме съдържанието на файла xtrabackup_binlog_info:
[email protected]:~# cat /home/rdscopy/xtrabackup_binlog_info
binlog.000052 896957365Това е двоичният регистрационен файл и позицията, която ще използваме в нашия ПРОМЯНА НА ГЛАВНИЯ КЪМ:
[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;Това е всичко - репликацията трябва да е готова и да работи и нашият роб на DigitalOcean трябва да наваксва репликацията. След като се настигне, нивото на нашата база данни е готово за превключване. Разбира се, обикновено това е нещо повече от един възел – най-вероятно ще трябва да настроите множество подчинени устройства на DO, преди инфраструктурата да е готова да обработва производствения трафик.
Самото превключване е друга тема - ще трябва да измислите план за минимизиране на престоя. По принцип трафикът трябва да се премести от старо на ново място, но как трябва да се направи зависи най-вече от вашата среда. Това може да бъде всичко от проста промяна в DNS записа до сложни скриптове, които ще изтеглят всички тригери в правилен ред, за да пренасочат трафика. Без значение какво, вашата база данни вече е на новото място, готова да обслужва заявки.
