Earlier this week, I wrote about the Synchronization Manager and gave a step-by-step tutorial on getting an initial scenario implemented. In this article, I’ll expand on the previous tutorial by introducing the concept of uni-directional synchronization.

Uni-directional participants act as destinations for replicated data. These participants are sometimes called “slaves,” because they are not capable of replicating changes to other members of the synchronization scenario. Theoretically, any RDBMS that provides an appropriate JDBC interface can participate as a replication destination with little effort on the part of the DBA. As an example of this, I have documented my experience creating a uni-directional MySQL participant.

One situation DBAs might use databases synchronized as uni-directional participants is when they want to provide information to clients without trusting the recipient to update the master database. Another situation might be scenarios such as IMAP or POP mail stores, which are not updated through direct interaction, but modified at a central source, later propagating the changes to clients. Other examples of such a scenario are caching DNS servers and proxy servers.

As you can see, much can be done using the Synchronization Manager along with uni-directional replication destinations. Those of you interested in implementing such a uni-directional synchronization participant, please take a look at my walk-through and notes here:

http://wiki.colliertech.org/index.php/MaxDB:SynchMan:MySQL_as_destination