Di chuyển Cơ sở dữ liệu MySQL từ Amazon RDS sang DigitalOcean

Trong các blog trước (phần 1 và phần 2), chúng tôi đã thảo luận về cách di chuyển dữ liệu RDS của bạn vào một phiên bản EC2. Trong quá trình này, chúng tôi đã cố gắng di chuyển dữ liệu của mình ra khỏi RDS, nhưng chúng tôi vẫn đang chạy trên AWS. Nếu bạn muốn chuyển hoàn toàn dữ liệu của mình ra khỏi Amazon Web Services, bạn còn phải làm thêm một số việc nữa. Trong bài đăng trên blog của ngày hôm nay, chúng tôi sẽ chỉ cho bạn cách thực hiện điều đó.

Giới thiệu Môi trường

Môi trường mà chúng tôi sẽ làm việc tương tự như những gì chúng tôi đã kết thúc trong bài đăng cuối cùng của chúng tôi trong loạt bài này. Sự khác biệt duy nhất là không có sự cắt bỏ nào xảy ra, vì chúng tôi sẽ sử dụng phiên bản EC2 như một bước trung gian trong quá trình chuyển ra khỏi AWS.

Thiết lập cơ sở hạ tầng ban đầu

Kế hoạch hành động

Các tài nguyên liên quan MySQL trong đám mây - Di chuyển trực tuyến từ phiên bản Amazon RDS sang EC2 (phần 1) MySQL trong đám mây - Di chuyển trực tuyến từ Amazon RDS sang máy chủ của riêng bạn (phần 2) MySQL trong đám mây - Ưu và nhược điểm của Amazon RDS

Trong blog trước, lần đầu tiên chúng tôi đã di chuyển dữ liệu của mình từ RDS sang phiên bản EC2 mà chúng tôi có toàn quyền truy cập. Vì chúng tôi đã có MySQL chạy trên phiên bản EC2 của mình, chúng tôi có nhiều tùy chọn hơn để lựa chọn về cách sao chép dữ liệu của chúng tôi sang một đám mây khác. DigitalOcean chỉ được sử dụng cho mục đích demo ở đây, quá trình chúng tôi mô tả bên dưới có thể được sử dụng để di chuyển sang bất kỳ nhà cung cấp dịch vụ lưu trữ hoặc đám mây nào khác. Bạn sẽ cần quyền truy cập trực tiếp vào các phiên bản VPS. Trong quá trình này, chúng tôi sẽ sử dụng xtrabackup để sao chép dữ liệu (mặc dù sử dụng bất kỳ phương pháp truyền nhị phân nào khác là hoàn toàn ổn). Chúng tôi cần chuẩn bị kết nối an toàn giữa AWS và DigitalOcean. Khi chúng tôi làm điều đó, chúng tôi sẽ thiết lập sao chép từ phiên bản EC2 thành giọt DigitalOcean. Bước tiếp theo sẽ là thực hiện cắt và di chuyển các ứng dụng, nhưng chúng tôi sẽ không trình bày ở đây.

Quyết định phương thức kết nối

Amazon Web Services cho phép bạn chọn từ nhiều cách khác nhau để tạo kết nối với các mạng bên ngoài. Nếu bạn có thiết bị phần cứng hỗ trợ kết nối VPN, bạn có thể sử dụng thiết bị đó để tạo kết nối VPN giữa VPC trong AWS và cơ sở hạ tầng cục bộ của bạn. Nếu nhà cung cấp mạng của bạn cung cấp cho bạn kết nối ngang hàng với mạng AWS và bạn có bộ định tuyến BGP, bạn có thể nhận được kết nối VLAN trực tiếp giữa mạng của mình và AWS thông qua AWS Direct Connect. Nếu bạn có nhiều mạng riêng biệt, bạn có thể liên kết chúng với nhau với Amazon bằng cách sử dụng AWS VPN CloudHub. Cuối cùng, vì các phiên bản EC2 là của bạn để quản lý, bạn cũng có thể thiết lập VPN giữa phiên bản EC2 đó và mạng cục bộ của mình bằng các giải pháp phần mềm như OpenVPN.

Khi chúng ta đang nói về cơ sở dữ liệu, bạn cũng có thể quyết định thiết lập bản sao SSL giữa MySQL trên EC2 (chính) và nô lệ đang chạy trên DigitalOcean. - Chúng tôi vẫn phải tìm ra cách thực hiện chuyển dữ liệu ban đầu đến nô lệ - một giải pháp có thể là tar đầu ra của xtrabackup, mã hóa tệp đó và gửi qua WAN (rsync) hoặc tải lên bộ chứa S3 rồi tải xuống từ đó. Bạn cũng có thể dựa vào mã hóa SSH và chỉ cần quét (hoặc thậm chí rsync, sử dụng SSH) dữ liệu đến vị trí mới.

