MySQL on 寻 Mi 处

1G 内存的小机器跑 MariaDB，我把能省的都省了

Thu, 03 Apr 2025 04:28:00 +0800

手里有台很便宜的 VPS，1 核 1G，一年一百多块。上面跑着一个小论坛，用户不多，但数据库不能少。

装完 MariaDB 之后，我 free -h 看了一眼，可用内存只剩三百多兆。系统自己占了点，MariaDB 占了将近五百兆。

当时没太在意，觉得还能跑。结果第三天凌晨，机器挂了。

先看是怎么死的

`1`	`journalctl -k --since "yesterday" \| grep -i 'out of memory'`

`1`	`Out of memory: Killed process 812 (mariadbd) total-vm:1024000kB, anon-rss:520000kB`

OOM killer 干的。MariaDB 吃到 520M，加上系统的，超过物理内存，内核直接把它杀了。

有意思的是，杀完之后 systemd 又把它拉起来，然后继续涨，第二天再杀一次。这就是为什么我早上起来发现论坛打不开，但服务状态显示 running。

内存都花在哪儿了

MariaDB 的内存占用分几块，得先搞清楚再动手。

`1`	`SHOW ENGINE INNODB STATUS\G`

输出里的 BUFFER POOL AND MEMORY 那一段，能看到 buffer pool 的实际大小。

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW VARIABLES LIKE 'innodb_log_buffer_size';
SHOW VARIABLES LIKE 'max_connections';
SHOW VARIABLES LIKE 'tmp_table_size';
SHOW VARIABLES LIKE 'max_heap_table_size';
SHOW VARIABLES LIKE 'sort_buffer_size';
SHOW VARIABLES LIKE 'join_buffer_size';
SHOW VARIABLES LIKE 'read_buffer_size';
SHOW VARIABLES LIKE 'read_rnd_buffer_size';

我查出来的默认值是这样的：

innodb_buffer_pool_size    134217728    (128M)
innodb_log_buffer_size     16777216     (16M)
max_connections            151
tmp_table_size             16777216     (16M)
max_heap_table_size        16777216     (16M)
sort_buffer_size           2097152      (2M)
join_buffer_size           262144       (256K)
read_buffer_size           131072       (128K)
read_rnd_buffer_size       262144       (256K)

看着每一项都不大，但问题是，sort_buffer_size、join_buffer_size 这些是每个连接独占的。151 个连接乘上 2M 的 sort buffer，理论上就是 300M。虽然实际不会所有连接都用到满，但这个乘数关系很吓人。

改配置

MariaDB 的配置我放在 /etc/mysql/mariadb.conf.d/99-small.cnf，这样不会被升级覆盖。

[mysqld]
# 内存相关的核心参数
innodb_buffer_pool_size = 64M
innodb_log_buffer_size = 8M
innodb_buffer_pool_instances = 1

# 连接数
max_connections = 30
max_user_connections = 25
thread_cache_size = 4
table_open_cache = 64
table_definition_cache = 256

# 每个连接的缓冲区，越小越好
sort_buffer_size = 256K
join_buffer_size = 256K
read_buffer_size = 128K
read_rnd_buffer_size = 256K
tmp_table_size = 16M
max_heap_table_size = 16M

# 日志和刷盘
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_log_file_size = 32M

# 关掉用不到的功能
performance_schema = OFF
innodb_stats_on_metadata = OFF

一条条说。

innodb_buffer_pool_size 是最大的一块。它是 InnoDB 的缓存池，索引和数据页都放里面。默认 128M 对 1G 的机器太大了，我改成 64M。这个值的经验法则是物理内存的百分之五十到七十，但在小内存机器上，得先保证系统和其他服务能活。

innodb_buffer_pool_instances 默认会按 buffer pool 大小自动分，分成多个实例能减少锁竞争。但在 64M 这个量级，分成多个反而浪费，因为每个实例有自己的最小页数。设成 1 就行。

max_connections 从 151 降到 30。这个小论坛日常在线不到十个人，三十个连接足够。这个改动省下的不是连接本身，而是每个连接的缓冲区乘数。

thread_cache_size 是缓存的线程数。连接断开之后线程不立刻销毁，留着给下一个连接用。设成 4 意味着常驻四个空闲线程，占的内存不多，但能减少频繁创建销毁的开销。

performance_schema 这个功能是用来做性能分析的，很强大，但默认开着会占不少内存，大概几十兆。小站用不上，关掉。

innodb_flush_log_at_trx_commit = 2 这个要谨慎。它控制事务提交时怎么刷日志。

设成 1 是最安全的，每次提交都刷盘，保证不丢数据。设成 2 是每秒刷一次，性能好很多，但极端情况下可能丢一秒的数据。设成 0 是交给操作系统，最不安全。

小论坛丢一秒的数据可以接受，我选了 2。如果你的业务涉及钱，别改这个。

innodb_flush_method = O_DIRECT 让 InnoDB 绕过操作系统的页缓存，直接写磁盘。这样同一份数据不会在内存里存两遍。小内存机器上这个能省下可观的空间。

重启之后看效果

1
2

sudo systemctl restart mariadb
free -h

改完 MariaDB 占了 180M 左右，比之前的 520M 小了一大截。

再看一下实际的 buffer pool：

1
2
3

SELECT
  POOL_SIZE * 16 / 1024 / 1024 AS buffer_pool_mb
FROM information_schema.INNODB_BUFFER_POOL_STATS;

确认是 64M。

一个更细的观察方法

free -h 只能看到整体，想看每个进程实际用了多少：

`1`	`ps -eo pid,comm,rss,vsz --sort=-rss \| head -10`

rss 是实际占用的物理内存，vsz 是虚拟内存。看 rss 才有意义，vsz 包含了大量没有真正分配的地址空间。

还可以看 MariaDB 自己的内存统计：

1
2

SHOW STATUS LIKE 'Innodb_buffer_pool_bytes_data';
SHOW STATUS LIKE 'Innodb_buffer_pool_pages_free';

pages_free 如果一直是 0，说明 buffer pool 不够用，可以适当调大。如果有一半以上是空闲的，说明给多了。

我观察了一周，pages_free 稳定在 40% 左右，说明 64M 是合适的。

swap 要不要开

这个问题争论很多。

我的看法是，小内存机器一定要开一点。不是因为 swap 能提升性能，而是因为它能在内存尖峰的时候给你一个缓冲，避免进程被直接杀掉。

我配了 1G 的 swap：

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

然后调一下 swap 的使用倾向：

`1`	`sudo sysctl vm.swappiness=10`

默认是 60，意思是内存还有富余的时候就开始往 swap 里挪。设成 10 让它尽量先用物理内存，真的不够了才用 swap。

这个值我写在 /etc/sysctl.d/99-swap.conf 里，重启也生效。

不过要提醒一句，如果你的 VPS 用的是机械盘或者网络存储，swap 的性能会很差，用到 swap 的时候整个系统会卡住。这种情况得权衡。

慢查询日志

内存调小了，可能会有些查询变慢，因为 buffer pool 小了，缓存命中率下降。

开个慢查询日志观察：

1
2
3

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2

跑一周，看看有没有超过两秒的查询。有的话，先优化 SQL，加索引，比加内存便宜。

我那台机器上确实发现了两条，一条是论坛的帖子列表，没走索引，全表扫描。加了复合索引之后，从三秒降到几十毫秒。

这个收益比调参数大得多。

还有一个坑：临时表

tmp_table_size 和 max_heap_table_size 这两个值要设成一样。

原因是有个隐藏的行为。内存临时表的大小受这两个值里较小的那个限制。如果不一样，实际生效的是小的那个，你改大的那个没用。

我一开始只改了 tmp_table_size，改成 64M，结果发现没效果，因为 max_heap_table_size 还是 16M。

另外，临时表超过这个大小之后，会转成磁盘临时表。磁盘临时表慢很多，但至少不会把内存撑爆。所以这两个值别设太大，16M 到 32M 就够了。

长期观察

调完到现在跑了三个多月，没再被 OOM 杀过。

free -h

现在的样子：

1
2
3

               total        used        free      shared  buff/cache   available
Mem:           979Mi       412Mi       102Mi       8.0Mi       464Mi       512Mi
Swap:          1.0Gi        12Mi       1.0Gi

MariaDB 稳定在 180M 左右，swap 只用了 12M，基本没动。

available 有 512M，说明还有余量。这个指标比 free 更有参考价值，因为它把可回收的缓存也算进去了。

一点心得

小内存机器上跑数据库，核心思路是"知道自己需要多少，然后只给这么多"。

默认配置是为通用场景设计的，它假设你有足够的内存。在 1G 的机器上，这些默认值就是灾难。

调参的顺序应该是，先降 max_connections，因为它带来的乘数效应最大；再降 innodb_buffer_pool_size，这是单项最大的一块；最后调各种 per-connection 的缓冲区。

调完之后别急着走，观察几天，看 buffer pool 的命中率和 free 页面数，再微调。

还有一点，如果你的库真的很小，比如就几兆数据，那其实可以考虑 SQLite。省掉整个数据库进程，内存占用直接降到几兆。我这个论坛是因为要用全文检索和并发写，才留着 MariaDB。

数据库备份这件事，我从手动导出做到全自动

Thu, 20 Mar 2025 03:45:00 +0800

我一直觉得备份是件很枯燥的事。

直到有一次，我在服务器上执行了一条 DELETE FROM comments WHERE id > 100，本来想删测试数据，结果忘了自己不在测试库。

那条语句跑完，生产库少了两千多条评论。

我坐在那儿愣了大概十秒钟，然后想起来，昨天晚上的备份还在。

从那次之后，我对备份的态度完全变了。

备份到底要解决什么问题

先说清楚，备份不是"把数据复制一份"这么简单。

它要能应对几种不同的场景。

误删数据，需要恢复到删除前的某个时间点。

磁盘损坏，需要换台机器把服务重新拉起来。

程序 bug 写坏了数据，需要回滚到某个版本。

被勒索软件加密，需要有离线副本。

这几种场景对备份的要求不一样。误删需要时间点密集，磁盘损坏需要副本在别的机器上，勒索需要副本不可写。

所以一个靠谱的方案，至少要有三个特征。定期自动跑，副本存在别的地方，而且真的能恢复。

最后一条最容易被忽略。很多人备份跑了半年，真要恢复的时候才发现文件是空的。

最基础的 mysqldump

小站用这个就够了。

mysqldump \
  --single-transaction \
  --quick \
  --routines \
  --triggers \
  --events \
  --default-character-set=utf8mb4 \
  -u root -p \
  myapp > /backup/myapp-$(date +%F).sql

几个参数都值得说一下。

--single-transaction 是关键。它在 InnoDB 上开一个一致性快照，导出过程中不会锁表，业务可以继续写。导出来的数据是开始那一刻的状态，不会出现前后不一致。

注意这个参数只对 InnoDB 有效。如果你的表还有 MyISAM，那就得用 --lock-tables，会锁表，业务会卡。

--quick 让 mysqldump 一行一行往客户端发，而不是全部读进内存。大表不加这个，很容易把内存撑爆。

--routines --triggers --events 这三个，默认是不导出的。不加上，恢复之后存储过程、触发器、定时任务全都没了。我第一次恢复的时候就踩了这个坑，恢复完发现定时清理任务不跑了。

--default-character-set=utf8mb4 防止中文乱码。如果源库是 utf8mb4，导出的时候不指定，有时候会被转成 latin1。

加压缩和加密

纯 sql 文件很大，压缩一下能小到十分之一：

`1`	`mysqldump ... \| gzip > /backup/myapp-$(date +%F).sql.gz`

如果数据里有敏感信息，还得加密：

`1`	`mysqldump ... \| gzip \| openssl enc -aes-256-cbc -pbkdf2 -salt -pass file:/etc/backup.key > /backup/myapp-$(date +%F).sql.gz.enc`

-pbkdf2 是让 openssl 用更安全的密钥派生方式，不加的话会有警告。

-pass file: 从文件读密码，比写在命令行里安全，因为命令行参数在 ps 里能看到。

/etc/backup.key 权限设成 600，只有 root 能读。

恢复的时候：

`1`	`openssl enc -d -aes-256-cbc -pbkdf2 -pass file:/etc/backup.key -in backup.sql.gz.enc \| gunzip \| mysql -u root -p myapp`

写成脚本

手动跑总会忘，得自动化。

#!/bin/bash
set -euo pipefail

BACKUP_DIR=/backup/mysql
KEEP_DAYS=14
DATE=$(date +%F_%H%M)
DB=myapp

mkdir -p "$BACKUP_DIR"

mysqldump \
  --single-transaction --quick --routines --triggers --events \
  --default-character-set=utf8mb4 \
  -u root -p"$(cat /etc/mysql/backup.pass)" \
  "$DB" | gzip > "$BACKUP_DIR/${DB}-${DATE}.sql.gz"

# 校验文件不是空的
SIZE=$(stat -c %s "$BACKUP_DIR/${DB}-${DATE}.sql.gz")
if [ "$SIZE" -lt 1024 ]; then
  echo "备份文件异常小：$SIZE 字节" >&2
  exit 1
