Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release Version 1.2.0 #734

Merged
merged 2 commits into from
Apr 11, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .mailmap
Original file line number Diff line number Diff line change
Expand Up @@ -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]>
1 change: 1 addition & 0 deletions AUTHORS
Original file line number Diff line number Diff line change
@@ -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]>
Expand Down
34 changes: 34 additions & 0 deletions CHANGELOG.md
julianbrost marked this conversation as resolved.
Show resolved Hide resolved
Original file line number Diff line number Diff line change
@@ -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,
Expand Down
14 changes: 7 additions & 7 deletions doc/04-Upgrading.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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
Expand Down Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion internal/version.go
Original file line number Diff line number Diff line change
Expand Up @@ -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$")
File renamed without changes.
File renamed without changes.
Loading