Replication Levels

Background

• Mirrororing non-transaction oriented, slowly changing data ... e.g. a product catalogue, on the east and west coast. This is easy to implement.

• Transaction oriented, but can incurr delays in establishing consistency. e.g. counting how much youve got in stock, but usually have so much in stock that consistency is re-established before you run out of stock. Harder problem.

• Financial, and/or limited stock (e.g. airplane seats). If you are withdrawn cash from teller machine, you CAN'T get inconsistent. Ditto when selling the last seat on an airplane. Known to be very hard problem.

The List

Master Mirroring

This is the easiest form of replication to implement. There is a single master copy, and all changes are made to it. After changes have been made, the database is taken off-line, a backup is made, and copies of the back are installed on the mirror machines. Of course, if a database supports hot, on-line, consistent backups, then the copies can be made without taking the master offline.

Any good system administrator can do this, and this reqires no special consideration from the database designers. This strategy is fairly robust: if the master copy is lost, the mirrors can still operate, and the master can be reconstructed from the mirrors.

The drawbacks of this style of replication should be obvious: this model does not support distributed transactions. Transaction processing can only be done on the master, and thus the master is a critical componenet, and is also a bottleneck. The mirrors can be used only for viewing (reading).

The advantages of this style should also be obvious: by installing mirrors (which may be geographically separated by thousands of miles) performance for viewing is radically improved, since one machine does not have to handle all the load. The strength of this scheme is it's simplicity.

Peer Mirroring

The next level above Master Mirroring is Peer Mirroring. In this scheme, database updates can be performed on multiple "masters". Synchronization is acheived by having changes propagated from one mirror to another through journal logs. Consistency should be verified monthly or weekly by comparing the contents of each of the peers.

The disadvantage of this system is that it does not support transactions. There is no record locking during updates, and race conditions exist.