Docker部署MariaDB生产实践：从容器化到数据持久化与高可用

这几年数据库容器化已经不是什么新鲜话题了，但真正敢把生产环境的 MariaDB 跑在容器里的人，仍然比想象中少。原因倒也不难理解：数据库是有状态服务，跟无状态的 Nginx、Redis 不一样，数据丢了就是事故。我在实际项目中用 Docker 部署 MariaDB 也跑了三年多，从早期单机测试库到后来承载线上业务的主库，踩了不少坑，也总结出一套相对完整的部署路径。这篇就按我个人的落地顺序，从环境准备、镜像选型、一条命令快速起实例，到 docker-compose 生产化配置、备份恢复、性能调优和常见故障排查，完整走一遍，目标是让你看完之后能直接在自己的机器上复现一套可用环境。

1. 容器化部署 MariaDB：为什么我建议从容器开始

1.1 MariaDB 是什么，它和 MySQL 是什么关系

MariaDB 是 MySQL 的一个分支。2010 年 MySQL 被 Oracle 收购后，创始人 Monty 带着核心团队另起炉灶，基于当时 MySQL 5.5 的代码库发展出了 MariaDB。所以它天生就兼容 MySQL 的协议和大部分语法，很多公司从 MySQL 迁移到 MariaDB 基本不需要改业务代码。如果原本的代码里用了 MySQL 专属函数或者存储引擎，迁移时多做一轮回归测试就能覆盖大部分问题。

对我来说，MariaDB 的吸引力有几个：一是开源协议更宽松，不用担心版权风险；二是官方持续在性能上做打磨，比如 Aria、MyRocks 这些存储引擎；三是社区活跃度不低，版本迭代节奏稳定。更重要的是，MariaDB 在运维层面跟 MySQL 几乎同构，会用 MySQL 的 DBA 接手 MariaDB 没有太大学习成本。所以当你需要一套开源数据库做容器化部署时，MariaDB 是个很容易上手的选择。

1.2 容器化的价值：环境隔离、快速交付、版本可控

为什么要把 MariaDB 容器化？我自己的理由很实际。第一是环境隔离。以前要在不同机器上装 MariaDB，最怕的就是系统里已有 MySQL 或者老版本冲突，端口、目录、配置文件各种打架，容器直接把整个运行时环境打包起来，宿主机只需要有 Docker 引擎就行。第二是快速交付。一个docker run命令就能在几十秒内拉起来一个新的实例，配合自动化脚本，团队里任何人申请测试库，我可以直接下发一个容器，不用每次手工初始化。第三是版本可控。镜像 tag 把版本钉死，完全不会出现"测试环境是 10.6，生产环境是 11.4"这种版本漂移问题。升级时换个 tag 重新起容器即可，回滚也快。

不过容器化不是银弹。数据库这种有状态应用，容器化之后依然要面对数据持久化、网络连通、性能隔离这些问题，处理不好事故比物理机更难看。这篇文章的目的不是劝你无脑把所有库都塞进容器，而是告诉你怎么用容器安全地跑 MariaDB，把翻车的概率降到最低。适合的读者包括：想把 MariaDB 快速部署到本机的开发者、正在建设微服务基础设施的团队，以及所有打算用 docker-compose 或 Kubernetes 管理有状态服务的运维同学。

1.3 哪些场景别急着容器化

我也得说实话，不是所有场景都适合容器化。如果是一个已经跑了很久、负载极高、对 IO 延迟极其敏感的 MySQL 实例，迁移容器化前要考虑清楚。容器本身没有魔法，它只是进程、文件系统和网络命名空间的封装，性能上最多做到和裸机持平，IO 因为中间多了一层存储驱动反而可能变差。特别是那种单机 QPS 上千、数据库文件好几个 TB 的重负载系统，容器化带来的收益并不明显，运维复杂度还会上升。这种情况下我会建议优先优化架构，而不是折腾容器。

如果你只是想在本地快速跑一个开发库，或者要交付一套微服务环境，那容器化 MariaDB 完全够用。从我的项目经验看，开发、测试、预发环境用容器化非常顺手，生产环境只要把数据卷、健康检查、备份策略做好，也完全可行。接下来我按实操顺序展开，先解决环境准备和镜像问题。

2. 部署前准备：镜像选型与环境检查

2.1 MariaDB 官方镜像与版本策略

