Docker 小记 — MySQL 与 Redis 配置

前言

本篇随笔是继 “Docker Engine”“Compose & Swarm” 之后的一个实例补充,初衷是记录测试环境中的一次 MySQL 事故,就当做 “Docker 系列” 的一个小收尾吧。其实在生产环境中不推荐使用 Docker 部署 MySQL 和 Redis,那可是 The First Domino,倒一个挂一片呀,不过在本地和测试环境中就随意了。

1. 部署准备

一般部署这些 db_service 容器都应该配套其管理工具(我不否认可以通过命令行完成所有的操作,而且功能更多,权限更大,但是非 DBA 的童鞋还是乖乖使用 UI 吧,耍酷浪费太多时间也不值当?),因此,这里我选择的镜像组合是 mysql、adminer 与 redis、erikdubbelboer/phpredisadmin。

Ps:这节太短了,就插一些题外话吧。现在爽 Docker 的同时其实也在为过去的自己默哀,想当年初入编程的时候还没普及云服务器和各种打包好的云服务方案,当然也没有 Docker,想做点什么实验和测试都得在本机。本本性能不行还得一天到晚折腾各种安装环境,就拿 db_service 来说吧,当时选择的是 SQL Server,流行的版本是 05、08 和 08 r2 等,客户要求啥版本的都有。那开发的时候得在本地装呀,要命的是这家伙根本无法彻底卸载,版本之间还有兼容问题,啥错误都遇到过,解决不了最后的终极方案就是重装系统,然后呢... 还得再装呀... 这一下子就是半天到一天的时间。使用虚拟机吧,打开几个 IDE 再启动几个虚拟机,不要说那时候了,就是现在的主流机也扛不动呀,编程体验几乎为零。这里算是忆苦思甜了,想想那时候,现在简直太幸福了。

2. 配置

adminer 与 phpredisadmin 都可以在集群内访问需要代理的服务,如果是在服务器上也不用额外暴露 3306 和 6379 端口,以下是我的 docker-compose 配置:

MySQL

mysql:
  image: mysql
  networks:
    - proxy
    - youclk
  volumes:
    - /mnt/nas/db/mysql:/var/lib/mysql
  environment:
    MYSQL_ROOT_PASSWORD: db_password
  deploy:
    restart_policy:
      condition: any
      max_attempts: 3
    update_config:
      delay: 5s
      order: start-first
    resources:
      limits:
        cpus: '0.50'
        memory: 1g
mysql_admin:
  image: adminer
  networks:
    - proxy
    - youclk
  depends_on:
    - mysql
  deploy:
    labels:
      - com.df.notify=true
      - com.df.port=8080
      - com.df.serviceDomain=mysql.youclk.com
    restart_policy:
      condition: any
      max_attempts: 3
    update_config:
      delay: 5s
      order: start-first
    resources:
      limits:
        cpus: '0.50'
        memory: 1g

启动后 UI 展示如下:

Redis

redis:
  image: redis
  networks:
    - proxy
    - youclk
  deploy:
    restart_policy:
      condition: any
      max_attempts: 3
    update_config:
      delay: 5s
      order: start-first
    resources:
      limits:
        cpus: '0.50'
        memory: 1g
redis_admin:
  image: erikdubbelboer/phpredisadmin
  networks:
    - proxy
    - youclk
  environment:
    - REDIS_1_HOST=redis
    - REDIS_1_NAME=redis
  depends_on:
    - redis
  deploy:
    labels:
      - com.df.notify=true
      - com.df.port=80
      - com.df.serviceDomain=redis.youclk.com
    restart_policy:
      condition: any
      max_attempts: 3
    update_config:
      delay: 5s
      order: start-first
    resources:
      limits:
        cpus: '0.50'
        memory: 1g

启动后 UI 展示如下:

如果看过我之前的两篇博文或者对 Compose 有一定了解的话,以上参数一目了然,此处不做过多赘述。

但如果是部署在本地的话,各种 db_service 工具或者是集群外的其他服务也可能需要连接 db,所以得暴露其各自的端口,我倾向于再编写一个 docker-compose.local.yml ,用于放置本地配置,如下:

version: '3.5'
services:

  mysql:
    ports:
      - 3306:3306
    volumes:
      - /Users/Jermey/Documents/data/db/mysql:/var/lib/mysql
  mysql_admin:
    deploy:
      labels:
        - com.df.notify=true
        - com.df.port=8080
        - com.df.serviceDomain=local-mysql.youclk.com

  redis:
    ports:
      - 6379:6379
  redis_admin:
    deploy:
      labels:
        - com.df.notify=true
        - com.df.port=80
        - com.df.serviceDomain=local-redis.youclk.com

然后再编写一个启动脚本,根据当前的系统环境判断是否合并多个配置文件(我的写法比较粗暴,若有更优雅的方案欢迎留言交流):

if [ -z "`uname -a | grep 'Linux'`" ];then
    docker-compose -f ../src/docker-compose.yml \
        -f ../src/docker-compose.local.yml \
        config > docker-stack.yml
    docker stack deploy -c docker-stack.yml --with-registry-auth db
