Sao chép là một trong những cách phổ biến nhất để đạt được tính khả dụng cao cho MySQL và MariaDB. Nó đã trở nên mạnh mẽ hơn nhiều với việc bổ sung GTID và được kiểm tra kỹ lưỡng bởi hàng nghìn hàng nghìn người dùng. Tuy nhiên, MySQL Replication không phải là một thuộc tính ‘set and forget’, nó cần được theo dõi các vấn đề tiềm ẩn và duy trì để nó luôn hoạt động tốt. Trong bài đăng trên blog này, chúng tôi muốn chia sẻ một số mẹo và thủ thuật về cách duy trì, khắc phục sự cố và khắc phục sự cố với sao chép MySQL.
Làm cách nào để xác định xem MySQL Replication có ở trạng thái tốt hay không?
Đây là kỹ năng quan trọng nhất mà bất kỳ ai chăm sóc thiết lập sao chép MySQL đều phải có. Hãy xem nơi để tìm kiếm thông tin về trạng thái sao chép. Có một sự khác biệt nhỏ giữa MySQL và MariaDB và chúng ta cũng sẽ thảo luận về vấn đề này.
HIỂN THỊ TRẠNG THÁI CHẬM
Đây là phương pháp phổ biến nhất để kiểm tra trạng thái sao chép trên máy chủ nô lệ - nó luôn ở bên chúng tôi và đây thường là nơi đầu tiên chúng tôi thực hiện nếu chúng tôi mong đợi rằng có một số vấn đề với sao chép.
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.101
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000002
Read_Master_Log_Pos: 767658564
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 405
Relay_Master_Log_File: binlog.000002
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: 767658564
Relay_Log_Space: 606
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: 1
Master_UUID: 5d1e2227-07c6-11e7-8123-080027495a77
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:
Executed_Gtid_Set: 5d1e2227-07c6-11e7-8123-080027495a77:1-394233
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)Một số chi tiết có thể khác nhau giữa MySQL và MariaDB nhưng phần lớn nội dung sẽ giống nhau. Các thay đổi sẽ hiển thị trong phần GTID khi MySQL và MariaDB thực hiện theo một cách khác. Từ TRẠNG THÁI CHẬM HIỂN THỊ, bạn có thể lấy một số thông tin - cái nào được sử dụng, người dùng nào và cổng nào được sử dụng để kết nối với cái chính. Chúng tôi có một số dữ liệu về vị trí nhật ký nhị phân hiện tại (không còn quan trọng nữa vì chúng tôi có thể sử dụng GTID và quên binlog) và trạng thái của chuỗi sao chép SQL và I / O. Sau đó, bạn có thể xem liệu bộ lọc có được định cấu hình hay không. Bạn cũng có thể tìm thấy một số thông tin về lỗi, độ trễ sao chép, cài đặt SSL và GTID. Ví dụ trên đến từ MySQL 5.7 slave đang ở trạng thái khỏe mạnh. Hãy xem một số ví dụ về việc sao chép bị hỏng.
MariaDB [test]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.104
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000003
Read_Master_Log_Pos: 636
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 765
Relay_Master_Log_File: binlog.000003
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: 1032
Last_Error: Could not execute Update_rows_v1 event on table test.tab; Can't find record in 'tab', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log binlog.000003, end_log_pos 609
Skip_Counter: 0
Exec_Master_Log_Pos: 480
Relay_Log_Space: 1213
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: 1032
Last_SQL_Error: Could not execute Update_rows_v1 event on table test.tab; Can't find record in 'tab', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log binlog.000003, end_log_pos 609
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-1-73243
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
1 row in set (0.00 sec)Mẫu này được lấy từ MariaDB 10.1, bạn có thể thấy các thay đổi ở cuối đầu ra để làm cho nó hoạt động với MariaDB GTID’s. Điều quan trọng đối với chúng tôi là lỗi - bạn có thể thấy có điều gì đó không ổn trong chuỗi SQL:
Last_SQL_Error: Could not execute Update_rows_v1 event on table test.tab; Can't find record in 'tab', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log binlog.000003, end_log_pos 609Chúng ta sẽ thảo luận về vấn đề cụ thể này sau, bây giờ đủ để bạn thấy cách kiểm tra xem có bất kỳ lỗi nào trong quá trình sao chép hay không bằng cách sử dụng SHOW SLAVE STATUS.
Một thông tin quan trọng khác đến từ TRẠNG THÁI CHẬM HIỂN THỊ là - nô lệ của chúng ta bị tụt lại một cách tồi tệ như thế nào. Bạn có thể kiểm tra nó trong cột “Seconds_Behind_Master”. Chỉ số này đặc biệt quan trọng để theo dõi xem bạn có biết ứng dụng của mình nhạy cảm khi đọc cũ hay không.
Trong ClusterControl, bạn có thể theo dõi dữ liệu này trong phần "Tổng quan":
Chúng tôi đã hiển thị tất cả các phần thông tin quan trọng nhất từ lệnh SHOW SLAVE STATUS. Bạn có thể kiểm tra trạng thái của bản sao, ai là chủ, nếu có độ trễ bản sao hay không, các vị trí nhật ký nhị phân. Bạn cũng có thể tìm thấy GTID đã truy xuất và thực thi.
Giản đồ hiệu suất
Một nơi khác bạn có thể tìm kiếm thông tin về sao chép là performance_schema. Điều này chỉ áp dụng cho Oracle’s MySQL 5.7 - các phiên bản cũ hơn và MariaDB không thu thập dữ liệu này.
mysql> SHOW TABLES FROM performance_schema LIKE 'replication%';
+---------------------------------------------+
| Tables_in_performance_schema (replication%) |
+---------------------------------------------+
| replication_applier_configuration |
| replication_applier_status |
| replication_applier_status_by_coordinator |
| replication_applier_status_by_worker |
| replication_connection_configuration |
| replication_connection_status |
| replication_group_member_stats |
| replication_group_members |
+---------------------------------------------+
8 rows in set (0.00 sec)Dưới đây, bạn có thể tìm thấy một số ví dụ về dữ liệu có sẵn trong một số bảng đó.
mysql> select * from replication_connection_status\G
*************************** 1. row ***************************
CHANNEL_NAME:
GROUP_NAME:
SOURCE_UUID: 5d1e2227-07c6-11e7-8123-080027495a77
THREAD_ID: 32
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 1
LAST_HEARTBEAT_TIMESTAMP: 2017-03-17 19:41:34
RECEIVED_TRANSACTION_SET: 5d1e2227-07c6-11e7-8123-080027495a77:715599-724966
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00
1 row in set (0.00 sec)mysql> select * from replication_applier_status_by_worker\G
*************************** 1. row ***************************
CHANNEL_NAME:
WORKER_ID: 0
THREAD_ID: 31
SERVICE_STATE: ON
LAST_SEEN_TRANSACTION: 5d1e2227-07c6-11e7-8123-080027495a77:726086
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00
1 row in set (0.00 sec)Như bạn có thể thấy, chúng tôi có thể xác minh trạng thái của bản sao, lỗi cuối cùng, tập hợp giao dịch đã nhận và một số dữ liệu khác. Điều quan trọng - nếu bạn đã bật tính năng sao chép đa luồng, trong bảng replication_applier_status_by_worker, bạn sẽ thấy trạng thái của từng nhân viên - điều này giúp bạn hiểu trạng thái sao chép cho từng luồng nhân viên.
Trễ sao chép
Trễ chắc chắn là một trong những vấn đề phổ biến nhất mà bạn sẽ gặp phải khi làm việc với nhân bản MySQL. Độ trễ sao chép xuất hiện khi một trong các nô lệ không thể theo kịp số lượng các hoạt động ghi được thực hiện bởi chủ. Các lý do có thể khác nhau - cấu hình phần cứng khác nhau, tải nặng hơn trên nô lệ, mức độ cao của việc ghi song song trên bản chính phải được tuần tự hóa (khi bạn sử dụng luồng đơn để sao chép) hoặc việc ghi không thể được song song ở cùng mức độ ở trên cái chính (khi bạn sử dụng sao chép đa luồng).
Làm thế nào để phát hiện ra nó?
Có một số phương pháp để phát hiện độ trễ sao chép. Trước hết, bạn có thể kiểm tra “Seconds_Behind_Master” trong đầu ra SHOW SLAVE STATUS - nó sẽ cho bạn biết nếu nô lệ có bị trễ hay không. Nó hoạt động tốt trong hầu hết các trường hợp nhưng trong các cấu trúc liên kết phức tạp hơn, khi bạn sử dụng các bậc thầy trung gian, trên các máy chủ ở đâu đó thấp trong chuỗi sao chép, nó có thể không chính xác. Một giải pháp khác tốt hơn là dựa vào các công cụ bên ngoài như pt-heartbeat. Ý tưởng rất đơn giản - một bảng được tạo, trong số những bảng khác, có một cột dấu thời gian. Cột này được cập nhật trên trang cái theo các khoảng thời gian đều đặn. Trên nô lệ, sau đó bạn có thể so sánh dấu thời gian từ cột đó với thời gian hiện tại - nó sẽ cho bạn biết mức độ chậm hơn của nô lệ.
Bất kể cách bạn tính toán độ trễ là gì, hãy đảm bảo rằng các máy chủ của bạn được đồng bộ hóa theo thời gian. Sử dụng ntpd hoặc các phương tiện đồng bộ hóa thời gian khác - nếu có thời gian trôi đi, bạn sẽ thấy độ trễ "sai" trên các nô lệ của mình.
Làm cách nào để giảm độ trễ?
Đây là một câu hỏi không dễ để trả lời. Nói tóm lại, nó phụ thuộc vào điều gì đang gây ra độ trễ và điều gì đã trở thành nút cổ chai. Có hai mẫu điển hình - nô lệ là I / O bị ràng buộc, có nghĩa là hệ thống con I / O của nó không thể đối phó với số lượng hoạt động ghi và đọc. Thứ hai - nô lệ bị ràng buộc bởi CPU, có nghĩa là luồng nhân bản sử dụng tất cả CPU mà nó có thể (một luồng chỉ có thể sử dụng một lõi CPU) và nó vẫn không đủ để xử lý tất cả các hoạt động ghi.
Khi CPU bị tắc nghẽn, giải pháp có thể đơn giản là sử dụng sao chép đa luồng. Tăng số luồng làm việc để cho phép độ song song cao hơn. Tuy nhiên, không phải lúc nào cũng có thể thực hiện được - trong trường hợp như vậy, bạn có thể muốn chơi một chút với các biến cam kết nhóm (cho cả MySQL và MariaDB) để trì hoãn các cam kết trong một khoảng thời gian nhỏ (chúng ta đang nói về mili giây ở đây) và theo cách này , tăng sự song song của các cam kết.
Nếu vấn đề nằm ở I / O, thì vấn đề khó giải quyết hơn một chút. Tất nhiên, bạn nên xem lại cài đặt I / O InnoDB của mình - có thể vẫn còn chỗ để cải thiện. Nếu điều chỉnh my.cnf không hữu ích, thì bạn không có quá nhiều lựa chọn - hãy cải thiện các truy vấn của mình (bất cứ khi nào có thể) hoặc nâng cấp hệ thống phụ I / O của bạn lên một thứ gì đó có khả năng hơn.
Hầu hết các proxy (ví dụ:tất cả proxy có thể được triển khai từ ClusterControl:ProxySQL, HAProxy và MaxScale) cung cấp cho bạn khả năng loại bỏ nô lệ ra khỏi vòng quay nếu độ trễ sao chép vượt qua một số ngưỡng được xác định trước. Đây hoàn toàn không phải là một phương pháp để giảm độ trễ nhưng nó có thể hữu ích để tránh việc đọc cũ và như một tác dụng phụ, giảm tải cho một nô lệ sẽ giúp nó bắt kịp.
Tất nhiên, điều chỉnh truy vấn có thể là một giải pháp trong cả hai trường hợp - luôn tốt để cải thiện các truy vấn nặng về CPU hoặc I / O.
Giao dịch không bình thường
Các giao dịch sai là các giao dịch chỉ được thực hiện trên một máy chủ, không phải trên máy chủ. Tóm lại, họ làm cho một nô lệ không nhất quán với chủ. Khi sử dụng bản sao dựa trên GTID, điều này có thể gây ra những rắc rối nghiêm trọng nếu nô lệ được thăng cấp thành chủ. Chúng tôi có một bài đăng chuyên sâu về chủ đề này và chúng tôi khuyến khích bạn xem xét vấn đề đó và làm quen với cách phát hiện và khắc phục sự cố với các giao dịch sai. Chúng tôi cũng đưa vào đó thông tin về cách ClusterControl phát hiện và xử lý các giao dịch sai.
Không có tệp Binlog trên Master
Làm cách nào để xác định vấn đề?
Trong một số trường hợp, có thể xảy ra trường hợp nô lệ kết nối với chủ và yêu cầu tệp nhật ký nhị phân không tồn tại. Một lý do cho điều này có thể là giao dịch sai - tại một thời điểm nào đó, một giao dịch đã được thực hiện trên nô lệ và sau đó nô lệ này trở thành chủ. Các máy chủ khác, được định cấu hình để làm nô lệ cho máy chủ đó, sẽ yêu cầu giao dịch bị thiếu đó. Nếu nó được thực thi cách đây khá lâu, có khả năng là các tệp nhật ký nhị phân đã bị xóa.
Một ví dụ khác, điển hình hơn - bạn muốn cung cấp một nô lệ bằng cách sử dụng xtrabackup. Bạn sao chép bản sao lưu trên máy chủ lưu trữ, áp dụng nhật ký, thay đổi chủ sở hữu của thư mục dữ liệu MySQL - các thao tác điển hình bạn thực hiện để khôi phục bản sao lưu. Bạn thực hiện
SET GLOBAL gtid_purged=dựa trên dữ liệu từ xtrabackup_binlog_info và bạn chạy CHANGE MASTER TO… MASTER_AUTO_POSITION =1 (đây là trong MySQL, MariaDB có một quy trình hơi khác), khởi động nô lệ và sau đó bạn gặp lỗi như:
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'trong MySQL hoặc:
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find GTID state requested by slave in any binlog files. Probably the slave state is too old and required binlog files have been purged.'trong MariaDB.
Về cơ bản, điều này có nghĩa là bản chính không có tất cả nhật ký nhị phân cần thiết để thực hiện tất cả các giao dịch bị thiếu. Rất có thể, bản sao lưu đã quá cũ và bản sao chính đã xóa một số nhật ký nhị phân được tạo trong khoảng thời gian từ khi tạo bản sao lưu đến khi cấp phép máy nô lệ.
Làm thế nào để giải quyết vấn đề này?
Rất tiếc, bạn không thể làm gì nhiều trong trường hợp cụ thể này. Nếu bạn có một số máy chủ MySQL lưu trữ nhật ký nhị phân trong thời gian lâu hơn máy chủ, bạn có thể thử sử dụng các nhật ký đó để phát lại các giao dịch bị thiếu trên máy chủ. Hãy xem cách nó có thể được thực hiện.
Trước hết, hãy xem GTID cũ nhất trong nhật ký nhị phân của chính:
mysql> SHOW BINARY LOGS\G
*************************** 1. row ***************************
Log_name: binlog.000021
File_size: 463
1 row in set (0.00 sec)Vì vậy, ‘binlog.000021’ là tệp mới nhất (và duy nhất). Hãy kiểm tra mục nhập GTID đầu tiên trong tệp này là gì:
[email protected]:~# mysqlbinlog /var/lib/mysql/binlog.000021
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @[email protected]@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#170320 10:39:51 server id 1 end_log_pos 123 CRC32 0x5644fc9b Start: binlog v 4, server v 5.7.17-11-log created 170320 10:39:51
# Warning: this binlog is either in use or was not closed properly.
BINLOG '
d7HPWA8BAAAAdwAAAHsAAAABAAQANS43LjE3LTExLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
AZv8RFY=
'/*!*/;
# at 123
#170320 10:39:51 server id 1 end_log_pos 194 CRC32 0x5c096d62 Previous-GTIDs
# 5d1e2227-07c6-11e7-8123-080027495a77:1-1106668
# at 194
#170320 11:21:26 server id 1 end_log_pos 259 CRC32 0xde21b300 GTID last_committed=0 sequence_number=1
SET @@SESSION.GTID_NEXT= '5d1e2227-07c6-11e7-8123-080027495a77:1106669'/*!*/;
# at 259Như chúng ta có thể thấy, mục nhật ký nhị phân cũ nhất hiện có là:5d1e2227-07c6-11e7-8123-080027495a77:1106669
Chúng tôi cũng cần kiểm tra GTID cuối cùng được bao gồm trong bản sao lưu là gì:
[email protected]:~# cat /var/lib/mysql/xtrabackup_binlog_info
binlog.000017 194 5d1e2227-07c6-11e7-8123-080027495a77:1-1106666
Đó là:5d1e2227-07c6-11e7-8123-080027495a77:1-1106666 nên chúng tôi thiếu hai sự kiện:
5d1e2227-07c6-11e7-8123-080027495a77:1106667-1106668
Hãy xem liệu chúng ta có thể tìm thấy các giao dịch đó trên nô lệ khác không.
mysql> SHOW BINARY LOGS;
+---------------+------------+
| Log_name | File_size |
+---------------+------------+
| binlog.000001 | 1074130062 |
| binlog.000002 | 764366611 |
| binlog.000003 | 382576490 |
+---------------+------------+
3 rows in set (0.00 sec)Có vẻ như ‘binlog.000003’ là nhật ký nhị phân mới nhất. Chúng tôi cần kiểm tra xem có thể tìm thấy GTID bị thiếu của chúng tôi trong đó hay không:
slave2:~# mysqlbinlog /var/lib/mysql/binlog.000003 | grep "5d1e2227-07c6-11e7-8123-080027495a77:110666[78]"
SET @@SESSION.GTID_NEXT= '5d1e2227-07c6-11e7-8123-080027495a77:1106667'/*!*/;
SET @@SESSION.GTID_NEXT= '5d1e2227-07c6-11e7-8123-080027495a77:1106668'/*!*/;Xin lưu ý rằng bạn có thể muốn sao chép các tệp binlog bên ngoài máy chủ sản xuất vì quá trình xử lý chúng có thể thêm một số tải. Khi chúng tôi xác minh rằng các GTID đó tồn tại, chúng tôi có thể trích xuất chúng:
slave2:~# mysqlbinlog --exclude-gtids='5d1e2227-07c6-11e7-8123-080027495a77:1-1106666,5d1e2227-07c6-11e7-8123-080027495a77:1106669' /var/lib/mysql/binlog.000003 > to_apply_on_slave1.sqlSau một khoảng thời gian ngắn, chúng tôi có thể áp dụng các sự kiện đó trên nô lệ
slave1:~# mysql -ppass < to_apply_on_slave1.sqlSau khi hoàn tất, chúng tôi có thể xác minh xem các GTID đó đã được áp dụng hay chưa bằng cách xem xét kết quả của TRẠNG THÁI CHẬM HIỂN THỊ:
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: 5d1e2227-07c6-11e7-8123-080027495a77
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: 170320 10:45:04
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set: 5d1e2227-07c6-11e7-8123-080027495a77:1-1106668Executed_GTID_set trông ổn, do đó chúng tôi có thể bắt đầu các chuỗi nô lệ:
mysql> START SLAVE;
Query OK, 0 rows affected (0.00 sec)Hãy kiểm tra xem nó có hoạt động tốt không. Một lần nữa, chúng tôi sẽ sử dụng đầu ra TRẠNG THÁI CHẬM:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 5d1e2227-07c6-11e7-8123-080027495a77:1106669
Executed_Gtid_Set: 5d1e2227-07c6-11e7-8123-080027495a77:1-1106669Có vẻ tốt, nó đang hoạt động!
Một phương pháp khác để giải quyết vấn đề này là sao lưu một lần nữa và cung cấp lại nô lệ, sử dụng dữ liệu mới. Điều này có thể sẽ nhanh hơn và chắc chắn là đáng tin cậy hơn. Thông thường, bạn có các chính sách xóa binlog khác nhau đối với chính và trên nô lệ)
Chúng tôi sẽ tiếp tục thảo luận về các loại vấn đề nhân bản khác trong bài đăng blog tiếp theo.