fi

# 清理过期
find "$BACKUP_DIR" -name "${DB}-*.sql.gz" -mtime +$KEEP_DAYS -delete

echo "备份完成：${DB}-${DATE}.sql.gz ($SIZE 字节)"

set -euo pipefail 这三件套一定要加。-e 让任何命令失败就退出，-u 让未定义变量报错，-o pipefail 让管道里任何一个环节失败都能被捕获。

没有 pipefail 的时候，mysqldump | gzip 如果 mysqldump 失败了，整个管道还是返回成功，因为 gzip 成功了。这是很隐蔽的坑，我吃过一次，备份文件是空的，脚本还报成功。

那个 SIZE 校验也是必须的。空文件、截断的文件，靠退出码是发现不了的。

用 cron 跑

sudo tee /etc/cron.d/mysql-backup <<'EOF'
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

30 3 * * * root /usr/local/bin/mysql-backup.sh >> /var/log/mysql-backup.log 2>&1
EOF

每天凌晨三点半跑。这个时间业务量最低。

cron.d 的格式比 crontab -e 多一个用户字段，就是 root 那个位置。写错了会不执行，而且没有任何提示。

增量备份

全量备份对数据量小的站够用，但如果库有几个 G，每天全量就不太现实了。

增量有两种做法。

一种是 binlog。MySQL 的 binlog 记录了所有数据变更，配上定期全量，可以把数据恢复到任意时间点。

先确认 binlog 开着：

`1`	`SHOW VARIABLES LIKE 'log_bin';`

如果是 ON，那 binlog 文件在 datadir 下面，名字形如 mysql-bin.000001。

备份 binlog：

1
2

mysqlbinlog --read-from-remote-server --host=127.0.0.1 --user=repl --password=xxx \
  --raw --stop-never mysql-bin.000001

这个会持续拉取新的 binlog。实际用的时候一般配合 --result-file 和定期切换。

另一种是 --incremental 配合 xtrabackup。Percona 的工具，支持热备和增量，适合大库。不过它需要单独装，配置也复杂一些。

我这个小站没到那个量级，用的还是每天全量。库里不到一百兆，压缩完十几兆，存三十天也就四百多兆。

存到别的地方

本地备份只能防误删，防不了磁盘坏或者机器没了。

所以至少要有两份，一份在本机，一份在别处。

我用的是 rclone 同步到对象存储：

`1`	`rclone sync /backup/mysql remote:mybackup/mysql --max-age 24h`

--max-age 24h 只同步一天内的新文件，不用每次全传。

对象存储那边开了版本控制，就算本地文件被勒索软件加密了，云上的历史版本还在。

还有一个细节，云上的凭据要单独放，不要和备份放在同一台机器上。不然机器被攻破，凭据一起泄露，备份也保不住。

真正的考验是恢复

这一步我建议每个人都做一次。

找个测试环境，把备份文件恢复进去，看看数据对不对。

`1`	`gunzip -c myapp-2025-03-19.sql.gz \| mysql -u root -p testdb`

然后：

1
2

SELECT COUNT(*) FROM comments;
SELECT MAX(created_at) FROM comments;

数字对得上，时间对得上，才算备份有效。

我第一次做这个演练的时候，发现恢复出来的库少了三张表。原因是那三张表是 MyISAM，--single-transaction 对它们无效，mysqldump 直接跳过了。后来改成全部 InnoDB 才好。

这种问题，只有真的恢复一次才能发现。

恢复的流程也要写下来

出事的时候人是慌的，容易漏步骤。

我把恢复流程写成了一个文档，放在 /srv/docs/restore.md，内容包括：

先停掉应用，防止有新的写入。

备份当前的数据库（哪怕是坏的，先留一份）。

创建新的库，导入备份。

检查表数量、行数、最新的记录时间。

确认无误之后，改应用的连接配置，启动。

最后记录这次事故的时间线和原因。

有这个文档，真出事的时候照着做就行，不用临场想。

现在的情况

这套东西跑了快一年，中间用上了两次。一次是我自己误删，一次是磁盘满了导致写入失败。

两次都在半小时内恢复，业务中断时间不到一小时。

备份这件事，平时感觉不到它的价值。它唯一的价值就在出事的那一刻，而那一刻你没有任何补救的机会，只能靠之前准备好的东西。

所以我现在对它的态度是，不追求多先进，但一定要简单、可靠、验证过。