DB2 10.5 for Linux, UNIX, and Windows

High availability through redundancy

An important strategy for maintaining high availability is having redundant components. If a component fails, a secondary or backup copy of that component can take over, enabling the database to remain available to user applications. If a component of the system is not redundant, that component could be a single point of failure for the system.

Redundancy is common in system design:

Uninterrupted or backup power supplies
Multiple network fibers between each component
Bonding or load balancing of network cards
Multiple hard drives in a redundant array
Clusters of CPUs

If any one of these components of the system is not redundant, that component could be a single point of failure for the whole system.

You can create redundancy at the database level, by having two databases: a primary database that normally processes all or most of the application workload; and a secondary database that can take over the workload if the primary database fails. In a DB2® High Availability Disaster Recover (HADR) environment, this secondary database is called the standby database.

For DB2 Connect™ clients, Sysplex workload balancing functionality on DB2 for z/OS® servers provides high availability for client applications that connect directly to a data sharing group. Sysplex workload balancing functionality provides workload balancing and seamless automatic client reroute capability. This support is available for applications that use Java™ clients (JDBC, SQLJ, or pureQuery) or other clients (ODBC, CLI, .NET, OLE DB, PHP, Ruby, or embedded SQL).