目前 MariaDB 官方在 Docker Hub 上有mariadb仓库，这是官方团队维护的镜像，优先选择它而不是第三方打包的镜像。第三方镜像虽然可能预装了一些插件，但你不知道它什么时候更新，也没法确认构建过程的可靠性。生产环境用官方镜像，至少能保证与官方发布的二进制保持一致，补丁更新也跟得上。

镜像 tag 的选择，我的建议是先看 LTS 版本。MariaDB 的版本发布大致分两类：长期支持版（LTS）和短周期创新版（Innovation）。比如 10.11 是 LTS，11.4 也是 LTS，而 11.5、11.6 这类是创新版，功能新但维护周期短。生产环境追求稳定，我倾向于使用mariadb:11.4这样的 LTS tag，等它发布后续补丁后，通过重新 pull 镜像来更新。如果是本地研究新特性，可以玩 11.x 创新版，但别轻易上生产。

实际拉取时，tag 可以写精确一点。比如mariadb:11.4.3表示完全固定的版本，mariadb:11.4表示同一系列内跟随最新补丁。我一般在生产用精确 tag，在测试环境用系列 tag，这样既能控制变更粒度，又能方便地收到安全修复。

2.2 宿主机环境检查清单

部署前先摸清宿主机的情况。我习惯先执行这几个命令：

docker --version # 检查 Docker 是否存在，当前版本是否过旧 systemctl status docker # 确认 Docker 服务是否是 active 状态 free -h df -h nproc # 了解内存、磁盘、CPU 资源，决定容器配额

内存和磁盘是数据库容器最容易忽视的瓶颈。MariaDB 的 InnoDB 缓冲池默认值在容器里通常很小，但如果你在生产环境跑，至少要保证宿主机内存不低于 4GB，磁盘有空闲空间用于数据卷和备份文件。同时确认一下磁盘类型是 SSD 还是 HDD，这直接决定 IO 延迟。我曾在 HDD 机器上跑测试库，写入性能慢得离谱，换成 SSD 之后提升非常明显。数据库对磁盘 IO 的敏感是天然存在的，容器化并不会改变这一点。

还有一个容易忽略的点：检查端口。3306 是 MariaDB 的默认端口，如果宿主机上已经跑了 MySQL 或者其他实例，要么停掉旧的，要么把容器的宿主端口改成 3307。我一般预先执行ss -lntp | grep 3306，避免起容器时端口冲突导致启动失败。

2.3 目录规划与权限准备

数据卷的规划虽然可以后补，但一开始就规划清楚能省掉后面很多痛苦。我推荐在宿主机上创建一个路径当作 MariaDB 的专用目录，比如/data/mariadb，下面再建两个子目录：

• /data/mariadb/conf：存放自定义的 MariaDB 配置文件
• /data/mariadb/data：存放真实的数据文件

如果你用 docker volume 管理数据，也可以完全交给 Docker 管理，但我个人更习惯 bind mount 到宿主机目录，原因后面会说。无论用哪种方式，数据文件都必须落在持久化存储上，不要把数据写进容器可写层——容器一旦重建，数据就全没了。这里提前提醒一下：MariaDB 容器内的 mysql 用户 UID 是 999，bind mount 目录的属主要设置为 999，否则容器启动时因为权限不足直接退出。具体命令是chown -R 999:999 /data/mariadb/data，这个坑我在第 5 章展开讲。

3. docker run 快速上手：一条命令把实例跑起来

3.1 基础部署命令与参数拆解

先把最简单的跑法给你，然后再逐项拆解参数。这条命令适合本地开发或者临时测试：

docker run -d \ --name mariadb-dev \ -p 3306:3306 \ -e MARIADB_ROOT_PASSWORD=YourStrongPassw0rd \ -e MARIADB_DATABASE=appdb \ -e MARIADB_USER=appuser \ -e MARIADB_PASSWORD=AppUserPassw0rd \ -v mariadb-data:/var/lib/mysql \ mariadb:11.4

参数一个一个说。-d表示后台运行容器，不加的话会直接占用当前终端。--name给容器起个管理用名字，方便后续docker start/stop/exec直接引用。-p 3306:3306把宿主机的 3306 端口映射到容器的 3306 端口，这样宿主机和局域网内其他机器都能通过宿主机IP:3306连接数据库。-e是环境变量，控制初始化时的密码和数据库设置。-v mariadb-data:/var/lib/mysql把数据卷挂载到容器内的数据目录，实现数据持久化。

注意这里用的是命名卷mariadb-data，不是 bind mount。命名卷的好处是 Docker 全权管理数据落盘位置，开发环境用起来很方便。数据位置可以用docker volume inspect mariadb-data查看，后续要备份时也需要知道卷的真实路径。

