devilbox: Can't start mysql 5.6 after working on 5.7
ISSUE TYPE
- Bug Report
Checklist
-
.envfile is attached env.txt -
./check-config.shnot available on my devilbox version 1.6.2 -
docker-compose logsN/A -
docker-compose.override.ymlis attached (if exists) N/A - Custom configs from
cfg/dir are attached (if exist) N/A - I’ve looked through the docs: https://devilbox.readthedocs.io/en/latest/
- I’ve looked through existing issues: https://github.com/cytopia/devilbox/issues
- I’ve read troubleshooting: https://devilbox.readthedocs.io/en/latest/support/troubleshooting.html
OS / ENVIRONMENT
- Host operating system and version: Windows 10 Pro
- (Windows only) Native Docker or Docker Toolbox: Native Docker
- Docker version: 2.3.0.3
- Docker Compose version: 1.25.5
- (Linux) Is SELinux enabled?:
- What git commit hash are you on?:
- devilbox version 1.6.2
SUMMARY
I worked without issues for months with mysql 5.6. I switched for a single project to mysql 5.7. Now I can start 5.7 but cannot start again 5.6 (even if I stop, kill images and restart docker)… it seems that 5.6 and 5.7 are somehow merged (and the mysql5.7 log directory is missing). The log on starting is this:
Attaching to devilbox_mysql_1
mysql_1 | 2021-01-05 16:46:46+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.6.46-1debian9 started.
mysql_1 | 2021-01-05 16:46:46+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
mysql_1 | 2021-01-05 16:46:46+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.6.46-1debian9 started.
mysql_1 | 2021-01-05 16:46:46 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
mysql_1 | 2021-01-05 16:46:46 0 [Note] mysqld (mysqld 5.6.46) starting as process 1 ...
mysql_1 | 2021-01-05 16:46:46 1 [Note] Plugin 'FEDERATED' is disabled.
mysql_1 | 2021-01-05 16:46:46 1 [Note] InnoDB: Using atomics to ref count buffer pool pages
mysql_1 | 2021-01-05 16:46:46 1 [Note] InnoDB: The InnoDB memory heap is disabled
mysql_1 | 2021-01-05 16:46:46 1 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
mysql_1 | 2021-01-05 16:46:46 1 [Note] InnoDB: Memory barrier is not used
mysql_1 | 2021-01-05 16:46:46 1 [Note] InnoDB: Compressed tables use zlib 1.2.11
mysql_1 | 2021-01-05 16:46:46 1 [Note] InnoDB: Using Linux native AIO
mysql_1 | 2021-01-05 16:46:46 1 [Note] InnoDB: Using CPU crc32 instructions
mysql_1 | 2021-01-05 16:46:46 1 [Note] InnoDB: Initializing buffer pool, size = 128.0M
mysql_1 | 2021-01-05 16:46:46 1 [Note] InnoDB: Completed initialization of buffer pool
mysql_1 | 2021-01-05 16:46:46 1 [Note] InnoDB: Highest supported file format is Barracuda.
mysql_1 | InnoDB: No valid checkpoint found.
mysql_1 | InnoDB: If you are attempting downgrade from MySQL 5.7.9 or later,
mysql_1 | InnoDB: please refer to http://dev.mysql.com/doc/refman/5.6/en/upgrading-downgrading.html
mysql_1 | InnoDB: If this error appears when you are creating an InnoDB database,
mysql_1 | InnoDB: the problem may be that during an earlier attempt you managed
mysql_1 | InnoDB: to create the InnoDB data files, but log file creation failed.
mysql_1 | InnoDB: If that is the case, please refer to
mysql_1 | InnoDB: http://dev.mysql.com/doc/refman/5.6/en/error-creating-innodb.html
mysql_1 | 2021-01-05 16:46:46 1 [ERROR] Plugin 'InnoDB' init function returned error.
mysql_1 | 2021-01-05 16:46:46 1 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
mysql_1 | 2021-01-05 16:46:46 1 [ERROR] Unknown/unsupported storage engine: InnoDB
mysql_1 | 2021-01-05 16:46:46 1 [ERROR] Aborting
mysql_1 |
mysql_1 | 2021-01-05 16:46:46 1 [Note] Binlog end
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'partition'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'PERFORMANCE_SCHEMA'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_SYS_DATAFILES'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_SYS_TABLESPACES'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_SYS_FOREIGN_COLS'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_SYS_FOREIGN'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_SYS_FIELDS'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_SYS_COLUMNS'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_SYS_INDEXES'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_SYS_TABLESTATS'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_SYS_TABLES'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_FT_INDEX_TABLE'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_FT_INDEX_CACHE'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_FT_CONFIG'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_FT_BEING_DELETED'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_FT_DELETED'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_FT_DEFAULT_STOPWORD'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_METRICS'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_BUFFER_POOL_STATS'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_BUFFER_PAGE_LRU'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_BUFFER_PAGE'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_CMP_PER_INDEX_RESET'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_CMP_PER_INDEX'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_CMPMEM_RESET'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_CMPMEM'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_CMP_RESET'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_CMP'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_LOCK_WAITS'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_LOCKS'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'INNODB_TRX'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'BLACKHOLE'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'ARCHIVE'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'MRG_MYISAM'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'MyISAM'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'MEMORY'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'CSV'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'sha256_password'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'mysql_old_password'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'mysql_native_password'
mysql_1 | 2021-01-05 16:46:46 1 [Note] Shutting down plugin 'binlog'
mysql_1 | 2021-01-05 16:46:46 1 [Note] mysqld: Shutdown complete
mysql_1 |
devilbox_mysql_1 exited with code 1
I read this link https://dev.mysql.com/doc/refman/5.6/en/error-creating-innodb.html but didn’t get how it could help me.
My main issue is that I have ~20 dbs on 5.6 which I would like to recover and dump, but since I cannot start the image I cannot do it. Is there a way to do it manually in such a situation? After recovering the dbs I can for sure upgrade everything (docker, devilbox and so on), but I really need to dump all the databases with no loss of data.
Thanks for any help.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 19 (8 by maintainers)
The solution is to fisically move the file form /var/lib/docker/volumes/devilbox_devilbox-mysql-5.6/_data/myDataBaseNameDirectory to /var/lib/docker/volumes/devilbox_devilbox-mysql-X.X/_data
Glad to hear. And do use the backup function on a regular base, this way you can always just destroy stuff and start from scratch easily if something breaks.
I will go ahead and document this behaviour so that everyone is aware.
Good troubleshooting!
I can confirm that it works. and using
stopandrm-favoid the problem of the unwanted auto upgrade of the data. Thanks again @cytopia !Glad to hear 😃 Pretty sure this issue will persist if you do not do a
docker-compose rm -fbefore switching container version with volumes (mysql, postgres).I managed to recover everything. It took me quite some time since I decided to move forward and do many upgrades I had in my list… windows, docker, wsl2 and finally devilbox. Now everything is updated to last version. I just restored a couple of databases and they work fine with mysql5.6.
Do you think the behavior I encountered was related to my old version of devilbox/docker, or the issue would persist also in the current versions?
Thanks a lot for your help and great work!