6.1 Monitoring Replication
Dùng câu truy vấn ‘SHOW MASTER STATUS’ để xem vị trí và cấu hình của các file binary log trên bản gốc
Dùng câu truy vấn “SHOW MASTER LOGS” để xem được các file binary log nào đang tồn tại trên ổ đĩa
Xem các sự kiện sao lưu có trong binary log bằng câu lệnh
6. Replication Administration and Maintenance
6.2 Measuring Replication Lag
Một trong những điều mà ta cần để ý tới là bản sao chạy chậm hơn bản gốc bao lâu. Dù cho ở cột Second_behind_master trong SHOW SLAVE STATUS trên lý thuyết có thể cho ta thấy điều này, thực tế nó không phải lúc nào cũng chính xác vì 1 vài lí do:
Bản sao không thể tự report khi nó thực thi câu truy vấn
Bản sao luôn report là NULL nếu tiến trình sao lưu không hoạt động
Một vài lỗi xảy ra (vd: mạng không ổn định, ..)
Đôi khi không thể tính toán độ trễ ngay cả khi tiến trình sao lưu đang chạy
Thực thi trong khoảng thời gian dài sẽ khiến việc report bị sai lệch
Giải pháp là heart-beat record – update các tem thời gian liên tục trên bản gốc. Độ trễ được tính toán bằng cách trừ heartbeat trong tem thời gian hiện tại cho cái có trên bản sao
6. Replication Administration and Maintenance
6.3 Determining whether replicas are Consistent with the master
Việc kiểm tra bản sao có đồng nhất với bản chính hay không là việc làm cần thực hiện thường xuyên đặc biệt là khi sử dụng Replication cho việc backup
MySQL ko tích hợp các phương pháp để kiểm tra sự đồng nhất mà chỉ cung cấp các khối được xây dựng từ bảng kiểm và dữ liệu, ví dụ CHECKSUM TABLE
Pt-table-checksum là 1 công cụ có thể giải quyết các vấn đề trên – Hoạt động bằng cách sử dụng câu lệnh INSERT…SELECT trên bản gốc
Hoặc dung:
$pt-table-checksum --replicate=test.checksum <master_host>
6. Replication Administration and Maintenance
6.4 Resyncing a replica from the master
Hai phương pháp truyền thống:
Dừng và tải lại từ bản gốc
Dừng và xóa bỏ (áp dụng với các vấn đề nghiêm trọng), sau đó tải lại bản sao hoặc restore từ file backup
Nhược điểm: - Bất tiện đặc biệt là khi xử lí với khối lượng dữ liệu lớn
Nếu sự bất đồng bộ được phát hiện ko quá nghiêm trọng, có thể chỉ cần đồng bộ lại với các dữ liệu bị ảnh hưởng
Cách đơn giản nhất là sử dụng mysqldump nhưng không thể thực hiện với các server đang trong tình trạng quá tải
Thay đổi dữ liệu của bản sao thông qua việc sao chép là kĩ thuật an toàn nhất, nó tránh được các vấn đề về race condition và các yếu tố bất ngờ khác
pt-table-sync là một công cụ của Percona Toolkit cho phép tìm kiếm và sửa lại nhưng dữ liệu sai lệch giữa các bảng
6. Replication Administration and Maintenance
6.5 Changing master
Sử dụng CHANGE MASTER TO trên bản sao với các giá trị phù hợp – bản sao sẽ bỏ cấu hình hiện tại cùng với file relay log và bắt đầu sao lưu dữ liệu từ bản gốc mới
Đẩy một bản sao lên làm bản gốc mới là 1 giải pháp nhưng sẽ khó thực hiện hơn đôi chút. Xảy ra 2 trường hợp khi làm việc này : khi được lên kế hoạch trước và trong tình huống phát sinh bất ngờ
6. Replication Administration and Maintenance
6.5.1 Planned Promotion
1. Nhìn chung thì sẽ có 4 bước cơ bản sau:
2. Dừng việc ghi trên bản gốc cũ
3. Để bản sao hoàn thành việc sao lưu
4. Cấu hình bản sao thành bản gốc mới
5. Kết nối các bản sao khác và các lệnh ghi đến bản gốc mới, thiết lập lệnh ghi trên đó
*Các bước có thể khác đi tùy thuộc vào giao thức khác nhau 6.5.2 Unplanned promotions
Xảy ra khi bản gốc bị crash khiến cho các bản sao mang khối lượng dữ liệu khác nhau gây khó khan trong việc xác định bản sao nào sẽ trở thành bản gốc mới
Các bước để đưa bản sao lên thành bản bản gốc mới trong giao thức phân cấp
6. Xác định bản sao nào được cập nhật đầy đủ nhất bằng cách kiểm tra đầu ra của SHOW SLAVE STATUS trên mỗi bản sao
7. Để các bản sao hoàn thành việc chạy file rely log được mang về từ bản gốc cũ trước khi bị crash
8. Thực hiện bước 5-7 như trên
9. So sánh vị trí file Master_Log_File/Read_Master_Log_Pos của mỗi bản sao với với các file trên bản gốc mới
10. Thực hiện bước 10-12 như trên
6. Replication Administration and Maintenance
6.5.3 Locate the desired log positions
Cần tìm vị trí file binary log của bản gốc tương ứng với sự kiện cuối cùng mà bản sao thực thi nếu như bản sao không nằm đúng vị trí như trên bản gốc
Việc tìm kiếm trên có thể sẽ chậm và nhàm chán nhưng không khó
Nếu cần khôi phục các sự kiện bị mất từ bản gốc cũ, nên làm điều đó sau khi tạo được bản gốc mới nhưng trước khi kết nối với client
6. Replication Administration and Maintenance
6.6 Switching roles in a Master-Master Configuration
Đặc điểm của việc sao lưu ngang hàng là có thể đổi vai trò của các server 1 cách dễ dàng bởi cấu hình đối xứng của nó
Các bước thực hiện đổi vai trò mà không xảy ra xung đột:
1.Dừng các bản ghi trên active server
2.Thực thi SET GLOBAL read_only = 1 trên active server và thiết lập read-only trên cấu hình của nó
3.Thực thi MASTER_STATUS trên active server để lưu lại vị trí của file binary_log
4.Thực thi SELECT MASTER_ROS_WAIT() trên vị trí của file binary log của active server
5.Thực thi SET GLOBAL read_only = 0 trên passive server, theo đó biến nó thành active server
6.Cấu hình lại ứng dụng để ghi trên active server mới