Less known Solaris Features: Remote Mirror with AVS - Part 5: Replication Groups

A new scenario: Okay, the filesystem gets replicated now. Let´s assume that we use /dev/rdsk/c1d0s1 for a database. The filesystem and the database partition are used from the same application and it´s important, that the metadata in the database an the binary objects are in sync even when you switched over to the remote site, albeit it´s acceptable to lose the last few transactions, as both sites are 1000km away from each other and synchronous replication is not an option.

The problem

When you use synchronous replication, all is well. But let´s assume you´ve choosen asychronous replication. Under this circumstances a situation can occure, where one queue is processed faster than another, thus the on-disk states of each volume may be consistent in itself, but both volumes may have the state at different point in time, thus leaving the application data model inconsistent. Such an behaviour is problematic, when you have a database volume and a filesystem volume working together for an application, but the results can be catastropic when you use a database splitted over several volumes. The solution of this problem would be a mechanism, that keeps the writes to a group of volumes in order for the complete group. Thus is inconsistencies can´t occur.

Replication Group

To solve such problems, AVS supports a concept called Replication Group. Adding volumes to a replication group has some implications: