搜索结果: "mysql"

title: MySQL / Redis 常见故障排查速查清单

tags: [mysql, redis, database, troubleshooting, production, command]

sources: [raw/articles/数据库运维必备-MySQL-Redis-常见故障排查清单.md]

# MySQL / Redis 常见故障排查速查清单

覆盖 MySQL 和 Redis 最常见的 20+ 种生产故障，每个故障按「现象 → 排查 → 根因 → 修复 → 验证」结构组织。适合值班 oncall、故障复盘、健康巡检时快速对号入座。

title: MySQL 备份方案对比与选型 — 从工具原理到生产落地的工程手册

tags: [database, mysql, backup, troubleshooting, storage]

- raw/articles/MySQL-备份方案对比与选型-从工具原理到生产落地的工程手册.md

# MySQL 备份方案对比与选型

| `FLUSH TABLES WITH READ LOCK` | 全库读锁，阻塞所有写 | mysqldump 无 `--single-transaction` 时 |

title: MySQL 连接失败排查指南 — 从报错定位到根因修复

tags: [mysql, database, troubleshooting, networking, security, command]

sources: [raw/articles/MySQL-连接不上-常见报错和排查方法.md]

# MySQL 连接失败排查指南

本文按"现象 → 信息收集 → 初步判断 → 命令检查 → 证据分析 → 根因 → 修复 → 验证 → 复盘"展开。命令基准为 MySQL 8.0（部分兼容 5.7）。

title: MySQL 磁盘空间紧急处置指南 — 哪些文件能删，哪些绝不能动

tags: [database, mysql, storage, troubleshooting, disk, command]

- raw/articles/MySQL-磁盘空间不足-哪些文件能删-哪些千万别动.md

# MySQL 磁盘空间紧急处置指南 — 哪些文件能删，哪些绝不能动

MySQL 磁盘告警最危险的处理方式，是进入数据目录按大小执行 `rm`。InnoDB 数据、redo、undo、doublewrite、二进制日志和复制元数据之间存在恢复关系；错误删除可能立刻中断复制，也可能等重启时才暴露数据损坏。本文适用于 **MySQL 8.0 + InnoDB**。

title: MySQL 性能调优 — 慢查询 / 锁分析 / 死锁排查 / 索引失效 / 深度分页 / 缓冲池 / 配置模板

tags: [mysql, database, performance, monitoring, production, deadlock, lock]

- raw/articles/mysql-deadlock-troubleshooting.md

- raw/articles/mysql-slow-query-optimization.md

# MySQL 性能调优

title: MySQL 主从复制指南 — 原理 / 手把手搭建 / GTID / 架构 / 故障排查 / 监控

tags: [mysql, database, replication, high-availability, troubleshooting, production]

sources: [raw/articles/mysql-replication-guide.md, raw/articles/2026-09-05-mysql-replication-setup-and-lag.md]

# MySQL 主从复制指南

> MySQL 主从复制是高可用数据库架构的基础。核心流程：**主库 Binlog → IO 线程拉取 → Relay Log → SQL 线程执行。**

title: MySQL 主从延迟排查 — 6 大根因 / 真实案例 / 万能四步流程

tags: [mysql, database, replication, troubleshooting, production, performance]

sources: [raw/articles/2026-09-05-mysql-replication-setup-and-lag.md]

# MySQL 主从延迟排查

> 复制原理、搭建步骤、并行复制开启命令见 [[mysql-replication-guide]]，本页专注**延迟的根因定位与解决**。

title: MySQL 慢查询 5 轮递进式优化实战 — 10.2s → 9.7ms 完整复盘

tags: [mysql, database, performance, troubleshooting, case-study]

# MySQL 慢查询 5 轮递进式优化实战 — 10.2s → 9.7ms

**根因：** 两个独立单字段索引，MySQL 无法合并，排序仍用临时表 + 文件排序。

- [[mysql-slow-query-case-study]] — 慢查询排查案例复盘（通用方法论，companion）

title: MySQL 慢查询排查案例复盘 — 从发现到根治的完整链路

tags: [mysql, database, performance, troubleshooting, case-study]

