Unable to successfully start Teslamate instance when messing with db before starting

[bcrooker]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

I have run into this issue before, but in the past I was able to follow the steps to backup, wipe, and restore the database to get things up and running again.

No other config/env changes were made between the system working and not working - I just restarted the main Teslamate service, and it failed to restart.

Initially I was running against a v15 Postgres container, but I have also tried v17 with no change. I have tried increasing the DATABASE_POOL_SIZE environment variable in the Teslamate container without any improvement. I have been running Teslamate for about 3-4 years. This is my second Tesla, I even tried deleting the data from all tables related to my first car (owned 2019 until late 2022) to see if it helped to prune some data. No other services/containers are using the Postgres container, it is dedicated to Teslamate. I have tried truncating and renaming the migration table as well.

Seems like the Ecto commands are relevant to the Teslamate container, but I couldn't figure out a way to run them because the container immediately fails and stops.

Expected Behavior

Successfully starting the Teslamate container.

Steps To Reproduce

Stop Teslamate container
Perform backup of DB
Run queries to reset DB
Perform restore of DB
Start Teslamate container

Relevant log output

date,stream,content
2025/02/05 21:30:52,stdout,
2025/02/05 21:30:52,stdout,The full error report is shown below.
2025/02/05 21:30:52,stdout,
2025/02/05 21:30:52,stdout, migration_repo: AnotherRepoForSchemaMigrations
2025/02/05 21:30:52,stdout," migration_source: "some_other_table_for_schema_migrations",
2025/02/05 21:30:52,stdout," config :teslamate, TeslaMate.Repo,
2025/02/05 21:30:52,stdout,
2025/02/05 21:30:52,stdout,migrations:
2025/02/05 21:30:52,stdout,configure Ecto to use another table and/or repository for managing
2025/02/05 21:30:52,stdout,""mix ecto.create", both for the desired MIX_ENV. Alternatively you may
2025/02/05 21:30:52,stdout,"To address the second, you can run "mix ecto.drop" followed by
2025/02/05 21:30:52,stdout,
2025/02/05 21:30:52,stdout,"To fix the first issue, run "mix ecto.create" for the desired MIX_ENV.
2025/02/05 21:30:52,stdout,
2025/02/05 21:30:52,stdout, indexes with a migration_lock)
2025/02/05 21:30:52,stdout, * There is a deadlock while migrating (such as using concurrent
2025/02/05 21:30:52,stdout," migrations, was defined by another library
2025/02/05 21:30:52,stdout," * The "schema_migrations" table, which Ecto uses for managing
2025/02/05 21:30:52,stdout, * The database does not exist
2025/02/05 21:30:52,stderr, nofile:1: (file)
2025/02/05 21:30:52,stderr, (ecto_sql 3.12.1) lib/ecto/migrator.ex:170: Ecto.Migrator.with_repo/3
2025/02/05 21:30:52,stderr, (ecto_sql 3.12.1) lib/ecto/migrator.ex:432: Ecto.Migrator.run/4
2025/02/05 21:30:52,stderr, (ecto_sql 3.12.1) lib/ecto/migrator.ex:563: Ecto.Migrator.lock_for_migrations/4
2025/02/05 21:30:52,stderr, (ecto_sql 3.12.1) lib/ecto/migrator.ex:779: Ecto.Migrator.verbose_schema_migration/3
2025/02/05 21:30:52,stderr, (ecto_sql 3.12.1) lib/ecto/adapters/sql.ex:1203: Ecto.Adapters.SQL.execute_ddl/4
2025/02/05 21:30:52,stderr, (elixir 1.17.3) lib/enum.ex:1703: Enum."-map/2-lists^map/1-1-"/2
2025/02/05 21:30:52,stderr (ecto_sql 3.12.1) lib/ecto/adapters/sql.ex:1096: Ecto.Adapters.SQL.raise_sql_call_error/1
2025/02/05 21:30:52,stderr,
2025/02/05 21:30:52,stderr,See DBConnection.start_link/2 for more information
2025/02/05 21:30:52,stderr,
2025/02/05 21:30:52,stderr, 4. Allowing requests to wait longer by increasing :queue_target and :queue_interval
2025/02/05 21:30:52,stderr, 3. Increasing the pool_size (although this increases resource consumption)
2025/02/05 21:30:52,stderr, 2. Tracking down slow queries and making sure they are running fast enough
2025/02/05 21:30:52,stderr, 1. Ensuring your database is available and that you can connect to it
2025/02/05 21:30:52,stderr,
2025/02/05 21:30:52,stderr,** (DBConnection.ConnectionError) connection not available and request was dropped from queue after 2975ms. This means requests are coming in and your connection pool cannot serve them fast enough. You can address this by:
2025/02/05 21:30:52,stdout,
2025/02/05 21:30:52,stdout,2025-02-05 21:30:52.204 [error] Could not create schema migrations table. This error usually happens due to the following:

Screenshots

No response

Additional data

No response

Type of installation

Docker

Version

1.32.0

[JakobLichterfeld]

Thanks for reporting, I'm not able to reproduce your issue. May I ask you to share your exact commands? Pleae ensure you really use https://docs.teslamate.org/docs/maintenance/backup_restore and ensure copying everything including .

[bcrooker]

Many times, yes. I have almost 6 years of data in my install (3-4 years of running Teslamate, plus import of TeslaFi data from around May 2019), not sure how much that has to do with it.

I finally got it to successfully start yesterday by setting DATABASE_POOL_SIZE=150 in the Teslamate container, and set the following in the Postgres postgresql.conf file:

max_connections = 200

[JakobLichterfeld]

I finally got it to successfully start yesterday by setting DATABASE_POOL_SIZE=150 in the Teslamate container, and set the following in the Postgres postgresql.conf file:

max_connections = 200

Glad you solved your issue.
May I ask on which host you are running? Perhaps this only happens on potent HW.

[bcrooker]

I think what I did was more of a bandaid, not a fix. Running this on an Synology RS1221+.