Haha, thank you sir.
A little update:
I continued to play with the icinga2 database and i did what i guess many developers do not like to see. There were two default instances in icinga_instances table (one of them with instance_id equal to 2), and few “duplicit/implicit” services in icinga_services with instance_id too equal to 2. They all had also object_id equal to 446. And there was only one object in icinga_objects with this id. It was duplicite and it also had instance_id = 2.
To my surprise there are almost non foreign constraints defined for tables in icinga2 database, and exactly zero of them for the instance_id fields on all tables I mentioned above.
So after stopping the icinga deamon and backing up the database i just deleted all these rows without fear of fucking up the database due to the cascade.
After all of that icinga started successfully and i have one less server in my Linux Servers group and one less error for service i cant see. So far its working great, but dont try this at home kids, this is not a production server. Atleast not yet.
hahahaha yeah. when I was building mine, I was gleefully nuking it as well. I wrote an event handler to fail over to the postgres logical subscription node so Icinga can fix its own database. It took me a few disasters before I realized that maybe this is what Docker is for.