sources: [raw/articles/mysql-slow-query-optimization.md]

# MySQL 慢查询排查案例复盘

| [[mysql-performance-config]] | MySQL 性能调优总纲（慢查询/索引失效/深度分页/锁分析/配置模板） |

title: 运维自动化脚本 5 件套 — 健康巡检/日志告警/MySQL备份/批量执行/服务守护

tags: [tools, linux, automation, monitoring, backup, mysql, debugging]

# 运维自动化脚本 5 件套 — 健康巡检/日志告警/MySQL备份/批量执行/服务守护

5 个即用型运维自动化脚本，覆盖服务器健康巡检、日志异常告警、MySQL 自动备份、批量命令执行和服务守护，可独立部署到生产环境。

for svc in nginx mysql redis; do

mysql:

image: mysql:8.0

- mysql_data:/var/lib/mysql

mysql_data:

**错误做法：** 使用匿名 volume（`volumes: - /var/lib/mysql`），重启后数据可能丢失。

Playbook 膨胀到几百行，变量散落各处，想改个 Nginx 配置翻半天，复用到新项目等于重写——这是从入门到进阶的典型瓶颈。Roles 就是 Ansible 的模块化：安装 Nginx、配置 MySQL、部署 PHP 各放一个 role，主 playbook 一句话调用。

├── install_mysql.yml

│ ├── mysql/

- mysql

**MySQL role** 核心：安装 → 设 root 密码（从 vault 读取）→ 创建应用库。关键变量如 `mysql_root_password` 必须从加密的 vault 文件读取，不在 defaults 中明文写死。

tags: [troubleshooting, production, monitoring, networking, database, mysql, nginx]

mysql -u root -p -e "SHOW FULL PROCESSLIST;"

# 查看锁等待（MySQL 5.7）

SELECT r.trx_id, r.trx_mysql_thread_id, r.trx_query,

b.trx_id, b.trx_mysql_thread_id, b.trx_query

### 10. MySQL 主从复制原理

参见 [[mysql-replication-guide]]（主从复制深度解析）；高频追问「主从延迟怎么排查」见 [[mysql-replication-lag-troubleshooting]]（6 大根因 + 万能四步流程）。

### 11. MySQL 常见存储引擎

### 21. MySQL 忘记 root 密码

mysqld_safe --skip-grant-tables &

| ReadWriteOnce | RWO | 单节点读写 | **数据库**（MySQL/Redis）— 最常用 |

### 案例 1：MySQL 数据库持久化

name: mysql

app: mysql

- name: mysql

> 是数据库（MySQL/Redis/Kafka/ZK）等有状态应用在 K8s 上的标准运行方式。

Pod 命名格式：`{statefulset-name}-{ordinal-index}`，如 `mysql-0`、`mysql-1`。

- Pod `mysql-0` → PVC `data-mysql-0`

- Pod `mysql-1` → PVC `data-mysql-1`

kubectl run test --image=busybox -- nslookup mysql-0.mysql.default.svc.cluster.local

| /usr/bin | 用户命令（含非基础工具） | yum, docker, nginx, mysql |

| /usr/sbin | 系统管理命令 | httpd, named, mysqld |

├── mysql/ / redis/ # 数据库配置

│ ├── mysql/ # MySQL 日志

│ ├── mysql/ # MySQL 数据库文件

某公司备份服务器在凌晨 02:17 发生了一起典型的 `rm -rf` 误删事故。这台机器承接应用层每天 02:00 的 mysqldump 输出，通过 rsync 推送到异地机房——典型的"用着没出过事、所以半年没巡检"的状态。

新任运维小 A 接手后做了一次目录重构，把 `/data/backup` 拆成了 `mysql/`、`app/`、`logs/`、`tmp/` 四个子目录。他改了 `cleanup.sh` 里的路径，把 `/data/backup` 改成了 `/data/backup/tmp`——因为他觉得临时目录总归要清。但这一步没有经过 Code Review，也没有在预发环境演练过。

