问题

昨天下午本来要去吃下午茶,然后前端小伙伴突然说接口怎么崩了,我登上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的管理方式还是比较原始,是不是要找机会上更现代化的容器管理方式?

参考资料

作者:|程序设计实验室|,原文链接: https://www.cnblogs.com/deali/p/16314219.html

文章推荐

ElasticSearch7.3学习(三十)----ES7.X SQL新特性解析及使用J...

shell脚本获取文件名字

Java开发学习(二)----IOC、DI入门案例

程序分析与优化 - 5 指针分析

Unity-自定义事件派发器的两次尝试

聊聊C#中的Mixin

关于线段树基础

Spring Cloud OpenFeign 的 5 个优化小技巧!

CoaXPress 线缆和接插件的设计要求

一个测试记录:利用分段锁来处理并发情况下的资源竞争问题

go-micro集成链路跟踪的方法和中间件原理

Blazor和Vue对比学习(基础1.9):表单输入绑定和验证,VeeV...