对某线上应用（测试 + 正式两套环境）做巡检：服务运行正常，但发现 4 个突出问题——MySQL 缓冲池配置过低、3306/5433 端口公网暴露、Redis 无密码且未绑内网、数据库完全无自动备份，并给出处理优先级。
巡检日期：2026-08-11
巡检范围：测试机 [测试机IP]、正式机 [正式机IP]
脱敏说明：IP、业务名、内网地址等已隐去。
线上服务本身运行正常，小程序和后台都能正常访问，证书也都在 Caddy 自动续期里。这次巡检主要看的是数据库和几个风险点，有四个问题比较突出，下面按情况说一下。
一、MySQL 缓冲池配置太低
目前正式机和测试机的 innodb_buffer_pool_size 都是 128M，等于没调过（InnoDB 默认值）。
机器内存有 7.3G，而正式库已经涨到 3.6G（其中 [业务日志表] 一张表就占了 2.9G）。128M 的缓冲池意味着热数据基本都落不到内存里，查询大概率直接打磁盘。现在数据量还不算太大感觉不明显，等数据再涨、并发再上来，MySQL 会先成为瓶颈。
建议调到 1G～2G，两步走：
-- 在线调整（先用 GLOBAL 试跑确认没问题）
SET GLOBAL innodb_buffer_pool_size = 2147483648;
-- 正式生效并持久化（MySQL 8 支持，正式 8.4、测试 9.3 都可以）
SET PERSIST innodb_buffer_pool_size = 2147483648;
更稳妥的做法是在 bitnami/mysql 里挂一份自定义 my.cnf 写上这个参数再重建容器，一劳永逸。
注意一点：SET PERSIST 写的是容器数据卷里的 mysqld-auto.cnf，只要数据卷在就生效；如果哪天重建容器没挂数据卷，需要重新配置。1G 是当前够用的底线，之后数据涨了再往 2G 调。
二、3306 端口对外暴露
这是这次巡检里最严重的安全问题。
MySQL 的端口是直接映射到宿主机 0.0.0.0 的，我实际从外网测试，公网能直接连上 3306；正式机的 PostgreSQL（5433）也是同样情况。等于任何人都能尝试连数据库，就算密码再复杂，也是把入口主动送上门，随时可能被扫到、被爆破。
处理办法，不用动应用代码： 通过安全组禁止3306公网访问
三、Redis 没设密码、也没绑内网
正式机一个 redis（6379），测试机三个 redis（6379 / 6479 / 6579），都是 redis:alpine3.14 起的，目前：
- 没设
requirepass，谁连上都能读写 - 没设
maxmemory，内存不设上限 - 端口绑在
0.0.0.0（公网虽然连不通，可能是安全组挡的，但宿主机层面是全开的）
Redis 里存的是业务缓存和会话，一旦被外部写入，或者内存被人刷爆，影响面比想象的大。测试机现在等于整个环境的数据随便读写。
建议：
- 给 redis 加
requirepass，同时给 server 配置文件补上密码。目前正式机 server 连 redis 的地址是[内网容器IP]:6379，改的时候两边要一起动，别只改一边把自己锁在外面。 - 去掉宿主机
-p 6379:6379的端口映射，只保留 docker 网络内访问。应用本来就是走容器网络直连的，去掉宿主机映射不影响。 - 顺手把
maxmemory设上（比如 512M，按实际使用情况来），避免内存被打满拖垮整台机器。
四、数据库没有备份
这个也是硬伤。
目前两台服务器上都没有自动备份任务，crontab 里只有云厂商的监控 agent，没有 mysqldump 之类的备份。交接文档里提到的那些备份，都是开发时手动 make sync 留下的快照，不能算自动备份。
一旦正式库出问题（误删、坏页、机房故障），数据基本找不回来。尤其 [业务日志表] 这种一直在涨的表，丢一天的日志都是实打实的损失。
建议至少做到：
- 正式库每天凌晨全量 mysqldump 一次，压缩后放到对象存储或异地服务器，别只放本机——本机磁盘满了、机器挂了，放在本机的备份一样没救。本地至少保留 7 天。
- 备份脚本放服务器上，用 cron 跑；脚本里账号密码走环境变量或配置文件，别明文写在命令行。
- 一个月做一次恢复演练，dump 出来的文件能不能还原，验证过才算真的备份了。
- 测试库那些
make sync留下的快照库现在堆了四十多个、占了好几个 G，定个清理机制，别让它一直堆下去。
其他问题
- 正式机还挂着约 30 个已下线的旧 go-zero 容器（user-api、store-api、auction 系列、es、kibana、etcd 等），光 Elasticsearch 一个就占 1.5G 内存，加起来两个多 G，还占了不少磁盘，纯属浪费。确认没有调用之后建议停掉删掉。
- 两台机器 UFW 防火墙都没开，fail2ban 也没装，SSH 密码登录是开着的，防暴力破解基本全靠云厂商安全组挡着。
- 正式机 server 配置里 Redis 和 PG 用的是写死的容器 IP（
[内网容器IP]），这种 IP 在容器重建之后会变，哪天一重建服务可能就起不来了。建议改成服务名或者固定 IP。 - 测试机 MySQL 是 9.3（Innovation 版，非长期支持版），正式机是 8.4，两边环境不一致，建议测试机对齐到 8.4。
处理优先级
- 数据库备份——先有备份再动别的，这是底线
- 收敛 3306 / 5433 端口
- Redis 加密码、去端口映射
- MySQL buffer pool 调整
- 防火墙、旧容器清理这些，排在前几项之后