Connection drops when using Bitnami MariaDB Galera Helm chart
search cancel

Connection drops when using Bitnami MariaDB Galera Helm chart

book

Article ID: 438782

calendar_today

Updated On:

Products

VMware Tanzu Application Catalog

Issue/Introduction

When using the Bitnami MariaDB helm chart, connection drops may be observed.


On the application side, the errors look like this:

Caused by: java.io.EOFException: unexpected end of stream, read 0 bytes from 4 (socket was closed by server)


The corresponding entry appears in the MariaDB log:

 

[Warning] Aborted connection 14784 to db: ‘test’ user: 'test' host: ‘<ip>’ (Got an error reading communication packets)

Environment

Bitnami MariaDB Galera Helm chart

Resolution

The "aborted connection" message usually means the TCP session ended while MariaDB was still reading or writing protocol data—often because the client closed abruptly, a proxy or idle timeout cut the connection, or the server dropped the session under load.

In order to mitigate this, you may need to tweak some of the default MariaDB settings under the mariaDBConfiguration value:

  • max_connections: Caps how many client sessions can be connected at once. 
  • thread_cache_size: Reuses server worker threads after disconnect instead of always creating new ones. A larger cache cuts thread churn when connections are opened and closed frequently.
  • back_log: Queues inbound TCP handshakes that have not been fully accepted yet. A modest increase helps short connection spikes without fixing a true max_connections shortage.
  • max_allowed_packet: Limits the largest single client/server message (big rows, BLOBs, large statements). Increase it if legitimate traffic exceeds the default and clients see failures or abrupt disconnects mid-transfer.
  • wait_timeout: Closes non-interactive sessions that stay idle with no queries for longer than this value. Tune it so idle pooled connections are not killed sooner than the pool or load balancer expect.
  • interactive_timeout: Same idea as wait_timeout, but for sessions MariaDB treats as interactive (often JDBC “interactive” clients). Keeping it aligned with wait_timeout avoids inconsistent idle behaviour across client types.
  • net_read_timeout: Times out waiting to read the next chunk of data from the client while a connection is active. Raising it reduces false “peer went away” situations on slow reads or large uploads.
  • net_write_timeout: Times out waiting to write result data to the client. Raising it helps long or slow result downloads finish without the server closing the stream mid-response.

 

Depending on the nature of your applications, you may need to tweak these values, as well as adjusting the resources assigned to each mariadb-galera pod, which can be configured under the resources values. This is something that will need to be adapted to your production needs, after performing extensive testing.