Windows7环境下使用MySQL docker容器踩坑记

本文详述了使用Docker部署MySQL的具体步骤,包括拉取镜像、启动容器、解决持久化数据错误、配置文件调整及权限问题,最终实现稳定运行。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

首先先拉取一个MySQL镜像:docker pull mysql:5.7.22

启动mysql容器

docker run -it --name mysql -p 3306:3306 -v /dockerShare/mysql/data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=root -d mysql:5.7.22 --character-set-server=utf8 --collation-server=utf8_unicode_ci

把本地文件夹目录挂载到容器/var/lib/mysql下,用于持久化数据,但是直接这样挂载会报错提示:File ./ib_logfile101: 'aio write' returned OS error 122

原因如下:

于是想使用外挂配置,去修改mysql的配置文件,官网的方法如下:

https://hub.docker.com/_/mysql/

但是,报错:Warning: World-writable config file ‘/etc/my.cnf’ is ignored

原因:

‘/etc/my.cnf’ is ignored ,大概意思是权限全局可写,任何一个用户都可以写。mysql担心这种文件被其他用户恶意修改,所以忽略掉这个配置文件。导致无法进入,这也是mysql的安全机制之一。所以我们必须得改一些权限。设置其他用户不可写。

尝试修改文件权限:https://blog.youkuaiyun.com/yumushui/article/details/49124699,失败

 

下面是正确的解决方法:

思路:启动一个干净的mysql容器,然后进入该容器,在/etc/mysql/conf.d文件夹下新建一个配置文件,文件内容如下:

[mysqld]

innodb_use_native_aio=0

然后把容器保存成一个镜像,下次再次实例化该镜像的再挂载本地主机目录到容器里面。

步骤如下:

启动一个干净的mysql容器:

docker run --name mysql -e MYSQL_ROOT_PASSWORD=root -d --rm mysql:5.7.22

带MySQL容器完全启动后,进入容器:

docker exec -it some-mysql bash
cd /etc/mysql/conf.d
touch my-config.cnf
nano my-config.cnf

复制进去保存退出。

PS.

由于mysql镜像的精简,如果没有nano命令,可以用如下方法中的一种解决:

1.apt-get update更新软件源,然后apt-get install nano

2.

echo "[mysqld]" > my-config.cnf

追加第二行:echo "innodb_use_native_aio=0" >> my-config.cnf // 两个箭头是追加,一个箭头是覆盖

echo 如果没有目标文件,会输出到窗口,如果有目标文件,会写入文件

 

在文件夹/etc/mysql/conf.d下新增my-config.cnf后把容器保存成镜像:

docker commit some-mysql mymysql:5.7.22.1

再次启动mymysql镜像,并挂载本机目录文件夹:

docker run --name some-mysql -p 3307:3306 -v /dockerShare/mysql/data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=root -it --rm mymysql:5.7.22.1

没有再报错,查看mysql服务运行情况:

登录mysql客户端:

新建一个test数据库:

查看本地挂载的路径文件夹是否同步的MySQL数据:

至此,mysql容器算是成功运行了。

 

说明:

如果不需要对宿主机暴露端口,可以不指定-p参数,mysql内部默认分配3306端口

设置数据库默认的编码:--character-set-server=utf8

设置排序的编码:--collation-server=utf8_unicode_ci

代码如下:

docker run --name mysql -v /dockerShare/mysql/data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=root -it --rm mymysql:5.7.22.1 --character-set-server=utf8 --collation-server=utf8_unicode_ci

后台运行了mysql容器,进入mysql容器命令

docker exec -it <容器名> bash  

