MySQL thrown exception from library option Log-slave-updates is not enabled.

Recently checked one based on copying a particular table from the library to another master library adjustment, the log-slave-updates is not configured to cause the table to not synchronize properly. The replicate-rewrite-db parameter and the replicate_wild_do_table parameter are used in our configuration file. See the description below for a specific scenario.

1, environmental introduction and the origin of the problem
Db1m (Master)---> db1s (Slave)
DB2M (Master)---> db2s (Slave)
The situation now is that you need to synchronize the specific table Tbname on the db1m instance to the DB2M instance in real time
To alleviate the pressure on the db1m, we will db1s as the main repository of DB2M, i.e. the final topological result is as follows:
Db1m (tbname)---> db1s (tbname)---> db2m (tbname)--->db2s (tbname)
The following parameters are configured on the DB2M:
Replicate-rewrite-db=db1->db2
Replicate_wild_do_table=db2.tbname
After the above configuration, the Tbname table is synchronized to the DB2 of the DB2M instance from the DB1M consistency export
When configured, the table Tbname on DB2M (Master)---> db2s (Slave) is not fully synchronized, and there is always a problem with data loss

2. Analysis
A, db1m (Master)---> db1s (Slave) Table Tbname no exception, excluding db1s as the possibility of the problem of DB2M master
B, Db1s (tbname)---> db2m (tbname) Table Tbname No exception, exclude related configuration enabled on Db1s, etc.
B, db2m (Master)---> db2s (Slave) The table Tbname there is a problem, that is, the DML log based on table db2m on Tbname is not written to Binlog
C, on the DB2M based on the table Tbname DML log is derived from db1s generated relay log, synchronization to DB2M (Master) No exception, you can find relay in Tbname log related operations
E, verify step c, and then check if DB2M (Master) has tbname binlog, if not, it must be a parameter is not set or a specific pair of reasons caused by the Apply relay log is not added to the Binlog

3, fault resolution
With the above analysis and verification, it is found that the parameters are missing on db2m (Master) log-slave-updates
Log-slave-updates after table Tbname synchronization is normal after db2m (Master) is added as an option from the library

4. About Log-slave-updates Options
Log-slave-updates is a global, non-dynamic option with a value of Boolean, which is true and false. The default is false, and modifying this parameter requires the instance to be restarted.

Normally, a slave does not log to its own binary log any updates this is received from a master server. This option tells the slave to log of the updates performed by their SQL thread to their own binary log. For this option to has any effect, the slave must also is started with the--log-bin [2039] option to enable binary Loggi Ng. Prior to MySQL 5.5, the server would not start when using the--log-slave-updates [2004] option without also starting the Server with the--log-bin [2039] option, and would fail with an error; In MySQL 5.6, only a warning is generated. (Bug #44663)--log-slave-updates [2004] is used if you want to chain replication servers. For example, you might want to set up replication servers using this arrangement:

C, A-B

Here, A serves as the master for the slave B, and b serves as the master for the slave C. For the to work, B must is both a master and a slave. You must start both A and B with--log-bin [2039] To enable binary logging, and B with the--log-slave-updates [2004] Opti On so the updates received from A is logged by B to their binary log.

MySQL thrown exception from library option Log-slave-updates is not enabled.