问题
昨天下午本来要去吃下午茶，然后前端小伙伴突然说接口怎么崩了，我登上sentry一看，报错了
(2005, "Unknown MySQL server host 'mysql' (-3)")
啥意思啊，连不上数据库，host是mysql因为这是在docker环境里.
直接ssh连上服务器查看，没啥问题呀，MySQL容器也正常运行着
奇怪
然后我重启了一波docker，结果发现MySQL容器没有正常重启？
手动docker stop一下，再重新docker compose up
结果寄了，服务恢复起来后MySQL数据全没了……
找原因
慌还是有点慌的，毕竟是生产数据，但我心里也明白数据不可能凭空消失，MySQL作为成熟的商用数据库，不可能犯这种低级错误，那问题八成就出在我们自己身上了…
果然，之前使用docker-compose编排容器的时候偷懒，没有给MySQL容器加上volume映射
现在强制stop的时候没有先commit，所以就导致容器数据“丢失”
我这里用了双引号，因为数据也并没有真正丢失，而是变成了一个orphan volume，（没人引用的卷？）
解决
那么情况就清楚了，现在我找到之前MySQL容器用到的这个volume，把里面的数据文件提取出来重新映射就好了
volume文件路径是/var/lib/docker/volumes/
里面有一堆volume文件夹，现在只能一个个慢慢看了
也可以执行du命令，根据大小来做一个预估
最终我找到了一个2.9G的目录，打开看到里面的数据就是MySQL的
那就好办了
cd到这个volume的目录中，把数据文件复制出来
cp -r _data /var/lib/mysql
然后修改之前的docker-compose.yml配置文件
version: "3"
services:
mysql:
image: daocloud.io/mysql
volumes:
- /var/lib/mysql:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=1234
expose:
- 3306
添加上volumes配置就好了~
重新启动容器
docker-compose up -V
我一开始不知道要加-V参数，映射了volume之后MySQL还一直没数据
后面看了文档才知道不加-V会一直使用原来的volume
小结
虽然是把数据给恢复起来了，但问题其实还没完全解决，到这里还留下一个疑问：一开始那个故障是怎么来的？MySQL容器为啥会莫名其妙无法连接？
这个问题暂时还不清楚，后续再看看binlog分析一下。
最后，这次出的故障带来几个教训
-
不要偷懒，volume一定要提前映射好 -
docker知识匮乏，一知半解，得系统学一下 -
docker-compose的管理方式还是比较原始，是不是要找机会上更现代化的容器管理方式？
参考资料
-
Docker mysql容器数据库丢失找回指北： http://i.lckiss.com/?p=4222
