[MXS-4823] error Write to Backend DCB Created: 2023-10-20  Updated: 2023-12-04

Status: Open
Project: MariaDB MaxScale
Component/s: None
Affects Version/s: 2.5.28
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bjoern Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Debian, Docker Container

Attachments: File maxscale-config-editforticketjira.cnf    

 Description   

We sometimes get the following error on our maxscale proxy:
error : (13034) (mariadb-xx) (socket_write): Write to Backend DCB 192.168.0.50 in state DCB::State::POLLING failed: 104, Connection reset by peer

Could maybe anyone help me to understand this error?
There is no other error, no conecction issues, noch backups running at the time.

 Comments   
Comment by markus makela [ 2023-10-20 ]

Error 104 is:

#define	ECONNRESET	104	/* Connection reset by peer */

This means that the other end of the connection, the database server in this case, closed the connection when MaxScale was attempting to write to it. Are there any errors in the database error logs?

What version of MariaDB is this using?

If possible, please also attach your maxscale.cnf with all sensitive information removed (e.g passwords, IP addresses)

Comment by Bjoern [ 2023-10-20 ]

Hi Markus, thank you very much for showing interest.
I attached the config.
The database version is MariaDB 10.6.12.
There is no error on the database server.

Comment by markus makela [ 2023-10-23 ]

Are there any other types of errors in the MaxScale log? Anything like timeouts from monitors or other network errors?

Comment by Bjoern [ 2023-10-23 ]

No.

Comment by Bjoern [ 2023-10-24 ]

I forgot to mention that we have this issue on two completely seperate infrastructures. So network issues are in my opinion out of the picture.

Comment by markus makela [ 2023-10-24 ]

If you can upgrade to MaxScale 6, you can use session_trace=100 and session_trace_match=Connection reset by peer to enable trace logging for sessions that generate that error.

The trace logging will write the last 100 entries (configurable) to the log whenever the regular expression in session_trace_match matches one of the log messages when the session is stopping.

Comment by Bjoern [ 2023-10-24 ]

Thank you, I can try that.
One more question before I do it:
Can this error be caused by timeout issues?
We have a pretty low wait_timeout (600s) configured on our MariaDB Server and maybe the combination of our connection pool - MaxScale - MariaDB is causing this?

Comment by markus makela [ 2023-12-04 ]

Sorry for the late replay, I was on vacation.

It's worth trying out if increasing wait_timeout helps with this error. It would allow us to rule it out as a cause if it doesn't change the amount of errors.

Generated at Thu Feb 08 04:31:25 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.