3.2 环境变量与初始化机制

MariaDB 官方镜像的初始化机制值得单独说。容器首次启动时，如果/var/lib/mysql目录是空的，entrypoint 脚本会执行以下动作：先初始化系统数据库，再根据环境变量创建用户和数据库，最后执行/docker-entrypoint-initdb.d目录下挂载进来的.sql或.sh脚本。这些初始化只会在数据目录为空时执行一次，之后数据目录已有内容就跳过。这个机制很重要，很多人误以为修改环境变量可以重置 root 密码，实际上重置密码必须手动进入容器操作，重新设置环境变量再重启容器并不会重复执行初始化。

可用的环境变量很多，常用的有：

还要注意，MariaDB 镜像中MYSQL_ROOT_PASSWORD这类 MySQL 兼容环境变量也依然可用，但官方推荐优先使用MARIADB_*命名，两者混用时以MARIADB_*优先。

3.3 连接验证与基本设置

容器跑起来以后，第一步验证它是否真的能连。我用两种方式检查：

# 方式一：进入容器内部用本机 socket 连接 docker exec -it mariadb-dev mariadb -uroot -p # 方式二：在宿主机上用 TCP 方式连接 mysql -h127.0.0.1 -P3306 -uappuser -pappdb

注意一个细节：容器内用mariadb客户端命令，宿主机上不一定装了 MariaDB 客户端。如果宿主机只装了 MySQL 客户端，用mysql命令连接基本兼容，因为协议一致。但容器里优先用mariadb命令，因为它读的是 MariaDB 自己的默认配置。

还有一些我每次部署都会顺手做的配置调整。比如字符集统一为 utf8mb4，避免中文乱码问题。方法是在启动参数里加--character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci。还有时区问题，加了-e TZ=Asia/Shanghai后，容器内默认时间为北京时间，否则默认是 UTC，比北京时间少 8 小时，写入的时间字段会让你怀疑人生。

4. docker-compose 落地：生产可用的编排方案

4.1 为什么单条命令不够用

docker run适合一次性启动，但真实项目里数据库要么配合应用容器一起编排，要么需要相对完整的配置管理。单条命令的问题在于：每次启动都要记一长串参数，漏一个就可能行为不一致；没有健康检查机制；配置文件和初始化脚本没法优雅管理。docker-compose（或者新版 Docker 自带的docker compose）可以把所有部署描述写进一个 YAML 文件，版本化管理、一键启动、一键停止，团队其他成员照抄就能复现环境。所以，如果你要把 MariaDB 纳入一套基础设施，compose 是最低门槛的正规化方式。

4.2 完整的 docker-compose.yml 解析

下面是我在生产环境中使用的 docker-compose 配置模板，去掉业务相关信息，保留核心结构：

services: mariadb: image: mariadb:11.4 container_name: mariadb-prod restart: unless-stopped environment: MARIADB_ROOT_PASSWORD: ${MARIADB_ROOT_PASSWORD} MARIADB_DATABASE: ${MARIADB_DATABASE} MARIADB_USER: ${MARIADB_USER} MARIADB_PASSWORD: ${MARIADB_PASSWORD} TZ: Asia/Shanghai ports: - "3306:3306" volumes: - /data/mariadb/data:/var/lib/mysql - /data/mariadb/conf:/etc/mysql/mariadb.conf.d - /data/mariadb/initdb:/docker-entrypoint-initdb.d command: - --character-set-server=utf8mb4 - --collation-server=utf8mb4_unicode_ci - --innodb-buffer-pool-size=2G - --max-connections=500 healthcheck: test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"] interval: 10s timeout: 5s retries: 5 deploy: resources: limits: memory: 4G cpus: '4'

这个文件里的几个设计点我单独解释一下。

restart: unless-stopped保证宿主机重启或容器异常退出时，Docker 服务会自动拉起容器，这是生产容器的基本保活策略。/etc/mysql/mariadb.conf.d是 MariaDB 镜像预留的自定义配置目录，镜像会把用户配置目录排在后面加载，从而覆盖默认配置。/docker-entrypoint-initdb.d挂载初始化脚本目录，作用在前面讲过了，首次启动时会执行里面的 SQL 或 shell 脚本，适合导入初始数据或创建分表。

环境变量我用${MARIADB_ROOT_PASSWORD}引用外部环境变量，而不是把明文密码直接写进 YAML。具体做法是在同目录下创建.env文件，内容类似：

