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