Hide Forgot
Description of problem: MariaDB/MySQL does not log error message when client connections are refused due to max_connection reached. Consequently, event if the servers logs are collected during the generation of sosreports, we can't know whether the max number of allowed connections was reached during the lifetime of the running mysqld pid. It would be helpful if the mysql plugin could be extended to collect the value of mysql's status variable 'Max_used_connections' [1] [1] https://mariadb.com/kb/en/mariadb/server-status-variables/#max_used_connections
> MariaDB/MySQL does not log error message when client connections are refused > due to max_connection reached. The obvious question is: "why not?"; Is this a deliberate design decision (if so, what is the reason for it?)? If this is simply a missing feature then it probably makes sense to also file a feature request against the relevant packages to have this capability added. In the interests of supporting versions that lack this ability this is something we could attempt to collect in sos however there are a couple of potential caveats: - Is this information available without authentication in all configurations? o Authenticating with a database is problematic in sos's typical use-cases. - What command(s) should be issued to obtain the data? The sos maintainers are not MariaDB/MySQL gurus and any command we execute must support 'one-shot' operation, i.e. supplying the DB commands as a command line option or script. We cannot invoke an interactive shell from sos and pipe commands into it.
(In reply to Bryn M. Reeves from comment #2) > > MariaDB/MySQL does not log error message when client connections are refused > > due to max_connection reached. > > The obvious question is: "why not?"; Is this a deliberate design decision > (if so, what is the reason for it?)? If this is simply a missing feature > then it probably makes sense to also file a feature request against the > relevant packages to have this capability added. > > In the interests of supporting versions that lack this ability this is > something we could attempt to collect in sos however there are a couple of > potential caveats: > > - Is this information available without authentication in all > configurations? > o Authenticating with a database is problematic in sos's typical > use-cases. > - What command(s) should be issued to obtain the data? The sos maintainers > are > not MariaDB/MySQL gurus and any command we execute must support > 'one-shot' > operation, i.e. supplying the DB commands as a command line option or > script. > We cannot invoke an interactive shell from sos and pipe commands into it. Hello, could you please provide the required information?
(In reply to Pavel Moravec from comment #4) > (In reply to Bryn M. Reeves from comment #2) > > > MariaDB/MySQL does not log error message when client connections are refused > > > due to max_connection reached. > > > > The obvious question is: "why not?"; Is this a deliberate design decision > > (if so, what is the reason for it?)? If this is simply a missing feature > > then it probably makes sense to also file a feature request against the > > relevant packages to have this capability added. > > > > In the interests of supporting versions that lack this ability this is > > something we could attempt to collect in sos however there are a couple of > > potential caveats: > > > > - Is this information available without authentication in all > > configurations? > > o Authenticating with a database is problematic in sos's typical > > use-cases. > > - What command(s) should be issued to obtain the data? The sos maintainers > > are > > not MariaDB/MySQL gurus and any command we execute must support > > 'one-shot' > > operation, i.e. supplying the DB commands as a command line option or > > script. > > We cannot invoke an interactive shell from sos and pipe commands into it. > > Hello, > could you please provide the required information? Bouncing the request. We can't resolve this BZ without that info.
Yet another bounce of the request. Also defering for potential inclusion in 7.6
Latest call for the needinfo before closing the BZ as WONTFIX. We are waiting for the info for >2 years.. (and removing from 7.6 scope)
Hey Pavel, sorry for the awfully long delay... let me add a quick update on that one and see how we should proceed. In our OpenStack use case, mysql is targetted by OpenStack internal services. From time to time a peak of traffic can yield to connection exhaustion, but it's difficult to prove/disprove the theory because mysql doesn't log all refused connection. Lately the way mysql is set up has evolved in OpenStack: we now use containers, we have a common user throughout the OpenStack mysql instances, and its password is managed in puppet's hiera [1]. So getting the info out of our mysql instances would look like e.g. "mysql -u root -p $(hiera -c /etc/puppet/hiera.yaml "mysql::server::root_password") -e {a-sql-command-to-fetch-info} This is specific RedHat-deployed Openstack (RDO or RHOSP), so I'm not sure where to best implement that feature in sosreports... in a mysql plugin? in a OpenStack plugin? I guess the goal of the RFE was to get some guidance on what would be the best approach here. Tell me what you think, I'd be happy to close it and continue the discussion upstream if you think it's a more appropriate path. [1] https://puppet.com/docs/puppet/5.2/hiera_intro.html
These is so deeply tied into OpenStack's use of MySql that it is not appropriate in the main mysql sos plugin. What OpenStack component(s) is this tied to, and is there any component that could be said to have an "owning" relationship to the resource? Ultimately, we should be able to find somewhere to put this, even if it ends up being a new plugin: we just need to understand its use in OpenStack to know what that place is.
(In reply to Bryn M. Reeves from comment #9) > These is so deeply tied into OpenStack's use of MySql that it is not > appropriate in the main mysql sos plugin. > > What OpenStack component(s) is this tied to, and is there any component that > could be said to have an "owning" relationship to the resource? > > Ultimately, we should be able to find somewhere to put this, even if it ends > up being a new plugin: we just need to understand its use in OpenStack to > know what that place is. Hello, could you please 1) provide precise command that sosreport should call? 2) clarify what OpenStack component(s) are relevant / what sosreport plugin shall collect that? List of OpenStack plugins in sos: ansible aodh ceilometer cinder glance heat horizon instack ironic keystone manila neutron novajoin nova octavia sahara swift trove Thanks in advance.
(In reply to Pavel Moravec from comment #10) > (In reply to Bryn M. Reeves from comment #9) > > These is so deeply tied into OpenStack's use of MySql that it is not > > appropriate in the main mysql sos plugin. > > > > What OpenStack component(s) is this tied to, and is there any component that > > could be said to have an "owning" relationship to the resource? > > > > Ultimately, we should be able to find somewhere to put this, even if it ends > > up being a new plugin: we just need to understand its use in OpenStack to > > know what that place is. > > Hello, > could you please > 1) provide precise command that sosreport should call? > > 2) clarify what OpenStack component(s) are relevant / what sosreport plugin > shall collect that? > > List of OpenStack plugins in sos: > > ansible > aodh > ceilometer > cinder > glance > heat > horizon > instack > ironic > keystone > manila > neutron > novajoin > nova > octavia > sahara > swift > trove > > > Thanks in advance. Last call for passenge.. err for needinfo, before the BZ will be closed! Until a repsonse will be received in 2 months, we close the BZ as insufficient data.
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.