Versions Compared

Version Old Version 9 New Version Current
Changes made by

Herman Kall

Herman Kall

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.

...

Valid Settings: YES or NO


 

title
Info
Note

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

 



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-way replication is possible allowing real time reporting across distributed reader farms reducing the performance impact on the production databases.

 

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