**致命陷阱：** `/data/backup/tmp` 是一个指向父目录 `/data/backup` 的软链——上一任运维为了偷懒创建的。`find -L` 主动跟随软链，结果把整个 `/data/backup` 当成"临时目录"展开去清理了。`/data/backup/mysql`（mysqldump 文件）和 `/data/backup/app`（应用归档包）全部被删，`/data/backup/logs` 因为被后台进程打开了几个文件（rm 删掉了硬链接但 inode 还在进程手上），看起来"还在"实际也是假象。

systemctl stop mysqld # 示例：如果 MySQL 写该目录

ls -la /mnt/snap/data/backup/mysql/

- [[cpu-100-full-chain-diagnosis]] — CPU 100% 故障排查从告警到根因的全链路分析：排查七步法、真实级联故障案例（MySQL 备份锁→从库延迟→GC→CPU）、10 大 CPU 场景速查、多语言排障、JVM 配置、故障复盘清单

- [[database-troubleshooting-checklist-mysql-redis]] — 覆盖 MySQL（12 种）和 Redis（11 种）最常见的生产故障，每个故障按现象→排查→根因→修复→验证结构组织，含决策树和命令速查

- [[mysql-backup-selection-guide]] — MySQL 备份方案完整工程手册 — 17 种工具对比/mysqldump/XtraBackup/mydumper 实战/PITR 时间点恢复/LVM 快照/云厂商快照/按数据量级选型/翻车案例

- [[mysql-connection-troubleshooting-guide]] — MySQL 连接失败排查指南 — 7 类报错根因定位 + 修复验证流程

- [[mysql-disk-space-cleanup-guide]] — MySQL 磁盘空间不足时的安全清理指南，哪些文件能用 SQL 清理，哪些绝不能动

- 新增标签：mysql

- Created concepts: fullstack-performance-troubleshooting, mysql-performance-config

- Updated concepts: fullstack-performance-troubleshooting, mysql-performance-config（交叉引用）

## [2026-05-11] ingest | 生产环境 MySQL 死锁：定位思路与根治方案

- Created raw: raw/articles/mysql-deadlock-troubleshooting.md

运维排障与数据管理 — 涵盖 Kubernetes 集群运维、Redis/MySQL 等数据库管理、容器化部署、生产环境最佳实践

2026-09-05 拓宽：database 15页（新增主从延迟专页；mysql-replication-guide 合并原理深拆+完整搭建+避坑清单）；总页数 178

├── database/ # MySQL + Redis 数据库

- mysql: MySQL 数据库

# MySQL：改连接数和超时

sed -i 's/^max_connections.*=.*100/max_connections = 500/' /etc/mysql/my.cnf

sed -i '/^\[mysqld\]$/a\innodb_buffer_pool_size = 4G' /etc/mysql/my.cnf

sed -i 's/jdbc:mysql:\/\/old-host:3306/jdbc:mysql:\/\/new-host:3306/g' app.properties

pgrep -u mysql mysqld # 按用户+进程名查找

smem -u mysql # 查看指定用户的内存

kill -9 mysqld # 可能丢数据，redo log 没刷盘可能崩溃恢复失败

# 安全做法：先 kill 发 SIGTERM 等 30 秒，或用 mysql -e "SHUTDOWN"

tags: [troubleshooting, performance, database, mysql, redis, java, monitoring, networking]

- **MySQL 慢查询：** 抓慢 SQL → `EXPLAIN` → 看锁等待

├─ 2. 调用链：MySQL 慢查询 / Redis 慢命令 / RPC 延迟 / 业务代码耗时

tags: [kubernetes, database, deployment, production, architecture, mysql, statefulset]

推荐 Operator：MySQL Operator、PostgreSQL Operator、Vitess（大规模）、TiDB（原生分布式）。

- [[mysql-performance-config]] — 数据库性能调优（无论是否在 K8s 上都需要）

**现象：** 部署了 MySQL 主从使用 Headless Service，但 Pod 之间无法通过 DNS 互相发现。

2. DNS 记录为空 `nslookup mysql-headless.database.svc.cluster.local` ❌

kubectl get statefulset mysql -n database \

