Trong thiết lập MySQL 5.7 master-slave sử dụng cài đặt sao chép bán đồng bộ mặc định cho rpl_semi_sync_master_wait_point , sự cố của chủ và chuyển đổi dự phòng sang nô lệ được coi là không mất dữ liệu. Tuy nhiên, khi bản chính bị sự cố quay lại, bạn có thể thấy rằng nó có các giao dịch không có trong bản chính hiện tại (trước đó là một nô lệ). Hành vi này có thể gây khó hiểu, vì sao chép bán đồng bộ được cho là không mất dữ liệu, nhưng đây thực sự là một hành vi được mong đợi trong MySQL. Chính xác tại sao điều này xảy ra được giải thích đầy đủ chi tiết trong bài đăng trên blog của Jean-François Gagné (JF).
Với tình huống như vậy, tài liệu MySQL khuyến nghị rằng bản chính bị lỗi phải được loại bỏ và không nên khởi động lại. Tuy nhiên, việc loại bỏ một máy chủ như thế này là tốn kém và không hiệu quả. Trong bài đăng trên blog này, chúng tôi sẽ giải thích một cách tiếp cận để phát hiện và khắc phục các giao dịch trên máy chủ chính MySQL bị lỗi trong thiết lập sao chép bán đồng bộ và cách khôi phục nó trở lại thiết lập chủ-nô lệ của bạn.
Tại sao việc phát hiện các giao dịch bổ sung trên Master đã phục hồi lại quan trọng?
Các giao dịch bổ sung trên trang cái được khôi phục có thể biểu hiện theo hai cách:
1. Sao chép MySQL thất bại khi bản gốc được khôi phục được tạo lại
Thông thường, điều này xảy ra khi bạn có khóa chính tự động tăng. Khi MySQL master mới chèn một hàng vào một bảng như vậy, quá trình sao chép sẽ không thành công vì khóa đã tồn tại trên nô lệ.
Một tình huống khác là khi ứng dụng của bạn thử lại giao dịch không thành công trong sự cố chính. Trên MySQL master đã được khôi phục (hiện là một nô lệ), giao dịch này sẽ thực sự tồn tại và một lần nữa, dẫn đến lỗi sao chép.
Thông thường, lỗi sao chép MySQL sẽ giống như sau:
| [ERROR] Slave SQL cho kênh '':Worker 5 không thực hiện được giao dịch 'fd1ba8f0-cbee-11e8- b27f-000d3a0df42d:5938858 'tại nhật ký chính mysql-bin.000030, end_log_pos 10262184; Lỗi 'Mục nhập trùng lặp' 5018 'cho khóa' CHÍNH '' trên truy vấn. Cơ sở dữ liệu mặc định:'test'. Truy vấn:'chèn vào các giá trị thử nghiệm (5018,2019,' item100 ')', Error_code:1062 |
2. Sự mâu thuẫn âm thầm trong dữ liệu giữa MySQL master và slave mới (chính được khôi phục)
Trong trường hợp ứng dụng không thử lại giao dịch không thành công và không có xung đột khóa chính trong tương lai, lỗi sao chép có thể không xảy ra. Do đó, sự mâu thuẫn dữ liệu có thể không bị phát hiện.
Trong cả hai trường hợp trên, tính khả dụng cao hoặc tính toàn vẹn dữ liệu của thiết lập MySQL của bạn đều bị ảnh hưởng, đó là lý do tại sao điều quan trọng là phải phát hiện tình trạng này càng sớm càng tốt.
Cách phát hiện các giao dịch bổ sung trên MySQL Master được khôi phục
Chúng tôi có thể phát hiện xem có bất kỳ giao dịch bổ sung nào trên bản chính được khôi phục hay không bằng cách sử dụng hàm MySQL GTID (mã định danh giao dịch toàn cầu):
GTID_SUBSET ( set1 , set2 ):Cung cấp hai bộ ID giao dịch toàn cầu set1 và set2 , trả về true nếu tất cả GTID trong set1 cũng có trong set2 . Nếu không thì trả về false.
Hãy sử dụng một ví dụ để hiểu điều này.
- GTID được đặt trên trang cái được khôi phục có UUID là:‘ 54a63bc3-d01d-11e7-bf52-000d3af93e52 ’Là:
- '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9700,57956099-d01d-11e7-80bc-000d3af97c09:1-810'
- Bộ GTID của trang cái mới có UUID là:‘ 57956099-d01d-11e7-80bc-000d3af97c09 ’Là:
- '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9690,57956099-d01d-11e7-80bc-000d3af97c09:1-870 ’
Bây giờ, nếu chúng ta gọi hàm GTID_SUBSET là GTID_SUBSET (bộ GTID của bản chính được khôi phục, bộ GTID của bản chính mới) , giá trị trả về sẽ là true, chỉ khi bản gốc được khôi phục không có bất kỳ giao dịch bổ sung nào. Trong ví dụ của chúng tôi ở trên, vì bản cái được khôi phục có thêm các giao dịch 9691 đến 9700, nên kết quả của truy vấn trên là sai.
Xử lý lại máy chủ chính #MySQL bị sự cố trong thiết lập sao chép bán đồng bộNhấp vào TweetCách sắp xếp lại MySQL Master đã khôi phục có giao dịch bổ sung
Dựa vào bước trên, có thể biết liệu bản chính được khôi phục có các giao dịch bổ sung hay không và những giao dịch này đang sử dụng hàm GTID: GTID_SUBTRACT (bộ GTID của bản chính đã khôi phục, bộ GTID của bản chính mới).
Cũng có thể trích xuất các giao dịch bổ sung này từ nhật ký nhị phân và lưu chúng. Có thể hữu ích cho nhóm kinh doanh của bạn sau này xem xét các giao dịch này để đảm bảo rằng chúng tôi không vô tình làm mất bất kỳ thông tin kinh doanh quan trọng nào, mặc dù thông tin đó không được cam kết. Khi việc này được thực hiện xong, chúng tôi cần một cách để loại bỏ các giao dịch bổ sung này để có thể khôi phục lại bản gốc đã khôi phục mà không gặp sự cố.
Một trong những cách đơn giản nhất để thực hiện việc này là chụp nhanh một bản sao lưu trên trang cái hiện tại và khôi phục dữ liệu trên máy chủ hiện tại của bạn. Hãy nhớ rằng bạn cần giữ lại UUID của máy chủ này như trước. Sau khi bạn khôi phục dữ liệu, máy chủ có thể được hoàn thiện lại và nó sẽ bắt đầu sao chép từ điểm của ảnh chụp nhanh được khôi phục. Bạn sẽ sớm có một nô lệ khỏe mạnh hoạt động trở lại!
Các bước trên rất tẻ nhạt nếu bạn phải thực hiện chúng theo cách thủ công, nhưng dịch vụ lưu trữ MySQL được quản lý hoàn toàn của ScaleGrid có thể tự động hóa toàn bộ quy trình cho bạn mà không cần bất kỳ sự can thiệp nào. Đây là cách nó hoạt động:
Nếu bản chính hiện tại của bạn gặp sự cố, ScaleGrid sẽ tự động hóa quá trình chuyển đổi dự phòng và quảng bá một nô lệ phù hợp làm bản chính mới. Sau đó, bản gốc cũ được khôi phục và chúng tôi tự động phát hiện xem có thêm giao dịch nào trên đó hay không. Nếu có bất kỳ điều gì được tìm thấy, việc triển khai MySQL đang ở trạng thái xuống cấp và chúng tôi sử dụng các công cụ tự động để trích xuất và lưu các giao dịch bổ sung để bạn xem xét. Sau đó, nhóm hỗ trợ của chúng tôi có thể khôi phục bản gốc cũ về trạng thái tốt và khôi phục nó trở lại thiết lập master-slave của bạn để bạn có một quá trình triển khai tốt!
Bạn muốn dùng thử? Bắt đầu bản dùng thử miễn phí 30 ngày để khám phá tất cả các khả năng quản lý cơ sở dữ liệu MySQL tại ScaleGrid.
