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...


Deny Sutani said...

Hi Henrik,

Good article.

I've done some DB2 HADR implementation, and I got shock when my customer said about superasync :(

If we want to use HADR, means that we want to have exact copy of database. I never recommended my customer to use ASYNC, but now IBM give SUPERASYNC. It will increase the risk of lost data right ?

Henrik Loeser said...

Yes, it will increase the risk, that is the trade-off. The faster the transactions return on the primary, the more risk is involved on the standby. On the upside you can get more throughput or shorter response times on the primary. It is a different design goal.


Related Posts with Thumbnails