MySQL tham nhũng binlog

Gần đây chúng tôi đã thực hiện một số thay đổi đối với cơ sở hạ tầng của mình và bây giờ tôi không thể tiếp tục sao chép MySQL. Các nô lệ phàn nàn về một binlog bị hỏng và đặt lại nó không giúp ích gì. Tôi tiếp tục thấy các mục như thế này trong nhật ký chính của tôi:

BINLOG '
WFxKTRNJAAAAPwAAAKY / YwAAABsAAAAAAAEACHdlYmVkaTMwAA1QYXJ0bmVyQ29uZmlnAAQICA8P
BC0AYwAA
WFxKTRhJAAAAXAAAAAJAYwAAABsAAAAAAAEABP // 8BoSAAAAAAAAggMAAAAAAAAJUEFDS0NPVU5U
Azc3MfAaEgAAAAAAAIIDAAAAAAAACVBBQ0tDT1VOVAM3NzI =
'/ *! * /;

Trong nhật ký nô lệ, điều này chỉ xuất hiện dưới dạng "Sự kiện không xác định" và việc sao chép thất bại ở vị trí đó.

Đây là my.cnf của tôi cho chủ:

[mysqld]
datadir = / data / mysql-data
ổ cắm = / tmp / mysql.sock
người dùng = mysql
log-error = / var / log / mysqld.log

binlog-do-db = db1
binlog-do-db = db2
binlog-do-db = db3
binlog-do-db = db4
binlog_format = 'TRỘN'

log-bin = /data/mysql-binlogs/mysql-bin.log
máy chủ-id = 73
máy chủ báo cáo = thisserver.mydomain.com

thread_cache_size = 30
key_buffer_size = 700M
myisam_sort_buffer_size = 300M
bảng_cache = 256
sort_buffer_size = 4M
read_buffer_size = 1M
innodb_data_home_dir = / data / mysql-data /
innodb_data_file_path = InnoDB: 100M: tự động gửi
set-biến = innodb_buffer_pool_size = 500M
set-biến = innodb_additable_mem_pool_size = 10M
set-biến = max_connections = 500
innodb_log_group_home_dir = / data / mysql-data
set-biến = innodb_log_file_size = 20M
set-biến = innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1

Có ai biết điều gì có thể gây ra sự vô nghĩa trong binlogs của tôi không?

Đáng ngạc nhiên, đó không phải là vô nghĩa.

Điều đó thực sự xuất hiện ở đầu binlogs bất cứ khi nào bạn thực hiện mysqlbinlog cho nhật ký nhị phân được tạo bằng MySQL 5.1 và MySQL 5.5. Bạn sẽ không thấy sự vô nghĩa trong nhật ký nhị phân cho MySQL 5.0 trở lại.

Đây là lý do tại sao điểm bắt đầu để sao chép từ nhật ký nhị phân trống là

• 107 cho MySQL 5.5
• 106 cho MySQL 5.1
• 98 cho MySQL 5.0 trở lại

Điều này rất tốt để nhớ nếu bạn thực hiện Sao chép MySQL trong đó Master nếu MySQL 5.1 và nô lệ là MySQL 5.0. Điều này có thể gây ra một cơn đau đầu thực sự lớn.

Sao chép từ Master sử dụng 5.0 và Slave sử dụng 5.1 hoạt động tốt, không phải theo cách khác. (Theo Tài liệu MySQL, nó thường không được hỗ trợ vì 3 lý do: 1) Định dạng nhật ký nhị phân, 2) Sao chép dựa trên hàng, 3) Tính không tương thích của SQL ).

Dù sao, làm một mysqlbinlog trên nhật ký nhị phân vi phạm trên bản gốc. Nếu kết xuất kết quả tạo ra vô nghĩa ở giữa bãi chứa (mà tôi đã thấy một vài lần trong sự nghiệp DBA của mình), bạn có thể phải chuyển sang vị trí 98 (MySQL 5.0) hoặc 106 (MySQL 5.1) hoặc 107 (MySQL 5.5) của nhật ký nhị phân tiếp theo của chủ và bắt đầu sao chép từ đó (SOB :( bạn có thể cần sử dụng các công cụ MAATKIT mk-table-checksum và mk-table-sync để tải lại các thay đổi chính không phải trên nô lệ [nếu bạn muốn trở thành anh hùng] ; thậm chí tệ hơn, mysqldump chủ và tải lại nô lệ và bắt đầu sao chép hoàn toàn [nếu bạn không muốn trở thành anh hùng])

Nếu mysqlbinlog của master hoàn toàn có thể đọc được sau khi nói vô nghĩa hàng đầu mà bạn đã thấy, có thể nhật ký nhị phân của master vẫn ổn nhưng nhật ký chuyển tiếp trên Slave bị hỏng (do lỗi truyền / CRC). Nếu đó là trường hợp, chỉ cần tải lại nhật ký chuyển tiếp bằng cách phát lệnh CHANGE MASTER TO như sau:

STOP SLAVE;
CHANGE MASTER TO
MASTER_HOST='< master-host ip or DNS >',
MASTER_PORT=3306,
MASTER_USER='< usernmae >',
MASTER_PASSWORD='< password >',
MASTER_LOG_FILE='< MMMM >',
MASTER_LOG_POS=< PPPP >;
START SLAVE;

Ở đâu

• MMMM là tệp cuối cùng được sử dụng từ Master được xử lý lần cuối trên Slave
• PPPP là vị trí cuối cùng được sử dụng từ Master được xử lý lần cuối trên Slave

Bạn có thể nhận MMMM và PPPP bằng cách thực hiện SHOW SLAVE STATUS\Gvà sử dụng

• Relay_Master_Log_File cho MMMM
• Exec_Master_Log_Pos cho PPPP

Hãy thử nó và cho tôi biết !!!

BTW đang chạy lệnh THAY ĐỔI MASTER để xóa nhật ký chuyển tiếp hiện tại của nô lệ và bắt đầu mới.