learning-cloud-native-go/myapp

MySQL fails to launch

kstenerud opened this issue · 4 comments

$ docker-compose up
Starting myapp_db_1 ... done
Starting myapp_app_1 ... done
Attaching to myapp_db_1, myapp_app_1
db_1   | [i] mysqld already present, skipping creation
db_1   | [i] MySQL data directory not found, creating initial DBs
db_1   | 2020-03-20  9:40:12 0 [ERROR] InnoDB: The Auto-extending innodb_system data file './ibdata1' is of a different size 0 pages than specified in the .cnf file: initial 768 pages, max 0 (relevant if non-zero) pages!
db_1   | 2020-03-20  9:40:12 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
app_1  | ERROR 2002 (HY000): Can't connect to MySQL server on 'db' (115)
app_1  | MySQL is unavailable - sleeping
db_1   | 2020-03-20  9:40:14 0 [ERROR] Plugin 'InnoDB' init function returned error.
db_1   | 2020-03-20  9:40:14 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
db_1   | 2020-03-20  9:40:14 0 [ERROR] Unknown/unsupported storage engine: InnoDB
db_1   | 2020-03-20  9:40:14 0 [ERROR] Aborting

It does this a few times, then repeats this message until stopped:

app_1  | ERROR 2002 (HY000): Can't connect to MySQL server on 'db' (115)
app_1  | MySQL is unavailable - sleeping
app_1  | ERROR 2002 (HY000): Can't connect to MySQL server on 'db' (115)
app_1  | MySQL is unavailable - sleeping
app_1  | ERROR 2002 (HY000): Can't connect to MySQL server on 'db' (115)
app_1  | MySQL is unavailable - sleeping

Run docker-compose down every time before up. But this will clear the data in the local DB.

Usually in production env, we are maintaining the DB separately and assume that it's up always. So, for production use a separate docker-compose.yml which having only app service
with dockerfile: docker/app/prod.Dockerfile. Also in production env, better not to run migrations every time app starts. Just run the main binary.

Also better use multistage builds only on production. So, you can reduce some build time in dev env.

@kstenerud I've added separate docker files for dev and production.

  • We use a local DB only on dev env, so we always start work on a fresh DB every time. So this is a design decision.
  • On production env usually we mange the database separately via Google Cloud SQL or Amazon RDS.

So dev time,
Run docker-compose down every time before up.

Also you can see initial Kubernetes files in https://github.com/learning-cloud-native-go/myapp/tree/k8s/k8s if you are planning to use k8s cluster env for production.

@kstenerud You may like this addition ; 5f0545d