# In-service Upgrade and HA

**URL:** <https://dmap-community.ductus.global/t/in-service-upgrade-and-ha/169>\
**Category:** Core Engine and APIs\
**Created:** [August 9, 2015, 1:51pm UTC](https://dmap-community.ductus.global/t/in-service-upgrade-and-ha/169 "2015-08-09T13:51:48Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![jjohansson](https://avatars.discourse-cdn.com/v4/letter/j/b782af/32.png) [@jjohansson](https://dmap-community.ductus.global/u/jjohansson)\
**Post date:** [August 9, 2015, 1:51pm UTC](https://dmap-community.ductus.global/t/in-service-upgrade-and-ha/169/1 "2015-08-09T13:51:49Z")

</div>

When we use the ConfD High Availability functionality, it is critical that all nodes in the HA cluster agree on the data model used. For this reason we can not do in-service upgrade on a ConfD instance that is part of a HA cluster. If ConfD is a HA slave, or a HA master with connected slaves, maapi\_init\_upgrade() will fail with confd\_errno CONFD\_ERR\_HA\_WITH\_UPGRADE. Conversely, when an in-service up-grade is in progress, calling confd\_ha\_beslave() will also result in this error, and connections from slaves will be rejected.

To do the in-service upgrade on a HA cluster, we must thus use “rolling upgrade”:

1. Disconnect one of the slaves from the cluster by calling confd\_ha\_benone().
2. Upgrade the disconnected slave as described above.
3. Tell the upgraded slave to become master by calling confd\_ha\_bemaster().
4. Upgrade the remaining nodes in the cluster one by one, telling each to connect as slave to the upgraded master by calling confd\_ha\_beslave() when the upgrade is done.  
  
  
Alternatively, since the HA configuration should be able to handle that a node is stopped and restarted without service interruption, we may simply use the upgrade method described in the CDB chapter in the ConfD User Guide for the “rolling upgrade”.