centos7 mariadb5.5 -> MariaDB10.3
Ever since I switched from the default included centos mariadb to your repo. The web applications are getting ~1 once a week connection refused or so. I have already scheduled a cron job to restart your server. But still that is not enough. In the previous 10 years or so I never had such issue nor do I have such issues with postgresql. Nothing is in the log file, only the restart. Should such things not be logged by default? How to configure that issues resulting in refusing access or being unable to give access are logged?
how to debug this?
Ever since I switched from the default included centos mariadb to your repo. The web applications are getting ~1 once a week connection refused or so. I have already scheduled a cron job to restart your server. But still that is not enough.
In the previous 10 years or so I never had such issue nor do I have such issues with postgresql.
Nothing is in the log file, only the restart. Should such things not be logged by default? How to configure that issues resulting in refusing access or being unable to give access are logged?
I added log_warnings = 9 and see a lot of these : mysqld: 2023-11-13 13:53:34 438 [Warning] Aborted connection 438 to db: 'xxxxx' user: 'xxxx' host: 'xxxxx' (CLOSE_CONNECTION) Why is this a warning? This is already generated by simple mysqli_connect with mysqli_close.
how to debug this?
Ever since I switched from the default included centos mariadb to your repo. The web applications are getting ~1 once a week connection refused
or
so. I have already scheduled a cron job to restart your server. But still that is not enough.
In the previous 10 years or so I never had such issue nor do I have such issues with postgresql.
Nothing is in the log file, only the restart. Should such things not be logged by default? How to configure that issues resulting in refusing access or being unable to give access are logged?
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
Hi Marc, This is working as documented: - log_warnings >=4 - Connections aborted due to "Too many connections" errors. - Connections closed normally. - Connections aborted due to KILL <https://mariadb.com/kb/en/data-manipulation-kill-connection-query/>. - Connections closed due to released connections, such as when completion_type <https://mariadb.com/kb/en/server-system-variables/#completion_type> is set to RELEASE. Please set log_warnings at 2 if you want the warnings for connection aborted due to errors or timeout. What is your wait_timeout server option set to? If it's too low and the connection is idle, it will be closed by the server. But generally, the application should properly handle the loss of connection. Le lun. 13 nov. 2023 à 13:57, Marc via discuss <discuss@lists.mariadb.org> a écrit :
I added log_warnings = 9
and see a lot of these :
mysqld: 2023-11-13 13:53:34 438 [Warning] Aborted connection 438 to db: 'xxxxx' user: 'xxxx' host: 'xxxxx' (CLOSE_CONNECTION)
Why is this a warning? This is already generated by simple mysqli_connect with mysqli_close.
how to debug this?
Ever since I switched from the default included centos mariadb to your repo. The web applications are getting ~1 once a week connection
refused or
so. I have already scheduled a cron job to restart your server. But still that is not enough.
In the previous 10 years or so I never had such issue nor do I have such issues with postgresql.
Nothing is in the log file, only the restart. Should such things not be logged by default? How to configure that issues resulting in refusing access or being unable to give access are logged?
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
Please set log_warnings at 2 if you want the warnings for connection aborted due to errors or timeout.
ok done
What is your wait_timeout server option set to? If it's too low and the connection is idle, it will be closed by the server. But generally, the application should properly handle the loss of connection.
I think it is the default wait_timeout | 28800
I added log_warnings = 9
and see a lot of these :
mysqld: 2023-11-13 13:53:34 438 [Warning] Aborted connection 438 to db: 'xxxxx' user: 'xxxx' host: 'xxxxx' (CLOSE_CONNECTION)
Why is this a warning? This is already generated by simple mysqli_connect with mysqli_close.
how to debug this?
Ever since I switched from the default included centos mariadb to
your
repo. The web applications are getting ~1 once a week connection refused or so. I have already scheduled a cron job to restart your server. But still that is not enough.
In the previous 10 years or so I never had such issue nor do I have such issues with postgresql.
Nothing is in the log file, only the restart. Should such things not be logged by default? How to configure that issues resulting in refusing access or being unable to give access are logged?
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org <mailto:discuss@lists.mariadb.org> To unsubscribe send an email to discuss-leave@lists.mariadb.org <mailto:discuss-leave@lists.mariadb.org>
discuss mailing list -- discuss@lists.mariadb.org <mailto:discuss@lists.mariadb.org> To unsubscribe send an email to discuss-leave@lists.mariadb.org <mailto:discuss-leave@lists.mariadb.org>
I am currently also running the mysqld_exporter what I notice is that, the backup mysql_dump is the only event that seems to cause 'load', and then: - mysql intern memory overview seems to increase at the backup time, but does not seem to be released. - mysql open files seems to increase at the backup time, but does not seem to be released. - mysql open tables seems to increase at the backup time, but does not seem to be released. - mysql open table definitions seems to increase at the backup time, but does not seem to be released. Should not at least something go down after the backup/mysql_dump event? PS I did not verify anything of the grafana dashboard I am using
Hello, It looks normal because mysqldump loads data into memory. as long as you dont exceed values for buffer pool, open files limit and open tables limit the data and/or handlers will be cached. BTW, if you run mysqldump in a locking way it could affect your application. Le mar. 14 nov. 2023 à 11:33, Marc <Marc@f1-outsourcing.eu> a écrit :
I am currently also running the mysqld_exporter
what I notice is that, the backup mysql_dump is the only event that seems to cause 'load', and then:
- mysql intern memory overview seems to increase at the backup time, but does not seem to be released.
- mysql open files seems to increase at the backup time, but does not seem to be released.
- mysql open tables seems to increase at the backup time, but does not seem to be released.
- mysql open table definitions seems to increase at the backup time, but does not seem to be released.
Should not at least something go down after the backup/mysql_dump event?
PS I did not verify anything of the grafana dashboard I am using
So what could be the main causes of mariadb not being available (it is still running) without reporting anything in the logs?
It looks normal because mysqldump loads data into memory. as long as you dont exceed values for buffer pool, open files limit and open tables limit the data and/or handlers will be cached.
BTW, if you run mysqldump in a locking way it could affect your application.
I am currently also running the mysqld_exporter
what I notice is that, the backup mysql_dump is the only event that seems to cause 'load', and then:
- mysql intern memory overview seems to increase at the backup time, but does not seem to be released.
- mysql open files seems to increase at the backup time, but does not seem to be released.
- mysql open tables seems to increase at the backup time, but does not seem to be released.
- mysql open table definitions seems to increase at the backup time, but does not seem to be released.
Should not at least something go down after the backup/mysql_dump event?
PS I did not verify anything of the grafana dashboard I am using
participants (2)
-
Guillaume Lefranc -
Marc