Max_allowed_packet nào đủ lớn và tại sao tôi cần thay đổi nó?


14

Tôi có MySQL (5.5) trong thiết lập master-Slave và tạo một máy chủ nô lệ khác.

Tôi đã dừng nô lệ ban đầu, đổ dữ liệu, sao chép và nhập lại và nó hoạt động tốt. Tôi đã lưu ý vị trí master_log của nô lệ gốc và sử dụng các lệnh này để đặt nó trên nô lệ mới

CHANGE MASTER TO MASTER_HOST='<ipaddress>', 
MASTER_USER='<username>', MASTER_PASSWORD='<password>', 
MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000851', 
MASTER_LOG_POS=15824150, 
MASTER_CONNECT_RETRY=10;

Khi tôi bắt đầu nô lệ mới, tôi đã nhận được

Last_IO_Error: Gặp lỗi nghiêm trọng 1236 từ chủ khi đọc dữ liệu từ nhật ký nhị phân: 'mục nhập sự kiện log vượt quá max_allowed_packet; Tăng max_allowed_packet trên master '

Tuy nhiên, khi tôi bắt đầu nô lệ ban đầu, nó đã bắt kịp tốt, và bây giờ đã đồng bộ.

Vì vậy, các câu hỏi:

  • giá trị hiện tại là 16 triệu, làm thế nào để tôi biết làm thế nào lớn? (Tôi muốn tránh dùng thử và lỗi với một máy chủ sản xuất).

  • Tại sao tôi cần tăng giá trị trên bản gốc khi nô lệ gốc đã xử lý tốt, vấn đề có thể thực sự xảy ra với nô lệ mới không?

cập nhật

Tôi đã tăng max_allowed_packet lên 1073741824 khi Rolando đề xuất về chủ, nô lệ cũ và nô lệ mới, và khởi động lại chúng ( SET GLOBAL max_allowed_packet = 1073741824;vì một số lý do dường như không mất)

bây giờ lỗi IO cuối cùng giống như trước đây, nhưng bây giờ tôi thấy

Last_Query_Error: Lỗi đọc nhật ký chuyển tiếp: Không thể phân tích mục sự kiện nhật ký chuyển tiếp. Những lý do có thể là: nhật ký nhị phân của chủ bị hỏng (bạn có thể kiểm tra điều này bằng cách chạy 'mysqlbinlog' trên nhật ký nhị phân), nhật ký chuyển tiếp của nô lệ bị hỏng (bạn có thể kiểm tra điều này bằng cách chạy 'mysqlbinlog' trên nhật ký chuyển tiếp), a sự cố mạng hoặc lỗi trong mã MySQL của chủ hoặc nô lệ. Nếu bạn muốn kiểm tra nhật ký nhị phân của chủ hoặc nhật ký chuyển tiếp của nô lệ, bạn sẽ có thể biết tên của họ bằng cách phát hành 'SHOW SLAVE STATUS' trên nô lệ này.

Nếu tôi thực hiện một mysqlbinlog trên tệp của chủ, nó sẽ cuộn qua các lệnh khá vui vẻ từ lâu - tệp là 722M - nếu tôi làm điều đó cho nhật ký chuyển tiếp nô lệ tôi sẽ nhận được

LRI: Lỗi trong Log_event :: read_log_event (): 'Kiểm tra trạng thái không thành công', data_len: 38916267, event_type: 69

LRI: Không thể đọc mục nhập ở offset 253: Lỗi ở định dạng nhật ký hoặc lỗi đọc.

Tôi đã kiểm tra các biến và các thay đổi hoạt động tuy nhiên

mysql hiển thị các biến THÍCH '% max_allowed_packet%';

trên nô lệ mới hiển thị max_allowed_packetslave_max_allowed_packetở đâu như trên chủ nó chỉ cómax_allowed_packet

Vì vậy, tôi đã kiểm tra phiên bản trên bản gốc:

mysql> show variables LIKE '%version%';
+-------------------------+--------------------------------------+
| Variable_name           | Value                                |
+-------------------------+--------------------------------------+
| innodb_version          | 1.1.6                                |
| protocol_version        | 10                                   |
| slave_type_conversions  |                                      |
| version                 | 5.5.11-log                           |
| version_comment         | MySQL Community Server (GPL) by Remi |
| version_compile_machine | x86_64                               |
| version_compile_os      | Linux                                |
+-------------------------+--------------------------------------+

và trên nô lệ mới

mysql> show variables LIKE '%version%';
+-------------------------+--------------------------------------+
| Variable_name           | Value                                |
+-------------------------+--------------------------------------+
| innodb_version          | 5.5.32                               |
| protocol_version        | 10                                   |
| slave_type_conversions  |                                      |
| version                 | 5.5.32-log                           |
| version_comment         | MySQL Community Server (GPL) by Remi |
| version_compile_machine | x86_64                               |
| version_compile_os      | Linux                                |
+-------------------------+--------------------------------------+

Có phải 2 phiên bản này quá xa nhau?


Có một số điều thú vị ở đây . Hy vọng điều này sẽ hữu ích.
Sathish D

Câu trả lời:


18

Bạn có thể đạt tối đa max_allowed_packet1G. Bất cứ khi nào một gói MySQL được xây dựng, nó sẽ không nhảy lên 1G từ đầu. Tại sao?

Trước tiên, bạn cần biết một gói MySQL. Trang 99 của cuốn sách

