Joe,

The HA server is not a complete duplicate of the primary environment, both the comments you noted are important in that while it is possible to run and for users to perceive that everything is normal, the day to day tasks of indexing, datawarehouseing, and various other tasks that are being handled transparently by JTS are not going on. So the most noticeable item will be DW data that will not be captured as usual and essentially lost data points, and if the indices are not being maintained that may effect the ability to search for new data (I'm not sure about that one).

The design is that your end users can still access core functionality and your team will try to return the primary repository back on line ASAP, the time is not specified but assumed this would be treated as a critical issue and the stand bye is a bandage or tool not the fix. The recommended time is to bring the system up ASAP, whether that is your 1 day scheduled downtime to replace a retired server or 15 minutes after applying patches and a reboot this is flexible to meet your needs, but with the understanding that there are limitations of running on the standby server.

-Sean

Joe,

Thanks Sean, that's helpful. Are there any more details about the risks of staying in backup mode for an extended time period? I could see a situation where it may take days, perhaps weeks, to obtain and rebuild a new primary server if the initial server dies. What would the impact be if they were in backup mode for days or weeks?

This really sounds like less of a HA solution we have documented and just a backup server. If you find that you will be running on the backup for extended periods of time, you can re-enable the background services and change that to the "primary" and restart the server. However you will need to eventually mark one as primary/backup again once the new server is back online via the property (com.ibm.team.repository.scheduler.migration.mode.enabled=true) since there is no current clustering support in RTC it is not possible to run two active repositories at once, which requires the active-pasive HA solution.

o Would they experience a drop in performance?
o Would they lose data (you mention the DW is not captured).
o What is the impact of not indexing for days/weeks?
o What happens when they bring the primary server back on line? Are there any steps they need to perform to rebuild the lost indexes?

The performance will be related to the configuration, since this recommends shared disks, and you are on the same database, the main factor here is the hardware the "backup" is on, if they match no.

Without backgrounds tasks, dw ETL jobs are one thing that would not be running, so daily snapshot data would not be captured.

If the indices are not updated, your full text search would less relevant if we assume that no new information is put into them once the primary went down.

The instructions here again are expecting that you bringing the primary back up in short order so the additional steps are not necessary and will be handled by the async tasks, for an extended downtime we could essentially treat this as a restore and perform the similar rebuild of the text indices prior to restarting the server.

o What are the "other tasks" you refer to? What impact will they have on a system that is down for an extended period of time?

Let's see if we can get some definitive answers to this one that might be relevant here, the only other thing that comes to mind besides the dw is builds.

-Sean