After HADR takeover new HADR primary should be able to request archive logs from old HADR primary on behalf of HADR auxiliary (s) that require archive logs from old primary in order to rollforward.

After HADR takeover new HADR primary should be able to request archive logs from old HADR primary on behalf of HADR auxiliary (s) that require archive logs from old primary in order to rollforward.

We have 3 node HADR

1. Site1a Primary
2. Site1b Standby
3. Site2 auxiliary Standby

In a planned switch where Site1a was going down for maintenance:

1. a) Site1b took over from Site1a and became the new primary with no issue.
2. b) Site1a switched to standby without issue, it's autonomous and smooth.
3. c) Site2 lost connection to Site1a, then tried to connect to Site1b. Its current log position at that time was behind Site1a and Site1b. Site2 required logs from Site1a that were only in Site1a's archive log path. Once they were archived on Site1a, Site1b deleted them. This is working as designed/documented. Site2 could not continue to rollforward. We manually copied the logs from Site1a to overcome the situation.

IBM recommends to use shared archive design to avoid this kind of issue (https://www.ibm.com/support/knowledgecenter/SSEPGG_11.1.0/com.ibm.db2.luw.admin.ha.doc/doc/c0020882.html ftp://ftp.software.ibm.com/software/data/db2/chatsgcg/ms.white.paper.3.5-1.pdf) but we cannot deploy this currently.

We will update our procedures to cater for the situation where one of the standbys is behind and we need to do a takeover. I.E. manually copy the missing logs from the old primary. However, it's a shame that a planned takeover triggers this issue. It should be possible for the new primary to ask for the missing logs from the old primary when the 2nd standby asks for them. 

Refer case TS002622552 Db2 V11.1.3.3 FP3b HADR on 2nd Standby fails after 1st Standby does takeover