Thiết lập cụm nhân bản chính / phụ là trường hợp sử dụng phổ biến trong hầu hết các tổ chức. Sử dụng MySQL Replication cho phép dữ liệu của bạn được sao chép trên các môi trường khác nhau và đảm bảo rằng thông tin sẽ được sao chép. Nó là không đồng bộ và đơn luồng (theo mặc định), nhưng sao chép cũng cho phép bạn định cấu hình nó đồng bộ (hoặc thực sự là "bán đồng bộ") và có thể chạy luồng phụ cho nhiều luồng hoặc song song.
Ý tưởng này rất phổ biến và thường xuất hiện với một thiết lập đơn giản, làm cho nô lệ của nó đóng vai trò khôi phục hoặc cho các giải pháp sao lưu. Tuy nhiên, điều này luôn phải trả giá, đặc biệt là khi các truy vấn không hợp lệ (chẳng hạn như thiếu khóa chính hoặc khóa duy nhất) được sao chép hoặc một số vấn đề với phần cứng (chẳng hạn như sự cố IO mạng hoặc đĩa). Khi những vấn đề này xảy ra, vấn đề phổ biến nhất phải đối mặt là độ trễ sao chép.
Độ trễ sao chép là chi phí của độ trễ đối với (các) giao dịch hoặc (các) hoạt động được tính bằng chênh lệch thời gian thực hiện giữa nút chính / chủ so với nút chờ / phụ. Các trường hợp nhất định trong MySQL dựa trên các truy vấn không hợp lệ được sao chép như thiếu khóa chính hoặc chỉ mục không hợp lệ, phần cứng mạng kém hoặc card mạng bị trục trặc, vị trí xa giữa các vùng hoặc khu vực khác nhau hoặc một số quá trình như sao lưu vật lý đang chạy có thể gây ra cơ sở dữ liệu MySQL của bạn để trì hoãn việc áp dụng giao dịch được sao chép hiện tại. Đây là một trường hợp rất phổ biến khi chẩn đoán các vấn đề này. Trong blog này, chúng tôi sẽ kiểm tra cách đối phó với những trường hợp này và những gì cần xem xét nếu bạn đang gặp phải độ trễ sao chép MySQL.
"TÌNH TRẠNG TRƯỢT HIỂN THỊ":Thần chú của MySQL DBA
Trong một số trường hợp, đây là viên đạn bạc khi xử lý độ trễ sao chép và nó tiết lộ hầu hết mọi thứ nguyên nhân gây ra sự cố trong cơ sở dữ liệu MySQL của bạn. Đơn giản chỉ cần chạy câu lệnh SQL này trong nút nô lệ của bạn bị nghi ngờ đang gặp phải độ trễ sao chép.
Các trường ban đầu thường dùng để theo dõi sự cố là,
- Slave_IO_State - Nó cho bạn biết luồng đang làm gì. Trường này sẽ cung cấp cho bạn thông tin chi tiết tốt nếu tình trạng sao chép đang chạy bình thường, đối mặt với các sự cố mạng như kết nối lại với thiết bị chính hoặc mất quá nhiều thời gian để xác nhận dữ liệu, điều này có thể chỉ ra sự cố đĩa khi đồng bộ hóa dữ liệu với đĩa. Bạn cũng có thể xác định giá trị trạng thái này khi chạy DANH SÁCH TIẾN TRÌNH.
- Master_Log_File - Tên tệp binlog của Master nơi chuỗi I / O hiện đang được tìm nạp.
- Read_Master_Log_Pos - vị trí tệp binlog từ cái chính nơi luồng I / O nhân bản đã đọc.
- Relay_Log_File - tên tệp nhật ký chuyển tiếp mà chuỗi SQL hiện đang thực thi các sự kiện
- Relay_Log_Pos - vị trí binlog từ tệp được chỉ định trong Relay_Log_File mà chuỗi SQL đã thực thi.
- Relay_Master_Log_File - Tệp binlog chính mà chuỗi SQL đã thực thi và là một đồng dư với giá trị Read_Master_Log_Pos.
- Seconds_Behind_Master - trường này hiển thị sự khác biệt gần đúng giữa dấu thời gian hiện tại trên máy chủ với dấu thời gian trên máy chủ cho sự kiện hiện đang được xử lý trên máy phụ. Tuy nhiên, trường này có thể không cho bạn biết độ trễ chính xác nếu mạng chậm vì sự khác biệt về giây được thực hiện giữa luồng SQL nô lệ và luồng I / O phụ. Vì vậy, có thể có trường hợp nó có thể bị bắt với luồng I / O nô lệ đọc chậm, nhưng tôi biết nó đã khác rồi.
- Slave_SQL_Running_State - trạng thái của chuỗi SQL và giá trị giống với giá trị trạng thái được hiển thị trong DANH SÁCH TIẾN TRÌNH.
- Retrieved_Gtid_Set - Có sẵn khi sử dụng bản sao GTID. Đây là tập hợp GTID tương ứng với tất cả các giao dịch mà nô lệ này nhận được.
- Executed_Gtid_Set - Có sẵn khi sử dụng bản sao GTID. Đó là tập hợp GTID được ghi trong nhật ký nhị phân.
Ví dụ:hãy lấy ví dụ dưới đây sử dụng bản sao GTID và đang gặp phải độ trễ sao chép:
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.10.70
Master_User: cmon_replication
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000038
Read_Master_Log_Pos: 826608419
Relay_Log_File: relay-bin.000004
Relay_Log_Pos: 468413927
Relay_Master_Log_File: binlog.000038
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: 826608206
Relay_Log_Space: 826607743
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: 251
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: 45003
Master_UUID: 36272880-a7b0-11e9-9ca6-525400cae48b
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: copy to tmp table
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 36272880-a7b0-11e9-9ca6-525400cae48b:7631-9192
Executed_Gtid_Set: 36272880-a7b0-11e9-9ca6-525400cae48b:1-9191,
864dd532-a7af-11e9-85f2-525400cae48b:1-173,
df68c807-a7af-11e9-9b56-525400cae48b:1-4
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)Chẩn đoán các vấn đề như thế này, mysqlbinlog cũng có thể là công cụ của bạn để xác định truy vấn nào đang chạy trên một vị trí x &y binlog cụ thể. Để xác định điều này, hãy lấy Retrieved_Gtid_Set, Relay_Log_Pos và Relay_Log_File. Xem lệnh bên dưới:
[[email protected] mysql]# mysqlbinlog --base64-output=DECODE-ROWS --include-gtids="36272880-a7b0-11e9-9ca6-525400cae48b:9192" --start-position=468413927 -vvv relay-bin.000004
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @[email protected]@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 468413927
#200206 4:36:14 server id 45003 end_log_pos 826608271 CRC32 0xc702eb4c GTID last_committed=1562 sequence_number=1563 rbr_only=no
SET @@SESSION.GTID_NEXT= '36272880-a7b0-11e9-9ca6-525400cae48b:9192'/*!*/;
# at 468413992
#200206 4:36:14 server id 45003 end_log_pos 826608419 CRC32 0xe041ec2c Query thread_id=24 exec_time=31 error_code=0
use `jbmrcd_date`/*!*/;
SET TIMESTAMP=1580963774/*!*/;
SET @@session.pseudo_thread_id=24/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
ALTER TABLE NewAddressCode ADD INDEX PostalCode(PostalCode)
/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET [email protected]_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;Nó cho chúng ta biết rằng nó đang cố gắng sao chép và thực thi một câu lệnh DML cố gắng trở thành nguồn gốc của sự chậm trễ. Bảng này là một bảng lớn chứa 13 triệu hàng.
Kiểm tra HIỂN THỊ TIẾN TRÌNH, HIỂN THỊ TRẠNG THÁI ĐỘNG CƠ INNODB với tổ hợp lệnh ps, top, iostat
Trong một số trường hợp, TRẠNG THÁI CHẬM HIỂN THỊ không đủ để cho chúng ta biết thủ phạm. Có thể các câu lệnh được sao chép bị ảnh hưởng bởi các quy trình nội bộ đang chạy trong máy chủ cơ sở dữ liệu MySQL. Chạy các câu lệnh SHOW [FULL] PROCESSLIST và SHOW ENGINE INNODB STATUS cũng cung cấp dữ liệu thông tin cung cấp cho bạn thông tin chi tiết về nguồn gốc của vấn đề.
Ví dụ:giả sử một công cụ đo điểm chuẩn đang chạy gây bão hòa IO đĩa và CPU. Bạn có thể kiểm tra bằng cách chạy cả hai câu lệnh SQL. Kết hợp nó với ps và các lệnh hàng đầu.
Bạn cũng có thể xác định tắc nghẽn với bộ lưu trữ ổ đĩa của mình bằng cách chạy iostat cung cấp số liệu thống kê về ổ đĩa hiện tại mà bạn đang cố gắng chẩn đoán. Chạy iostat có thể hiển thị mức độ bận hoặc tải của máy chủ của bạn. Ví dụ:được thực hiện bởi một nô lệ đang bị trễ nhưng đồng thời cũng có mức sử dụng IO cao,
[[email protected] ~]# iostat -d -x 10 10
Linux 3.10.0-693.5.2.el7.x86_64 (testnode5) 02/06/2020 _x86_64_ (2 CPU)
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.42 3.71 60.65 218.92 568.39 24.47 0.15 2.31 13.79 1.61 0.12 0.76
dm-0 0.00 0.00 3.70 60.48 218.73 568.33 24.53 0.15 2.36 13.85 1.66 0.12 0.76
dm-1 0.00 0.00 0.00 0.00 0.04 0.01 21.92 0.00 63.29 2.37 96.59 22.64 0.01
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.20 392.30 7983.60 2135.60 49801.55 12.40 36.70 3.84 13.01 3.39 0.08 69.02
dm-0 0.00 0.00 392.30 7950.20 2135.60 50655.15 12.66 36.93 3.87 13.05 3.42 0.08 69.34
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.06 183.67 0.00 183.67 61.67 1.85
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 1.40 370.93 6775.42 2557.04 46184.22 13.64 43.43 6.12 11.60 5.82 0.10 73.25
dm-0 0.00 0.00 370.93 6738.76 2557.04 47029.62 13.95 43.77 6.20 11.64 5.90 0.10 73.41
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.03 107.00 0.00 107.00 35.67 1.07
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 299.80 7253.35 1916.88 52766.38 14.48 30.44 4.59 15.62 4.14 0.10 72.09
dm-0 0.00 0.00 299.80 7198.60 1916.88 51064.24 14.13 30.68 4.66 15.70 4.20 0.10 72.57
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.10 215.50 8939.60 1027.60 67497.10 14.97 59.65 6.52 27.98 6.00 0.08 72.50
dm-0 0.00 0.00 215.50 8889.20 1027.60 67495.90 15.05 60.07 6.60 28.09 6.08 0.08 72.75
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.01 32.33 0.00 32.33 30.33 0.91
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.90 140.40 8922.10 625.20 54709.80 12.21 11.29 1.25 9.88 1.11 0.08 68.60
dm-0 0.00 0.00 140.40 8871.50 625.20 54708.60 12.28 11.39 1.26 9.92 1.13 0.08 68.83
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.01 27.33 0.00 27.33 9.33 0.28
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 1.70 284.50 8621.30 24228.40 51535.75 17.01 34.14 3.27 8.19 3.11 0.08 72.78
dm-0 0.00 0.00 290.90 8587.10 25047.60 53434.95 17.68 34.28 3.29 8.02 3.13 0.08 73.47
dm-1 0.00 0.00 0.00 2.00 0.00 8.00 8.00 0.83 416.45 0.00 416.45 63.60 12.72
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.30 851.60 11018.80 17723.60 85165.90 17.34 142.59 12.44 7.61 12.81 0.08 99.75
dm-0 0.00 0.00 845.20 10938.90 16904.40 83258.70 17.00 143.44 12.61 7.67 12.99 0.08 99.75
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 1.10 24.60 12965.40 420.80 51114.45 7.93 39.44 3.04 0.33 3.04 0.07 93.39
dm-0 0.00 0.00 24.60 12890.20 420.80 51114.45 7.98 40.23 3.12 0.33 3.12 0.07 93.35
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 3.60 13420.70 57.60 51942.00 7.75 0.95 0.07 0.33 0.07 0.07 92.11
dm-0 0.00 0.00 3.60 13341.10 57.60 51942.00 7.79 0.95 0.07 0.33 0.07 0.07 92.08
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00Kết quả trên hiển thị mức sử dụng IO cao và số lần ghi cao. Nó cũng tiết lộ rằng kích thước hàng đợi trung bình và kích thước yêu cầu trung bình đang di chuyển, có nghĩa là đó là dấu hiệu của khối lượng công việc cao. Trong những trường hợp này, bạn cần xác định xem có quá trình bên ngoài nào khiến MySQL bị nghẹt các chuỗi sao chép hay không.
ClusterControl có thể trợ giúp như thế nào?
Với ClusterControl, việc xử lý lỗi nô lệ và xác định thủ phạm rất dễ dàng và hiệu quả. Nó trực tiếp cho bạn biết trong giao diện người dùng web, xem bên dưới:
Nó cho bạn thấy độ trễ nô lệ hiện tại mà các nút nô lệ của bạn đang gặp phải. Không chỉ vậy, với bảng điều khiển SCUMM, nếu được bật, cung cấp cho bạn nhiều thông tin chi tiết hơn về tình trạng của nút nô lệ của bạn hoặc thậm chí toàn bộ cụm đang hoạt động:
Không chỉ có những thứ này trong ClusterControl, nó còn cung cấp cho bạn khả năng tránh các truy vấn xấu xảy ra với các tính năng này như được thấy bên dưới,
Các chỉ mục dư thừa cho phép bạn xác định rằng các chỉ mục này có thể gây ra các vấn đề về hiệu suất cho các truy vấn đến tham chiếu đến các chỉ mục trùng lặp. Nó cũng cho bạn biết các bảng không có Khóa chính thường là vấn đề phổ biến của độ trễ nô lệ khi truy vấn SQL nhất định hoặc các giao dịch tham chiếu đến các bảng lớn không có khóa chính hoặc khóa duy nhất khi nó được sao chép sang các khóa phụ.
Kết luận
Đối phó với độ trễ của MySQL Replication là một vấn đề thường xuyên xảy ra trong thiết lập sao chép master-slave. Nó có thể dễ dàng để chẩn đoán, nhưng rất khó để giải quyết. Đảm bảo rằng bạn có các bảng của mình với khóa chính hoặc khóa duy nhất, đồng thời xác định các bước và công cụ về cách khắc phục sự cố và chẩn đoán nguyên nhân của độ trễ nô lệ. Tuy nhiên, hiệu quả luôn là chìa khóa khi giải quyết vấn đề.
