Laradockがv5.5.2になって、MySQL8.0対応になってしまったため、なんだか色々トラブる
ということで、先日投稿した以下でもv5.5.1でタグ指定してgit cloneするような記載に変えましたが、一度、v5.5.2でdocker-compose upしてしまうと内部的に持っているデータの一部がMySQL8.0形式になってしまい、v5.5.1に戻しても、MySQLが起動してこないです。
で、この問題に遭遇した際、docker-compose logsを実行してログを確認したところ、以下のようなエラーが出ていたので原因は分かったものの... どう対処すれば良いかがわからず、ググりまくり
mysql_1 | 2017-07-19T15:35:24.694417Z 0 [ERROR] InnoDB: Unsupported redo log format. The redo log was created with MySQL 8.0.1. Please follow the instructions at http://dev.mysql.com/doc/refman/5.7/en/upgrading-downgrading.html
mysql_1 | 2017-07-19T15:35:24.694473Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
mysql_1 | 2017-07-19T15:35:25.296412Z 0 [ERROR] Plugin 'InnoDB' init function returned error.
mysql_1 | 2017-07-19T15:35:25.296496Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
mysql_1 | 2017-07-19T15:35:25.296521Z 0 [ERROR] Failed to initialize plugins.
mysql_1 | 2017-07-19T15:35:25.296535Z 0 [ERROR] Aborting
mysql_1 |
mysql_1 | 2017-07-19T15:35:25.296593Z 0 [Note] Binlog end
mysql_1 | 2017-07-19T15:35:25.296717Z 0 [Note] Shutting down plugin 'CSV'
mysql_1 | 2017-07-19T15:35:25.301788Z 0 [Note] mysqld: Shutdown complete
でも、なかなか直接的な解決方法が見つからず...
GitHubのlaradockのIssueを覗いて見たら、同様の事象で困っている人を発見
冷静に考えれば、redo logってことはmysql自体のデータに起因していることには気づきそうなので、あとは、Laradockの設定を辿っていければ、いずれは解決できただろうけれど...
後、先ほど、別のQiitaの記事からリンクされていることに気づいて、おそらく、似たような原因ではないかと思われる人が、データ削除して復旧できたとの投稿を見つけた。
Laradockの場合、複数のインスタンスを使い分けるような場合、データファイルが共有されるってことになりそう... だとすると、コレ、.envでのDATA_SAVE_PATH=~/.laradock/dataの指定は、インスタンスごとに別れるようにした方が良さそう