Synchronization of multiple user database families with msimportauto.bat

In certain circumstances, successfully importing of user database update packets may depend on information contained in other user database packets. If your schema repository is associated with multiple user database families, import may fail if the packets are not replayed in the order they were generated.

The script msimportauto.bat, which is included with this version of HCL Compass, scans the import directory for update packets and then attempts to import the packets to each family. If any packets are successfully imported, the imported packets are deleted from the directory and the script attempts to import the next packet. The script stops executing when all packets are replayed and the directory is empty. If a series of import attempts results in no packets being deleted from the directory, the script stops executing and import fails.

The following sections explain when to use the tool and provide syntax examples and instructions.

Example

A particular clan, with sites in Boston and Denver has two user databases, User1 and User2. The Boston administrator generates a synchronization packet for User1 (Packet1) and then generates one for User2 (Packet2). While the packets are being created, an administrator modifies user account information; this causes schema repository oplog content to be included in both of the user database packets.

Some time later, the Boston administrator generates another pair of user database synchronization packets for User1 (Packet3) and User2 (Packet4). Again, an administrator modifies user account information while the packets are being created, and schema repository oplog content is included in both user database packets.

All four packets are sent to the Denver site. At the Denver site, the administrator runs syncreplica -import and specifies the User1 database family. Packet1 and Packet3 are both intended for the User1 family. Import of Packet1 is successful and replays oplogs in User1 and the schema repository. However, import of Packet3 fails, because it depends on schema repository database oplogs contained in Packet2, which have not yet been replayed at the Denver replica.

Solution

To avoid this situation, packets created at the exporting site must be replayed in the same sequence at the importing sites. Use the msimportauto.bat script.