IcingaDB Health IcingaHealth

[apenning (Alvar)]

@ShowMeYourSkil

I am currently checking the database files as the schema has definitely been updated.

Why do you suspect that the scheme upgrade was not correctly performed?

@ShowMeYourSkil

MariaDB [icingadb]> SELECT * FROM icingadb_schema;
+----+---------+---------------+
| id | version | timestamp     |
+----+---------+---------------+
|  1 |       3 | 1672298914000 |
|  2 |       4 | 1694762696000 |
|  3 |       5 | 1713527524000 |
|  4 |       7 | 1744916671000 |
|  5 |       6 | 1745304889000 |
|  6 |       6 | 1753104098000 |
+----+---------+---------------+
6 rows in set (0.002 sec)

Looking at your icingadb_schema table, you have first updated from MySQL schema version 5 to 7 (Icinga DB version 1.2.0 and 1.4.0, respectively) and have skipped schema version 6 (Icinga DB 1.2.1). Then, you have applied schema version 6 twice. However, there are some time gaps between updates:

3. schema version 5 on Fri Apr 19 11:52:04 AM UTC 2024
4. schema version 7 on Thu Apr 17 07:04:31 PM UTC 2025
5. schema version 6 on Tue Apr 22 06:54:49 AM UTC 2025
6. schema version 6 on Mon Jul 21 01:21:38 PM UTC 2025

Since the current Icinga DB check logic is quite simple, it selects the schema version with the greatest id, which would be 6 in your case. You can try to quick fix this by updating the version value of the column where id is 6.

Afterwards, please try to restart Icinga DB and check if it logs any errors. If not, you are lucky. Otherwise, either try to address them accordingly or just import your latest backup.

In general, upgrading is an iterative approach where one upgrade needs to be performed after the other, as described at the beginning of our upgrading documentation.

For future updates, please take a look at the changelog or latest release information. If manual intervention becomes necessary, it is stated there.