- August 29, 2017 at 5:11 pm #11005ggoodrichKeymaster
HVR is very flexible as to where to locate the hub database. So there is really no right or wrong from the HVR perspective. Most of the time these decisions are based upon organizational reasons like responsibilities or (lack of) technical skills.
- When replicating between a legacy system and a new system, it seems logical to put the hub on the new machine instead of on the old hardware.
- When replicating for high-availability (production to a hot-standby system); the hub will be on the production system (which is online almost always). A 2nd mirror hub can be on the standby system taking over replication when the prod system fails.
- A separate hub is chosen when several channels are managed by the same group (operators/dba’s). The main advantage is to have a single point of control for all of the replication. Hence only one machine to manage/monitor. The requirements of such a machine for memory and CPU are minor (a small VM would suffice). There is a requirement on the size of the disk that contains HVR_CONFIG because this is where replicated changes are queued when the Iintegrate job fails or is suspended. See our post in the Expert Note forum titled “The $HVR_CONFIG directory – is this just for log files? How much disk space is needed?” A disadvantage would be that if one needs to upgrade the HVR version on the HUB machine e.g. for a bug-fix that affects a certain channel, this would also mean upgrading other channels. Although theoretically, it is possible to have coexistence of several HVR version on the same machine, that seems overly complicated.
It is always advised to have separate HUB installations for Test/QA/Production environments.
- The forum ‘Expert Notes’ is closed to new topics and replies.