I am seeing warning messages in my MariaDB server logs. I have tried many things.
I have optimize and repair all of my databases but warning are still there.
2018-04-19 22:50:14 139673358411520 [Warning] Aborted connection 473891 to db: 'admin_' user: 'admin_' host: 'localhost' (Got timeout reading communication packets)
2018-04-19 22:52:43 139672739514112 [Warning] Aborted connection 474608 to db: 'admin_' user: 'admin_' host: 'localhost' (Got timeout reading communication packets)
My my.cnf
skip-external-locking
key_buffer_size = 256M
max_allowed_packet = 500M
table_open_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 16M
thread_concurrency = 8
innodb_file_per_table
max_connections=500
wait_timeout=60
interactive_timeout=60
long_query_time=5
I am using CentOS 7 with 8 GB of RAM.
Can someone help me?
Solve this problem by reading the https://mariadb.com/kb/en/library/upgrading-from-mariadb-101-to-mariadb-102/ incompatibilities web page. The problem has existed in past releases because log_warnings use to default to 1 and now default to 2.
Dynamically set global log_warnings=1; and watch the messages stop almost immediately, reset to 2 and within 3-5 minutes the messages resume.
This explains why 10.2.14 they just show up, yet the real problems most likely related to improper application exception handling.
Suggestions to consider for your my.cnf-ini [mysqld] section
Lead with # or REMOVE to allow defaults to work for you. . sort_buffer_size . read_buffer_size . read_rnd_buffer_size . thread_concurrency
change this global variable
You have
wait_timeout=60
in the settings. It means that connections that are idle for 60 seconds, are aborted. Increase the value to fix the problem.Reference: https://mariadb.com/docs/reference/mdb/system-variables/wait_timeout/
I got this same error by doing a query that returned multiple rows, then processing those rows using rows.Next() (in Golang), and exiting early because of an unrelated error without calling rows.Close(). The confusing part was that it worked the first few times, but eventually failed, indicating some resource (connections?) was being used up.
I was able to take advantage of Golang's defer statement, and just do
defer rows.Close()
before ever calling rows.Next(), but calling rows.Close() before every early exit from the rows.Next() loop works as well.