<think>嗯,用户这次的问题聚焦在实际生产环境使用大规模Docker和Kubernetes的具体场景。从对话历史看,用户已经对容器编排的基本概念有所了解,现在需要更落地的实践指导。 用户可能是个DevOps工程师或架构师,正在评估是否要引入Kubernetes。ta的提问方式很专业,直接锁定“生产环境”和“大规模”这两个关键维度,说明不是理论探讨而是面临实际决策。 我注意到用户引用的资料很有价值:引用[1]指出当容器数量增多时Docker原生管理会失效;引用[2]对比了Swarm和K8s的适用规模;引用[4]强调了K8s的自动化运维能力。这些恰好构成回答的底层逻辑链。 需要重点突出两个转折点:一是从“能用”到“好用”的体验转折(比如健康检查),二是从“手动”到“自动”的效率转折(比如滚动更新)。特别要强调K8s在故障场景下的价值,这是生产环境最关心的。 对于电商案例,应该用具体数字说话:比如“万级QPS”“毫秒级响应”这样的量化描述,比单纯说“高并发”更有说服力。AI训练案例则要突出GPU资源调度的特殊性。 最后的风险提示很重要,用户可能被K8s的优势吸引而忽略实施成本。要客观说明学习曲线和运维负担,特别是etcd维护、网络插件选择这些容易的点。</think>在实际生产环境中,以下场景通常需要大规模 Docker 部署并依赖 Kubernetes 进行容器编排管理,其核心需求源于**规模性、复杂性、可靠性**的突破临界点: --- ### 一、典型场景与需求分析 #### 1. **高并发微服务架构** - **场景特征**: 数百个微服务相互依赖(如电商系统包含订单、支付、库存等服务),需动态扩缩容应对流量高峰。 - **K8s 价值**: - 自动水平扩展(HPA):根据 CPU/内存或自定义指标自动增减 Pod 副本数[^1] - 服务网格集成(如 Istio):实现细粒度流量管理和服务熔断 ```yaml # HPA 配置示例 apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: order-service minReplicas: 3 maxReplicas: 100 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 ``` #### 2. **持续交付与滚动更新** - **场景特征**: 每日数十次生产环境发布,需零停机更新(如金融科技平台)。 - **K8s 实现**: - 滚动更新策略:分批替换 Pod,结合就绪探针(Readiness Probe)确保服务可用性 - 蓝绿部署/金丝雀发布:通过 Service 和 Ingress 精准控制流量分发[^4] ```yaml # 金丝雀发布配置片段 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "10%" # 10%流量导向新版本 ``` #### 3. **混合云与多云部署** - **场景特征**: 业务需跨 AWS/Azure/私有云部署,避免供应商锁定(如全球化 SaaS 应用)。 - **K8s 方案**: - 集群联邦(Kubefed):统一管理多个集群的部署策略 - 持久卷抽象(PV/PVC):解耦存储与基础设施,实现数据跨云迁移 #### 4. **有状态服务集群化** - **场景特征**: 分布式数据库(如 Cassandra)、消息队列(如 Kafka)需要稳定的网络标识和存储。 - **K8s 支撑能力**: - StatefulSet:保障 Pod 有序部署、唯一网络标识(PodName-{0..N}) - 持久化存储卷(PersistentVolume):数据生命周期独立于容器 ```mermaid graph LR A[StatefulSet] -->|创建| B[Pod-mysql-0] A -->|创建| C[Pod-mysql-1] B --> D[PV-mysql-0] C --> E[PV-mysql-1] ``` #### 5. **AI/大数据计算平台** - **场景特征**: 分布式训练任务(如 TensorFlow Job)需动态调度 GPU 资源。 - **K8s 创新点**: - 设备插件(Device Plugin):高效管理 GPU/FPGA 等异构资源 - 批处理调度(Kube-batch):优化 MPI/Spark 作业的资源抢占 --- ### 二、何时需引入 Kubernetes?关键决策指标 | 指标 | 临界点 | 纯 Docker 局限 | K8s 解决方案 | |---------------------|---------------------------|--------------------------|---------------------------| | **容器数量** | > 50 节点或 > 500 容器 | Swarm 扩展性不足[^2] | 多集群管理能力 | | **发布频率** | > 5 次/天 | 手动编排易出错 | 声明式部署策略 | | **故障恢复时间** | 要求 < 1 分钟 | 依赖外部监控脚本 | 自愈(Self-healing)机制 | | **资源利用率** | 服务器成本占比 > 30% | 静态分配导致浪费 | 动态装箱(Bin Packing) | | **多云需求** | 跨 ≥2 云平台 | 配置差异大 | 统一 API 抽象层 | --- ### 三、Kubernetes 的不可替代性体现 1. **声明式 API** 描述“期望状态”(如 Deployment 定义副本数),由控制器自动收敛现实状态,降低运维复杂度。 2. **算子生态(Operator Pattern)** 封装领域知识(如数据库备份/恢复),实现有状态应用的全生命周期管理。 3. **服务网格集成** 通过 Sidecar 代理(如 Envoy)实现微服务可观测性,无需修改业务代码。 > **典型案例**:某视频平台使用 K8s 管理 20,000+ 容器,高峰期自动扩展至 3000 节点,资源利用率提升 40%,版本发布耗时从小时级降至分钟级[^1]。 --- ### 四、风险提示(引入 Kubernetes 前需评估) - **学习曲线陡峭**:需掌握 Pod/Service/Ingress 等核心概念 - **运维复杂度**:etcd 集群维护、网络插件(CNI)调优挑战 - **资源开销**:控制平面组件消耗约 1-2 核 CPU/2GB 内存 > 对于中小规模(<50 节点),可考虑 Docker Swarm 或 Nomad;当突破规模临界点时,Kubernetes 的自动化能力将带来显著 ROI 提升[^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值