else
    docker stack deploy -c ../src/docker-compose.yml --with-registry-auth db
fi

3. MySQL 异常事故记录

开门见山先说结果吧,最后确认是导致异常的原因是使用 NFS 存储 MySQL 的数据。起初服务一直能非常稳定在我本地的集群中运行,但在测试服务器上却时不时突然挂掉且无法重启,开始的时候一头雾水,本地和测试环境的配置文件完全一致呀,而且都是 Docker Swarm 集群,不应该有任何系统因素相关的干扰。而且它不是启动过后立马会挂,而是运行一段时间之后,期间我发了疯地去排除一个个可能导致 MySQL 宕机的其他服务,而因 NFS 能够正常挂载却被我最先排除(期间的心塞程度有 BUG 经历的工友应当能理解)。

直到我在 MySQL 官网看到了这则申明:

Caution is advised when considering using NFS with MySQL. Potential issues, which vary by operating system and NFS version, include:

  • MySQL data and log files placed on NFS volumes becoming locked and unavailable for use. Locking issues may occur in cases where multiple instances of MySQL access the same data directory or where MySQL is shut down improperly, due to a power outage, for example. NFS version 4 addresses underlying locking issues with the introduction of advisory and lease-based locking. However, sharing a data directory among MySQL instances is not recommended.
  • Data inconsistencies introduced due to messages received out of order or lost network traffic. To avoid this issue, use TCP with hard and intr mount options.
  • Maximum file size limitations. NFS Version 2 clients can only access the lowest 2GB of a file (signed 32 bit offset). NFS Version 3 clients support larger files (up to 64 bit offsets). The maximum supported file size also depends on the local file system of the NFS server.

Using NFS within a professional SAN environment or other storage system tends to offer greater reliability than using NFS outside of such an environment. However, NFS within a SAN environment may be slower than directly attached or bus-attached non-rotational storage.

If you choose to use NFS, NFS Version 4 or later is recommended, as is testing your NFS setup thoroughly before deploying into a production environment.

官方文档非常直白地警告 NFS 有风险,使用需谨慎。这下总算松了一口气,终于知道问题源头了,反正是测试环境,随便指定 MySQL 挂载集群中一个节点的目录就行。但不死心的我又尝试了下先将 NFS 挂载到主机,然后由 MySQL 容器再去挂载已经挂载了 NFS 的主机目录,现在是已经正常运行好几天了没有再宕机。

Ps:可以将挂载的命令写入初始配置脚本,新服务器到手之后只需执行一行代码就可以愉快地玩耍了,有兴趣可以看我这篇随笔:“Ubuntu 自动化配置”

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Debian社区

Ubuntu Server自18.04 LTS开始不再提供32位镜像

2016年6月份Canonical公司在社区公布的草案,明确自Ubuntu 16.10开始逐步放弃32位支持,并在Ubuntu 18.10中彻底移除对32位架构...

1284
来自专栏JAVA高级架构

一个分布式服务器集群架构方案

4722
来自专栏大魏分享(微信公众号:david-share)

Openshift3.9高可用部署考虑点1

一个典型的OCP高可用架构是:master至少应为三个,且为奇数个(上面有etcd);

2654
来自专栏腾讯移动品质中心TMQ的专栏

像 google 一样测试系列之五:流程与覆盖率篇

有了用例,还需持续跑起来,并能有覆盖率。如何让 Local Unit Tests和Instrumented Tests 都支持脚本执行?

2161
来自专栏IT技术精选文摘

微服务部署策略的选择

动机 部署单体应用程序意味着运行多个通常是单个大型应用程序的相同副本。您通常会提供N个服务器(物理或虚拟)并在每个服务器上运行M个应用程序的实例。部署单体应用程...

2297
来自专栏Jerry的SAP技术分享

C4C Product Price List的模型中和有效期相关的两个字段

SAP C4C的price list实例可以在工作中心Products,视图Price Lists里看到。

1557

教你快速安装OpenShift容器平台3.6

自OpenShift容器平台(OCP)发布以来,我一直希望提供一个简单、完整且易用的安装教程。

43010
来自专栏CSDN技术头条

运用Kubernetes进行分布式负载测试

本文为CSDN原创编译文章,禁止转载。 负载测试是开发后台基础架构的重要一环,它不但能够演示系统在真实需求面前的性能表现,还可以通过模拟用户与设备行为,在应用程...

2136
来自专栏SDNLAB

基于Linux Network Namespace的Mininet架构分析

Mininet作为一个轻量级的SDN仿真工具,在其系统实现架构中充分利用了Linux命名空间内核技术,其中Linux Network Namespace机制更是...

4246
来自专栏杨建荣的学习笔记

海量数据迁移之一个误操作的问题总结(r3笔记第21天)

在生产环境中的数据迁移还是很惊心动魄的,毕竟生产的数据不容许有任何潜在的问题,很小的问题也可能导致业务的终端,这个时候dba的角色是很重要的,如果dba犯了一个...

3397

扫码关注云+社区

领取腾讯云代金券