> 定位：面向中高级开发者/架构师/技术负责人的生产排障手册。重点不是命令大全，而是**遇到故障时如何快速缩小范围、判断根因、做出正确修复**。全文案例取自真实事故：电商平台「速卖商城」（日活 2300 万、核心链路峰值 QPS 8.5 万、微服务 200+、3 个集群 260 节点、RocketMQ 日处理 14 亿条，K8s 1.27 + Containerd，Nginx + Spring Cloud Gateway + Nacos + Redis Cluster + MySQL 8.0 分库分表 + Prometheus/Grafana/EFK）。

服务启动即退出，不一定是代码崩了，也可能是依赖还没准备好：启动阶段强依赖 Redis/MySQL/配置中心，依赖未就绪时启动脚本立即失败，kubelet 反复拉起形成 CrashLoopBackOff。关键判断不是「怎么让 Pod 重启成功」，而是「**这个失败是否应该发生在启动期**」。

StatefulSet 保证固定 Pod 名称和稳定存储绑定，意味着 **删 Pod 不等于换数据**。真实误判：mysql-0 所挂 PVC 数据损坏 → 运维删除 mysql-0 → 新 Pod 起来继续挂同一个坏卷 → 故障毫无改善。因为设计核心就是「身份稳定」（名称 + 卷绑定关系），不能用无状态「删掉重建」思路。

### 6.4 MySQL 数据库 IO 优化

[mysqld]

### 案例 1：MySQL 响应延迟（促销期 iowait 45%）

# 1234 be/4 mysql 30.5 M/s 50.2 M/s 0.00 % 85.23 % mysqld

# → mysqld 和 rsync 在进行大量磁盘 IO

**应用日志常见路径：** Nginx `/var/log/nginx/error.log`、Apache `/var/log/httpd/error_log`、MySQL `/var/log/mysql/error.log`、Redis `/var/log/redis/redis-server.log`、PHP-FPM `/var/log/php-fpm/error.log`。

tags: [linux, troubleshooting, performance, monitoring, production, debugging, networking, mysql, filesystem]

- MySQL：`innodb_buffer_pool_size` 设为物理内存 60~70%

| [[cpu-100-full-chain-diagnosis]] | CPU 100% 故障排查从告警到根因的全链路分析：排查七步法、真实级联故障案例（MySQL 备份锁 |

- [[database-troubleshooting-checklist-mysql-redis]] — 数据库常见故障排查清单（MySQL + Redis）

- [[mysql-slow-query-case-study]] — MySQL 慢查询案例复盘（消息积压后消费端数据库瓶颈排查）

**适用场景：** 数据库（MySQL/PostgreSQL）、消息队列（Kafka）、分布式存储

database_url: "mysql://db:3306/mydb"

## 真实案例：MySQL 备份锁导致的级联故障

MySQL 从库备份锁表 → 从库查询超时 → 线程池 200 个请求积压

grep -rn "max_connections" /etc/mysql/

# 输出: /etc/mysql/mysql.conf.d/mysqld.cnf:23:max_connections = 500

3421 be/4 mysql 0.00 B 2.81 M/s mysqld

找到 `mysqld` 疯狂写磁盘后，下一步进 MySQL 查慢查询日志，或检查是否配置触发大量 fsync。

nginx -v && apache2 -v && mysql --version && redis-server --version && docker --version

重点关注不该对外开放的端口（MySQL 3306、Redis 6379）和未知服务监听端口。

tags: [linux, troubleshooting, performance, monitoring, nginx, mysql]

### CASE 03：MySQL 慢查询导致首页加载 10s

| **MySQL/PostgreSQL/Redis 数据** | 保留全卷镜像，按数据库恢复流程 | 从 /proc 孤立的 fd 复制单个数据文件 |

- [[mysql-backup-selection-guide]] — MySQL 备份方案对比，涉及数据库一致性恢复

快速定位到 Nginx、MySQL 或 Java 应用等具体进程。

- **CLOSE_WAIT 泄漏**：Java 应用发布后 CLOSE_WAIT 缓慢上升至爆表 → 异常处理中未关闭 MySQL 连接 → 修复代码后重启