MARIADB_ROOT_PASSWORD=YourStrongPassw0rd MARIADB_DATABASE=appdb MARIADB_USER=appuser MARIADB_PASSWORD=AppUserPassw0rd

docker compose会自动读取同目录.env文件，替换变量。这样密码不会进到代码仓库，也方便在不同环境里覆盖。

4.3 配置挂载与健康检查

配置文件和数据目录的权限是容易踩坑的地方。MariaDB 容器内的mysql用户 UID 是 999，如果 bind mount 的宿主机目录权限不是 999 或所属组不正确，容器启动时会因为无法写入数据目录而报错。我之前在 RHEL 系宿主机上遇到过，宿主机上的 999 UID 对应的是另一个系统用户，导致数据目录权限校验失败。解决办法是直接设置目录 owner 为 999，或者通过user: root让容器以 root 启动，但后者并不推荐，权限问题应该用正确的 owner 解决。

健康检查是 compose 中很值得加的内容。上面配置里用healthcheck.sh --connect --innodb_initialized，这是 MariaDB 镜像内置的脚本，会发起一个连接测试并检查 InnoDB 是否完成初始化。配合depends_on使用，可以让依赖数据库服务的容器等在数据库健康后才启动，解决"应用启动时数据库还没就绪"的经典问题。实测中，数据库初次初始化可能要 30 秒到 1 分钟，没有健康检查的话应用容器大概率会因连接失败而崩溃。

另外，日志轮转也建议在 compose 里直接配好，这个话题我在第 6 章展开。

5. 数据持久化、备份与恢复：容器化最不能偷懒的部分

5.1 数据卷挂载与权限踩坑记录

前面说过，数据必须放在卷或宿主机目录上，容器可写层绝不能存业务数据。实际使用 bind mount 时，有一个容易被忽略的点：MariaDB 容器启动时对数据目录的属主有严格检查，如果不是 uid/gid 999，会直接报错退出。日志里常见的错误类似chown: invalid user: 'mysql'或者Unable to write to /var/lib/mysql，就是这个原因。

如果目录权限改不过来，最简单的办法是先用chown -R 999:999 /data/mariadb/data强制修改属主。注意这个 999 是容器内 mysql 用户的 UID，和宿主机上的用户名没有关系。在数据目录已经有数据的情况下，通过chown修改属主有风险，建议在初始化之前就把权限设置正确，而不是等数据写入后再改。

还要提醒一下，CentOS/RHEL 上如果开了 SELinux，bind mount 时会遇到限制，导致容器无法写入数据文件。首次部署时如果一直报权限错误，可以执行getenforce确认 SELinux 状态，临时改到 Permissive 或者给挂载点加上:Z后缀，比如-v /data/mariadb/data:/var/lib/mysql:Z，让 Docker 自动调整 SELinux 标签。这个问题很多新手会卡很久，因为我一开始也以为是目录权限问题，后来才发现是 SELinux 拦截。

5.2 逻辑备份方案与自动化

备份是整个部署方案里最值得花时间的部分。容器化之后，备份通常有两条路线：逻辑备份和物理备份。

逻辑备份我用的是mariadb-dump，它是 mysqldump 的 MariaDB 版本。基本命令如下：

docker exec mariadb-prod mariadb-dump --all-databases -uroot -pYourPassw0rd > /data/backup/mariadb_all_$(date +%F).sql

注意这里是先进入容器执行 dump，然后把标准输出重定向到宿主机路径，所以备份文件直接落在宿主机磁盘上，不会因为容器生命周期而丢失。全库备份方便恢复，但数据量大了之后全量备份时间长、文件大，建议按库拆分备份，或者加--single-transaction --quick --routines --triggers参数保证一致性。--single-transaction依赖 InnoDB 事务特性，MariaDB 默认引擎就是 InnoDB，可以放心使用。

自动化方面，我通常写一个简单脚本配合 crontab：

#!/bin/bash BACKUP_DIR=/data/backup DATE=$(date +%Y%m%d_%H%M%S) mkdir -p $BACKUP_DIR docker exec mariadb-prod mariadb-dump --all-databases -uroot -p"MARIADB_ROOT_PASSWORD" | gzip > $BACKUP_DIR/mariadb_$DATE.sql.gz find $BACKUP_DIR -name "mariadb_*.sql.gz" -mtime +7 -delete

脚本核心是备份加保留七天策略，避免磁盘被历史备份撑爆。如果你不想在脚本里写明文密码，可以从.env文件读取，或者使用 MariaDB 的/root/.my.cnf配置文件，这都是常规做法。

