OS Patching on Multistandby HADR & TSA-- Please correct me if I am wrong.

Laxman Majji

OS Patching on Multistandby HADR & TSA-- Please correct me if I am wrong.

Hi All

Greetings!!!

We have OS Patching activity on our servers. In our environment we had one primary and three standby's. Activity was planned as below:

In each server we had 4 instances. Please suggest me on this.

Auxialary2--- Day1

Aux1---------- Day2

Principle standby---------- Day3

Primary---------------------- Day4

My plan on this activity:

Day1--- Aux2

1.Deactivate DB

2.db2stop

3.Handover the server to OS team for patching

4.db2start

5.activate db

Day2--- Aux1 (Same as Day1)

Day3--- Standby

1. Disable TSAMP (db2haicu -disable) 2. Deactivate DB 3.db2stop 4.stoprpnode -f <standby node> 5.OS Patching 6.startrpnode <standby node> 6.db2start 7.activate db 8. Enable TSAMP

Day4---- Primary

1. Take online backup in primary 2. Disable TSAMP 3. Takeover DB in standby (DB must be in Peer state) 4. Inform Apps team to connect on standby(New Primary) 5. Deactivate DB on primary(New standby) 6.db2stop 7.stoprpnode -f <standby node> 8.OS Patching 9.startrpnode <standby node> 8. db2start 9. activate db 10.Takeover DB in standby (DB must be in Peer state) 11. Inform Apps team to connect on primary back 12. Enable TSAMP.

Nadir Doctor

OS Patching on Multistandby HADR & TSA-- Please correct me if I am wrong.
(in response to Laxman Majji)
Hi Laxman,

I believe you have a similar cluster in a non-production environment for os
patching - instead of spreading this activity for more than a 0.5 week, it
can all be done on same day in case feasible.

Assuming that the automatic client reroute feature has been setup and
validated fine, then this should be transparent to the applications when
failover done.


Best Regards,
Nadir


On Thu, Sep 21, 2017 at 9:35 AM, Laxman Majji <[login to unmask email]> wrote:

> Hi All
>
> Greetings!!!
>
> We have OS Patching activity on our servers. In our environment we had one
> primary and three standby's. Activity was planned as below:
>
> In each server we had 4 instances. Please suggest me on this.
>
> Auxialary2--- Day1
>
> Aux1---------- Day2
>
> Principle standby---------- Day3
>
> Primary---------------------- Day4
>
> My plan on this activity:
>
> Day1--- Aux2
>
> 1.Deactivate DB
>
> 2.db2stop
>
> 3.Handover the server to OS team for patching
>
> 4.db2start
>
> 5.activate db
>
> Day2--- Aux1 (Same as Day1)
>
> Day3--- Standby
>
> 1. Disable TSAMP (db2haicu -disable) 2. Deactivate DB 3.db2stop
> 4.stoprpnode -f 5.OS Patching 6.startrpnode 6.db2start 7.activate db 8.
> Enable TSAMP
>
> Day4---- Primary
>
> 1. Take online backup in primary 2. Disable TSAMP 3. Takeover DB in
> standby (DB must be in Peer state) 4. Inform Apps team to connect on
> standby(New Primary) 5. Deactivate DB on primary(New standby) 6.db2stop
> 7.stoprpnode -f 8.OS Patching 9.startrpnode 8. db2start 9. activate db
> 10.Takeover DB in standby (DB must be in Peer state) 11. Inform Apps team
> to connect on primary back 12. Enable TSAMP.
>
> -----End Original Message-----
>

Laxman Majji

OS Patching on Multistandby HADR & TSA-- Please correct me if I am wrong.
(in response to Nadir Doctor)
Hi Nadir

Greetings!!!

Thanks for your response. Every server has 4 instances.There is no
non-production environment.ACR is not configured.

Regards
Laxman

On Thu, Sep 21, 2017 at 11:36 AM, Nadir Doctor <[login to unmask email]> wrote:

