Di chuyển trực tuyến từ MySQL 5.6 Non-GTID sang MySQL 5.7 với GTID

Trong bài đăng trên blog này, chúng ta sẽ xem xét cách thực hiện di chuyển trực tuyến từ thiết lập độc lập MySQL 5.6 sang một tập hợp bản sao mới chạy trên MySQL 5.7, được triển khai và quản lý bởi ClusterControl.

Kế hoạch là thiết lập một liên kết nhân rộng từ cụm mới chạy trên MySQL 5.7 đến cụm chính đang chạy trên MySQL 5.6 (bên ngoài cung cấp ClusterControl), không sử dụng GTID. MySQL không hỗ trợ trộn GTID và không phải GTID trong một chuỗi sao chép. Vì vậy, chúng tôi cần thực hiện một số thủ thuật để chuyển đổi giữa các chế độ không phải GTID và GTID trong quá trình di chuyển.

Kiến trúc và kế hoạch di chuyển của chúng tôi có thể được minh họa như sau:

Thiết lập bao gồm 4 máy chủ, với đại diện như sau:

• mysql56a - Bậc thầy cũ - Oracle MySQL 5.6 không có GTID
• Cụm nô lệ:
  • mysql57a - Phiên bản chính mới - Oracle MySQL 5.7 với GTID
  • mysql57b - Nô lệ mới - Oracle MySQL 5.7 với GTID
• cc - Máy chủ ClusterControl - Máy chủ triển khai / quản lý / giám sát cho các nút cơ sở dữ liệu.

Tất cả các máy chủ MySQL 5.7 đang chạy trên Debian 10 (Buster), trong khi MySQL 5.6 đang chạy trên Debian 9 (Stretch).

Triển khai Cụm nô lệ

Đầu tiên, hãy chuẩn bị cụm nô lệ trước khi thiết lập liên kết sao chép từ bản chính cũ. Cấu hình cuối cùng của cụm nô lệ sẽ chạy trên MySQL 5.7, với GTID được bật. Cài đặt ClusterControl trên máy chủ ClusterControl (cc):

$ wget https://severalnines.com/downloads/install-cc
$ chmod 755 install-cc
$ ./install-cc

Làm theo hướng dẫn cho đến khi quá trình cài đặt hoàn tất. Sau đó, thiết lập SSH không mật khẩu từ ClusterControl thành mysql57a và mysql57b:

$ whoami
root
$ ssh-keygen -t rsa # press Enter on all prompts
$ ssh-copy-id [email protected] # enter the target host root password
$ ssh-copy-id [email protected] # enter the target host root password

Sau đó, đăng nhập vào ClusterControl UI, điền vào biểu mẫu ban đầu và đi đến phần ClusterControl -> Deploy -> MySQL Replication và điền như sau:

Sau đó nhấp vào Tiếp tục và chọn Oracle làm nhà cung cấp và 5.7 là nhà cung cấp phiên bản. Sau đó, chuyển đến phần cấu trúc liên kết và cấu hình nó như bên dưới:

Chờ cho đến khi quá trình triển khai hoàn tất và bạn sẽ thấy cụm mới như bên dưới:

Cụm nô lệ của chúng tôi đang chạy trên MySQL 5.7 với GTID hiện đã sẵn sàng.

Chuẩn bị cho Thầy cũ

Bản chính hiện tại mà chúng tôi muốn sao chép là MySQL 5.6 độc lập (bật nhật ký nhị phân, được định cấu hình id máy chủ, không có GTID) và nó đang phục vụ cơ sở dữ liệu sản xuất. Vì vậy, thời gian chết không phải là một tùy chọn cho việc di chuyển này. Mặt khác, ClusterControl định cấu hình MySQL 5.7 mới có hỗ trợ GTID, có nghĩa là chúng ta cần tắt chức năng GTID bên trong cụm phụ để có thể sao chép chính xác từ chính độc lập này.

Các dòng sau hiển thị cấu hình liên quan đến bản sao hiện tại của chúng tôi cho chính /etc/mysql/mysql.conf.d/mysqld.cnf trong chỉ thị [mysqld]:

server_id=1
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
relay_log=relay-bin
expire_logs_days=7
sync_binlog=1

Xác minh máy chủ MySQL đang tạo nhật ký nhị phân, không có GTID:

mysql> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+-------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000007 |   734310 |              |                  |                   |
+---------------+----------+--------------+------------------+-------------------+