5.3 物理备份与恢复演练

逻辑备份适合中小数据量的系统，到了几十 GB 以上，我建议用mariadb-backup（原 Percona XtraBackup 的 MariaDB 分支）做物理热备份。它直接拷贝数据文件，速度快，对业务影响小。容器里执行物理备份通常需要把备份目录也映射进来，或者直接宿主机执行备份工具，但要注意权限。物理备份的恢复流程比逻辑备份复杂，一般需要 prepare 步骤，不是简单的解压就能用。如果你对备份恢复的每一步还不熟悉，先拿测试环境模拟几次完整恢复，别等到灾难降临再临时找文档。

恢复逻辑备份就简单多了。先启动一个全新的空库容器，然后把 dump 文件导入：

docker exec -i mariadb-restore mariadb -uroot -pYourPassw0rd < /data/backup/mariadb_all_20250101.sql

或者利用前面提到的/docker-entrypoint-initdb.d机制，把 dump 文件放到初始化目录里，容器首次启动时会自动执行。这个方法在搭建测试库或者复刻生产数据时很好用，我经常直接对着 dump 文件重新起一个容器，完全复现线上的表结构和数据。

无论用哪种备份方式，我都强烈建议定期做恢复演练。备份存在却恢复不了，等于没有备份。我见过的大部分备份事故都发生在恢复阶段，比如 dump 文件没带--routines导致存储过程丢失，或者备份权限配置错误导致导出的文件为空。演练的意义就是提前发现这些坑。

6. 性能调优与资源限制：容器不是放任不管

6.1 内存配置与 InnoDB 缓冲池

容器部署的 MariaDB，最需要调优的参数是innodb_buffer_pool_size。这个参数决定 InnoDB 用于缓存表数据和索引的内存大小，直接关系读写性能。官方镜像的默认值非常保守，只有 128MB 左右，对任何真实业务来说都不够。一般建议设置为宿主物理内存的 50%~70%，但要考虑容器本身的内存限制。

比如我给容器配置memory: 4G，那 buffer pool 一般设置为 2G 到 2.5G 之间，留部分内存给连接线程、排序缓冲、临时表和操作系统。如果 buffer pool 设置过高，容器内存超限会被操作系统杀掉，容器自动重启，这也是生产环境常见的故障原因之一。

在 docker-compose 中可以通过command传递启动参数，也可以写进配置文件挂载到/etc/mysql/mariadb.conf.d/custom.cnf：

[mariadb] innodb_buffer_pool_size = 2G innodb_log_file_size = 512M max_connections = 500

配置文件放在 bind mount 的宿主机目录后，执行docker restart mariadb-prod让配置生效。改配置之前记得先做一次备份，避免配置错误导致数据库无法启动时没有任何退路。

6.2 连接数与并发参数

max_connections默认只有 151 个连接，高峰期容易不够用。如果业务量不大，建议先设置为 300~500。连接数越多，每条连接占用的内存也越多，一般每连接 1MB 上下。所以连接数调高时，内存规划也要同步考虑。我遇到过一台 2G 内存的测试机，把 max_connections 调到 2000，结果启动几分钟后 OOM，容器直接被 kill。后来把连接数降到 500，内存限制设为 2G，才稳定下来。调参要成组地调，不能只改一个数字不管系统总量。

其他关键参数还包括innodb_flush_log_at_trx_commit。如果对数据安全要求极高，保持默认值 1 最安全，每次事务提交都刷盘，但性能会打折扣。如果业务可以接受最多丢 1~2 秒的日志，可以设为 2，减少刷盘次数，性能提升明显。这个参数的选择是数据安全和性能之间的经典权衡，没有绝对正确，只有合不合适。

6.3 容器资源限制与日志轮转

在 compose 里用deploy.resources.limits限制容器的 CPU 和内存之后，还需要配套监控才能知道容器运行状态。我常用的监控组合是docker stats加基本的日志检查：

docker stats mariadb-prod # 查看实时 CPU、内存、网络 IO docker logs --tail 200 mariadb-prod # 查看数据库日志，注意 MariaDB 日志会写到 stdout/stderr

docker stats只能看到瞬时数据，拿来做故障定位可以，做长期趋势分析不够。如果想更完善，可以用 Prometheus 加 mysqld_exporter 采集指标，容器化环境下安装 exporter 也方便。不过对只有一两台机器的项目，先把docker stats用好，配合慢查询日志定位问题，性价比比搭一套完整监控高得多。