> Hi Laxman,
>
> I believe you have a similar cluster in a non-production environment for
> os patching - instead of spreading this activity for more than a 0.5 week,
> it can all be done on same day in case feasible.
>
> Assuming that the automatic client reroute feature has been setup and
> validated fine, then this should be transparent to the applications when
> failover done.
>
>
> Best Regards,
> Nadir
>
>
> On Thu, Sep 21, 2017 at 9:35 AM, Laxman Majji <[login to unmask email]>
> wrote:
>
>> Hi All
>>
>> Greetings!!!
>>
>> We have OS Patching activity on our servers. In our environment we had
>> one primary and three standby's. Activity was planned as below:
>>
>> In each server we had 4 instances. Please suggest me on this.
>>
>> Auxialary2--- Day1
>>
>> Aux1---------- Day2
>>
>> Principle standby---------- Day3
>>
>> Primary---------------------- Day4
>>
>> My plan on this activity:
>>
>> Day1--- Aux2
>>
>> 1.Deactivate DB
>>
>> 2.db2stop
>>
>> 3.Handover the server to OS team for patching
>>
>> 4.db2start
>>
>> 5.activate db
>>
>> Day2--- Aux1 (Same as Day1)
>>
>> Day3--- Standby
>>
>> 1. Disable TSAMP (db2haicu -disable) 2. Deactivate DB 3.db2stop
>> 4.stoprpnode -f 5.OS Patching 6.startrpnode 6.db2start 7.activate db 8.
>> Enable TSAMP
>>
>> Day4---- Primary
>>
>> 1. Take online backup in primary 2. Disable TSAMP 3. Takeover DB in
>> standby (DB must be in Peer state) 4. Inform Apps team to connect on
>> standby(New Primary) 5. Deactivate DB on primary(New standby) 6.db2stop
>> 7.stoprpnode -f 8.OS Patching 9.startrpnode 8. db2start 9. activate db
>> 10.Takeover DB in standby (DB must be in Peer state) 11. Inform Apps team
>> to connect on primary back 12. Enable TSAMP.
>>
>> -----End Original Message-----
>

Nadir Doctor

OS Patching on Multistandby HADR & TSA-- Please correct me if I am wrong.
(in response to Laxman Majji)
Hi Laxman,

You may want to consider the automatic client reroute feature as it is easy
to implement - this will aid in minimizing application downtime further.


Best Regards,
Nadir


On Thu, Sep 21, 2017 at 10:48 AM, Laxman Majji <[login to unmask email]> wrote:

> Hi Nadir
>
> Greetings!!!
>
> Thanks for your response. Every server has 4 instances.There is no
> non-production environment.ACR is not configured.
>
> Regards
> Laxman
>
> On Thu, Sep 21, 2017 at 11:36 AM, Nadir Doctor <[login to unmask email]>
> wrote:
>
>> Hi Laxman,
>>
>> I believe you have a similar cluster in a non-production environment for
>> os patching - instead of spreading this activity for more than a 0.5 week,
>> it can all be done on same day in case feasible.
>>
>> Assuming that the automatic client reroute feature has been setup and
>> validated fine, then this should be transparent to the applications when
>> failover done.
>>
>>
>> Best Regards,
>> Nadir
>>
>>
>> On Thu, Sep 21, 2017 at 9:35 AM, Laxman Majji <[login to unmask email]>
>> wrote:
>>
>>> Hi All
>>>
>>> Greetings!!!
>>>
>>> We have OS Patching activity on our servers. In our environment we had
>>> one primary and three standby's. Activity was planned as below:
>>>
>>> In each server we had 4 instances. Please suggest me on this.
>>>
>>> Auxialary2--- Day1
>>>
>>> Aux1---------- Day2
>>>
>>> Principle standby---------- Day3
>>>
>>> Primary---------------------- Day4
>>>
>>> My plan on this activity:
>>>
>>> Day1--- Aux2
>>>
>>> 1.Deactivate DB
>>>
>>> 2.db2stop
>>>
>>> 3.Handover the server to OS team for patching
>>>
>>> 4.db2start
>>>
>>> 5.activate db
>>>
>>> Day2--- Aux1 (Same as Day1)
>>>
>>> Day3--- Standby
>>>
>>> 1. Disable TSAMP (db2haicu -disable) 2. Deactivate DB 3.db2stop
>>> 4.stoprpnode -f 5.OS Patching 6.startrpnode 6.db2start 7.activate db 8.
>>> Enable TSAMP
>>>
>>> Day4---- Primary
>>>
>>> 1. Take online backup in primary 2. Disable TSAMP 3. Takeover DB in
>>> standby (DB must be in Peer state) 4. Inform Apps team to connect on
>>> standby(New Primary) 5. Deactivate DB on primary(New standby) 6.db2stop
>>> 7.stoprpnode -f 8.OS Patching 9.startrpnode 8. db2start 9. activate db
>>> 10.Takeover DB in standby (DB must be in Peer state) 11. Inform Apps team
>>> to connect on primary back 12. Enable TSAMP.
>>>
>>> -----End Original Message-----
>