1 row in set (0.00 sec)

Đối với không phải GTID, Executed_Gtid_Set dự kiến ​​sẽ trống. Lưu ý rằng cụm sao chép MySQL 5.7 mới của chúng tôi do ClusterControl triển khai được định cấu hình với GTID được bật.

1) Tạo một người dùng nhân bản để mysql57a sử dụng:

mysql> CREATE USER 'slave'@'192.168.10.31' IDENTIFIED BY 'slavepassword';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave'@192.168.10.31';

2) Tắt khôi phục tự động ClusterControl. Trong Giao diện người dùng ClusterControl -> chọn cụm -> đảm bảo Nút và Cụm khôi phục tự động được TẮT (biểu tượng nguồn màu đỏ), như được hiển thị trong ảnh chụp màn hình bên dưới:

Chúng tôi không muốn ClusterControl khôi phục nút trong cấu hình sao chép này.

3) Bây giờ chúng ta cần tạo một bản sao lưu mysqldump đầy đủ vì đây sẽ là một bản nâng cấp phiên bản lớn. Các công cụ sao lưu không chặn khác như Percona Xtrabackup hoặc MySQL Enterprise Backup không hỗ trợ khôi phục thành một phiên bản chính khác. Chúng tôi cũng cần duy trì vị trí và tệp nhật ký nhị phân hiện tại bằng cách sử dụng cờ --master-data:

$ mysqldump -u root -p --single-transaction --master-data=2 --all-databases > mysql56a-fullbackup.sql

Lưu ý rằng lệnh trên sẽ không chặn bất kỳ bảng InnoDB nào vì --single-transaction. Vì vậy, nếu bạn có bảng MyISAM, các bảng sẽ bị chặn trong thời gian sao lưu để duy trì tính nhất quán.

4) Sao chép bản sao lưu từ mysql56a sang mysql57a và mysql57b:

$ scp mysql56a-fullbackup.sql [email protected]:~
$ scp mysql56a-fullbackup.sql [email protected]:~

Chuẩn bị Cụm nô lệ

Ở giai đoạn này, chúng tôi sẽ định cấu hình cụm nô lệ để bắt đầu sao chép từ chính cũ, mysql56a mà không có GTID.

1) Dừng sao chép giữa mysql57a và mysql57b, xóa tất cả thông tin đăng nhập liên quan đến nô lệ được cấu hình bởi ClusterControl và tắt chế độ chỉ đọc trên mysql57b:

mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;

2) Tắt GTID trên mysql57a:

mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF';
mysql> SET GLOBAL enforce_gtid_consistency = 'OFF';

3) Tắt GTID trên mysql57b:

mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF';
mysql> SET GLOBAL enforce_gtid_consistency = 'OFF';

4) Khôi phục bản sao lưu mysqldump trên mysql57a:

$ mysql -uroot -p < mysql56a-fullbackup.sql

5) Khôi phục bản sao lưu mysqldump trên mysql57b:

$ mysql -uroot -p < mysql56a-fullbackup.sql

6) Chạy tập lệnh nâng cấp MySQL trên mysql57a (để kiểm tra và cập nhật tất cả các bảng lên phiên bản hiện tại):

$ mysql_upgrade -uroot -p

7) Chạy tập lệnh nâng cấp MySQL trên mysql57b (để kiểm tra và cập nhật tất cả các bảng lên phiên bản hiện tại):

$ mysql_upgrade -uroot -p

Cả hai máy chủ trên cụm máy chủ hiện đã được sắp xếp với ảnh chụp nhanh dữ liệu từ máy chủ cũ, mysql56a và hiện đã sẵn sàng sao chép.

Thiết lập Bản sao cho Cụm nô lệ

1) Đặt lại nhật ký nhị phân bằng cách sử dụng RESET MASTER trên mysql57a, vì vậy chúng tôi không phải chỉ định tệp nhị phân và định vị nhật ký sau này trên mysql57b. Ngoài ra, chúng tôi xóa tất cả các tham chiếu GTID hiện có đã được định cấu hình trước đó:

mysql> RESET MASTER;
mysql> SET @@global.gtid_purged='';

2) Trên mysql57a, truy xuất tệp binlog và vị trí từ tệp kết xuất, mysql56a-fullbackup.sql:

