- ведомые обновления журнала ВЫКЛЮЧЕНЫ, но некоторые обновления все еще зарегистрированы к ведомому двоичному журналу?
Если Вы решили иметь установщик, создают сервисную учетную запись для Вас, Вы должны будете:
- Создайте резервную копию любых существующих данных.
- Пост-ГРЭС удаления.
- Удалите сервисную учетную запись. Это важно!
- Переустановите пост-ГРЭС.
- Данные восстановления из резервного копирования.
Это связано с проблемой сброса пароля в сценарии установщика. В действительности исходная сервисная учетная запись просто должна быть убрана при переустановке. Это может быть исправлено в более новых версиях.
Значения server-id показывают, что для меня все работает, как ожидалось.
Каждый оператор связан с server-id с сервера, на котором этот оператор был создан (так mysql сервер знает, что нельзя копировать инструкции от самого себя, если вы не используете конкретную настройку). Эта ассоциация сохраняется даже при репликации.
Вы можете видеть, что операторы от ведущего (server-id 1) только реплицируются, сохраняются в журналах ретрансляции, а затем выполняются на ведомом устройстве без записи в двоичные журналы ведомого. Операторы, которые вы видите, связанные с server-id 3 (подчиненным), должны выполняться локально на подчиненной базе данных. Вот почему они записываются в бинлоги. log-slave-updates не исключает локально записанные запросы.
Вы должны посмотреть трафик на вашей подчиненной базе данных: что-то должно подключаться и выполнять эти запросы. Если вы ничего не видите в списке процессов (нет постоянных соединений), вы можете попробовать включить общий журнал или перехватить трафик mysql с помощью tcpdump или чего-то еще.
Также: вы говорите, что хотите, чтобы двоичные журналы на ведомом устройстве для инкрементных резервных копий . Если вы намеренно исключаете трафик репликации из своих ведомых двоичных журналов, это не похоже на то, что у вас действительно есть возможность использовать эти двоичные журналы для резервного копирования / восстановления на определенный момент времени. Вам будет не хватать всего трафика репликации. Так, может быть, вам все-таки стоит использовать log-slave-updates? Не уверен.
-Дэн
В вашем вопросе вы сказали, что двоичные журналы на ведомом устройстве имеют
#120404 19:08:57 server id 3 end_log_pos 110324763 Query thread_id=382435 exec_time=0 error_code=0
SET TIMESTAMP=1333541337/*!*/;
INSERT INTO norep_SplitValues VALUES ( NAME_CONST('cur_string',_utf8'118212' COLLATE 'utf8_general_ci'))
/*!*/;
# at 110324763
Если репликация перенесла это, то тот же запрос должен быть в журналах ретрансляции . Найдите журнал реле, содержащий запрос INSERT с тем же TIMESTAMP (1333541337).
Если вы не можете найти его в журналах реле, посмотрите, отправляет ли Infobright запрос INSERT. В этом случае INSERT должен быть записан в двоичные журналы Slave.
UPDATE 2012-04-04 14:49 EDT
Вот эксперимент. Выполните следующий запрос на ведущем устройстве:
CREATE DATABASE quantatest;
Этот оператор должен попасть в журналы реле на ведомом устройстве после выполнения на ведущем устройстве . В нормальных условиях этот оператор не должен появляться в двоичных журналах ведомого устройства, если log-slave-updates отключено.
Согласно вашему вопросу, если у вас отключено log-slave-updates , вы говорите, что этот запрос появится в двоичных журналах Slave.
Выполните CREATE DATABASE qualatest; сейчас на Master, пожалуйста. Сообщите мне, если CREATE DATABASE Quantatest; появилось в двоичных журналах ведомого устройства.