5.1.2 Architecture of HADR

Figure 5-1 illustrates the architecture of HADR.

Figure 5-1 DB2 HADR architecture

Figure 5-1 illustrates the following key aspects of a HADR environment:

• Enabling HADR on a primary server starts up a process called db2hadrp that communicates with the standby server. At the same time, on the standby server, a process called db2hadrs is started, which receives log records from the primary server, writes them to the log file on the standby server, and applies those transactions to the data and index pages.

• When an application is running on the primary server, normal insert/update/delete activity results in log records being written to the log buffer. When the log buffer is full, or whenever a transaction commits, the log buffer is flushed to disk (to the log files) prior to the application receiving a successful return code to its commit request.

• When the primary database is in peer state, log pages are shipped to the standby database whenever the primary database flushes a log page to disk. The log pages are written to the local log files on the standby database to ensure that the primary and standby databases have identical log file sequences. The log pages can then be replayed on the standby database to keep the standby database synchronized with the primary database.

Since HADR ensures that the primary and standby databases have identical log file sequences. If a disaster happens at the primary site, the standby database server can take over as the new primary database server to handle client application requests.

xxxx