Laxman Majji

OS Patching on Multistandby HADR & TSA-- Please correct me if I am wrong.
(in response to Nadir Doctor)
Hi Nadir

Sure,Please suggest me steps I have to implement for this activity. We have
to provide servers to OS team for patching. They will perform patching on
Standby server on day1 and primary server on day 2. We had TSA configured.
Please help me with your suggestions. (If we need downtime please mention
where we need downtime).

Thank you.

Regards
Laxman

On Thu, Sep 21, 2017 at 2:42 PM, Nadir Doctor <[login to unmask email]> wrote:

> Hi Laxman,
>
> You may want to consider the automatic client reroute feature as it is
> easy to implement - this will aid in minimizing application downtime
> further.
>
>
> Best Regards,
> Nadir
>
>
> On Thu, Sep 21, 2017 at 10:48 AM, Laxman Majji <[login to unmask email]>
> wrote:
>
>> Hi Nadir
>>
>> Greetings!!!
>>
>> Thanks for your response. Every server has 4 instances.There is no
>> non-production environment.ACR is not configured.
>>
>> Regards
>> Laxman
>>
>> On Thu, Sep 21, 2017 at 11:36 AM, Nadir Doctor <[login to unmask email]>
>> wrote:
>>
>>> Hi Laxman,
>>>
>>> I believe you have a similar cluster in a non-production environment for
>>> os patching - instead of spreading this activity for more than a 0.5 week,
>>> it can all be done on same day in case feasible.
>>>
>>> Assuming that the automatic client reroute feature has been setup and
>>> validated fine, then this should be transparent to the applications when
>>> failover done.
>>>
>>>
>>> Best Regards,
>>> Nadir
>>>
>>>
>>> On Thu, Sep 21, 2017 at 9:35 AM, Laxman Majji <[login to unmask email]>
>>> wrote:
>>>
>>>> Hi All
>>>>
>>>> Greetings!!!
>>>>
>>>> We have OS Patching activity on our servers. In our environment we had
>>>> one primary and three standby's. Activity was planned as below:
>>>>
>>>> In each server we had 4 instances. Please suggest me on this.
>>>>
>>>> Auxialary2--- Day1
>>>>
>>>> Aux1---------- Day2
>>>>
>>>> Principle standby---------- Day3
>>>>
>>>> Primary---------------------- Day4
>>>>
>>>> My plan on this activity:
>>>>
>>>> Day1--- Aux2
>>>>
>>>> 1.Deactivate DB
>>>>
>>>> 2.db2stop
>>>>
>>>> 3.Handover the server to OS team for patching
>>>>
>>>> 4.db2start
>>>>
>>>> 5.activate db
>>>>
>>>> Day2--- Aux1 (Same as Day1)
>>>>
>>>> Day3--- Standby
>>>>
>>>> 1. Disable TSAMP (db2haicu -disable) 2. Deactivate DB 3.db2stop
>>>> 4.stoprpnode -f 5.OS Patching 6.startrpnode 6.db2start 7.activate db
>>>> 8. Enable TSAMP
>>>>
>>>> Day4---- Primary
>>>>
>>>> 1. Take online backup in primary 2. Disable TSAMP 3. Takeover DB in
>>>> standby (DB must be in Peer state) 4. Inform Apps team to connect on
>>>> standby(New Primary) 5. Deactivate DB on primary(New standby) 6.db2stop
>>>> 7.stoprpnode -f 8.OS Patching 9.startrpnode 8. db2start 9. activate db
>>>> 10.Takeover DB in standby (DB must be in Peer state) 11. Inform Apps team
>>>> to connect on primary back 12. Enable TSAMP.
>>>>
>>>> -----End Original Message-----
>

Nadir Doctor

