MarkLogic: why does deleting an appserver cause a cluster to restart?

Question

Why does deleting an appserver cause a cluster to restart? Are there scripting options where multiple appservers could be deleted and not trigger multiple restarts? E.g., can I: open a transaction, get the config, run multiple admin:appserver-delete() calls, save the new configuration, then commit the transaction and only trigger one restart?

MarkLogic= 8.0-3.2 & 8.0-4.2 , Linux= RedHat

Answer 1

The restart is most importantly necessary to disconnect the HTTP port listener that listens on the port of that particular app-server. The config for that app-server (like all configuration details) are shared within the entire cluster, and all hosts assigned to the group in which the app-server is defined, have listeners on that same port. Deleting an app-server therefore requires a restart of at least all hosts in the same group. Doing a cluster-wide restart is just as quick though.

Yes, it is possible to have one xquery statement that, for instance, deletes multiple app-servers at once, re-assign hosts to a different group, maybe also delete the original group they belonged to, and finish off with just one restart. The admin functions allow you to make multiple updates to the admin config, and end with just a single admin:save-configuration to persist your changes.

Small example:

let $config := admin:get-configuration()
let $config := admin:appserver-delete($config,
  admin:appserver-get-id($config, xdmp:group(), "app-serv1")
)
let $config := admin:appserver-delete($config,
  admin:appserver-get-id($config, xdmp:group(), "app-serv2")
)
let $config := admin:appserver-delete($config,
  admin:appserver-get-id($config, xdmp:group(), "app-serv3")
)
return admin:save-configuration($config)

Actually, the admin:appserver-delete takes a sequence of appserver ids, so you could compress the code in this case. You could however combine all kinds of admin function calls in the same way like this. Just keep an eye out in which order you execute them, that could be relevant. Create a database, before applying settings, unlink artifacts, before deleting them, etc..

HTH!