HDR in IDS 10.0xc5: slow Secondary restart

Hi, everybody, Long-awaited IDS 10.0xC5 (with a great FASTPOLL feature) is finally released... and appeared to be almost unusable for large installations, using HDR Really, really bad 'feature' was added to HDR mechanism. Every time, HDR Secondary is restarted (that is, stopped and started again), IDS completely re-writes all logical logs on Secondary. All logical logs become market with F------ flag, and all logical log pages become re-initialized with page number in a page header and zeroes inside, like: stage10@dw-1g:~$ hexdump -s 108544 -n 2048 /dev/lds1 001a800 0000 0000 0000 0000 0000 0000 0000 0000 * 001b000 Do I need to say, how slow it is? On my staging machine (older copy of production, used for QA), I have 140 GB of logical logs. The staging array (not very fast) is able to write at 50 MB/sec, but IDS (may be, because of small 1-MB block size, used for data writing with pwrite() ) only writes at 20 MB/sec. That is, it takes about two hours to simply restart Secondary... I had plan to double the total logical log volume.. With 10.0fc4, it takes me just two minutes to restart Secondary and have the HDR replication re-synchronized. >From 2 minutes to two hours... Not a good upgrade path (FC4->FC5) I plan to file this problem to IBM asap -Alexey Sonkin

Alexey Sonkin wrote: > Hi, everybody, > > Long-awaited IDS 10.0xC5 (with a great FASTPOLL feature) is finally released... and appeared to be almost unusable for large installations, using HDR > > Really, really bad 'feature' was added to HDR mechanism. > > Every time, HDR Secondary is restarted (that is, stopped and started again), > IDS completely re-writes all logical logs on Secondary. > All logical logs become market with F------ flag, and all logical log pages become re-initialized with page number in a page header and zeroes inside, like: > Alexey, We've always had code in place to zap the logs when we needed to. We have to do this to prevent us from trying to apply the logs which we need to ignore and recapture from the primary. We recently put in some modifications to address some places where we were clearing the logs needlessly. I suspect that the case that you're running into. Please open a case on the problem. We'll address it as quickly as possible. > stage10@dw-1g:~$ hexdump -s 108544 -n 2048 /dev/lds1 > 001a800 0000 0000 0000 0000 0000 0000 0000 0000 > * > 001b000 > > Do I need to say, how slow it is? > On my staging machine (older copy of production, used for QA), > I have 140 GB of logical logs. > The staging array (not very fast) is able to write at 50 MB/sec, > but IDS (may be, because of small 1-MB block size, > used for data writing with pwrite() ) only writes at 20 MB/sec. > > That is, it takes about two hours to simply restart Secondary... > I had plan to double the total logical log volume.. > With 10.0fc4, it takes me just two minutes to restart Secondary > and have the HDR replication re-synchronized. > >>From 2 minutes to two hours... Not a good upgrade path (FC4->FC5) > > I plan to file this problem to IBM asap > > > -Alexey Sonkin > >