Database error: Lost connection to MySQL server during query

TeamSpeak 3 Server
1

Sometimes when I try to connect to my server, I get “database error”. When I check the logs of the TeamSpeak container, here’s what gets logged: 2024-11-16 10:04:21.042771|ERROR |DatabaseQuery | |db_open() select * from clients where client_unique_id = '[REDACTED ID] error: Lost connection to MySQL server during query. When I try to connect 3 or 4 times in a row I can successfully connect. Where is this error from and how can I solve it?

I’m using Docker and here’s my config:

services:
  teamspeak:
    image: teamspeak:3.13.7
    ports:
      - 9987:9987/udp
      - 10011:10011
      - 30033:30033
    environment:
      TS3SERVER_DB_PLUGIN: ts3db_mariadb
      TS3SERVER_DB_SQLCREATEPATH: create_mariadb
      TS3SERVER_DB_HOST: teamspeak-db
      TS3SERVER_DB_USER: root
      TS3SERVER_DB_PASSWORD_FILE: /run/secrets/ts3_db_password
      TS3SERVER_DB_NAME: teamspeak
      TS3SERVER_DB_WAITUNTILREADY: 30
      TS3SERVER_LICENSE: accept
    volumes:
      - "teamspeak-data:/var/ts3server"
    secrets:
      - ts3_db_password
    networks:
      - teamspeak-network
      - monitoring-network
    depends_on:
      - teamspeak-db

  teamspeak-db:
    image: mariadb:11.5.2
    environment:
      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/ts3_db_password
      MYSQL_DATABASE: teamspeak
    volumes: 
      - "teamspeak-db:/var/lib/mysql"
    secrets:
      - ts3_db_password
    networks:
      - teamspeak-network
2

After forwarding this internally it might be due to high CPU usage / spikes.

Also you might wanna have a look at your MariaDB logs and maybe update it to a newer Version.

2 Likes
3

I updated my database. Here are the database logs—which look fine:

2025-06-16 15:44:55+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:11.8.2+maria~ubu2404 started.
2025-06-16 15:44:56+00:00 [Warn] [Entrypoint]: /sys/fs/cgroup///memory.pressure not writable, functionality unavailable to MariaDB
2025-06-16 15:44:56+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2025-06-16 15:44:56+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:11.8.2+maria~ubu2404 started.
2025-06-16 15:44:56+00:00 [Note] [Entrypoint]: MariaDB upgrade (mariadb-upgrade or creating healthcheck users) required, but skipped due to $MARIADB_AUTO_UPGRADE setting
2025-06-16 15:44:56 0 [Note] Starting MariaDB 11.8.2-MariaDB-ubu2404 source revision 8d36cafe4fc700e6e577d5a36650c58707e76b92 server_uid VP/n9WIkiT8akEqUXEqJeE45qkk= as process 1
2025-06-16 15:44:59 0 [Note] InnoDB: Compressed tables use zlib 1.3
2025-06-16 15:44:59 0 [Note] InnoDB: Using transactional memory
2025-06-16 15:44:59 0 [Note] InnoDB: Number of transaction pools: 1
2025-06-16 15:44:59 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2025-06-16 15:44:59 0 [Note] mariadbd: O_TMPFILE is not supported on /tmp (disabling future attempts)
2025-06-16 15:44:59 0 [Warning] mariadbd: io_uring_queue_init() failed with EPERM: sysctl kernel.io_uring_disabled has the value 2, or 1 and the user of the process is not a member of sysctl kernel.io_uring_group. (see man 2 io_uring_setup).
2025-06-16 15:44:59 0 [Warning] InnoDB: liburing disabled: falling back to innodb_use_native_aio=OFF
2025-06-16 15:44:59 0 [Note] InnoDB: innodb_buffer_pool_size_max=128m, innodb_buffer_pool_size=128m
2025-06-16 15:44:59 0 [Note] InnoDB: Completed initialization of buffer pool
2025-06-16 15:44:59 0 [Note] InnoDB: Buffered log writes (block size=512 bytes)
2025-06-16 15:44:59 0 [Note] InnoDB: End of log at LSN=71630124
2025-06-16 15:45:04 0 [Note] InnoDB: Opened 3 undo tablespaces
2025-06-16 15:45:04 0 [Note] InnoDB: 128 rollback segments in 3 undo tablespaces are active.
2025-06-16 15:45:04 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
2025-06-16 15:45:04 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
2025-06-16 15:45:04 0 [Note] InnoDB: log sequence number 71630124; transaction id 3724
2025-06-16 15:45:04 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2025-06-16 15:45:04 0 [Note] Plugin 'FEEDBACK' is disabled.
2025-06-16 15:45:04 0 [Note] Plugin 'wsrep-provider' is disabled.
2025-06-16 15:45:04 0 [Note] InnoDB: Buffer pool(s) load completed at 250616 15:45:04
2025-06-16 15:45:06 0 [Note] Server socket created on IP: '0.0.0.0'.
2025-06-16 15:45:06 0 [Note] Server socket created on IP: '::'.
2025-06-16 15:45:06 0 [Note] mariadbd: Event Scheduler: Loaded 0 events
2025-06-16 15:45:06 0 [Note] mariadbd: ready for connections.
Version: '11.8.2-MariaDB-ubu2404'  socket: '/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution

But the TeamSpeak server logs look less fine:

2025-06-16 14:45:47.837864|ERROR   |DatabaseQuery |   |db_open() select distinct c.client_id, c.server_id from (clients c left outer jo error: Lost connection to MySQL server during query

As I was about to post this message, I realized that Telegraf could be the culprit, so I stopped the service and now I don’t get any errors for connecting. I won’t post my Telegraf configuration here as I think it’s not related to TeamSpeak and would not really be relevant for the TeamSpeak team.

I guess Telegraf was flooding the TeamSpeak server or eating up all connections in the pool. I’m going to dive into it later, but I hope my findings can also help someone down the road.

2 Likes
4

I have bad news to report: I stopped the Telegraf service a few hours ago and tried to connect to my TeamSpeak server and got the same error…

This is definitely not a Telegraf issue.

5

Try to start the instance without declaring the socket path.

Just remove it and leave socket= blank.

You can also try setting the host to localhost host=localhost

2 Likes
6

I sincerely apologize but I don’t understand which instance you’re talking about. How do I "leave socket= blank and where? And on which service and where do I set host=localhost?

7

This would be in the ts3db_mariadb.ini but as you’re using Docker this does not seem to exist right?

I was searching through the forums and found a post about a similar issue as most of the devs are off due to public holidays. But that does not seem to be working for this case.

Are you using any other software on that server?

2 Likes
8

I basically only have Docker installed and run all my services through Docker (Swarm).

I’d be open to try with another database if you think that’s the issue. Would you recommend something else?

9

Perhaps try ts3db_sqlite3 or ts3db_postgresql instead.
The former is local and does not require an additional container, which probably eliminates the issue.

1 Like
10

I will try this as soon as I get back home. I’m just going to delete the TeamSpeak volume and not bother with the migration. I don’t have any important data.

If I use SQLite, do you know the location of the .sqlite file inside the TeamSpeak container?

11

It should be located here: /var/ts3server/ts3server.sqlitedb

2 Likes
12

Here’s my updated Docker Compose:

services:
  teamspeak:
    image: teamspeak:3.13.7
    deploy:
      placement:
        constraints:
          - "node.labels.teamspeak==true"
    ports:
      - 0.0.0.0:9987:9987/udp
      - 0.0.0.0:10011:10011
      - 0.0.0.0:30033:30033
    environment:
      TS3SERVER_DB_PLUGIN: ts3db_postgresql
      TS3SERVER_DB_SQLCREATEPATH: create_postgresql
      TS3SERVER_DB_HOST: teamspeak-db
      TS3SERVER_DB_USER: teamspeak
      TS3SERVER_DB_PASSWORD_FILE: /run/secrets/ts3_db_password
      TS3SERVER_DB_NAME: teamspeak
      TS3SERVER_DB_WAITUNTILREADY: 30
      TS3SERVER_LICENSE: accept
    volumes:
      - "teamspeak-data:/var/ts3server"
    secrets:
      - ts3_db_password
    networks:
      - teamspeak-network
      - monitoring-network
    depends_on:
      - teamspeak-db

  teamspeak-db:
    image: postgres:17.2-alpine
    deploy:
      placement:
        constraints:
          - "node.labels.teamspeak-db==true"
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/ts3_db_password
      POSTGRES_DB: teamspeak
      POSTGRES_USER: teamspeak
    volumes:
      - "teamspeak-db:/var/lib/postgresql/data"
    secrets:
      - ts3_db_password
    networks:
      - teamspeak-network

volumes:
  teamspeak-data:
  teamspeak-db:

secrets:
  ts3_db_password:
    external: true

networks:
  teamspeak-network:
  monitoring-network:
    external: true

But I get the following logs in the TeamSpeak container:

2025-06-20 16:40:06.947920|INFO    |ServerLibPriv |   |TeamSpeak 3 Server 3.13.7 (2022-06-20 12:21:53)
2025-06-20 16:40:06.948065|INFO    |ServerLibPriv |   |SystemInformation: Linux 6.4.0-150600.23.33-default #1 SMP PREEMPT_DYNAMIC Thu Jan  9 14:10:22 UTC 2025 (ba46628) x86_64 Binary: 64bit
2025-06-20 16:40:06.948110|INFO    |ServerLibPriv |   |Using hardware aes
2025-06-20 16:40:06.949485|INFO    |DatabaseQuery |   |dbPlugin name:    PostgreSQL plugin, version 1, (c)TeamSpeak Systems GmbH
2025-06-20 16:40:06.949547|INFO    |DatabaseQuery |   |dbPlugin version: 1
2025-06-20 16:40:06.960457|ERROR   |DatabaseQuery |   |make_connection had broken connect could not parse network address "teamspeak-db": Name does not resolve 
2025-06-20 16:40:06.960522|CRITICAL|ServerLibPriv |   |Server() DatabaseError

I wonder if it’s because Postgres 17 is not supported by TeamSpeak?

Edit:
Running it with TS3SERVER_DB_PLUGIN=ts3db_sqlite3 and TS3SERVER_DB_SQLCREATEPATH=create_sqlite3 I get the following:

2025-06-20 16:49:56.904161|INFO    |ServerLibPriv |   |TeamSpeak 3 Server 3.13.7 (2022-06-20 12:21:53)
2025-06-20 16:49:56.904305|INFO    |ServerLibPriv |   |SystemInformation: Linux 6.4.0-150600.23.33-default #1 SMP PREEMPT_DYNAMIC Thu Jan  9 14:10:22 UTC 2025 (ba46628) x86_64 Binary: 64bit
2025-06-20 16:49:56.904354|INFO    |ServerLibPriv |   |Using hardware aes
2025-06-20 16:49:56.914589|INFO    |DatabaseQuery |   |dbPlugin name:    SQLite3 plugin, Version 3, (c)TeamSpeak Systems GmbH
2025-06-20 16:49:56.914664|INFO    |DatabaseQuery |   |dbPlugin version: 3.11.1
2025-06-20 16:49:56.915144|INFO    |DatabaseQuery |   |checking database integrity (may take a while)
2025-06-20 16:49:56.916085|CRITICAL|DatabaseQuery |   |setSQLfromFile( file:create_sqlite3/create_tables.sql) failed
13

Right now, it seems like there’s a networking problem between the Swarm nodes, and we were not able to reproduce this issue on our side.

It is also strange that it doesn’t even work with SQLite, which should normally run without much setup.

Try using docker run or docker compose up without Swarm to see if the problem still occurs. That should help narrow things down.

Here is a slightly modified version, which has been validated to work on a locally hosted setup:

services:
  teamspeak:
    image: teamspeak:3.13.7
    ports:
      - 9987:9987/udp
      - 10011:10011
      - 30033:30033
    environment:
      TS3SERVER_DB_PLUGIN: ts3db_mariadb
      TS3SERVER_DB_SQLCREATEPATH: create_mariadb
      TS3SERVER_DB_HOST: teamspeak-db
      TS3SERVER_DB_USER: root
      TS3SERVER_DB_PASSWORD_FILE: /run/secrets/ts3_db_password
      TS3SERVER_DB_NAME: teamspeak
      TS3SERVER_DB_WAITUNTILREADY: 30
      TS3SERVER_LICENSE: accept
    volumes:
      - "teamspeak-data:/var/ts3server"
    secrets:
      - ts3_db_password
    networks:
      - teamspeak-network
    depends_on:
      - teamspeak-db

  teamspeak-db:
    image: mariadb:11.5.2
    environment:
      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/ts3_db_password
      MYSQL_DATABASE: teamspeak
    volumes: 
      - "teamspeak-db:/var/lib/mysql"
    secrets:
      - ts3_db_password
    networks:
      - teamspeak-network
volumes:
  teamspeak-data:
  teamspeak-db:

networks:
  teamspeak-network:

secrets:
  ts3_db_password:
    file: ./db_password.txt
3 Likes
14

Thank you for providing the example and going to such lengths to help me.

Did you let it run for a few hours before trying to connect again? I usually can connect just fine if the server just started; after a few hours, problems start to appear.

15

That I don’t know, my colleague did the testing and provided the information. I’ll ask him tomorrow.

2 Likes
16

I recommend booting the containers up the morning, forget about it and try to connect at the end of the day.

17

The server was online for just a bit, but this then hints towards a networking issue.

2 Likes
18

This makes sense. However, all my other services run fine.

I wonder if there’s a timeout value that may be changed within TeamSpeak that could help with that. Even if it’s just for troubleshooting.