Hot Standby configurations consist of two or more servers bundled in a hardware cluster. The cluster has to provide the mechanism to change roles between master and standby component (IP switching etc.) and furthermore continiously has to monitor the components. Additionally the storage system must be configurable as follows: Master and standby instance(s) must access a shared log area, whereas the master has read/write privilege and the standby has only read privilege. The data volumes of the instances are not shared and must be seperate for each instance. The storage system must provide fast binary copy services (e.g. BCV or Snapshot) and to avoid any blocking the master component should be able to continue writing to the data volumes during copy. With such copy algorithm the data volumes of the standby instance(s) are set up to the current state of the master instance. All standby components in a hot standby system are synchronised continiously by redoing all log information that is written by the master instance. The standby instance always gets the information from the master instance up to which position the log has to be redone. According to the individual purpose of your hot standby system a delay value can be set to define the time gap between master and standby instances. This for instance can be some hours for development systems to reset user errors or close to zero for production systems to restart within second in case of hardware failure.
In case the master instance fails, the cluster software assigns a standby instance to be the new master. This new master takes over the write privilege for the log volume redoes the remaining log entries and restarts to online mode. Master and standby instances use exactly the same parameter settings. Changes of parameters will always apply to the master instance and will be propagated to the standby instances.
But hot standby is no insurance against user or application errors or inconsistencies. Thus log and data backups are of the same importance as in a standard configuration.
Hot Standby will be offered in 2004 in course of the MaxDB and SAP liveCache version 7.5. SAP liveCache 7.5 will address SCM 4.1 and MaxDB 7.5 will first become visible with Netweaver ’04 (6.40).
Currently EMC Symetrix, IBM Shark and IBM ESS support this technology.