Wednesday, December 14, 2011

If you are late, just say you are super asynchronous... (HADR)

Well, not everybody is on time and waiting for them can hold up a meeting, important decisions, or completing tasks. The same waiting can happen in an IT environment for various reasons, e.g., a replication or synchronization process taking longer because of network congestion or temporarily overloaded hardware. But what can you do when other tasks are waiting for?

When using DB2 HADR (High Availability Disaster Recovery) some thoughts have to be put into the decision of what synchronization mode to use. Starting with DB2 9.7 FP 5 there are now 4 instead of 3 modes offered:
  • SYNC (synchronous): the transaction log has been written on both the primary and standby
  • NEARSYNC (nearly synchronous): the transaction log has been written on the primary and has been transferred to the standby
  • ASYNC (asynchronous): the transaction log has been written on the primary and is ready to be sent over to the standby
  • SUPERASYNC (super asynchronous): the transaction log has been written on the primay
The SYNC mode needs the most work before a transaction is considered committed the SUPERASYNC mode the least. On the reverse, the SUPERASYNC mode has the most potential for loss of a transaction in the case of a failure. It is the traditional battle between performance and consistency as we have with isolation levels in database systems.

If you want to learn more about HADR for DB2, take a look at the best practices section on developerWorks. In August a new paper on DB2 HADR has been added that focuses on the configuration and tuning of HADR environments. And remember, you are not reading the paper late. You are just super asynchronous with the news...