$ head -100 mysql56a-fullbackup.sql | grep LOG_POS
-- CHANGE MASTER TO MASTER_LOG_FILE='binlog.000007', MASTER_LOG_POS=4677987;

3) Bắt đầu sao chép nô lệ từ máy chủ cũ, mysql56a sang máy chủ mới mysql57a, bằng cách chỉ định các giá trị MASTER_LOG_FILE và MASTER_LOG_POS chính xác được truy xuất ở bước trước. Trên mysql57a:

mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.22', MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_LOG_FILE='binlog.000007', MASTER_LOG_POS=4677987;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

Đảm bảo rằng bạn nhìn thấy các dòng sau:

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Bạn có thể cần phải đợi cho đến khi mysql57a bắt kịp với mysql56a bằng cách theo dõi "Seconds_Behind_Master" và đảm bảo rằng nó quay bằng 0.

4) Tại thời điểm này, mysql57a đang sao chép dữ liệu từ mysql56a, có nghĩa là tất cả người dùng được tạo bởi ClusterControl hiện đang bị thiếu trong máy chủ (vì mysql57a hiện đang theo dõi dữ liệu trên mysql56a). ClusterControl sẽ gặp sự cố khi kết nối với mysql57a và nó sẽ xuất hiện là "không hoạt động". Về cơ bản, điều đó có nghĩa là ClusterControl không thể kết nối với máy chủ MySQL vì thiếu các khoản tài trợ. Những người dùng bị thiếu là:

• [email protected]
• [email protected] '{tất cả các nút trong một cụm cụ thể}'
• [email protected] '{ClusterControl host}'

Tất cả thông tin đăng nhập được lưu trữ an toàn trong ClusterControl và chính máy chủ cơ sở dữ liệu. Bạn cần có quyền truy cập root để lấy lại thông tin xác thực từ các tệp có liên quan.

Bây giờ, hãy tạo lại những người dùng bị thiếu trên trang cái mới, mysql57a:

a) Tạo người dùng sao lưu (mật khẩu được lấy từ /etc/mysql/secrets-backup.cnf trên mysql57a):

mysql> CREATE USER [email protected] IDENTIFIED BY '[email protected]!65%JlNB1z';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, SUPER, REPLICATION CLIENT ON *.* TO [email protected];

b) Tạo người dùng sao chép, cho tất cả các máy chủ DB (mật khẩu được lấy từ biến repl_password bên trong /etc/cmon.d/cmon_X.cnf trên máy chủ ClusterControl, trong đó X là ID cụm của cụm máy chủ):

mysql> CREATE USER 'rpl_user'@'192.168.10.31' IDENTIFIED BY '68n61F+bdsW1}[email protected]}x5J';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'rpl_user'@'192.168.10.31';
mysql> CREATE USER 'rpl_user'@'192.168.10.32' IDENTIFIED BY '68n61F+bdsW1}[email protected]}x5J';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'rpl_user'@'192.168.10.32';

c) Tạo hai người dùng cơ sở dữ liệu cmon (một cho địa chỉ IP và một cho tên máy chủ) để sử dụng ClusterControl (mật khẩu được lấy từ biến mysql_password bên trong /etc/cmon.d/cmon_X.cnf trên máy chủ ClusterControl, trong đó X là ID cụm của máy chủ cụm):

mysql> CREATE USER [email protected]'192.168.10.19' IDENTIFIED BY 'My&Passw0rd90';
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'192.168.10.19' WITH GRANT OPTION;
mysql> CREATE USER [email protected]'cc.local' IDENTIFIED BY 'My&Passw0rd90';
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'cc.local' WITH GRANT OPTION;

5) Tại thời điểm này, mysql57a sẽ xuất hiện màu xanh lục trong ClusterControl. Bây giờ, chúng ta có thể thiết lập một liên kết sao chép từ mysql57a đến mysql57b. Trên mysql57b:

mysql> RESET MASTER;
mysql> SET @@global.gtid_purged='';
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.31', MASTER_USER = 'rpl_user', MASTER_PASSWORD = '68n61F+bdsW1}[email protected]}x5J';
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

** Chúng tôi không cần chỉ định MASTER_LOG_FILE và MASTER_LOG_POS vì nó sẽ luôn bắt đầu với vị trí ban đầu cố định sau khi ĐẶT LẠI MASTER ở bước # 1.

