Synchronization schedule
The synchronization schedule for a family defines when replicas in the family send and receive updates. The schedule is affected by many factors, including the rate of development at different sites, the connections among sites, and whether you use MultiSite as a backup strategy.
- Rate of development
If you schedule synchronizations frequently, you lose less work if a replica is deleted accidentally and you must restore it from backup. Also, merging is simpler because fewer changes have been made.
Make sure that synchronizations do not overlap with backups. VOBs must be locked while they are being backed up, and the syncreplica command fails if the VOB is locked.
- Time zone differences
Take different time zones into account when you send an update or set up automated updates. Figure 1 illustrates synchronization among replicas in multiple time zones.
- Use of administrative VOBs
Because local type objects in VOBs are linked to global type objects in the administrative VOB, synchronize VOBs and their administrative VOB at the same time.
For example, at the Boston site, the VOB /vobs/dev is linked to administrative VOB /vobs/admin, and both VOBs are replicated to San Francisco and Bangalore. You export update packets to replicas sanfran_hub@/vobs/dev and sanfran_hub@/vobs/admin at 11:00 p.m. local time and export update packets to replicas bangalore@/vobs/dev and bangalore@/vobs/admin at 5:00 a.m. local time. The administrator at San Francisco imports both packets at the same time, as does the administrator at Bangalore.
If you do not synchronize VOBs and their administrative VOBs at the same time, users may have trouble accessing type objects.
- Use of HCL
VersionVault UCM
Synchronize a component VOB and its PVOB at the same time. If you are using composite baselines or have activities whose change sets will span component VOBs, synchronize these inter-dependent component VOBs on the same schedule. If you do not, users may have trouble accessing baselines and activities and the versions associated with those objects.
- Changes that affect both the schema repository and the
user database
Many changes are recorded in the schema repository and the user database, and oplog entries are created in both operation logs. Synchronize your schema repositories first, and then synchronize the user databases.
- The hub replicas, which undergo rapid development, synchronize every hour.
- Each hub replica synchronizes daily with its spoke replicas. Each spoke replica sends an update packet to the hub replica, and then the hub replica sends update packets back to the spoke replicas. Because these packets may be large and take a long time to import, the synchronization must not take place during working hours or during backups.
- All replica hosts use receipt handlers to import packets as soon as they are received.
