The error, ‘mysql_error out of range value for column’ appears in the /var/log/messages file on the Nagios XI server.

As part of our Server Management Services, we assist our customers with several Nagios queries.

Today, let us see how to effectively resolve this error.

 

mysql_error out of range value for column

The error in the /var/log/messages file on the Nagios XI server looks like this:

Apr 23 23:30:03 centosxx ndo2db: Error: mysql_query() failed for ‘INSERT INTO nagios_scheduleddowntime SET instance_id=’1′, downtime_type=’1′,
object_id=’830′, entry_time=FROM_UNIXTIME(1517155261), author_name=’nagios_user’, comment_data=’AUTO: Standby Server’, internal_downtime_id=’804′,
triggered_by_id=’0′, is_fixed=’1′, duration=’31536000′, scheduled_start_time=FROM_UNIXTIME(1517239800),
scheduled_end_time=FROM_UNIXTIME(1548775800) ON DUPLICATE KEY UPDATE instance_id=’1′, downtime_type=’1′, object_id=’830′,
entry_time=FROM_UNIXTIME(1517155261), author_name=’nagios_user’, comment_data=’AUTO: Standby Server’, internal_downtime_id=’804′, triggered_by_id=’0′,
is_fixed=’1′, duration=’31536000′, scheduled_start_time=FROM_UNIXTIME(1517239800), scheduled_end_time=FROM_UNIXTIME(1548775800)’

Apr 23 23:30:03 centosxx ndo2db: mysql_error: ‘Out of range value for column ‘duration’ at row 1′

The error above may not be identical. However, it usually follows the ‘Out of range value for column message’.

It is the result of the MySQL/MariaDB server having the SQL Mode set to STRICT_TRANS_TABLES, NO_ENGINE_SUBSTITUTION.

Generally, this problem arises when we attempt to offload the databases to an external server using a MySQL/MariaDB custom installation.

With the following steps, we can identify what the SQL Mode is currently configured for.

Initially, we establish a terminal session to MySQL/MariaDB server hosting the Nagios XI databases.

Then we execute the following command:

mysql -u root -p’nagiosxi’ -e “SELECT @@GLOBAL.sql_mode;”

Replace the password of Nagios xi with the password of the root user on the database server.

The output shows us the SQL Mode has been defined:

+——————————————–+
| @@GLOBAL.sql_mode |
+——————————————–+
| STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION |
+——————————————–+
Output that shows that NO SQL Mode has been defined:

+——————-+
| @@GLOBAL.sql_mode |
+——————-+
| |
+——————-+

 

Solution

To resolve this issue, we need to define the SQL Mode in the MySQL/MariaDB my.cnf configuration file.

Initially, we have to stop the required services on the Nagios XI server:

RHEL 7/8|CentOS 7/8|Debian|Ubuntu 16/18

systemctl stop nagios.service
systemctl stop ndo2db.service

Then we have to edit the my.cnf configuration file on MySQL/MariaDB database server.

• RHEL 8|CentOS 8

vi /etc/my.cnf.d/mysql-server.cnf

• RHEL 6/7| CentOS 6/7

vi /etc/my.cnf

• Ubuntu 16/18

vi /etc/mysql/mysql.conf.d/mysqld.cnf

• Debian 9

vi /etc/mysql/mariadb.conf.d/50-server.cnf

Eventually, locate the [mysqld] section and check to see if there exists a sql_mode:

[mysqld]
# Recommended in standard MySQL setup
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

If it does, we need to replace it with the following. If it does not exist, we need to add the following:

[mysqld]
sql_mode=””

Then we save and close the file.

Later, we need to restart the database service:

• RHEL 7|CentOS 7|Debian 9

systemctl restart mariadb.service

• Debian 8|Ubuntu 16/18

systemctl restart mysql.service

Once done, execute the following command to ensure the SQL Mode is no longer set:

mysql -u root -p’nagiosxi’ -e “SELECT @@GLOBAL.sql_mode;”

Replace the password of Nagios xi with that of the root user on the database server.

A successful output with NO SQL Mode looks like this:

+——————-+
| @@GLOBAL.sql_mode |
+——————-+
| |
+——————-+

If it is correct, we can start the services on Nagios XI:

RHEL 7|CentOS 7|Debian|Ubuntu 16/18

systemctl start ndo2db.service
systemctl start nagios.service

Then we check the /var/log/messages file to ensure the error messages no longer appear.

[Failed with the resolution? We are here for you]

 

Conclusion

In short, the error appears in the /var/log/messages file on the Nagios XI server. Today, we saw how our Support Techs fix it