# 10 Upgrade notes for 3.2.0 These notes are for upgrading from Zabbix 3.0.x to Zabbix 3.2.0. All notes are grouped into: - `Critical` - the most critical information related to the upgrade process and the changes in Zabbix functionality - `Informational` - all remaining information describing the changes in Zabbix functionality It is possible to upgrade to Zabbix 3.2.0 from versions before Zabbix 3.0.0. See the [upgrade procedure](/manual/installation/upgrade) section for all relevant information about upgrading from previous Zabbix versions. ### Critical #### Database upgrade The history\_text.id and history\_log.id fields will be removed from the corresponding history tables during database upgrade. Depending on the history table size this process can be slow. #### Case-sensitive MySQL database A case-sensitive MySQL database is required for proper server work. It is [recommended](/manual/appendix/install/db_scripts#mysql) to create a case-sensitive MySQL database during new installations. If you created a MySQL database with the utf8 character set previously, in order to support case sensitiveness of stored data, you need to convert the charset to utf8\_bin. ### Informational #### Escalation changes ##### Delaying escalations during maintenance The logic of delaying problem notifications during host maintenance [has been changed](/manual/introduction/whatsnew320#delaying_escalations_during_maintenance). In previous Zabbix versions, problem notifications during a host maintenance period were skipped if you were using the *Maintenance status = not in "maintenance"* action condition. In the new version, the old mechanism is dropped. Instead there is a new *Pause operations while in maintenance* option in action configuration, which allows to pause notifications during a maintenance if you wish so. To ensure that escalations using this functionality work properly after the upgrade you must reconfigure the relevant actions by: - removing the *Maintenance status = not in "maintenance"* condition - making sure that *Pause operations while in maintenance* is selected in action configuration ##### Parallel escalation for each of multiple PROBLEM events Before Zabbix 3.2 every new *PROBLEM* event would abort the escalation of an earlier *PROBLEM* event, i.e. only one active escalation could run for a trigger with multiple event generation. Now escalation procedures for all these events are processed in parallel. This change and newly introduced [event correlation](/manual/config/event_correlation) and [event tags](/manual/config/triggers/event_tags) enable more flexible approach to multiple *PROBLEM* event resolution. For example, depending on configuration now *OK* event may either stop escalation for the particular *PROBLEM* event, for numerous events or for all of them. #### Recovery operations [Recovery operations](/manual/config/notifications/action/recovery_operations) are a new unified way of executing scripts or getting notified on resolved problems. Before the only way to execute a script when problem triggers went OK was to configure an action to start an escalation on the 'Trigger value = OK' condition. This is not supported any more - an action with recovery operations must be used instead. During database upgrade actions with simple conditions are updated automatically while actions having complex conditions are disabled with a corresponding log message. The disabled actions must be updated manually. The action upgrade steps performed automatically are: - Recovery messages are moved to recovery operations; - All trigger-based and internal actions having 'Or' or 'Custom expression' calculation type are disabled; - Trigger-based actions that could handle both PROBLEM and OK events are disabled; - Trigger-based actions that could handle OK events only, but have a recovery message or more than one escalation step are disabled; - Internal actions that could handle any other event except those corresponding a single *Item in “not supported” state*, *Low-level discovery rule in “not supported” state* or *Trigger in “unknown” state* condition are disabled; - "Trigger value" conditions for trigger events and "Event type" conditions for internal events - *Item in “normal” state*, *Low-level discovery rule in “normal” state*, *Trigger in “normal” state* are removed from the conditions - they are not supported any more. After database upgrade Zabbix server log must be checked if there are any actions that must be updated manually. It's recommended to check also other actions. Recovery operations also get a dedicated tab in the action configuration form, while the condition tab has been dropped and conditions now can be set in the general action property tab. #### IBM DB2 connection encoding When connecting to IBM DB2 database Zabbix server, proxy and frontend will now ensure that database server anticipates UTF-8 encoded text. Previously the way IBM DB2 server interpreted text information from Zabbix was fully determined by Zabbix server/proxy or web server locale settings (LC\_ALL, LANG, LC\_CTYPE and other environment variables). If the latter were not configured properly text containing non-ASCII characters was saved in the database incorrectly. In such situations after upgrade non-ASCII characters will be displayed in Zabbix incorrectly. The problem could easily not manifest itself if locale was identically misconfigured for Zabbix server and for web server running Zabbix frontend and the number of non-ASCII characters was too low to cause "Value too long..." errors. Please check the database contents before upgrading. #### Host availability, discovery, auto-registration and history data validation When Zabbix server had received invalid host availability, discovery or auto-registration data it used to write a warning to the log file for every invalid entry. Now in the case of invalid entries it will reject the whole data packet and log a single line like *proxy "" at "" returned invalid host availability data\[: \]* (for passive proxies) or *received invalid host availability data from proxy "" at "": * (for active proxies). Also, if passive proxy for example returns invalid host availability data, server will skip polling discovery, history and auto-registration data from that proxy. Like before, Zabbix will try to process as much historical data from proxies and active agents as it can and will silently ignore invalid entries. If the whole packet is invalid a message containing name, IP address and error description will be logged. This will help tracking down misconfiguration issues when proxypoller connects server's trapper port or agent instead of proxy. #### Miscellaneous - The customizable time period for displaying resolved problems/OK triggers and for blinking upon trigger status change has been limited to 86400 seconds (24 hours) in *Administration* → *General* → *Trigger displaying options*. #### Logging changes The messages printed to the log files about completion of the trend data synchronization have been changed. The following messages were changed: syncing trends data... → syncing trend data... syncing trends data done → syncing trend data done #### Item changes **system.sw.os\[name\]** item might have different value on Linux systems. Now the PRETTY\_NAME parameter from /etc/os-release file is used by default. Only if os-release is not supported by the system the /etc/issue.net file is used to obtain system name. #### Changes in evaluating trigger and calculated item expressions Previously any unsupported item in trigger expression or error in function evaluation immediately rendered the whole expression value to *Unknown*. In the new version unsupported items and errors in function evaluation continue to take part in expression evaluation as unknown values. These unknown values may turn into "known" values in logical operations, e.g.: - '1 or Unsuported\_item1.some\_function()' is now evaluated to '1' (True) - '0 and Unsuported\_item1.some\_function()' is now evaluated to '0' (False) Additionally **nodata()**, **date()**, **dayofmonth()**, **dayofweek()**, **now()** and **time()** trigger functions are now calculated for unsupported items as well. See [Expressions with unsupported items and unknown values](/manual/config/triggers/expression#expressions_with_unsupported_items_and_unknown_values). #### Changes in graphs after item data type is changed When item property "Type of information" is changed, previous history and trend data will not be displayed in graphs. ### See also - [Template changes](/manual/installation/template_changes)