MySQL error on restarting containers

General Discussions General
1

I just made a rookie error and have lost access to a Wordpress site I was building locally. So, I had docker running locally just fine, installed Wordpress using a yml file and proceeded to build the site. All good. Then in a ham fisted attempt to synch with the repo, I stopped all containers, removed all containers and moved all the Wordpress files into a new folder. I ran docker-compose up -d again. Luckily, docker created an entirely new Wordpress install. I realised this when I went to login to the Wordpress admin area and was presented with the usual Wordpress setup page.

Realising the error. I stopped the new containers and removed them. I then put the new Wordpress files out of the way and restored the original Wordpress files to their original location. I re-ran docker-compose up -d but now have a database connection error. Seeing the mysql container was continuously restarting I checked the logs. This is what I see repeated each restart:

2019-11-22 10:27:09+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.28-1debian9 started.

2019-11-22 10:27:09+00:00 [Note] [Entrypoint]: Switching to dedicated user ‘mysql’

2019-11-22 10:27:09+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.28-1debian9 started.

2019-11-22T10:27:10.045251Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).

2019-11-22T10:27:10.054173Z 0 [Note] mysqld (mysqld 5.7.28) starting as process 1 …

2019-11-22T10:27:10.065320Z 0 [Warning] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive

2019-11-22T10:27:10.069116Z 0 [Note] InnoDB: PUNCH HOLE support available

2019-11-22T10:27:10.069590Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins

2019-11-22T10:27:10.069653Z 0 [Note] InnoDB: Uses event mutexes

2019-11-22T10:27:10.069713Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier

2019-11-22T10:27:10.069766Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11

2019-11-22T10:27:10.069817Z 0 [Note] InnoDB: Using Linux native AIO

2019-11-22T10:27:10.070242Z 0 [Note] InnoDB: Number of pools: 1

2019-11-22T10:27:10.070579Z 0 [Note] InnoDB: Using CPU crc32 instructions

2019-11-22T10:27:10.072688Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M

2019-11-22T10:27:10.084431Z 0 [Note] InnoDB: Completed initialization of buffer pool

2019-11-22T10:27:10.087729Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().

2019-11-22T10:27:10.148591Z 0 [Note] InnoDB: Highest supported file format is Barracuda.

2019-11-22T10:27:10.176669Z 0 [ERROR] InnoDB: Ignoring the redo log due to missing MLOG_CHECKPOINT between the checkpoint 29919063 and the end 29919035.

2019-11-22T10:27:10.176796Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error

2019-11-22T10:27:10.788614Z 0 [ERROR] Plugin ‘InnoDB’ init function returned error.

2019-11-22T10:27:10.788948Z 0 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.

2019-11-22T10:27:10.789047Z 0 [ERROR] Failed to initialize builtin plugins.

2019-11-22T10:27:10.789119Z 0 [ERROR] Aborting

2019-11-22T10:27:10.789268Z 0 [Note] Binlog end

2019-11-22T10:27:10.789483Z 0 [Note] Shutting down plugin ‘CSV’

2019-11-22T10:27:10.793277Z 0 [Note] mysqld: Shutdown complete

Docker 2.1.0.5 on OSX 10.13.6 NGINX:latest MySql:5.7 Wordpress:latest

I’m a competent Docker novice, so this is a out of my area of expertise. I’ve lost a couple of days work, so would really appreciate some pointers. Thanks for reading!

2

The Wordpress content consists of some config files, the files under wp-content and the database. The actual content is in the database, not in the files. If you restored the original files, but not the original database then your installation is probably broken.
Not sure what docker-compose file you use. If you took the one from Wordpress on Dockerhub, then you have 2 volumes with persistent data, ‘wordpress’ for the files and ‘db’ for the MySQL database. You need backups of both of them to restore your site.

3

Thanks tekki - I fixed this, mostly. The issue was data corruption as detailed in this thread: https://github.com/drud/ddev/issues/748

To fix it I deleted the ib_logfiles as per this post (and others): https://dba.stackexchange.com/questions/163445/innodb-ignoring-the-redo-log-due-to-missing-mlog-checkpoint.

Here’s how I did it:

  • docker-compose run --rm db /bin/bash
  • this gives access to the container.
  • navigate to the folder where the files are. In my setup it was var/lib/mysql/
  • I then moved the files to trash, so I can recover them if need be
  • mv ib_logfile0 ~/.Trash
  • mv ib_logfile1 ~/.Trash

WARNING: some people report data loss. I have not, but I cannot edit or create new posts on my site, apart from the homepage. I’ve no idea what causes this. Rather than spending more time on it, I am going to deploy to production (for the first time) and see if the build there fixes the issue.

  1. List item
4

docker-compose file:

version: '3.3'

services:

   nginx:
image: nginx:latest
ports:
    - '80:80'
volumes:
    - ./nginx:/etc/nginx/conf.d
    - ./logs/nginx:/var/log/nginx
    - ./wordpress:/var/www/html
links:
    - wordpress
restart: always

   db:
 image: mysql:5.7
 volumes:
   - ./db_data:/var/lib/mysql
 restart: always
 environment:
   MYSQL_ROOT_PASSWORD: 3.*****
   MYSQL_DATABASE: ***** 
   MYSQL_USER: ***** 
   MYSQL_PASSWORD: *****

   wordpress:

 depends_on:
   - db
 image: wordpress:latest
 ports:
   - "8000:80"
 volumes:
   - ./wordpress:/var/www/html
 restart: always
 environment:
   WORDPRESS_DB_HOST: *****
   WORDPRESS_DB_USER: *****
   WORDPRESS_DB_PASSWORD: *****
   WORDPRESS_DB_NAME: *****