Mastership restrictions prevent most inconsistent changes in different replicas, but some are unavoidable. To avoid many naming conflicts, the administrators for a family must create and enforce naming rules for objects. A use model that is enforced consistently across sites reduces the potential for conflicts. For example, the administrators for a family follow these rules:
Two objects of the same type in the same VOB cannot have identical names. Accordingly, the syncreplica –import command detects a conflict when an update packet includes an operation that would create a type object with the same name as an existing object at the current replica. It resolves the conflict by creating the new type object with a different name.
For example, in Figure 3, two types created at two different replicas have the same name but are different objects. When the type created at the boston_hub replica is imported at the bangalore replica, it is not renamed because the bangalore replica does not contain a type with that name. However, when the type created at the sanfran_hub replica is imported at the bangalore replica, it is renamed because the bangalore replica already has a type with that name.
syncreplica generates a warning message when it renames an object during import. To resolve the conflict, the Bangalore administrator must inform the Boston and San Francisco administrators of the name conflict, and they must take one of the following actions:
multitool rename lbtype:V2.0 V2.0_boston_hub
At San Francisco:
multitool rename lbtype:V2.0 V2.0_sanfran_hub
The Boston and San Francisco administrators must then send updates to the bangalore replica.
For more information, see Automatic Renaming of Type Objects and Replica Objects.