Versions Compared

Version Old Version 8 New Version Current
Changes made by

Herman Kall (Deactivated)

Herman Kall (Deactivated)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

From version 2.8 onwards Replicate parameters APPLY_LOOP_PREVENTION and MINE_LOOP_PREVENTION will become public ones.

...

Comment: MINE_LOOP_PREVENTION is preferred to APPLY_LOOP_PREVENTION as the changes are filtered sooner and don't even get written to a PLOG file. But it's too aggressive in more complicated scenarios.

Valid Settings: YES or NO


 NOTE:

Info

...

 If both APPLY_LOOP_PREVENTION and MINE_LOOP_PREVENTION are disabled APPLY will not set/use transaction name 'DBREPL_%'.

The settings for APPLY_LOOP_PREVENTION and MINE_LOP_PREVENTION can be different on each DB, but usually it's not necessary. And if they are kept the same, then using MINE implies APPLY has no effect. (MINE already filtered the changes.) 



USE CASES:

One-To-One Replication: MINE_LOOP_PREVENTION is not needed.

Bi-direction (or 2-way): MINE_LOOP_PREVENTION can be used.  

replication is possible allowing master-to-master replication to provide real time information across multiple applications and sites. 

...

.

...

 

One-To-Many: MINE_LOOP_PREVENTION is not needed.

One-On-One (cascade A -> B -> C): don't use MINE_LOOP_PREVENTION, it would prevent changes from first to last. APPLY_LOOP_PREVENTION is not needed.

One-On-One-Back (triangle A -> B -> C -> A): don't use MINE_LOOP_PREVENTION. Use APPLY_LOOP_PREVENTION to stop the loop when s change gets back "home".

Bi-direction (or 2-way): MINE_LOOP_PREVENTION can be used. 

 

Info

The settings for APPLY_LOOP_PREVENTION and MINE_LOP_PREVENTION can be different on each DB, but usually it's not necessary. And if they are kept the same, then using MINE_LOOP_PREVENTION implies APPLY_LOOP_PREVENTION has no effect. (MINE already filtered the changes.)

 

See also:

Filtering deletes at a transaction level

Filter the data to be replicated