OS Patching on Multistandby HADR & TSA-- Please correct me if I am wrong.
(in response to Laxman Majji)
Hi Laxman,

Here's a webpage for the 10.5 release -

https://www.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.admin.ha.doc/doc/c0011558.html
--an instance restart will assist in taking effect for all connections -
existing + new


Best Regards,
Nadir



On Fri, Sep 22, 2017 at 5:32 AM, Laxman Majji <[login to unmask email]> wrote:

> Hi Nadir
>
> Sure,Please suggest me steps I have to implement for this activity. We
> have to provide servers to OS team for patching. They will perform patching
> on Standby server on day1 and primary server on day 2. We had TSA
> configured. Please help me with your suggestions. (If we need downtime
> please mention where we need downtime).
>
> Thank you.
>
> Regards
> Laxman
>
> On Thu, Sep 21, 2017 at 2:42 PM, Nadir Doctor <[login to unmask email]>
> wrote:
>
>> Hi Laxman,
>>
>> You may want to consider the automatic client reroute feature as it is
>> easy to implement - this will aid in minimizing application downtime
>> further.
>>
>>
>> Best Regards,
>> Nadir
>>
>>
>> On Thu, Sep 21, 2017 at 10:48 AM, Laxman Majji <[login to unmask email]>
>> wrote:
>>
>>> Hi Nadir
>>>
>>> Greetings!!!
>>>
>>> Thanks for your response. Every server has 4 instances.There is no
>>> non-production environment.ACR is not configured.
>>>
>>> Regards
>>> Laxman
>>>
>>> On Thu, Sep 21, 2017 at 11:36 AM, Nadir Doctor <[login to unmask email]>
>>> wrote:
>>>
>>>> Hi Laxman,
>>>>
>>>> I believe you have a similar cluster in a non-production environment
>>>> for os patching - instead of spreading this activity for more than a 0.5
>>>> week, it can all be done on same day in case feasible.
>>>>
>>>> Assuming that the automatic client reroute feature has been setup and
>>>> validated fine, then this should be transparent to the applications when
>>>> failover done.
>>>>
>>>>
>>>> Best Regards,
>>>> Nadir
>>>>
>>>>
>>>> On Thu, Sep 21, 2017 at 9:35 AM, Laxman Majji <[login to unmask email]>
>>>> wrote:
>>>>
>>>>> Hi All
>>>>>
>>>>> Greetings!!!
>>>>>
>>>>> We have OS Patching activity on our servers. In our environment we had
>>>>> one primary and three standby's. Activity was planned as below:
>>>>>
>>>>> In each server we had 4 instances. Please suggest me on this.
>>>>>
>>>>> Auxialary2--- Day1
>>>>>
>>>>> Aux1---------- Day2
>>>>>
>>>>> Principle standby---------- Day3
>>>>>
>>>>> Primary---------------------- Day4
>>>>>
>>>>> My plan on this activity:
>>>>>
>>>>> Day1--- Aux2
>>>>>
>>>>> 1.Deactivate DB
>>>>>
>>>>> 2.db2stop
>>>>>
>>>>> 3.Handover the server to OS team for patching
>>>>>
>>>>> 4.db2start
>>>>>
>>>>> 5.activate db
>>>>>
>>>>> Day2--- Aux1 (Same as Day1)
>>>>>
>>>>> Day3--- Standby
>>>>>
>>>>> 1. Disable TSAMP (db2haicu -disable) 2. Deactivate DB 3.db2stop
>>>>> 4.stoprpnode -f 5.OS Patching 6.startrpnode 6.db2start 7.activate db
>>>>> 8. Enable TSAMP
>>>>>
>>>>> Day4---- Primary
>>>>>
>>>>> 1. Take online backup in primary 2. Disable TSAMP 3. Takeover DB in
>>>>> standby (DB must be in Peer state) 4. Inform Apps team to connect on
>>>>> standby(New Primary) 5. Deactivate DB on primary(New standby) 6.db2stop
>>>>> 7.stoprpnode -f 8.OS Patching 9.startrpnode 8. db2start 9. activate
>>>>> db 10.Takeover DB in standby (DB must be in Peer state) 11. Inform Apps
>>>>> team to connect on primary back 12. Enable TSAMP.
>>>>>
>>>>> -----End Original Message-----
>