Docker Desktop Mac 3.0.0 にアップデートで起動しなくなって対応した後、mysqlが動かない時の対応

> 2020/12/15追記 
> 喜び勇んで 3.0 にアップデート→問題があって、本件を書いたわけですが、複数プロジェクトの開発を進めて行くと、どうも不安定です・・・
> なので、ver. 2.5 にダウングレードすることにしました・・・
> 奇しくもダウングレードの方法は [この記事のダウングレード](https://qiita.com/shibomb/items/34fe78233a2bd0bf7338#1docker-desktop-%E3%82%92%E3%83%80%E3%82%A6%E3%83%B3%E3%82%B0%E3%83%AC%E3%83%BC%E3%83%89) に書いていたのですんなりできました ＼(^o^)／


前回の記事「[Docker Desktop Mac 3.0.0 にアップデートしたら、起動しなくなった時の対応](https://qiita.com/shibomb/items/1b9e63f54900bc82a5a2)」の続きです。
mysqlが永久起動失敗ループに・・・

#現象
下記のようなログを出力しながら、mysqlが起動→失敗→再起動を繰り返しています。

```
mysql             | 2020-12-11 14:28:26+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
mysql             | 2020-12-11 14:28:26+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.21-1debian10 started.
mysql             | 2020-12-11T14:28:26.491369Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.21) starting as process 1
mysql             | 2020-12-11T14:28:26.508161Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
mysql             | 2020-12-11T14:28:27.034000Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
mysql             | 2020-12-11T14:28:27.040556Z 1 [ERROR] [MY-011087] [Server] Different lower_case_table_names settings for server ('0') and data dictionary ('2').
mysql             | 2020-12-11T14:28:27.040839Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
mysql             | 2020-12-11T14:28:27.041084Z 0 [ERROR] [MY-010119] [Server] Aborting
mysql             | 2020-12-11T14:28:27.601939Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.21)  MySQL Community Server - GPL.
```

#stack overflow に同様の現象を発見
[Mysql not starting in a docker container on MacOS after docker update](
https://stackoverflow.com/questions/64146845/mysql-not-starting-in-a-docker-container-on-macos-after-docker-update)
mysqlのデータディレクトリをホストのvolumesに指定していると、この状況になるのでしょうか。
2.3 から 2.4 にUpdateしたときに発生していた模様です。
今回現象が出ている環境は2.5で新規作成した環境ですから、初めて出くわしたのですね・・・
（埋蔵している過去のプロジェクトを復活することになった時、これが発生するのか・・・）

#対応方法
stack overflowの記事の１つ目の回答の方法はダメでした。
２つ目の方法でやってみます。
**要するに、Dockerのバージョン戻して、データ救出セヨ！です^^**

##1.Docker Desktop をダウングレード
###1) ver. 3.0.0 をUninstall
Docker Desktop > 設定 > 右上の虫っぽいマーク > Uninstall

###2) ver. 2.5.0.0 をインストール
[Docker for Mac release notes](https://docs.docker.com/docker-for-mac/release-notes/)の [2.5.0.0](https://desktop.docker.com/mac/stable/49427/Docker.dmg)をダウンロードして、インストール。
_※2.5.0.1のDownloadリンクのものは「最新版dmg」へのリンクなので、3.0.0でした・・・直しておいてほしいですね；_

##2.User gRPC FUSE for file sharing を オン
Dockerを起動して、バージョンが3.0.0でないことを確認し、
メニュー Docker Desktop > 設定 > Experimental Features の
User gRPC FUSE for file sharing を **オン** になっていることを確認

##3.docker-compose up
無事、起動しました！
(って、このまま3.0.0にアップデートせずに使えば良いのでは・・・と悪魔が囁いたのですが、本記事と前回記事の意味がなくなりますので、頑張ってみようと思います。）

##4.DBダンプ
どんな手段でも良いので、mysqlのDBダンプをとりましょう

##5.docker-compose stop
止めます

##6.mysqlのデータディレクトリを削除
mysqlコンテナ起動時に再作成してくれるそうです。
_※僕は、念の為、renameにしましたが^^_

##7.Docker Desktop 3.0.0 にアップグレード
Docker Desktop > Check for Updates... が手っ取り早いですね。

##8.Docker Desktop 起動
_アップデート後にStartingのまま起動しない場合は、Docker Desktop > 設定 > 右上の虫っぽいマーク > Uninstall をした後、 ver. 3.0.0をダウンロードして再インストールしてみてください。_

##9.User gRPC FUSE for file sharing を オフ に設定
メニュー Docker Desktop > 設定 > Experimental Features の
User gRPC FUSE for file sharing を **オフ** に再度設定します

##10.docker-compose up
無事、起動しましたか？

##11.DBダンプからデータ復旧
どんな手段でも良いので、4のダンプでデータを復旧しましょう

#今後は・・・
Volumeはコンテナのを使うことにします。
いま思えば、なぜホストのVolumeを割り当てていたのだろうか・・・

---
追記：
> いま思えば、なぜホストのVolumeを割り当てていたのだろうか・・・

これ、Laradockの標準がこうなっていたから、オリジナルでdocker-compose.ymlを書くときに参考にしたのでした。
全世界のMacでLaradock使いの方々が阿鼻叫喚ってことですか！？

個人的に他にも該当プロジェクトが多数あります・・・
これはやはり2.5に戻s...うぅん、なんでもないです。