HADR Remote Catchup Speed && Throttle Primary--->Aux-Standby-stream hardware usage on Primary

Rui Chen

HADR Remote Catchup Speed && Throttle Primary--->Aux-Standby-stream hardware usage on Primary

Got 3 HADR related questions here, hope someone could share some insights :)

  1. What's the remote-catchup speed?
    Learnt from multiple references that db2lfr fetches log record at 16pg (or 64kB) per batch, but how often does db2lfr perform this fetch/batch operation? HADRCalculator models the remote catchup log shipping rate at 16pg/flush using async (ref.link section Remote Catchup Speed), which equivalents to about 70MB/sec in our OLTP db on average, according to the HADRCalculator output. Should we expect at least 140MB/sec disk IO transfer rate on average to accommodate 2 aux-Standbys? Currently our OLTP has logging rate at about 4MB/sec on average, with peak value less than 15MB/sec, so i'm definitely missing something here....... 

  2. Can we throttle the hardware resources, eg. network and/or disk IO bandwidth consumed by aux-Standby log shipping? 
    The goal is to avoid exhausting resources required by principle-Standby stream. We'll most likely use NEARSYNC, and want to minimize any disruption to this stream. 

  3. Any recommendation on automating HADR+(uni-direction)QRepl failover operation? 
    Just wondering if anyone could share some suggestions (existing solutions would be even better!), especially when shared storage is not available. Right now we are following this link, and i can think of the high level steps include:
  • 3.1 Automated db failover/role-switch;
  • 3.2 (Re-)populate transmissionQ / receiveQ / adminQ on new Primary, depends on if it's source or target side failover/role-switch; 
  • 3.3 [optinoal] Copy any archived logs to new Primary, if QCapture needs any;
  • 3.4 Start QCapture/QApply program.

    Notice step 3.2 and 3.3 could be parallelized.

Btw, we use V10.5FP8 on linux.

Really appreciate your help.

Edited By:
Rui Chen[Organization Members] @ Oct 18, 2017 - 02:57 PM (America/Eastern)
Rui Chen[Organization Members] @ Oct 18, 2017 - 03:05 PM (America/Eastern)