Я установил MySQL (5.5) в режиме «главный-подчиненный» и создал еще один подчиненный сервер.

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

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 на master '

Однако, когда я запустил оригинальное ведомое устройство, оно отлично справилось и теперь синхронизировано.

Итак, вопросы:

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

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

Обновить

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

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

Last_SQL_Error: Ошибка чтения журнала ретрансляции: не удалось проанализировать запись события журнала ретрансляции. Возможные причины: бинарный журнал мастера поврежден (вы можете проверить это, запустив mysqlbinlog в двоичном журнале), журнал реле подчиненного устройства поврежден (вы можете проверить это, запустив mysqlbinlog в журнале ретрансляции), проблема с сетью или ошибка в коде MySQL ведущего или подчиненного. Если вы хотите проверить двоичный журнал ведущего или журнал ретрансляции ведомого, вы сможете узнать их имена, введя «SHOW SLAVE STATUS» на этом ведомом устройстве.

Если я делаю 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:

Максимальный размер одного пакета, любой сгенерированной / промежуточной строки или любого параметра, отправленного функцией API C mysql_stmt_send_long_data (). По умолчанию 4 МБ на MySQL 5.6.6, 1 МБ до этого.

Буфер пакетных сообщений инициализируется байтами 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_packet1G на ведущем и ведомом
• установить net_buffer_lengthмаксимальное значение 1M как на ведущем, так и на ведомом

Ведущий и ведомый должны совпадать с точки зрения того, кому они передают данные, особенно данные BLOB.

ОБНОВЛЕНИЕ 2013-07-04 07:03 ПО ВОСТОЧНОМУ ВРЕМЕНИ

Из ваших сообщений, касающихся релейного журнала, похоже, что у вас есть следующее

• поврежденный релейный журнал
• хороший мастер-лог

ПРЕДЛОЖЕНИЕ

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очищает все журналы реле и запускается с новым. Вы будете выполнять репликацию из последнего события Master BinLog (BinLog, Position), которое было выполнено на подчиненном устройстве.

Попробуйте!

Скорее смущающая проблема была неправильными именами файлов для журналов, вызывающими странные результаты, повторно импортированными с правильными именами файлов, и все было хорошо висит голова в позоре