Di blog sebelumnya (bagian 1 dan bagian 2), kami membahas cara memigrasikan data RDS Anda ke instans EC2. Dalam prosesnya, kami berhasil memindahkan data kami dari RDS, tetapi kami masih menjalankan AWS. Jika Anda ingin memindahkan data Anda sepenuhnya dari Amazon Web Services, ada sedikit pekerjaan yang harus dilakukan. Dalam postingan blog hari ini, kami akan menunjukkan cara melakukannya.
Pengenalan Lingkungan
Lingkungan yang akan kami kerjakan sangat mirip dengan apa yang kami dapatkan pada posting terakhir kami di seri ini. Satu-satunya perbedaan adalah tidak ada peralihan yang terjadi, karena kami akan menggunakan instans EC2 sebagai langkah perantara dalam proses keluar dari AWS.
Pengaturan infrastruktur awalRencana Tindakan
Sumber daya terkait MySQL di Cloud - Migrasi Online dari Amazon RDS ke instans EC2 (bagian 1) MySQL di Cloud - Migrasi Online dari Amazon RDS ke server Anda sendiri (bagian 2) MySQL di Cloud - Pro dan Kontra Amazon RDSDi blog sebelumnya, pertama-tama kami memigrasikan data kami dari RDS ke instans EC2 yang dapat kami akses penuh. Karena kami telah menjalankan MySQL pada instans EC2 kami, kami memiliki lebih banyak opsi untuk dipilih terkait cara menyalin data kami ke cloud lain. DigitalOcean hanya digunakan untuk tujuan demo di sini, proses yang kami jelaskan di bawah ini dapat digunakan untuk bermigrasi ke hosting atau penyedia cloud lainnya. Anda akan memerlukan akses langsung ke instans VPS. Dalam proses ini, kita akan menggunakan xtrabackup untuk menyalin data (walaupun tidak masalah menggunakan metode transfer biner lainnya). Kita perlu menyiapkan koneksi yang aman antara AWS dan DigitalOcean. Setelah kami melakukannya, kami akan mengatur replikasi dari instans EC2 ke dalam tetesan DigitalOcean. Langkah selanjutnya adalah melakukan cutover dan memindahkan aplikasi, tetapi kami tidak akan membahasnya di sini.
Memutuskan Metode Konektivitas
Amazon Web Services memungkinkan Anda memilih dari berbagai cara untuk membuat koneksi ke jaringan eksternal. Jika Anda memiliki perangkat keras yang mendukung koneksi VPN, Anda dapat menggunakannya untuk membentuk koneksi VPN antara VPC Anda di AWS dan infrastruktur lokal Anda. Jika penyedia jaringan Anda menawarkan koneksi peering dengan jaringan AWS dan Anda memiliki router BGP, Anda bisa mendapatkan koneksi VLAN langsung antara jaringan Anda dan AWS melalui AWS Direct Connect. Jika Anda memiliki beberapa jaringan yang terisolasi, Anda dapat menautkannya bersama-sama dengan Amazon menggunakan AWS VPN CloudHub. Terakhir, karena instans EC2 adalah milik Anda untuk dikelola, Anda juga dapat mengatur VPN antara instans EC2 itu dan jaringan lokal Anda menggunakan solusi perangkat lunak seperti OpenVPN.
Saat kita berbicara tentang database, Anda juga dapat memutuskan untuk mengatur replikasi SSL antara MySQL di EC2 (master) dan slave yang berjalan di DigitalOcean. - Kami masih harus mencari cara untuk melakukan transfer data awal ke slave - salah satu solusinya adalah dengan tar keluaran xtrabackup, mengenkripsi file itu dan mengirimkannya melalui WAN (rsync) atau mengunggah ke ember S3 dan kemudian mengunduhnya dari sana. Anda juga dapat mengandalkan enkripsi SSH dan hanya scp (atau bahkan rsync, menggunakan SSH) data ke lokasi baru.
Ada banyak pilihan untuk dipilih. Kami akan menggunakan solusi lain - kami akan membuat terowongan SSH antara instans EC2 dan tetesan DigitalOcean kami untuk membentuk saluran aman yang akan kami gunakan untuk mereplikasi data. Transfer awal akan dilakukan menggunakan rsync melalui koneksi SSH.
Panduan Manynines DevOps untuk Manajemen DatabasePelajari tentang apa yang perlu Anda ketahui untuk mengotomatisasi dan mengelola database open source AndaUnduh GratisMenyalin Data ke DigitalOcean
Setelah MySQL 5.7 aktif dan berjalan pada instans DigitalOcean, kita perlu melakukan pencadangan instans EC2 dan kemudian mentransfernya ke DO. Secara teknis, seharusnya dimungkinkan untuk melakukan streaming langsung data xtrabackup antar node tetapi kami tidak dapat merekomendasikannya. Tautan WAN bisa jadi tidak dapat diandalkan, dan akan lebih baik untuk mengambil cadangan secara lokal dan kemudian menggunakan rsync dengan kemampuannya untuk mencoba kembali transfer kapan pun ada yang tidak beres.
Pertama, mari kita backup pada instance EC2 kita:
[email protected]:~# innobackupex --user=tpcc --password=tpccpass /tmp/backup
Setelah siap, kita perlu mentransfernya ke jaringan DigitalOcean. Untuk melakukannya dengan cara yang aman, kami akan membuat pengguna baru di droplet DO, membuat kunci SSH dan menggunakan pengguna ini untuk menyalin data. Tentu saja, Anda juga dapat menggunakan salah satu pengguna yang ada, tidak perlu membuat yang baru. Jadi, mari tambahkan pengguna baru. Ada banyak cara untuk melakukannya, kita akan menggunakan perintah '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
Sekarang, saatnya membuat sepasang kunci ssh yang akan digunakan untuk konektivitas:
[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 |
| . . |
| |
+-----------------+
Memiliki kunci SSH, kita perlu mengaturnya di tetesan Digital Ocean kita. Kita perlu membuat direktori .ssh dan membuat file otor_keys dengan izin akses yang tepat.
[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
Kemudian, kita perlu menyalin kunci pribadi kita ke instance EC2. Ketika kami siap dengan itu, kami dapat menyalin data kami. Seperti yang kami sebutkan sebelumnya, kami akan menggunakan rsync untuk itu - ini akan memungkinkan kami untuk memulai kembali transfer jika, karena alasan apa pun, prosesnya terganggu. Dikombinasikan dengan SSH, kami telah menciptakan metode penyalinan data yang aman dan kuat melalui WAN. Mari kita mulai rsync pada host 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
Setelah beberapa saat, yang akan bergantung pada jumlah data dan kecepatan transfer, data cadangan kami akan tersedia di tetesan DigitalOcean. Ini berarti sudah waktunya untuk mempersiapkannya dengan menerapkan log redo InnoDB, dan kemudian menyalinnya kembali ke direktori data MySQL. Untuk itu kita perlu menghentikan MySQL, menghapus direktori data saat ini, menyalin file kembali menggunakan innobackupex atau secara manual, dan akhirnya, verifikasi bahwa pemilik dan grup untuk file baru disetel ke 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
Sebelum kita memulai MySQL, kita juga perlu memastikan bahwa server_id dan UUID berbeda. Yang pertama dapat diedit di my.cnf, yang terakhir dapat dijamin oleh:
[email protected]:~# rm /var/lib/mysql/auto.cnf
Sekarang, kita dapat memulai MySQL:
[email protected]:~# service mysql start
Menyiapkan Replikasi
Kami siap untuk mengatur replikasi antara EC2 dan DO, tetapi pertama-tama kami perlu menyiapkan terowongan ssh - kami akan membuat kunci ssh tambahan untuk pengguna ubuntu pada instance EC2 dan menyalinnya ke instance DO. Kemudian kita akan menggunakan user ubuntu untuk membuat tunnel yang akan kita gunakan untuk replikasi.
Mari kita mulai dengan membuat kunci ssh baru:
[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|
| . . |
| |
| |
| |
+-----------------+
Langkah selanjutnya - kita perlu menambahkan kunci publik kita ke file Authorized_keys pada instance EC2, yang akan kita sambungkan dari DigitalOcean untuk membuat tunnel.
[email protected]:~# cat id_rsa_tunnel.pub >> /home/ubuntu/.ssh/authorized_keys
Kami juga membutuhkan kunci pribadi untuk ditransfer ke droplet DO. Ini dapat dilakukan dengan banyak cara, tetapi kami akan menggunakan secure scp menggunakan pengguna dan kunci rdscopy yang telah kami buat sebelumnya:
[email protected]:~# scp -i id_rsa_rdscopy id_rsa_tunnel [email protected]:/home/rdscopy
id_rsa_tunnel 100% 3247 3.2KB/s 00:00
Hanya itu yang kita butuhkan - sekarang kita dapat membuat terowongan SSH. Kami ingin itu tersedia sepanjang waktu sehingga kami akan menggunakan sesi layar untuk itu.
[email protected]:~# screen -S tunnel
[email protected]:~# ssh -L 3307:localhost:3306 [email protected] -i /home/rdscopy/id_rsa_tunnel
Apa yang kami lakukan di sini adalah membuka terowongan SSH antara localhost, port 3307 dan host jarak jauh, 54.224.107.6, port 3306 menggunakan pengguna "ubuntu" dan kunci yang terletak di /home/rdscopy/id_rsa_tunnel. Lepaskan sesi layar dan host jarak jauh harus tersedia melalui 127.0.0.1:3307.
Untuk mengatur replikasi, kita masih perlu menambahkan n pengguna yang akan kita gunakan untuk terhubung ke MySQL di EC2. Kami akan membuatnya di host EC2 dan kami akan menggunakan '127.0.0.1' sebagai host - koneksi melalui terowongan SSH akan terlihat seperti berasal dari 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)
Semua sudah siap untuk mengatur replikasi, sekarang saatnya untuk mengikuti proses tradisional membuat slave berdasarkan data xtrabackup. Kita perlu menggunakan data dari xtrabackup_binlog_info untuk mengidentifikasi posisi master pada saat pencadangan. Posisi inilah yang ingin kita gunakan dalam perintah CHANGE MASTER TO … kita. Mari kita lihat isi file xtrabackup_binlog_info:
[email protected]:~# cat /home/rdscopy/xtrabackup_binlog_info
binlog.000052 896957365
Ini adalah file log biner dan posisi yang akan kita gunakan di CHANGE MASTER TO:
[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;
Ini dia - replikasi sekarang harus aktif dan berjalan dan budak DigitalOcean kita harus mengejar replikasi. Setelah berhasil, tingkat basis data kami siap untuk peralihan. Tentu saja, biasanya lebih dari satu node - kemungkinan besar Anda harus menyiapkan beberapa slave di DO sebelum infrastruktur siap menangani lalu lintas produksi.
Peralihan itu sendiri adalah topik yang berbeda - Anda harus menyusun rencana untuk meminimalkan waktu henti. Secara umum, lalu lintas harus dipindahkan dari lokasi lama ke lokasi baru, tetapi cara melakukannya sangat bergantung pada lingkungan Anda. Ini bisa berupa apa saja mulai dari perubahan sederhana dalam entri DNS, hingga skrip kompleks yang akan menarik semua pemicu dalam urutan yang benar untuk mengarahkan lalu lintas. Apa pun yang terjadi, database Anda sekarang sudah berada di lokasi baru, siap melayani permintaan.