--log-slave-updates está OFF, mas algumas atualizações ainda estão registradas no log binário do slave?

Question

MySQL versão 5.5.14

De acordo com o documento , pelo padrão, o escravo não registra em seu log binário todas as atualizações recebidas de um servidor mestre.

Aqui está minha configuração. no escravo:

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

mas o escravo ainda registra algumas alterações em seus logs binários, vamos ver o tamanho do arquivo:

-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

e a consulta de exemplo ao ler esses arquivos binários com o utilitário 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

Eu senti falta de algo?

Responder a @RolandoMySQLDBA:

If replication brought this over, then the same query has to be in the relay logs. Please go find the relay log that has the INSERT query with the same TIMESTAMP (1333541337).

Não existe tal consulta com o mesmo TIMESTAMP nos registros de relés.

If you cannot find it in the relay logs, then look and see if Infobright is posting the INSERT query. In that instance, the INSERT should be recorded in the binary logs of the Slave.

Examinando mais profundamente os logs binários , vejo que quase todas as consultas são tabelas "temporárias" de CREATE / INSERT / UPDATE / DROP, algo assim:

# 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 */

"temporário" significa que eles são descartados depois que o cálculo é feito. Eu também instrui o escravo a não replicar nenhuma instrução que corresponda ao padrão de curinga norep_ :

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

Mas há uma tabela de exceções nos logs binários:

# 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)
/*!*/;

Descrição:

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

Tenho certeza de que todas essas consultas estão postadas pelo MySQL, não 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)

Eu tenho tentado algumas consultas INSERT / UPDATE com tabelas de teste no master, ele é copiado para os logs relay , não para logs binários no slave:

# 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='[email protected]' where id=22
/*!*/;

Preste atenção no server id , nos logs do relay , o id do servidor é master (1) e no log binário , o id do servidor é escravo (3 in neste caso).

Responder a @RolandoMySQLDBA: Qui Abr 5 10:06:00 ICT 2012

Run CREATE DATABASE quantatest; on the Master now, please. Tell me if CREATE DATABASE quantatest; showed up in the Slave's Binary Logs.

Como eu disse acima:

I've been trying some INSERT/UPDATE queries with testing tables on the master, it is copied to the relay logs, not binary logs

e você pode adivinhar, o thread IO copiou para os logs de relay, não para logs binários.

#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
/*!*/;

A pergunta provavelmente deve mudar para: por que algumas consultas de atualização ainda registradas nos logs binários de escravo, embora --log-slave-updates estejam desativadas? De onde eles vêm?

Aqui estão alguns últimos:

/*!*/;
# 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 */
/*!*/;

    

Answer 1

Os valores do ID do servidor mostram que as coisas estão funcionando como esperado, para mim.

Cada declaração é associada ao server-id do servidor no qual aquela instrução se originou (é assim que um servidor mysql sabe não replicar instruções de si mesmo, a menos que você use uma configuração específica). Essa associação é preservada até por replicação.

Você pode ver que as instruções do mestre (id do servidor 1) são apenas replicadas, armazenadas nos logs de relay e, em seguida, executadas no escravo sem gravar nos log bogs do escravo. As instruções que você vê associadas ao server-id 3 (o escravo) devem ser executadas localmente no banco de dados escravo. É por isso que eles são escritos no log binário. log-slave-updates não excluirá consultas escritas localmente.

Você deve olhar para o tráfego em seu banco de dados escravo: algo deve estar se conectando e executando essas consultas. Se você não vê nada na lista de processos (nenhuma conexão persistente), você pode tentar ativar o log geral ou capturar o tráfego mysql usando o tcpdump ou algo assim.

Além disso, você diz que deseja os binlogs no escravo para backups incrementais. Se você está intencionalmente excluindo o tráfego de replicação de seus logs binários de escravo, isso não soa como se você realmente tivesse a capacidade de usar esses binlogs para backups / recuperação pontuais. Você perderá todo o tráfego de replicação. Então, talvez você deva estar usando log-slave-updates, afinal? Não tenho certeza.

-Dan

    

Answer 2

Na sua pergunta, você disse que os registros binários no Escravo têm

#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

Se a replicação trouxe isto, então a mesma consulta tem que estar nos logs de relay . Por favor, vá encontrar o log de retransmissão que tem a consulta INSERT com o mesmo TIMESTAMP (1333541337).

Se você não conseguir encontrá-lo nos registros de retransmissão, verifique se o Infobright está postando a consulta INSERT. Nesse caso, o INSERT deve ser registrado nos logs binários do escravo.

ATUALIZAÇÃO 2012-04-04 14:49 EDT

Aqui está uma experiência. Execute a seguinte consulta no mestre:

CREATE DATABASE quantatest;

Esta declaração deve pousar nos logs de retransmissão no Escravo após a execução no mestre . Em circunstâncias normais, essa declaração não deve aparecer nos logs binários do Escravo com log-slave-updates desativado.

De acordo com a sua pergunta, com log-slave-updates desativado, você diz que esta consulta aparecerá nos registros binários do Escravo.

Execute CREATE DATABASE quantatest; no mestre agora, por favor. Diga-me se CREATE DATABASE quantatest; apareceu nos Registros Binários do Escravo.