Đảm bảo rằng bạn nhìn thấy các dòng sau:

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Theo dõi trạng thái sao chép và đảm bảo rằng mysql57b theo kịp với mysql57a và mysql57a theo kịp với mysql56a. Sau đó, bạn có thể cần bật chế độ chỉ đọc trên mysql57b (và / hoặc mysql57a) để bảo vệ khỏi việc ghi nhầm.

mysql> SET GLOBAL super_read_only = 1;
mysql> SET GLOBAL read_only = 1;

Từ giao diện người dùng ClusterControl, bạn sẽ thấy trạng thái hiện tại trong phần Tổng quan:

Tại thời điểm này, chính mới mysql57a, 192.168.10.31 đang sao chép từ máy chủ độc lập cũ mysql56a, 192.168.10.22, trong khi máy chủ phụ mysql57b mới (chỉ đọc) đang sao chép từ mysql57a, 192.168.10.31. Tất cả các nút được đồng bộ hóa với độ trễ sao chép bằng 0.

Ngoài ra, bạn có thể nhận xét các dòng sau bên trong tệp cấu hình MySQL trong phần [mysqld]:

#gtid_mode=ON
#enforce_gtid_consistency=1

Bật GTID trên Cụm nô lệ

Lưu ý rằng đối với MySQL 5.6 trở lên, ClusterControl không hỗ trợ triển khai không phải GTID trên một số tính năng quản lý của nó nữa như Rebuild Replication Slave và Change Replication Master. Vì vậy, trong thời gian tạm dừng (khi bạn trỏ ứng dụng đến cụm mới) từ máy chủ MySQL độc lập (mysql56a), bạn nên bật GTID trở lại trên mysql57a và mysql57b bằng các bước sau:

1) Đảm bảo tắt tính năng khôi phục tự động ClusterControl:

2) Trong thời gian bảo trì bị cắt, chúng tôi phải ngừng sao chép từ chính cũ, mysql56a, hãy xóa tất cả cấu hình nô lệ trên mysql57a và bật lại GTID. Trên mysql57a, hãy chạy các lệnh sau theo đúng thứ tự:

mysql> SHOW SLAVE STATUS\G # Make sure you see "Slave has read all relay log"
mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL enforce_gtid_consistency = 'ON';
mysql> SET GLOBAL gtid_mode = 'ON';

Tại thời điểm này, thực tế là an toàn cho ứng dụng của bạn khi bắt đầu viết lên bản chính mới, mysql57a. MySQL độc lập cũ hiện đã ra khỏi chuỗi sao chép và có thể bị đóng.

3) Lặp lại các bước tương tự cho mysql57b. Hãy nhớ làm theo các bước theo đúng thứ tự:

mysql> SHOW SLAVE STATUS\G # Make sure you see "Slave has read all relay log"
mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL enforce_gtid_consistency = 'ON';
mysql> SET GLOBAL gtid_mode = 'ON';

4) Sau đó, đặt lại trang cái trên trang cái mới, mysql57a:

mysql> RESET MASTER;

3) Sau đó, trên nô lệ mới, mysql57b thiết lập liên kết sao chép bằng GTID tới mysql57a:

mysql> RESET MASTER;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.31', MASTER_USER = 'rpl_user', MASTER_PASSWORD = '68n61F+bdsW1}[email protected]}x5J', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

Đảm bảo rằng bạn thấy các trường Retrieved_Gtid_Set và Executed_Gtid_Set có giá trị GTID của nó.

4) Tại thời điểm này, chúng tôi đã khôi phục lại cấu hình sao chép như đã được cấu hình trước đó bởi ClusterControl trong giai đoạn triển khai cụm. Sau đó, chúng tôi có thể bật chế độ chỉ đọc trên máy nô lệ mới, mysql57b để bảo vệ nó khỏi việc ghi nhầm:

mysql> SET GLOBAL super_read_only = 1;
mysql> SET GLOBAL read_only = 1;

Cuối cùng, bật lại tính năng khôi phục tự động ClusterControl cho cụm, bằng cách chuyển các biểu tượng nguồn sang màu xanh lục. Sau đó, bạn có thể gỡ bỏ trang chủ cũ, mysql56a. Chúng tôi vừa hoàn thành quá trình di chuyển trực tuyến từ MySQL 5.6 sang MySQL 5.7 với thời gian ngừng hoạt động rất tối thiểu. Các bước tương tự cũng sẽ hoạt động để chuyển sang MySQL 8.0.