Có rất nhiều tùy chọn để lựa chọn. Tuy nhiên, chúng tôi sẽ sử dụng một giải pháp khác - chúng tôi sẽ thiết lập một đường hầm SSH giữa phiên bản EC2 và giọt DigitalOcean của chúng tôi để tạo thành một kênh an toàn mà chúng tôi sẽ sử dụng để sao chép dữ liệu. Quá trình chuyển lần đầu sẽ được thực hiện bằng rsync qua kết nối SSH.

Somenines DevOps Guide to Management DatabaseTìm hiểu về những điều bạn cần biết để tự động hóa và quản lý cơ sở dữ liệu nguồn mở của mìnhTải xuống miễn phí

Sao chép dữ liệu sang DigitalOcean

Khi chúng tôi đã thiết lập và chạy MySQL 5.7 trên phiên bản DigitalOcean, chúng tôi cần thực hiện sao lưu phiên bản EC2 và sau đó chuyển nó sang DO. Về mặt kỹ thuật, có thể thực hiện truyền trực tiếp dữ liệu xtrabackup giữa các nút nhưng chúng tôi không thực sự khuyến nghị. Các liên kết WAN có thể không đáng tin cậy và tốt hơn là bạn nên sao lưu cục bộ rồi sử dụng rsync với khả năng thử lại quá trình truyền bất cứ khi nào có điều gì đó không ổn.

Đầu tiên, hãy sao lưu trên phiên bản EC2 của chúng tôi:

[email protected]:~# innobackupex --user=tpcc --password=tpccpass /tmp/backup

Khi nó đã sẵn sàng, chúng tôi cần chuyển nó sang mạng DigitalOcean. Để làm điều đó một cách an toàn, chúng tôi sẽ tạo một người dùng mới trên giọt DO, tạo khóa SSH và sử dụng người dùng này để sao chép dữ liệu. Tất nhiên, bạn cũng có thể sử dụng bất kỳ người dùng hiện có nào, không bắt buộc phải tạo một người dùng mới. Vì vậy, hãy thêm một người dùng mới. Có nhiều cách để thực hiện việc này, chúng tôi sẽ sử dụng lệnh ‘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

Bây giờ, đã đến lúc tạo một cặp khóa ssh để sử dụng cho kết nối:

[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          |
|   .   .         |
|                 |
+-----------------+

Có khóa SSH, chúng ta cần thiết lập nó trên giọt Digital Ocean của mình. Chúng tôi cần tạo thư mục .ssh và tạo tệp ủy quyền_key với các quyền truy cập thích hợp.

[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

Sau đó, chúng ta cần sao chép khóa cá nhân của mình vào phiên bản EC2. Khi chúng tôi đã sẵn sàng với nó, chúng tôi có thể sao chép dữ liệu của mình. Như chúng tôi đã đề cập trước đó, chúng tôi sẽ sử dụng rsync cho điều đó - nó sẽ cho phép chúng tôi bắt đầu lại quá trình chuyển nếu vì bất kỳ lý do gì, quá trình bị gián đoạn. Kết hợp với SSH, chúng tôi đã tạo ra một phương pháp sao chép dữ liệu qua mạng WAN an toàn và mạnh mẽ. Hãy bắt đầu rsync trên máy chủ 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

Sau một thời gian, sẽ phụ thuộc vào lượng dữ liệu và tốc độ truyền, dữ liệu sao lưu của chúng tôi sẽ khả dụng trên giọt DigitalOcean. Điều này có nghĩa là đã đến lúc chuẩn bị bằng cách áp dụng InnoDB làm lại nhật ký, sau đó sao chép lại vào thư mục dữ liệu MySQL. Để làm được điều đó, chúng tôi cần dừng MySQL, xóa thư mục dữ liệu hiện tại, sao chép các tệp trở lại bằng cách sử dụng innobackupex hoặc theo cách thủ công, và cuối cùng, xác minh rằng chủ sở hữu và nhóm cho các tệp mới được đặt thành 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

Trước khi bắt đầu MySQL, chúng ta cũng cần đảm bảo rằng cả server_id và UUID đều khác nhau. Phần trước có thể được chỉnh sửa trong my.cnf, phần sau có thể được đảm bảo bằng cách:

[email protected]:~# rm /var/lib/mysql/auto.cnf

Bây giờ, chúng ta có thể khởi động MySQL:

[email protected]:~# service mysql start

Thiết lập bản sao

Chúng tôi đã sẵn sàng thiết lập sao chép giữa EC2 và DO, nhưng trước tiên chúng tôi cần thiết lập một đường hầm ssh - chúng tôi sẽ tạo một khóa ssh bổ sung cho người dùng ubuntu trên phiên bản EC2 và sao chép nó vào phiên bản DO. Sau đó, chúng tôi sẽ sử dụng người dùng ubuntu để tạo một đường hầm mà chúng tôi sẽ sử dụng để nhân bản.

Hãy bắt đầu bằng cách tạo khóa ssh mới:

[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|
|             . . |
|                 |
|                 |
|                 |
+-----------------+

Bước tiếp theo - chúng tôi cần thêm khóa công khai của mình vào tệp allow_keys trên phiên bản EC2 mà chúng tôi sẽ kết nối từ DigitalOcean để tạo đường hầm.

[email protected]:~# cat id_rsa_tunnel.pub >> /home/ubuntu/.ssh/authorized_keys

Chúng tôi cũng cần một khóa riêng để được chuyển sang giọt DO. Nó có thể được thực hiện theo nhiều cách, nhưng chúng tôi sẽ sử dụng scp an toàn bằng cách sử dụng người dùng và khóa rdscopy mà chúng tôi đã tạo trước đó:

[email protected]:~# scp -i id_rsa_rdscopy id_rsa_tunnel [email protected]:/home/rdscopy
id_rsa_tunnel                                                                                                                                                                    100% 3247     3.2KB/s   00:00

Đó là tất cả những gì chúng tôi cần - bây giờ chúng tôi có thể tạo đường hầm SSH. Chúng tôi muốn nó luôn có sẵn vì vậy chúng tôi sẽ sử dụng phiên màn hình cho nó.

[email protected]:~# screen -S tunnel
[email protected]:~# ssh -L 3307:localhost:3306 [email protected] -i /home/rdscopy/id_rsa_tunnel

Những gì chúng tôi đã làm ở đây là mở một đường hầm SSH giữa localhost, cổng 3307 và máy chủ từ xa, 54.224.107.6, cổng 3306 bằng người dùng “ubuntu” và một khóa nằm trong / home / rdscopy / id_rsa_tunnel. Tách phiên màn hình và máy chủ từ xa sẽ khả dụng qua 127.0.0.1:3307.

Để thiết lập sao chép, chúng ta vẫn cần thêm n người dùng mà chúng ta sẽ sử dụng để kết nối với MySQL trên EC2. Chúng tôi sẽ tạo nó trên máy chủ EC2 và chúng tôi sẽ sử dụng ‘127.0.0.1’ làm máy chủ lưu trữ - các kết nối qua đường hầm SSH sẽ giống như chúng đến từ 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)

Tất cả đã sẵn sàng để thiết lập sao chép, đã đến lúc làm theo quy trình truyền thống là tạo nô lệ dựa trên dữ liệu xtrabackup. Chúng tôi cần sử dụng dữ liệu từ xtrabackup_binlog_info để xác định vị trí chính tại thời điểm sao lưu. Vị trí này là những gì chúng ta muốn sử dụng trong lệnh CHANGE MASTER TO…. Hãy xem nội dung của tệp xtrabackup_binlog_info:

[email protected]:~# cat /home/rdscopy/xtrabackup_binlog_info
binlog.000052    896957365

Đây là tệp nhật ký nhị phân và vị trí mà chúng tôi sẽ sử dụng trong 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;

Đây là nó - bản sao sẽ được bắt đầu và đang chạy và nô lệ DigitalOcean của chúng tôi sẽ bắt kịp việc nhân rộng. Khi nó đã bắt kịp, tầng cơ sở dữ liệu của chúng tôi đã sẵn sàng để chuyển đổi. Tất nhiên, thông thường nó không chỉ là một nút đơn lẻ - bạn rất có thể sẽ phải thiết lập nhiều nô lệ trên DO trước khi cơ sở hạ tầng sẵn sàng xử lý lưu lượng sản xuất.

Bản thân Switchover là một chủ đề khác - bạn sẽ phải đưa ra kế hoạch để giảm thiểu thời gian ngừng hoạt động. Nói chung, lưu lượng truy cập nên được chuyển từ vị trí cũ sang vị trí mới nhưng nó nên được thực hiện như thế nào chủ yếu phụ thuộc vào môi trường của bạn. Nó có thể là bất cứ điều gì từ một thay đổi đơn giản trong mục nhập DNS, đến các tập lệnh phức tạp sẽ kéo tất cả các trình kích hoạt theo đúng thứ tự để chuyển hướng lưu lượng truy cập. Không có vấn đề gì, cơ sở dữ liệu của bạn hiện đã ở vị trí mới, sẵn sàng phục vụ các yêu cầu.