运维日志

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

手上几台 5.7 的库要升 8.0，第一反应是 `yum update mysql-server` 然后重启？别。我见过这么干的，重启完应用连不上，查半天发现是认证插件变了，账号全废了。升级这种事，慢就是快。 先跑官方预检，别凭感觉 MySQL Shell 自带的 `util.check

应用日志里蹦出一行： ``` Deadlock found when trying to get lock; try restarting transaction ``` 很多人第一反应是加个重试就完事。重试确实能让业务不报错，但死锁频繁说明**并发控制的设计有问题**，光重试是把火药桶盖住了

那个报错 ``` Deadlock found when trying to get lock; try restarting transaction ``` 第一次见到这行，我的反应和大多数人一样——加个重试。重试确实有用，死锁本来就是数据库自己会挑一个事务回滚掉，业务层补一次通常就过

单表到两三千万行，索引还能撑；再往上，加个字段要半小时、DDL 锁表、备份慢、单实例 QPS 打满——这时候就该考虑拆了。 但分库分表这事的难点从来不是"怎么分"，是**分片键选什么**和**分完之后那些原本一个 SQL 能干的事都干不了了**。我见过拆完上线第一天就后悔的，因为分片键按用户 I

为什么需要文件完整性监控 安全加固（关端口、改密码、上 SELinux）解决的是"门有没有锁好"，但挡不住已经进来的攻击者。一旦拿到权限，黑客最常见的动作是： - 篡改 `/etc/passwd`、`/etc/shadow` 加后门账号； - 替换 `sshd`、`ls` 等二进制文件（