mysqladmin -h <数据库地址> -u <检查账号> -p ping

mysql -h <数据库地址> -u <检查账号> -p -e "SHOW GLOBAL STATUS LIKE 'Threads_running';"

- [[mysql-backup-selection-guide]] — MySQL 备份方案完整工程手册 — 17 种工具对比/mysqldump/XtraBackup/m

| [[database-troubleshooting-checklist-mysql-redis]] | 覆盖 MySQL（12 种）和 Redis（11 种）最常见的生产故障，每个故障按现象→排查→根因→ |

| [[database-troubleshooting-checklist-mysql-redis]] | 覆盖 MySQL（12 种）和 Redis（11 种）最常见的生产故障，每个故障按现象→排查→根因→ |

| [[database-troubleshooting-checklist-mysql-redis]] | 覆盖 MySQL（12 种）和 Redis（11 种）最常见的生产故障，每个故障按现象→排查→根因→ |

- [[database-troubleshooting-checklist-mysql-redis]] — 覆盖 MySQL（12 种）和 Redis（11 种）最常见的生产故障，每个故障按现象→排查→根因→

iptables -A INPUT -p tcp --dport 3306 -s 10.0.1.0/24 -j ACCEPT # MySQL 白名单

| [[ops-automation-scripts]] | 运维自动化脚本 5 件套（健康巡检/日志告警/MySQL备份/批量执行/服务守护） |

| MySQL | `my.cnf` | `bind-address = 0.0.0.0` |

- [[cpu-100-full-chain-diagnosis]] — CPU 100% 故障排查从告警到根因的全链路分析：排查七步法、真实级联故障案例（MySQL 备份锁

### 数据库（MySQL / PostgreSQL）

### 案例一：MySQL 主从集群调度

3. **启动依赖优先怀疑**：启动即退出的高频根因是 Redis/MySQL/配置中心未就绪，启动脚本立即失败。止血用 initContainer 等待依赖（`until nc -z redis 6379; do sleep 2; done`）；长期治理用 `startupProbe` 给冷启动时间 + 应用自身重连退避，避免 K8s 把可恢复的短暂故障放大成持续重启

- 建议 limits.memory 设为 requests.memory 的 1.5-2 倍（MySQL/Java 等）

| [[cpu-100-full-chain-diagnosis]] | CPU 100% 故障排查从告警到根因的全链路分析：排查七步法、真实级联故障案例（MySQL 备份锁 |

| [[cpu-100-full-chain-diagnosis]] | CPU 100% 故障排查从告警到根因的全链路分析：排查七步法、真实级联故障案例（MySQL 备份锁 |

- [[cpu-100-full-chain-diagnosis]] — CPU 100% 故障排查从告警到根因的全链路分析：排查七步法、真实级联故障案例（MySQL 备份锁

journalctl -u mysqld -f # 监控 MySQL 服务

| 数据库 | MySQL 5.7，独立 RDS |

- 对于生产环境核心业务数据库（如 MySQL / PostgreSQL）所在的磁盘，若出现坏道，**优先使用 mysqldump 或 pg_dump 逻辑导出恢复，而非在坏盘上执行 fsck -y**，以免数据错乱导致无法恢复

| 数据库（MySQL/Redis/PG） | `1` | 最大限度避免 Swap |

- 数据库慢查询（MySQL、PostgreSQL 等）

| **DB fsync 瓶颈** | wa 高, iostat 写延迟高, MySQL 进程 | `innodb_flush_log_at_trx_commit=1` + `sync_binlog=1` |

⚠️ 数据库盘（MySQL/PostgreSQL）出现坏道时，**优先 mysqldump / pg_dump 逻辑导出抢救数据，不要直接在坏盘上跑 fsck -y**——数据错乱后无法恢复。物理损坏抢救用 ddrescue 跳坏块（`ddrescue -f -n` 首轮 + `-r 3` 深度复读），勿用裸 dd。

| 怀疑数据库瓶颈 | `mysqldumpslow -s c -t 10 /var/log/mysql/slow.log` 统计慢查询 |