MySQL nô lệ có thể trở nên không nhất quán. Bạn có thể cố gắng tránh nó, nhưng nó thực sự khó. Đặt super_read_only và sử dụng sao chép dựa trên hàng có thể giúp ích rất nhiều, nhưng bất kể bạn làm gì, vẫn có khả năng nô lệ của bạn trở nên không nhất quán.
Có thể làm gì để xây dựng lại một MySQL slave không nhất quán? Trong bài đăng blog này, chúng tôi sẽ xem xét vấn đề này.
Trước hết, hãy thảo luận về những gì phải xảy ra để xây dựng lại nô lệ. Để đưa một nút vào MySQL Replication, nó phải được cung cấp dữ liệu từ một trong các nút trong cấu trúc liên kết sao chép. Dữ liệu này phải nhất quán tại thời điểm mà nó được thu thập. Bạn không thể lấy nó trên cơ sở từng bảng hoặc lược đồ theo giản đồ, bởi vì điều này sẽ làm cho nút được cung cấp không nhất quán trong nội bộ. Có nghĩa là một số dữ liệu sẽ cũ hơn một số phần khác của tập dữ liệu.
Ngoài tính nhất quán của dữ liệu, cũng có thể thu thập thông tin về mối quan hệ giữa dữ liệu và trạng thái sao chép. Bạn muốn có vị trí nhật ký nhị phân mà tại đó dữ liệu được thu thập là nhất quán hoặc ID giao dịch toàn cầu của giao dịch được thực hiện cuối cùng trên nút là nguồn dữ liệu.
Điều này dẫn chúng ta đến những cân nhắc sau. Bạn có thể xây dựng lại một nô lệ bằng cách sử dụng bất kỳ công cụ sao lưu nào miễn là công cụ này có thể tạo bản sao lưu nhất quán và nó bao gồm các tọa độ sao chép cho thời điểm mà bản sao lưu nhất quán. Điều này cho phép chúng tôi chọn từ một số tùy chọn.
Sử dụng Mysqldump để xây dựng lại MySQL Slave không nhất quán
Mysqldump là công cụ cơ bản nhất mà chúng ta phải đạt được điều này. Nó cho phép chúng tôi tạo một bản sao lưu hợp lý, trong số những người khác, dưới dạng các câu lệnh SQL. Điều quan trọng, mặc dù là cơ bản, nhưng nó vẫn cho phép chúng ta sao lưu nhất quán:nó có thể sử dụng giao dịch để đảm bảo rằng dữ liệu nhất quán vào đầu giao dịch. Nó cũng có thể ghi ra tọa độ sao chép cho điểm đó, thậm chí là toàn bộ câu lệnh CHANGE MASTER, giúp dễ dàng bắt đầu sao chép bằng cách sử dụng bản sao lưu.
Sử dụng Mydumper để xây dựng lại MySQL Slave không nhất quán
Một tùy chọn khác là sử dụng mydumper - công cụ này, giống như mysqldump, tạo một bản sao lưu hợp lý và cũng giống như mysqldump, có thể được sử dụng để tạo một bản sao lưu nhất quán của cơ sở dữ liệu. Sự khác biệt chính giữa mydumper và mysqldump là mydumper, khi được kết hợp với myloader, có thể kết xuất và khôi phục dữ liệu song song, cải thiện kết xuất và đặc biệt là thời gian khôi phục.
Sử dụng Ảnh chụp nhanh để xây dựng lại MySQL Slave không nhất quán
Đối với những người sử dụng nhà cung cấp dịch vụ đám mây, khả năng là chụp nhanh bộ nhớ khối bên dưới. Ảnh chụp nhanh tạo ra chế độ xem dữ liệu theo thời gian. Tuy nhiên, quá trình này khá phức tạp vì tính nhất quán của dữ liệu và khả năng khôi phục nó phụ thuộc chủ yếu vào cấu hình MySQL.
Bạn nên đảm bảo rằng cơ sở dữ liệu hoạt động ở chế độ lâu bền (nó được cấu hình theo cách mà sự cố của MySQL sẽ không dẫn đến mất mát dữ liệu). Điều này là do (theo quan điểm của MySQL) chụp nhanh một khối lượng và sau đó bắt đầu một phiên bản MySQL khác từ dữ liệu được lưu trữ trong đó, về cơ bản, quá trình tương tự như nếu bạn giết -9 mysqld và sau đó bắt đầu lại nó. Quá trình khôi phục InnoDB phải xảy ra, phát lại các giao dịch đã được lưu trữ trong nhật ký nhị phân, các giao dịch khôi phục chưa hoàn thành trước sự cố, v.v.
Nhược điểm của quy trình xây dựng lại dựa trên ảnh chụp nhanh là nó bị ràng buộc chặt chẽ với nhà cung cấp hiện tại. Bạn không thể dễ dàng sao chép dữ liệu ảnh chụp nhanh từ nhà cung cấp đám mây này sang nhà cung cấp dịch vụ đám mây khác. Bạn có thể di chuyển nó giữa các vùng khác nhau nhưng nó vẫn sẽ là cùng một nhà cung cấp.
Sử dụng Xtrabackup hoặc Mariabackup để xây dựng lại MySQL Slave không nhất quán
Cuối cùng là xtrabackup / mariabackup - đây là một công cụ được viết bởi Percona và được phân tách bởi MariaDB cho phép tạo một bản sao lưu vật lý. Nó nhanh hơn nhiều so với sao lưu logic - nó bị hạn chế chủ yếu bởi hiệu suất phần cứng - đĩa hoặc mạng là những nguyên nhân có thể xảy ra tắc nghẽn nhất. Phần lớn khối lượng công việc liên quan đến việc sao chép tệp từ thư mục dữ liệu MySQL sang một vị trí khác (trên cùng một máy chủ lưu trữ hoặc qua mạng).
Mặc dù không nhanh bằng ảnh chụp nhanh bộ nhớ khối, nhưng xtrabackup linh hoạt hơn và có thể được sử dụng trong mọi môi trường. Bản sao lưu mà nó tạo ra bao gồm các tệp, do đó hoàn toàn có thể sao chép bản sao lưu vào bất kỳ vị trí nào bạn muốn. Một nhà cung cấp đám mây khác, trung tâm dữ liệu cục bộ của bạn, không thành vấn đề miễn là bạn có thể chuyển tệp từ vị trí hiện tại của mình.
Nó thậm chí không cần phải có kết nối mạng - bạn cũng có thể sao chép bản sao lưu vào một số thiết bị "có thể chuyển nhượng" như USB SSD hoặc thậm chí là thẻ USB, miễn là nó có thể chứa tất cả và lưu trữ dữ liệu đó trong túi của bạn khi bạn di chuyển từ trung tâm dữ liệu này sang trung tâm dữ liệu khác.
Cách xây dựng lại MySQL Slave bằng Xtrabackup?
Chúng tôi quyết định tập trung vào xtrabackup, do tính linh hoạt và khả năng hoạt động của nó trong hầu hết các môi trường mà MySQL có thể tồn tại. Làm cách nào để bạn xây dựng lại nô lệ của mình bằng xtrabackup? Hãy cùng xem.
Ban đầu, chúng ta có một chủ nhân và một nô lệ, bị một số vấn đề về sao chép:
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.141
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000004
Read_Master_Log_Pos: 386
Relay_Log_File: relay-bin.000008
Relay_Log_Pos: 363
Relay_Master_Log_File: binlog.000004
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1007
Last_Error: Error 'Can't create database 'mytest'; database exists' on query. Default database: 'mytest'. Query: 'create database mytest'
Skip_Counter: 0
Exec_Master_Log_Pos: 195
Relay_Log_Space: 756
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1007
Last_SQL_Error: Error 'Can't create database 'mytest'; database exists' on query. Default database: 'mytest'. Query: 'create database mytest'
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1001
Master_UUID: 53d96192-53f7-11ea-9c3c-080027c5bc64
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp: 200306 11:47:42
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 53d96192-53f7-11ea-9c3c-080027c5bc64:9
Executed_Gtid_Set: 53d96192-53f7-11ea-9c3c-080027c5bc64:1-8,
ce7d0c38-53f7-11ea-9f16-080027c5bc64:1-3
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
Master_public_key_path:
Get_master_public_key: 0
Network_Namespace:
1 row in set (0.00 sec)Như bạn thấy, có vấn đề với một trong các lược đồ. Giả sử chúng ta phải xây dựng lại nút này để đưa nó trở lại bản sao. Đây là các bước chúng tôi phải thực hiện.
Trước tiên, chúng ta phải đảm bảo rằng xtrabackup đã được cài đặt. Trong trường hợp của chúng tôi, chúng tôi sử dụng MySQL 8.0 do đó chúng tôi phải sử dụng xtrabackup trong phiên bản 8 để đảm bảo tính tương thích:
[email protected]:~# apt install percona-xtrabackup-80
Reading package lists... Done
Building dependency tree
Reading state information... Done
percona-xtrabackup-80 is already the newest version (8.0.9-1.bionic).
0 upgraded, 0 newly installed, 0 to remove and 143 not upgraded.Xtrabackup được cung cấp bởi Percona repository và bạn có thể tìm thấy hướng dẫn cài đặt tại đây:
https://www.percona.com/doc/percona-xtrabackup/8.0/installation/apt_repo.html
Công cụ này phải được cài đặt trên cả cái chính và cái phụ mà chúng ta muốn xây dựng lại.
Bước tiếp theo, chúng tôi sẽ xóa tất cả dữ liệu khỏi nô lệ "bị hỏng":
[email protected]:~# service mysql stop
[email protected]:~# rm -rf /var/lib/mysql/*Tiếp theo, chúng ta sẽ lấy bản sao lưu trên master và truyền nó tới slave. Xin lưu ý rằng một lớp lót cụ thể này yêu cầu kết nối gốc SSH không mật khẩu từ máy chủ đến máy phụ:
[email protected]:~ # xtrabackup --backup --compress --stream =xbstream --target-dir =. / | ssh [email protected] "xbstream -x --decompress -C / var / lib / mysql /"
Ở cuối, bạn sẽ thấy một dòng quan trọng:
200306 12:10:40 completed OK!Đây là chỉ báo rằng quá trình sao lưu đã hoàn tất OK. Đôi điều có thể vẫn xảy ra sai nhưng ít nhất chúng tôi đã có dữ liệu đúng. Tiếp theo, trên nô lệ, chúng ta phải chuẩn bị bản sao lưu.
[email protected]:~# xtrabackup --prepare --target-dir=/var/lib/mysql/
.
.
.
200306 12:16:07 completed OK!Bạn sẽ thấy, một lần nữa, quá trình đã hoàn tất OK. Bây giờ bạn có thể muốn sao chép dữ liệu trở lại thư mục dữ liệu MySQL. Chúng tôi không phải làm điều đó vì chúng tôi đã lưu trữ bản sao lưu phát trực tiếp trong / var / lib / mysql. Tuy nhiên, điều chúng tôi muốn làm là đảm bảo quyền sở hữu chính xác các tệp:
[email protected]:~# chown -R mysql.mysql /var/lib/mysqlBây giờ, hãy kiểm tra tọa độ GTID của bản sao lưu. Chúng tôi sẽ sử dụng chúng sau này khi thiết lập bản sao.
[email protected]:~# cat /var/lib/mysql/xtrabackup_binlog_info
binlog.000007 195 53d96192-53f7-11ea-9c3c-080027c5bc64:1-9Ok, tất cả có vẻ ổn, hãy khởi động MySQL và tiến hành định cấu hình bản sao:
[email protected]:~# service mysql start
[email protected]:~# mysql -ppass
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.0.18-9 Percona Server (GPL), Release '9', Revision '53e606f'
Copyright (c) 2009-2019 Percona LLC and/or its affiliates
Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>Bây giờ chúng ta phải đặt gtid_purged thành bộ GTID mà chúng ta tìm thấy trong bản sao lưu. Đó là những GTID đã được "bao phủ" trong bản sao lưu của chúng tôi. Chỉ GTID mới nên sao chép từ GTID chính.
mysql> SET GLOBAL gtid_purged='53d96192-53f7-11ea-9c3c-080027c5bc64:1-9';
Query OK, 0 rows affected (0.00 sec)
Now we can start the replication:
mysql> CHANGE MASTER TO MASTER_HOST='10.0.0.141', MASTER_USER='rpl_user', MASTER_PASSWORD='yIPpgNE4KE', MASTER_AUTO_POSITION=1;
Query OK, 0 rows affected, 2 warnings (0.02 sec)
mysql> START SLAVE;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.141
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000007
Read_Master_Log_Pos: 380
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 548
Relay_Master_Log_File: binlog.000007
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 380
Relay_Log_Space: 750
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1001
Master_UUID: 53d96192-53f7-11ea-9c3c-080027c5bc64
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 53d96192-53f7-11ea-9c3c-080027c5bc64:10
Executed_Gtid_Set: 53d96192-53f7-11ea-9c3c-080027c5bc64:1-10
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
Master_public_key_path:
Get_master_public_key: 0
Network_Namespace:
1 row in set (0.00 sec)Như bạn có thể thấy, nô lệ của chúng tôi đang sao chép từ chủ nhân của nó.
Cách xây dựng lại MySQL Slave bằng ClusterControl?
Nếu bạn là người dùng ClusterControl, thay vì thực hiện quá trình này, bạn có thể xây dựng lại nô lệ chỉ trong một vài cú nhấp chuột. Ban đầu, chúng tôi có một vấn đề rõ ràng với việc sao chép:
Nô lệ của chúng tôi không sao chép đúng cách do lỗi.
Tất cả những gì chúng ta phải làm là chạy công việc "Rebuild Replication Slave" .
Bạn sẽ thấy một hộp thoại mà bạn nên chọn một nút chính cho nô lệ mà bạn muốn xây dựng lại. Sau đó, nhấp vào Tiếp tục và bạn đã hoàn tất. ClusterControl sẽ xây dựng lại nô lệ và thiết lập bản sao cho bạn.
Trong thời gian ngắn, dựa trên kích thước tập dữ liệu, bạn sẽ thấy nô lệ đang hoạt động:
Như bạn có thể thấy, chỉ với một vài cú nhấp chuột, ClusterControl đã hoàn thành nhiệm vụ xây dựng lại nô lệ sao chép không nhất quán.
