I discovered some Problems with my HA-Setup and therefore want to reconfigure my “slave-master” server (I am running this setup from the docs)
Currently the icinga2 service on the second master fails to start because (that’s my assumption) the replication of the configuration Items didn’t work because of the misconfiguration 
What should I do in order to NOT redeploy the whole server?
I’d say paste the output of icinga2 daemon -C if you can, but typically do this, ONLY on the secondary master:
rm -rf /var/lib/icinga2/api/
After you restart it, your main master will push the api config over to it again. Also check the zones.conf file on each server and make sure they both have each other’s IP address but not their own. Also, enable_ha = true in your ido config or the secondary wont take over database insertions when the primary goes down.
Please share the exact output of the config validation icinga2 daemon -C, or the startup logs.
Cheers,
Michael
Thanks Guys, there was a typo in the zones-endpoint configuration that existed quite a long time and nobody noticed 
I corrected my zones.conf and took @blakehartshorn 's approach (because I chew bees instead of eating honey… 
) with removing everything below
/var/lib/icinga2/api/
That worked like a charm 
It’s always a good morning when I tell someone to rm -rf something as root and I don’t get kicked off the forum.
Well, if you’re doing that inside a script, I will kick you.
Background: A customer was reporting that the HA functionality didn’t work, the secondary master would always receive new config and reload. Turns out, they had a cron which rm’ed that directory on a minute basis. That’s not how you spend support troubleshooting hours.
I mean… I just … can’t … wow.
Well, just to be clear: There was a problem with unpurged zone files, a problem within Icinga and a gentle workaround. Still, the script lacked sanity checks and purged the entire directory tree instead of partially nuking the affected ones.