运维日志

pg_dump 是逻辑备份，做不了时间点恢复，库一大还慢得离谱。真要扛误删表、误更新全表这种事故，得靠物理备份加 WAL 归档的 PITR。从建备份账号、开归档、跑 pg_basebackup，到真的把库恢复到「出事前一秒」，把每一步命令和每个坑都摊开讲。

报警说磁盘 100%，可 du 加起来差了一大截；或者 df -h 明明还有空间，应用却报 No space left on device。这两种情况我都遇过不止一次，根因通常是已删除但被进程占用的文件、inode 耗尽，或者文件被挂载点盖住。逐个拆开讲怎么定位、怎么在不重启服务的前提下把空间腾出来。

打开表结构，14 个索引，其中 6 个是单列索引，还有几个前缀完全重复。这张 2000 万的表写入从 2000 TPS 掉到 600，磁盘占用比数据本身还大——索引比数据多。 索引不是越多越好。每多一个索引，每次 INSERT/UPDATE/DELETE 都要多维护一棵 B+ 树，写入成本实实在

服务器重启之后不起来了。屏幕上要么是 `grub rescue>`，要么是刷一堆 `dracut` 报错后掉进 emergency shell。这种时候最忌讳的就是乱试命令——搞清楚**卡在启动的哪一步**，问题就解决一半了。 启动的四个阶段 定位的第一步是判断停在哪： 1. **固件

权限问题的标准解法是 `chmod 777`，然后问题解决，然后没人再管。这事的麻烦在于：三个月后另一个人也遇到"没权限"，也 `777`，最后整个数据目录对所有人可写，谁删的你都查不出来。 Linux 权限其实就三层，搞清楚之后大部分问题有更干净的解法。 基础：rwx 到底是谁的 `

为什么 ETL 不够用了 传统数据同步靠**定时批量抽取**： ```sql -- 每天凌晨抽昨天的数据 INSERT INTO dw.orders SELECT * FROM oltp.orders WHERE update_time >= '2026-09-06 00:00:00';