Merge pull request #734 from Icinga/i707-release-v1.1.2

Release Version 1.2.0
Icinga · Apr 11, 2024 · a0a65af · a0a65af
2 parents c76788a + f0b7aa2
commit a0a65af
Show file tree

Hide file tree

Showing 9 changed files with 44 additions and 8 deletions.
diff --git a/.mailmap b/.mailmap
@@ -3,5 +3,6 @@ Diana Flach <[email protected]> <[email protected]>
 Diana Flach <[email protected]> <[email protected]>
 Diana Flach <[email protected]> <[email protected]>
 Henrik Triem <[email protected]> <[email protected]>
+Julian Brost <[email protected]> <[email protected]>
 <[email protected]> <[email protected]>
 <[email protected]> <[email protected]>
diff --git a/AUTHORS b/AUTHORS
@@ -1,4 +1,5 @@
 Alexander A. Klimov <[email protected]>
+Alvar Penning <[email protected]>
 Eric Lippmann <[email protected]>
 Feu Mourek <[email protected]>
 Henrik Triem <[email protected]>

diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -1,5 +1,39 @@
 # Icinga DB Changelog
 
+## 1.2.0 (2024-04-11)
+
+This release addresses multiple issues related to fault recoveries,
+with a particular focus on retryable database errors that may occur when using Icinga DB with database clusters.
+
+Since there may be a large number of errors that are resolved by retrying after a certain amount of time,
+#698 changed the retry behavior to retry every database-related error for five minutes.
+This helps Icinga DB survive network hiccups or more complicated database situations,
+such as working with a database cluster.
+
+The latter was specifically addressed in #711 for Galera Clusters on MySQL or MariaDB by configuring `wsrep_sync_wait` on used database sessions.
+Galera users should refer to the [Configuration documentation](doc/03-Configuration.md#database-options) for more details.
+
+In summary, the most notable changes are as follows:
+
+* Custom Variables: Render large numbers as-is, not using scientific notation. #657
+* Enhance retries for database errors and other failures for up to five minutes. #693, #698, #739, #740
+* MySQL/MariaDB: Use strict SQL mode. #699
+* MySQL/MariaDB Galera Cluster: Set `wsrep_sync_wait` for cluster-wide causality checks. #711
+* Don't crash history sync in the absence of Redis®[\*](doc/TRADEMARKS.md#redis). #725
+* Update dependencies. [27 times](https://github.com/Icinga/icingadb/pulls?q=is%3Apr+is%3Amerged+label%3Adependencies+milestone%3A1.2.0)
+
+### Schema
+
+In addition to mandatory schema upgrades, this release includes an optional upgrade that can be applied subsequently.
+Details are available in the [Upgrading documentation](doc/04-Upgrading.md#upgrading-to-icinga-db-v120) and #656.
+
+All schema changes are listed below:
+
+* Allow host and service check attempts >= 256. #656
+* Composite `INDEX` for the history table to speed up history view in Icinga DB Web. #686
+* MySQL/MariaDB: Fix `icingadb_schema.timestamp` not being Unix time. #700
+* PostgreSQL: Change `get_sla_ok_percent` to return decimal numbers in SLA overview. #710
+
 ## 1.1.1 (2023-08-09)
 
 This release fixes a few crashes in the Icinga DB daemon, addresses some shortcomings in the database schema,

diff --git a/doc/04-Upgrading.md b/doc/04-Upgrading.md
@@ -3,9 +3,9 @@
 Specific version upgrades are described below. Please note that version upgrades are incremental.
 If you are upgrading across multiple versions, make sure to follow the steps for each of them.
 
-## Upgrading to Icinga DB v1.1.2
+## Upgrading to Icinga DB v1.2.0
 
-Please apply the `1.1.2.sql` upgrade script to your database. For package installations, you can find this file at
+Please apply the `1.2.0.sql` upgrade script to your database. For package installations, you can find this file at
 `/usr/share/icingadb/schema/mysql/upgrades/` or `/usr/share/icingadb/schema/pgsql/upgrades/`, depending on your
 database vendor.
 
@@ -24,23 +24,23 @@ restart the daemon when upgrading the package.
 ### Upgrading the state_history Table
 
 This release includes fixes for hosts and services reaching check attempt 256. However, on existing installations,
-the schema upgrade required to fix the history tables isn't automatically applied by `1.1.2.sql` as a rewrite of the
+the schema upgrade required to fix the history tables isn't automatically applied by `1.2.0.sql` as a rewrite of the
 whole `state_history` table is required. This can take a lot of time depending on the history size and the performance
 of the database. During this time that table will be locked exclusively and can't be accessed otherwise. This means that
 the existing history can't be viewed in Icinga Web and new history entries will be buffered in Redis®.
 
-There is a separate upgrade script `optional/1.1.2-history.sql` to perform the rewrite of the `state_history` table.
+There is a separate upgrade script `optional/1.2.0-history.sql` to perform the rewrite of the `state_history` table.
 This allows you to postpone part of the upgrade to a longer maintenance window in the future, or skip it entirely
 if you deem this safe for your installation.
 
 !!! warning
 
-    Until `optional/1.1.2-history.sql` is applied, you'll have to lower `max_check_attempts` to 255 or less, otherwise
+    Until `optional/1.2.0-history.sql` is applied, you'll have to lower `max_check_attempts` to 255 or less, otherwise
     Icinga DB will crash with a database error if hosts/services reach check attempt 256. If you need to lower
     `max_check_attempts` but want to keep the same timespan from an outage to a hard state, you can raise
     `retry_interval` instead so that `max_check_attempts * retry_interval` stays the same.
 
-If you apply it, be sure that `1.1.2.sql` was already applied before. Do not interrupt it! At best use tmux/screen not
+If you apply it, be sure that `1.2.0.sql` was already applied before. Do not interrupt it! At best use tmux/screen not
 to lose your SSH session.
 
 ### Unblock History Tables
@@ -87,7 +87,7 @@ You can now either just wait for the `SELECT` statements to finish by themselves
 and all Icinga DB queries on all `*_history` tables or forcibly terminate them and let the remaining queries do their
 work. In this case, cancelling that one blocking `SELECT` query will let the upgrade script continue normally without
 blocking any other queries.
-``` 
+```
 MariaDB [icingadb]> kill 1485;
 ```
 In case you are insecure about which Icinga DB Web queries are blocking, you may simply cancel all long-running

diff --git a/internal/version.go b/internal/version.go
@@ -7,4 +7,4 @@ import (
 // Version contains version and Git commit information.
 //
 // The placeholders are replaced on `git archive` using the `export-subst` attribute.
-var Version = version.Version("1.1.1", "$Format:%(describe)$", "$Format:%H$")
+var Version = version.Version("1.2.0", "$Format:%(describe)$", "$Format:%H$")
diff --git a/schema/mysql/upgrades/1.1.2.sql → schema/mysql/upgrades/1.2.0.sql b/schema/mysql/upgrades/1.1.2.sql → schema/mysql/upgrades/1.2.0.sql
diff --git a/...mysql/upgrades/optional/1.1.2-history.sql → ...mysql/upgrades/optional/1.2.0-history.sql b/...mysql/upgrades/optional/1.1.2-history.sql → ...mysql/upgrades/optional/1.2.0-history.sql
diff --git a/schema/pgsql/upgrades/1.1.2.sql → schema/pgsql/upgrades/1.2.0.sql b/schema/pgsql/upgrades/1.1.2.sql → schema/pgsql/upgrades/1.2.0.sql
diff --git a/...pgsql/upgrades/optional/1.1.2-history.sql → ...pgsql/upgrades/optional/1.2-0-history.sql b/...pgsql/upgrades/optional/1.1.2-history.sql → ...pgsql/upgrades/optional/1.2-0-history.sql