Home > other >  MariaDB stops working without reason on small centos8 server
MariaDB stops working without reason on small centos8 server

Time:10-07

I have small web/mail server with apache/mariadb. Last week we changed some of the WWW code and to make it work I changed in php.ini line :

max_input_vars to 5000 (now 4000, it was 1000 at the start)

And it seems changed something because our mariadb 10.3.28 starts making problems. It just stops reciving any information. Restart of mysql (and httpd) helps for 24h now ... Log:

2022-10-05 14:28:58 2796199 [Warning] Aborted connection 2796199 to db: 'ACTIVEDB' user: 'USER' host: 'localhost' (Got an error reading communication packets)

This kind of warnings shows up sometimes but now we got dozens every hour.

In PHP i decrased max_input_vars, in my.cnf I addedd

max_allowed_packet = 124M
max_connections = 400

log_warnings     = 3

Everything was at default values before. Log level was for some time at level 4 but it stared to get too big without any time give to "crush". Disk is nvme 500GB, Intel and shows no problems. I would like to hear :

  • how to check/connect mariadb when it looks inactive
  • what and how (step by step) to check

Thanks all

CodePudding user response:

This is not an answer, but too long for a comment.

The error "Aborted connection ... (Got an error reading communication packets)" occurs if a client disconnected without sending a COM_CLOSE notification to the server before.

This behavior is easily reproducible, e.g. by starting the command line client and killing the command line client from another session. Depending on the log_warning level, the server will write a log entry and increase the server status variable aborted_clients (or aborted_connects if this happens during connection handshake).

Here are only a few possible reasons:

  • Before 10.2.3 the default log_warning level was 1 (no logging of aborted_connections), since 10.2.4 default value is 2 (log aborted connections) - if the server was recently upgraded from 10.2.3 or lower the problem may have already existed in previous installation, but was not written into log file.

  • The PHP script(s) doesn't close the connection: As soon the script is ready with its work, make sure that all transactions were committed, memory (result sets) were freed, and the connection was closed properly.

  • A timeout occurred, e.g. wait_timeout was set too low and exceeded or PHP's max_execution_time exceeded (and script was killed) or net_read/write_timeouts occurred.

  • DNS problems: In this case enable skip-name-resolve, use IP's and verify against IP's.

  • Network or firewall problems

CodePudding user response:

I would like to thank for sugestions and your time. Looks like there was a problem with one table, I don't know how/why but after some time it was set up as READ-ONLY. There was no information in log about it up to level 3 (level 4 generated too much information for me :( ) The DB works some time fine (expect for one table) and in time it looks like it just hangs whole DB. The case is still "under investigation".

About "damaged" table :

  • listed and read-only related thinks works fine
  • insert/change hangs the whole DB for 2-3 minutes and then gets back to work
  • after few "hangs" the DB just freezes
  • there was nothing strange in logs level 3
  • copy table to new and then change names to switch tables works (I hope so)

If anyone have any idea how to check table would be great (standard operatinos like check, analyse did nothing).

Thanks again.

  • Related