11.4.2. BidiRemoteSlave (BidiSlave) Filter

The BidiRemoteSlaveFilter is used by Tungsten Replicator to prevent statements that originated from this service (i.e. where data was extracted), being re-applied to the database. This is a requirement for replication to prevent data that may be transferred between hosts being re-applied, particularly in Active/Active and other bi-directional replication deployments.

Pre-configured filter name bidiSlave
Classname com.continuent.tungsten.replicator.filter.BidiRemoteSlaveFilter
Property prefix replicator.filter.bidiSlave
Stage compatibility  
tpm Option compatibility  
Data compatibility Any event
Parameter Type Default Description
localServiceName string ${local.service.name} Local service name of the service that reads the binary log
allowBidiUnsafe boolean false If true, allows statements that may be unsafe for bi-directional replication
allowAnyRemoteService boolean false If true, allows statements from any remote service, not just the current service

The filter works by comparing the server ID of the THL event that was created when the data was extracted against the server ID of the current server.

When deploying through the tpm service the filter is automatically enabled for remote Appliers. For complex deployments, particularly those with bi-directional replication (including active/active), the allowBidiUnsafe parameter may need to be enabled to allow certain statements to be re-executed.


Known Issue for Active/Active installations with AWS Aurora

Due to a change in behaviour from MySQL v5.7 onwards, USER, VIEW, TRIGGER information is logged differently in the binary logs.

When AWS Aurora is in use as a Source, this change in behaviour prevents the filter from working correctly for DDL specific to USER (CREATE USER, GRANT etc), VIEWS (CREATE and DROP) and TRIGGERS (CREATE and DROP)

A current workaround would be to additionally use the dropDDL fiter until a future Tungsten Replicator release addresses the issue.