Achieving hot standby

With hot standby, we see a process that minimizes the MTTR, but is also (in the majority of cases) a lot more complicated than either the cold or warm standby.

The reason for the additional complexity is due to a number of factors. The standby process may need to actively:

• monitor the health of its primary process — this could be anything from establishing a connection to the primary process and blocking until it dies, or it may involve more complex heuristics.
• receive current transaction-by-transaction updates, so that it always stays in sync with the primary. This is the basis for the hot standby process's ability to instantly take over the functionality—it's already up to date and running.

Of course, as with the warm standby process, the hot standby process needs to create another copy of itself to feed updates to when it becomes primary, in case it fails.

An excellent example of a hot standby process is a database. As transactions to the primary version of the database are occurring, these same transactions are fed to the hot standby process, ensuring that it is synchronized with the primary.