У мене MySQL (5.5) в налаштуваннях майстер-підлеглого і створив ще один підлеглий сервер.

Я зупинив оригінального раба, скинув дані, скопіював і повторно імпортував, і це працювало чудово. Я відзначив master_log pos оригінального підлеглого і використав ці команди, щоб встановити його на новому підлеглому

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;

Коли я заводив нового раба, я отримав

Last_IO_Error: Отримала фатальну помилку 1236 від майстра під час зчитування даних з бінарного журналу: 'запис події журналу перевищив max_allowed_packet; Збільшити max_allowed_packet на головний '

Однак коли я запустив оригінального раба, він наздогнав просто чудово і зараз синхронізується.

Отже, питання:

• поточне значення - 16 млн. Як я можу знати, наскільки великим потрібно пройти? (Я вважаю за краще уникати спроб та помилок із виробничим сервером).

• чому мені потрібно збільшити значення головного господаря, коли оригінальний раб справився просто чудово, чи може справді проблема бути з новим рабом?

оновлення

Я збільшив max_allowed_packet до 1073741824, коли Роландо запропонував про головного, старого раба та нового раба, і перезапустив їх ( SET GLOBAL max_allowed_packet = 1073741824;чомусь не здавалося)

тепер остання помилка вводу-виводу така ж, як і раніше, але тепер я бачу

Last_SQL_Error: Помилка читання журналу ретрансляції: Не вдалося проаналізувати запис події журналу ретрансляції. Можливі причини: пошкоджений бінарний журнал господаря (ви можете перевірити це, запустивши "mysqlbinlog" на бінарний журнал), журнал ретранслятора підлеглого пошкоджений (ви можете перевірити це, запустивши "mysqlbinlog" у журналі ретрансляції), проблема з мережею або помилка в MySQL-коді головного або підлеглого. Якщо ви хочете перевірити бінарний журнал ведучого або журнал ретрансляції підлеглого, ви зможете дізнатися їх назви, видавши на цьому підлеглому "ПОКАЗАТИ СЛОВА СЛОВА".

Якщо я роблю mysqlbinlog у файлі господаря, він прокручується повз командами цілком щасливо протягом століть - файл 722M - якщо я це роблю для журналу реле реле, я отримую

ПОМИЛКА: Помилка в Log_event :: read_log_event (): 'Перевірка надійності не вдалася', data_len: 38916267, тип події: 69

ПОМИЛКА: Не вдалося прочитати запис при зміщенні 253: Помилка у форматі журналу або помилка читання.

Я перевірив змінні, але зміни працювали

mysql> показати змінні LIKE '% max_allowed_packet%';

на новому рабі показав max_allowed_packetІ slave_max_allowed_packetде, як на господаря, він тільки маєmax_allowed_packet

тому я зробив перевірку версії майстра:

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                                |
+-------------------------+--------------------------------------+

і на нового раба

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                                |
+-------------------------+--------------------------------------+

Ці 2 версії занадто далеко один від одного?

Гаразд, щоб збільшити максимум max_allowed_packetдо 1G. Кожен раз, коли сконструйовано пакет MySQL, він не буде переходити до 1G з самого початку. Чому?

Спочатку потрібно знати, що таке пакет MySQL. Сторінка 99 Книги

в пунктах 1-3 пояснюється так:

Код зв'язку в мережі MySQL був написаний з припущенням, що запити завжди досить короткі, а тому можуть бути відправлені та оброблені сервером за один фрагмент, який в термінології MySQL називається пакетом . Сервер виділяє пам'ять на тимчасовий буфер для зберігання пакету, і він вимагає достатньо, щоб повністю його вмістити. Ця архітектура вимагає запобіжних заходів, щоб уникнути втрати пам’яті сервера --- обмеження розміру пакету, яке виконується цим параметром.

Код, що цікавить цей параметр, можна знайти в sql / net_serv.cc . Погляньте на my_net_read () , а потім слідкуйте за викликом до my_real_read () і зверніть особливу увагу на net_realloc () .

Ця змінна також обмежує довжину результату багатьох функцій струн. Дивіться sql / field.cc та sql / intem_strfunc.cc .

Порівняйте це з документацією на MySQL на max_allowed_packet :

Максимальний розмір одного пакету або будь-якого згенерованого / проміжного рядка або будь-якого параметра, надісланого функцією C API mysql_stmt_send_long_data (). За замовчуванням 4MB станом на MySQL 5.6.6, до цього 1MB.

Буфер повідомлень пакетів ініціалізується до байтів net_buffer_length, але при необхідності може вирости до байтів max_allowed_packet. Це значення за замовчуванням невелике, щоб уловлювати великі (можливо, неправильні) пакети.

Ви повинні збільшити це значення, якщо ви використовуєте великі колони BLOB або довгі рядки. Він повинен бути таким же великим, як найбільший BLOB, який ви хочете використовувати. Ліміт протоколу для max_allowed_packet - 1 Гб. Значення має бути кратним 1024; немножини округляються до найближчого кратного.

Коли ви змінюєте розмір буфера повідомлень, змінюючи значення змінної max_allowed_packet, вам також слід змінити розмір буфера на стороні клієнта, якщо ваша клієнтська програма це дозволяє. На стороні клієнта max_allowed_packet за замовчуванням становить 1 Гб. Деякі програми, такі як mysql та mysqldump, дозволяють змінити значення на стороні клієнта, встановивши max_allowed_packet у командному рядку або у файлі опцій.

Враховуючи цю інформацію, ви повинні раді, що MySQL буде розширювати та брати участь у пакеті MySQL за потребою. Тому вперед і

• набір max_allowed_packet на 1G як для Master, так і для Slave
• встановлено net_buffer_lengthмаксимальне значення 1М як для Master, так і Slave

Головний і ведений повинні відповідати за тим, хто передає дані, особливо дані BLOB.

ОНОВЛЕННЯ 2013-07-04 07:03 EDT

З ваших повідомлень, що стосуються журналу ретрансляції, виходить, що у вас є наступне

• корумпований журнал реле
• хороший майстер журналу

ПРОПОЗИЦІЯ

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;

Запуск CHANGE MASTER TOочищає всі журнали ретрансляції і починається з нового. Ви будете реплікувати з останньої події головного BinLog (BinLog, позиція), що виконується на підлеглому.

Спробувати !!!

Доволі бентежно проблемою були неправильні назви файлів для журналів, спричиняючи дивні результати, повторно імпортувались із правильними файлами файлів, і все було добре, висить голова від сорому