Hiểu nội bộ MySQL

giải thích nó trong đoạn 1-3 như sau:

Mã giao tiếp mạng MySQL được viết theo giả định rằng các truy vấn luôn luôn ngắn một cách hợp lý và do đó có thể được gửi đến và xử lý bởi máy chủ trong một đoạn, được gọi là một gói theo thuật ngữ MySQL. Máy chủ phân bổ bộ nhớ cho bộ đệm tạm thời để lưu trữ gói và nó yêu cầu đủ để phù hợp với nó hoàn toàn. Kiến trúc này yêu cầu một biện pháp phòng ngừa để tránh việc máy chủ hết bộ nhớ --- giới hạn về kích thước của gói, tùy chọn này thực hiện.

Mã quan tâm liên quan đến tùy chọn này được tìm thấy trong sql / net_serv.cc . Hãy xem my_net_read () , sau đó thực hiện cuộc gọi đến my_real_read () và đặc biệt chú ý đến net_realloc () .

Biến này cũng giới hạn độ dài của kết quả của nhiều chuỗi functon. Xem sql / field.ccsql / intem_strfunc.cc để biết chi tiết.

So sánh điều đó với Tài liệu MySQL trên max_allowed_packet:

Kích thước tối đa của một gói hoặc bất kỳ chuỗi được tạo / trung gian hoặc bất kỳ tham số nào được gửi bởi hàm API mysql_stmt_send_long_data (). Mặc định là 4 MB kể từ MySQL 5.6.6, 1MB trước đó.

Bộ đệm thông điệp gói được khởi tạo thành các byte net_buffer_length, nhưng có thể tăng lên đến byte max_allowed_packet khi cần. Giá trị này theo mặc định là nhỏ, để bắt các gói lớn (có thể không chính xác).

Bạn phải tăng giá trị này nếu bạn đang sử dụng các cột BLOB lớn hoặc chuỗi dài. Nó phải lớn như BLOB lớn nhất bạn muốn sử dụng. Giới hạn giao thức cho max_allowed_packet là 1GB. Giá trị phải là bội số của 1024; nonmultiples được làm tròn xuống bội số gần nhất.

Khi bạn thay đổi kích thước bộ đệm thông báo bằng cách thay đổi giá trị của biến max_allowed_packet, bạn cũng nên thay đổi kích thước bộ đệm ở phía máy khách nếu chương trình máy khách của bạn cho phép. Về phía khách hàng, max_allowed_packet có mặc định là 1GB. Một số chương trình như mysql và mysqldump cho phép bạn thay đổi giá trị phía máy khách bằng cách đặt max_allowed_packet trên dòng lệnh hoặc trong tệp tùy chọn.

Đưa ra thông tin này, bạn nên vui mừng khi MySQL sẽ mở rộng và ký hợp đồng với Gói MySQL khi cần. Do đó, hãy tiếp tục và

Master và Slave phải phù hợp về mặt họ truyền dữ liệu, đặc biệt là dữ liệu BLOB.

CẬP NHẬT 2013-07-04 07:03 EDT

Từ các tin nhắn của bạn liên quan đến nhật ký chuyển tiếp, có vẻ như bạn có những điều sau đây

  • một bản ghi chuyển tiếp bị hỏng
  • một bản ghi tổng thể tốt

GỢI Ý

SHOW SLAVE STATUS\G
STOP SLAVE;
CHANGE MASTER TO
MASTER_LOG_FILE='(Relay_Master_Log_File from SHOW SLAVE STATUS\G)',
MASTER_LOG_POS=(Exec_Master_Log_Pos from SHOW SLAVE STATUS\G);
START SLAVE;

Chạy CHANGE MASTER TOxóa tất cả các bản ghi chuyển tiếp và bắt đầu với một cái mới. Bạn sẽ sao chép từ Sự kiện BinLog chính cuối cùng (BinLog, Vị trí) đã thực hiện trên Slave.

Hãy thử một lần !!!


cảm ơn, thật tuyệt khi nó an toàn; nhưng tôi vẫn không hiểu tại sao tôi cần phải thay đổi nó khi giá trị hiện tại khớp với chủ và nô lệ khác đang hoạt động hoàn hảo?
CodeMonkey

một cái gì đó khác đang diễn ra, tôi đã thêm chi tiết
CodeMonkey

1
Chỉ cho thông tin của bạn: Điều này xảy ra với tôi khi tôi đặt lại quy trình sao chép và vô tình nhập sai MASTER_LOG_FILEtên. Ví dụ được sử dụng mysql-bin.000001khi tôi nên sử dụng mysql-bin.000003từ SHOW MASTER STATUStrong CHANGE MASTER TO.
Mikko Ohtamaa

7

Thật đáng xấu hổ, vấn đề là tên tệp không chính xác cho nhật ký, gây ra kết quả kỳ lạ, được nhập lại với tên tệp chính xác và mọi thứ đều ổn khi bị treo đầu trong sự xấu hổ


Cảm ơn rất nhiều! Bạn không phải là người duy nhất mắc lỗi này.
Mikko Ohtamaa

2
Luôn luôn đáng để đăng câu trả lời ngay cả khi nó ngớ ngẩn. Mọi người đều phạm sai lầm ngớ ngẩn vì chúng ta đều là con người. Ngoài những người trong chúng ta là robot.
John Hunt
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.