还有一点必须强调：日志不要无限增长。容器默认日志驱动是 json-file，如果不设置 max-size，一个写满错误日志的容器能把磁盘撑爆。我在 compose 里会这样配置：

logging: driver: json-file options: max-size: "100m" max-file: "5"

这个配置把单个日志文件限制在 100MB，最多保留 5 个文件，超过就滚动清理。200G 数据盘被日志占满这种事，我确实在线上踩过一次，从那以后所有容器的日志轮转都列为标配。

7. 常见问题与排查技巧实录

7.1 容器启动失败，先查日志再动手

容器起不来，最常见的报错是端口冲突和数据目录权限错误。端口冲突好判断，docker logs里能看到Address already in use。权限问题就是前面反复讲的 UID 999 对应不上，报错会写Can't create/write to file '/var/lib/mysql'。另外还有一种情况：宿主机的/data/mariadb/data下面已经有数据文件，但属主和容器用户对不上，同样启动失败。解决方式是chown -R 999:999后用docker restart重新拉起。

还有一次比较隐蔽的问题是数据目录里存在一个无效的ibdata1文件，容器启动时 InnoDB 校验失败。这种情况通常是之前直接在宿主机上复制了其他实例的数据文件导致损坏。排查时先看docker logs里有没有 InnoDB 校验错误，如果确实损坏，从备份重新恢复吧，别尝试手工修复损坏的 InnoDB 文件，折腾半天通常只是浪费时间。

7.2 远程连接失败，多半是授权和字符集问题

远程连接 MariaDB 失败，先分清是网络层、认证层还是权限配置层。telnet 127.0.0.1 3306能通说明端口映射没问题。如果端口通但报Access denied for user 'appuser'@'...'，就是用户授权的问题。容器内 MariaDB 默认 root 用户通常只允许从 localhost 连接，远程用 root 登录需要先进入容器，执行授权 SQL：

CREATE USER 'root'@'%' IDENTIFIED BY 'str0ngPassw0rd'; GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION; FLUSH PRIVILEGES;

不过我更推荐创建专用账号而不是开放 root 远程访问，权限最小化原则在数据库安全里永远是第一位。另外还要检查宿主机防火墙是否放行 3306 端口，这个和容器无关，但经常被忽略。

字符集问题是另一个高频故障。连接后执行SHOW VARIABLES LIKE 'character_set%';发现是 latin1 而不是 utf8mb4，大概率是配置文件没有生效或者连接字符串没指定字符集。解决方法是确保启动参数里带--character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci，客户端连接时也加上charset=utf8mb4参数。顺便说一句，连接统一了字符集，不等于历史表结构里的默认字符集会迁移，需要在建表时指定，或者用ALTER TABLE … CONVERT TO CHARACTER SET utf8mb4转换旧表。

7.3 配置和数据丢失，问题出在写错地方

容器重建后数据还在但配置变了，这个现象通常是把配置写进了容器内而不是挂载目录。MariaDB 镜像里有一些默认配置文件位于/etc/mysql/，如果你直接在容器内修改了它们，一旦执行docker rm容器，配置就永久丢失。解决思路是把所有自定义配置放到挂载的宿主机目录（如/data/mariadb/conf），容器无论如何重建都能保留。

时间久了你会发现，容器化数据库的运维逻辑其实就两个字：声明。所有状态尽量通过 compose 文件、配置文件、环境变量来表达，而不是在运行中的容器里手工东改一下西改一下。手工操作一时爽，重建过一回你就知道疼了。我踩过最狠的坑是，把一份重要配置写进了容器内，后来因为升级镜像重建容器，那套定制参数全没了，服务切换过去后直接 Connection reset，排障花了大半天。从那以后我的规矩就是"容器内只运行，不配置"。

7.4 典型问题速查表

上面这些内容，基本就是我这两年部署 MariaDB 时一步步踩出来的经验。容器化部署数据库的好处是环境规范和交付高效，但前提是你把持久化、健康检查、备份恢复和资源限制都做到位。每次遇到启动失败，先别急着删容器重来，docker inspect和docker logs永远是定位问题的第一把钥匙。如果你也想把 MariaDB 放上容器，建议先从一个小实例开始跑，把这一套流程走通，备份恢复演练至少做一次，再考虑上生产。稳定跑起来之后你会发现，数据库容器化其实没那么可怕，但它确实逼着你把基础设施的细节补齐，这反而是好事。