Re: drop table is written to bin-log, load table is NOT - why????
Hello Artem, thanks for your answer. For selective replication I would check startup options --replicate-do-* and --replicate-wild-*. I'm using replicate-do-db on the client but the problem is, that the master sends the sql-statements of ALL databases to the repl-client and the replicate-do-db-command only tells the client which sql-statements it should carry out and which statements it should drop without notice. In the actual case only 5% of the traffic is caused by the database which needs to be replicated so we would have to pay for 95% useless traffic if we wouldn't use daisy-chain Replication to filter the traffic. . Also you may need log-slave-update option on if you have daisy-chain replication. I'm using this option too but it seems to have no effect doing a load table ... from master. Greetings from Germany Lutz -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: drop table is written to bin-log, load table is NOT - why????
Hello Lutz, I was not aware of this behavior of the master server. Maybe somebody with more insight can explain. If the traffic volume is so important I would turn on compression on the master-slave connection to reduce network traffic. I think it is slave_compressed_protocol=1 option in the [mysqld] section of the MySQL configuration file. Regards, Artem -Original Message- From: Lutz Maibach [mailto:[EMAIL PROTECTED] Sent: Thursday, January 27, 2005 9:58 AM To: mysql Liste Subject: Re: drop table is written to bin-log, load table is NOT - why Hello Artem, thanks for your answer. For selective replication I would check startup options --replicate-do-* and --replicate-wild-*. I'm using replicate-do-db on the client but the problem is, that the master sends the sql-statements of ALL databases to the repl-client and the replicate-do-db-command only tells the client which sql-statements it should carry out and which statements it should drop without notice. In the actual case only 5% of the traffic is caused by the database which needs to be replicated so we would have to pay for 95% useless traffic if we wouldn't use daisy-chain Replication to filter the traffic. . Also you may need log-slave-update option on if you have daisy-chain replication. I'm using this option too but it seems to have no effect doing a load table ... from master. Greetings from Germany Lutz -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] Attention: Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
drop table is written to bin-log, load table is NOT - why????
Hello, I'm wondering why on a replication client (MySQL 4.0.23) a drop table XYZ is written to the mysql binlog while the following load table XYZ from master is not. This missing binlog-entry in the first repl. client causes a second replication client, which is replicating the first client, (sounds silly but this construction is necessary to filter the entries of a single database out of dozen hosted on the master and to replicate the logentries for this database only) to go out of sync cause it still holds the old values while the first client now is up to date. Help would be appreciated Lutz Maibach EasyCom GmbH -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: drop table is written to bin-log, load table is NOT - why????
Hello Lutz, As far as I know, binlog records only DML and DDL statements, and LOAD TABLE FROM MASTER is not the one. For selective replication I would check startup options --replicate-do-* and --replicate-wild-*. See http://dev.mysql.com/doc/mysql/en/replication-options.html for details. Also you may need log-slave-update option on if you have daisy-chain replication. Regards, Artem -Original Message- From: Lutz Maibach [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 26, 2005 8:24 AM To: mysql Liste Subject: drop table is written to bin-log, load table is NOT - why Hello, I'm wondering why on a replication client (MySQL 4.0.23) a drop table XYZ is written to the mysql binlog while the following load table XYZ from master is not. This missing binlog-entry in the first repl. client causes a second replication client, which is replicating the first client, (sounds silly but this construction is necessary to filter the entries of a single database out of dozen hosted on the master and to replicate the logentries for this database only) to go out of sync cause it still holds the old values while the first client now is up to date. Help would be appreciated Lutz Maibach EasyCom GmbH -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] Attention: Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
