Назад | Перейти на главную страницу

--log-slave-updates ВЫКЛЮЧЕНА, но некоторые обновления все еще регистрируются в двоичном журнале подчиненного устройства?

MySQL версии 5.5.14

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

Вот мой конфиг. на раб:

# egrep 'bin|slave' /etc/my.cnf
relay-log=mysqld-relay-bin
log-bin = /var/log/mysql/mysql-bin
binlog-format=MIXED
sync_binlog = 1
log-bin-trust-function-creators = 1

mysql> show global variables like 'log_slave%';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| log_slave_updates | OFF   |
+-------------------+-------+
1 row in set (0.01 sec)

mysql> select @@log_slave_updates;
+---------------------+
| @@log_slave_updates |
+---------------------+
|                   0 |
+---------------------+
1 row in set (0.00 sec)

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

-rw-rw---- 1 mysql mysql  37M Apr  1 01:00 /var/log/mysql/mysql-bin.001256
-rw-rw---- 1 mysql mysql  25M Apr  2 01:00 /var/log/mysql/mysql-bin.001257
-rw-rw---- 1 mysql mysql  46M Apr  3 01:00 /var/log/mysql/mysql-bin.001258
-rw-rw---- 1 mysql mysql 115M Apr  4 01:00 /var/log/mysql/mysql-bin.001259
-rw-rw---- 1 mysql mysql 105M Apr  4 18:54 /var/log/mysql/mysql-bin.001260

и пример запроса при чтении этих двоичных файлов с помощью mysqlbinlog утилита:

#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

Я что-то пропустил?

Ответ на @RolandoMySQLDBA:

Если репликация принесла это, то тот же запрос должен быть в журналах реле. Найдите журнал реле, в котором есть запрос INSERT с тем же TIMESTAMP (1333541337).

В журналах реле нет такого запроса с тем же TIMESTAMP.

Если вы не можете найти его в журналах ретрансляции, посмотрите, отправляет ли Infobright запрос INSERT. В этом случае INSERT должен быть записан в двоичные журналы Slave.

Заглянув глубже в двоичный logs, я вижу, что почти все запросы - это «временные» таблицы CREATE / INSERT / UPDATE / DROP, примерно так:

# at 123873315
#120405  0:42:04 server id 3  end_log_pos 123873618     Query   thread_id=395373        exec_time=0     error_code=0
SET TIMESTAMP=1333561324/*!*/;
SET @@session.pseudo_thread_id=395373/*!*/;
CREATE TEMPORARY TABLE `norep_tmpcampaign` (
    `campaignid` INTEGER(11)  NOT NULL DEFAULT '0' ,
    `status` INTEGER(11)  NOT NULL DEFAULT '0' ,
    `updated` DATETIME,
         KEY `campaignid` (`campaignid`)             
        )ENGINE=MEMORY
/*!*/;
# at 123873618
#120405  0:42:04 server id 3  end_log_pos 123873755     Query   thread_id=395373        exec_time=0     error_code=0
SET TIMESTAMP=1333561324/*!*/;
DROP TABLE IF EXISTS `norep_tmpcampaign1` /* generated by server */

«временные» здесь означает, что они удаляются после завершения расчета. Я также приказываю ведомому устройству не повторять никаких операторов, соответствующих norep_ шаблон подстановки:

replicate-wild-ignore-table=%.norep_%

Но в двоичных журналах есть таблица исключений:

# at 123828094
#120405  0:37:21 server id 3  end_log_pos 123828495     Query   thread_id=395209        exec_time=0     error_code=0
SET TIMESTAMP=1333561041/*!*/;
INSERT INTO sessions  (SessionId, ApplicationName, Created, Expires,   LockDate, LockId, Timeout, Locked, SessionItems, Fla
gs)  Values('pgv2exo4y4vo4ccz44vwznu0', '/', '2012-04-05 00:37:21', '2012-04-05 00:57:21',   '2012-04-05 00:37:21', 0, 20, 
0, 'AwAAAP////8IdXNlcm5hbWUGdXNlcmlkCHBlcm1pdGlkAgAAAAQAAAAGAAAAAQABAAEA', 0)
/*!*/;

Описание:

mysql> desc reportingdb.sessions;
+-----------------+------------------+------+-----+---------------------+-------+
| Field           | Type             | Null | Key | Default             | Extra |
+-----------------+------------------+------+-----+---------------------+-------+
| SessionId       | varchar(64)      | NO   | PRI |                     |       |
| ApplicationName | varchar(255)     | NO   |     |                     |       |
| Created         | timestamp        | NO   |     | 0000-00-00 00:00:00 |       |
| Expires         | timestamp        | NO   |     | 0000-00-00 00:00:00 |       |
| LockDate        | timestamp        | NO   |     | 0000-00-00 00:00:00 |       |
| LockId          | int(11) unsigned | NO   |     | NULL                |       |
| Timeout         | int(11) unsigned | NO   |     | NULL                |       |
| Locked          | bit(1)           | NO   |     | NULL                |       |
| SessionItems    | varchar(255)     | YES  |     | NULL                |       |
| Flags           | int(11)          | NO   |     | NULL                |       |
+-----------------+------------------+------+-----+---------------------+-------+

Я уверен, что все эти запросы отправляются MySQL, не Infobright:

$ mysql-ib -u root -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 48971
Server version: 5.1.40 build number (revision)=IB_4.0.5_r15240_15370(ice) (static)

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select * from information_schema.tables where table_name='sessions';
Empty set (0.02 sec)

Я пробовал несколько запросов INSERT / UPDATE с тестовыми таблицами на главном сервере, он копируется в реле журналы, а не двоичные журналы на ведомом устройстве:

# at 311664029
#120405  0:15:23 server id 1  end_log_pos 311664006     Query   thread_id=10458250      exec_time=0     error_code=0
use testuser/*!*/;
SET TIMESTAMP=1333559723/*!*/;
update users set email2='xx@gmail.com' where id=22
/*!*/;

Обратите внимание на server id, в реле журналы, идентификатор сервера - ведущий (1), а в двоичный log, идентификатор сервера - подчиненный (в данном случае 3).

Ответ на @RolandoMySQLDBA: четверг, 5 апреля, 10:06:00 ICT 2012

Бегать CREATE DATABASE quantatest; на Мастера, пожалуйста. Скажите мне, если CREATE DATABASE quantatest; появился в двоичных журналах Slave.

Как я уже сказал выше:

Я пробовал несколько запросов INSERT / UPDATE с тестовыми таблицами на главном сервере, он копируется в реле журналы, а не двоичные журналы

и вы можете догадаться, поток ввода-вывода скопировал его в журналы реле, а не в двоичные журналы.

#120405 10:07:25 server id 1  end_log_pos 347573819     Query   thread_id=10480775      exec_time=0     error_code=0
SET TIMESTAMP=1333595245/*!*/;
/*!\C latin1 *//*!*/;
SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=8/*!*/;
create database quantatest
/*!*/;

Вопрос, вероятно, должен измениться на: почему некоторые запросы на обновление все еще регистрируются в двоичных журналах подчиненного устройства --log-slave-updates выключен? Откуда они?

Вот несколько последних:

/*!*/;
# at 27492197
#120405 10:12:45 server id 3  end_log_pos 27492370      Query   thread_id=410353        exec_time=0     error_code=0
SET TIMESTAMP=1333595565/*!*/;
CREATE TEMPORARY TABLE norep_SplitValues (
        value VARCHAR(1000) NOT NULL
      ) ENGINE=MEMORY
/*!*/;
# at 27492370
#120405 10:12:45 server id 3  end_log_pos 27492445      Query   thread_id=410353        exec_time=0     error_code=0
SET TIMESTAMP=1333595565/*!*/;
BEGIN
/*!*/;
# at 27492445
#120405 10:12:45 server id 3  end_log_pos 27492619      Query   thread_id=410353        exec_time=0     error_code=0
SET TIMESTAMP=1333595565/*!*/;
INSERT INTO norep_SplitValues VALUES ( NAME_CONST('cur_string',_utf8'119577' COLLATE 'utf8_general_ci'))
/*!*/;
# at 27492619
#120405 10:12:45 server id 3  end_log_pos 27492695      Query   thread_id=410353        exec_time=0     error_code=0
SET TIMESTAMP=1333595565/*!*/;
COMMIT
/*!*/;
# at 27492918
#120405 10:12:46 server id 3  end_log_pos 27493115      Query   thread_id=410353        exec_time=0     error_code=0
SET TIMESTAMP=1333595566/*!*/;
SELECT `reportingdb`.`selfserving_get_locationad`(_utf8'3' COLLATE 'utf8_general_ci',_utf8'' COLLATE 'utf8_general_ci')
/*!*/;
# at 27493199
#120405 10:12:46 server id 3  end_log_pos 27493353      Query   thread_id=410353        exec_time=0     error_code=0
SET TIMESTAMP=1333595566/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
DROP TEMPORARY TABLE IF EXISTS `norep_SplitValues` /* generated by server */
/*!*/;

В вашем вопросе вы сказали, что двоичные журналы на Slave имеют

#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.

ОБНОВЛЕНИЕ 2012-04-04 14:49 EDT

Вот эксперимент. Выполните следующий запрос на Мастере:

CREATE DATABASE quantatest;

Этот оператор должен попасть в журналы реле на ведомом устройстве после выполнения на ведущем устройстве.. При нормальных обстоятельствах этот оператор не должен появляться в двоичных журналах ведомого устройства, имеющих log-slave-updates отключен.

По вашему вопросу у вас есть log-slave-updates отключено, вы говорите, что этот запрос появится в двоичных журналах Slave.

Бегать CREATE DATABASE quantatest; на Мастера, пожалуйста. Скажите мне, если CREATE DATABASE quantatest; появился в двоичных журналах Slave.

Значения server-id показывают, что все работает, как я ожидал.

Каждый оператор связан с идентификатором сервера с сервера, на котором этот оператор был создан (именно так сервер mysql знает, что не следует копировать операторы от самого себя, если вы не используете конкретный параметр). Эта ассоциация сохраняется даже при репликации.

Вы можете видеть, что операторы от ведущего (server-id 1) только реплицируются, сохраняются в журналах реле, а затем выполняются на ведомом устройстве без записи в двоичные журналы ведомого устройства. Операторы, которые вы видите, связанные с server-id 3 (подчиненным), должны выполняться локально на подчиненной базе данных. Вот почему они записываются в бинлоги. log-slave-updates не исключает локально написанные запросы.

Вы должны посмотреть трафик на вашей подчиненной базе данных: что-то должно подключаться и выполнять эти запросы. Если вы ничего не видите в списке процессов (нет постоянных подключений), вы можете попробовать включить общий журнал или захватить трафик mysql с помощью tcpdump или чего-то еще.

Также: вы говорите, что хотите, чтобы двоичные журналы на ведомом устройстве использовались для инкрементных резервных копий. Если вы намеренно исключаете трафик репликации из своих ведомых двоичных журналов, это не похоже на то, что у вас действительно есть возможность использовать эти двоичные журналы для резервного копирования / восстановления на определенный момент времени. Вам будет не хватать всего трафика репликации. Так, может быть, вам все-таки стоит использовать log-slave-updates? Точно сказать не могу.

-Дэн