本文直接补齐关系型数据库的基本概念和常用操作。

本篇进一步落到实际数据库系统，重点介绍 Linux 运维中非常常见的 MySQL 与 PostgreSQL。内容覆盖数据库安装与服务管理、用户与权限、备份与恢复、日志、故障排查、性能与索引，以及复制和高可用的基础概念。

本文关注的是“如何理解和管理数据库系统”，而不是完整的 SQL 教程，因此不会展开大量 SQL 语法，也暂不讨论 Redis、MongoDB 等 NoSQL 数据库。

MySQL 与 PostgreSQL#

MySQL 和 PostgreSQL 都属于：

关系型数据库管理系统（RDBMS）

它们都以：

1
Table
2
Row
3
Column
4
Primary Key
5
Transaction
6
Index
7
SQL

等概念为基础。

但两者在：

1
SQL 能力
2
事务实现
3
索引类型
4
扩展机制
5
权限模型
6
存储架构
7
复制

等方面存在明显差异。

可以先建立这样的认识：

1
关系型数据库
2
      │
3
      ├── MySQL
4
      │
5
      └── PostgreSQL

它们解决的是相似的问题，但并不是：

1
两个名字不同、完全相同的数据库

更准确地说：

MySQL 和 PostgreSQL 是两个独立的 DBMS，各自拥有不同的实现和运维体系。

MySQL#

MySQL 是什么#

MySQL 是一种广泛使用的关系型数据库管理系统。

现代 Linux 环境中，MySQL Server 通常由：

1
mysqld

提供服务。

MySQL 官方文档将 mysqld 描述为执行 MySQL Server 核心工作的多线程服务器程序，它负责监听客户端连接并管理数据目录中的数据库和表。MySQL Reference Manual

可以简单理解为：

1
MySQL Client
2
     │
3
     ▼
4
  mysqld
5
     │
6
     ├── Connection
7
     ├── SQL
8
     ├── Transaction
9
     ├── Buffer
10
     ├── Log
11
     └── Storage Engine
12
             │
13
             ▼
14
          Database

MySQL 安装#

Debian / Ubuntu#

例如使用系统的软件包管理器：

1
sudo apt update
2
sudo apt install mysql-server

安装完成后可以：

1
mysql --version

查看客户端版本。

然后检查服务：

1
sudo systemctl status mysql

MySQL 官方 APT 安装文档也以 mysql-server 软件包和 systemctl 作为 Debian / Ubuntu 环境中的典型安装与管理方式。Installing MySQL with APT

RHEL 系#

在 RHEL 系环境中，具体安装方式取决于：

1
发行版版本
2
MySQL 官方仓库
3
系统仓库

实际安装前应确认仓库和版本策略。

安装完成后，服务名称可能是：

1
mysqld

可以：

1
sudo systemctl status mysqld

查看。

MySQL 官方文档也明确说明，使用 RPM 系安装时通常由 systemd 管理 MySQL 服务。Managing MySQL Server with systemd

MySQL 服务管理#

常见命令：

1
sudo systemctl start mysql
2
sudo systemctl stop mysql
3
sudo systemctl restart mysql
4
sudo systemctl status mysql

RHEL 系环境中可能使用：

1
sudo systemctl start mysqld
2
sudo systemctl stop mysqld
3
sudo systemctl restart mysqld
4
sudo systemctl status mysqld

具体服务名要以实际系统为准。

设置开机启动：

1
sudo systemctl enable mysql

或者：

1
sudo systemctl enable mysqld

MySQL 初始安全配置#

数据库安装完成后，不应该直接认为：

1
“服务启动了 = 可以投入生产”

还需要处理：

1
管理员账户
2
密码 / 认证
3
匿名账户
4
远程访问
5
测试数据库
6
权限

MySQL 官方安全指南建议遵循最小权限原则，并通过 GRANT / REVOKE 控制账户权限，不应随意授予过大的权限。MySQL Security Guidelines

MySQL 用户与权限#

创建用户#

MySQL 中使用：

1
CREATE USER 'app'@'localhost'
2
IDENTIFIED BY 'strong-password';

这里：

1
app

是数据库账户。

而：

1
'localhost'

表示这个账户对应的来源主机条件。

因此 MySQL 的账户概念可以理解为：

1
用户名
2
+
3
主机条件

例如：

1
'app'@'localhost'
2
'app'@'192.168.1.10'
3
'app'@'%'

在权限意义上并不等价。

授予权限#

例如：

1
GRANT SELECT, INSERT, UPDATE
2
ON appdb.*
3
TO 'app'@'localhost';

表示：

1
数据库 appdb
2
↓
3
允许 app
4
↓
5
SELECT / INSERT / UPDATE

查看权限：

1
SHOW GRANTS FOR 'app'@'localhost';

撤销：

1
REVOKE UPDATE
2
ON appdb.*
3
FROM 'app'@'localhost';

MySQL 官方推荐通过 GRANT、REVOKE 等机制管理权限，并强调不要授予超出需要范围的权限。MySQL Security Guidelines

MySQL 远程访问#

很多数据库“连接不上”的问题并不一定是：

1
用户名密码错误

还可能是：

1
监听地址
2
端口
3
防火墙
4
账户 Host 条件
5
认证插件

例如：

1
应用服务器
2
192.168.1.10
3

4
MySQL
5
192.168.1.20:3306

需要同时确认：

1
网络可达
2
+
3
3306 可访问
4
+
5
MySQL 正在监听
6
+
7
账户允许该来源连接

因此：

数据库用户权限和 Linux 网络防火墙是两个不同层次的问题。

PostgreSQL#

PostgreSQL 是什么#

PostgreSQL 是另一套成熟的开源关系型数据库管理系统。

它具有：

1
SQL
2
Transaction
3
MVCC
4
Index
5
WAL
6
Replication

等完整数据库能力。

官方 PostgreSQL 18 文档将数据库服务器管理划分为：

1
Installation
2
Server Setup and Operation
3
Server Configuration
4
Client Authentication
5
Database Roles
6
Backup and Restore
7
High Availability / Replication

等章节。PostgreSQL 18 Documentation

PostgreSQL 安装#

Debian / Ubuntu#

例如：

1
sudo apt update
2
sudo apt install postgresql

查看版本：

1
psql --version

检查服务：

1
sudo systemctl status postgresql

PostgreSQL 的 Cluster#

PostgreSQL 与 MySQL 的一个重要区别，是它经常使用：

Database Cluster

这一概念。

这里的 Cluster 不一定指：

1
多台服务器组成的集群

而是：

一个 PostgreSQL Server 实例管理的一组数据库及其共享系统对象。

可以简单理解：

1
PostgreSQL Instance
2
        │
3
        ▼
4
   Database Cluster
5
        │
6
   ┌────┼────┐
7
   ▼    ▼    ▼
8
 db1   db2   db3

这与 PostgreSQL 的具体目录结构和系统目录管理方式有关。

因此不要把：

1
PostgreSQL Cluster

和：

1
PostgreSQL High-Availability Cluster

直接画等号。

PostgreSQL 服务管理#

使用 systemd 时：

1
sudo systemctl start postgresql
2
sudo systemctl stop postgresql
3
sudo systemctl restart postgresql
4
sudo systemctl status postgresql

开机启动：

1
sudo systemctl enable postgresql

具体服务单元名称可能随着发行版和 PostgreSQL 安装方式有所差异。

PostgreSQL 用户与 Role#

PostgreSQL 使用：

Role（角色）

管理数据库身份和权限。

官方文档明确指出：

PostgreSQL 将“用户”和“组”的概念统一在 Role 中。

一个 Role 可以：

1
登录数据库
2
拥有对象
3
拥有权限
4
继承其他 Role 的权限

例如：

1
CREATE ROLE app LOGIN PASSWORD 'strong-password';

这里：

1
app
2
↓
3
Role
4

5
LOGIN
6
↓
7
允许登录

可以参考官方 Database Roles。

PostgreSQL 权限#

例如：

1
GRANT CONNECT
2
ON DATABASE appdb
3
TO app;

对表授权：

1
GRANT SELECT, INSERT, UPDATE
2
ON TABLE users
3
TO app;

撤销：

1
REVOKE UPDATE
2
ON TABLE users
3
FROM app;

PostgreSQL 权限通常涉及：

1
Database
2
Schema
3
Table
4
Sequence
5
Function

等对象。

因此在排查：

1
permission denied

时，需要先确定：

1
哪个 Role
2
+
3
哪个对象
4
+
5
缺少什么权限

MySQL 与 PostgreSQL 权限模型对比#

两者都有：

1
User / Role
2
Privilege
3
Grant
4
Revoke

但模型不同。

可以粗略理解：

1
MySQL
2
↓
3
Account
4
(user + host)
5

6
PostgreSQL
7
↓
8
Role
9
(Login / Membership / Privilege)

因此不能把 MySQL 的权限命令机械搬到 PostgreSQL。

例如：

1
MySQL
2
'user'@'host'
3

4
PostgreSQL
5
Role

这就是两个 DBMS 在权限模型上的明显差异。

数据库连接#

客户端连接数据库#

MySQL 常见：

1
mysql -h 127.0.0.1 -P 3306 -u app -p

PostgreSQL 常见：

1
psql -h 127.0.0.1 -p 5432 -U app -d appdb

连接信息通常包含：

1
Host
2
Port
3
Database
4
User
5
Password

默认端口#

常见默认端口：

数据库	默认端口
MySQL	`3306`
PostgreSQL	`5432`

例如：

1
MySQL
2
192.168.1.20:3306
3

4
PostgreSQL
5
192.168.1.20:5432

实际部署时当然可以修改。

因此排查连接问题时：

不要假设数据库一定监听默认端口。

首先应该使用：

1
ss -lntp

确认实际监听情况。

连接池#

Web 应用通常不会对每一个 HTTP 请求都重新创建数据库连接。

更典型的方式是：

1
Application
2
     │
3
     ▼
4
Connection Pool
5
     │
6
 ┌───┼───┐
7
 ▼   ▼   ▼
8
 C1  C2  C3
9
     │
10
     ▼
11
    DBMS

请求：

1
HTTP Request
2
    │
3
    ▼
4
Application
5
    │
6
    ▼
7
获取连接
8
    │
9
    ▼
10
执行 SQL
11
    │
12
    ▼
13
归还连接

连接池过小：

1
请求等待连接

连接池过大：

1
数据库连接数过多
2
↓
3
内存 / CPU / 锁压力增加

因此：

连接池是应用与数据库之间的重要容量控制点。

数据库备份#

为什么需要备份#

数据库存在：

1
磁盘损坏
2
误删
3
误更新
4
程序 Bug
5
人为操作错误
6
勒索 / 攻击

等风险。

因此：

数据库必须存在独立于数据库本身正常运行机制之外的备份策略。

需要区分：

1
事务持久性

和：

1
备份

前者解决：

1
数据库崩溃恢复

后者解决：

1
人为 / 逻辑 / 灾难性数据损失

MySQL 备份#

mysqldump#

MySQL 中最常见的逻辑备份工具之一：

1
mysqldump -u root -p appdb > appdb.sql

得到：

1
appdb.sql

之后可以恢复：

1
mysql -u root -p appdb < appdb.sql

可以简单理解：

1
Database
2
   │
3
   ▼
4
mysqldump
5
   │
6
   ▼
7
SQL Dump
8
   │
9
   ▼
10
恢复
11
   │
12
   ▼
13
Database

MySQL 逻辑备份的特点#

逻辑备份的优势：

1
可读
2
通用
3
迁移方便

但缺点也很明显：

1
数据量大时速度较慢
2
恢复时间可能较长
3
需要执行大量 SQL

因此大型数据库不能只依赖简单的 mysqldump。

MySQL 官方文档对逻辑备份、恢复以及其他备份方式都有专门说明。MySQL Backup and Recovery

MySQL 物理备份#

物理备份更接近：

1
复制数据库文件

而不是：

1
导出 SQL

例如：

1
Data Directory
2
      │
3
      ▼
4
Physical Backup
5
      │
6
      ▼
7
Restore

物理备份通常更适合：

1
大型数据库
2
快速恢复
3
完整实例迁移

但它通常要求：

1
备份工具
2
数据库状态
3
文件一致性
4
版本兼容

等条件更加严格。

MySQL 官方的备份文档同时涵盖逻辑和物理备份方案。

PostgreSQL 备份#

PostgreSQL 常见的逻辑备份工具：

1
pg_dump
2
pg_dumpall

例如：

1
pg_dump -U app appdb > appdb.sql

恢复：

1
psql -U app -d appdb < appdb.sql

这里：

1
pg_dump
2
↓
3
备份单个数据库
4

5
pg_dumpall
6
↓
7
备份整个 PostgreSQL Cluster 的逻辑对象

PostgreSQL 自定义格式备份#

pg_dump 不一定只能输出纯 SQL。

例如：

1
pg_dump -Fc -U app appdb > appdb.dump

然后可以通过：

1
pg_restore -U app -d appdb appdb.dump

进行恢复。

相比普通 SQL dump：

1
Custom Format
2
↓
3
更适合配合 pg_restore
4
↓
5
可以进行更灵活的恢复操作

PostgreSQL 物理备份#

PostgreSQL 还支持基于：

1
Base Backup
2
+
3
WAL

的物理备份和恢复体系。

例如：

1
Base Backup
2
     +
3
    WAL
4
     │
5
     ▼
6
恢复数据库

这与 PostgreSQL 的：

WAL（Write-Ahead Logging）

机制密切相关。

官方文档对 Backup and Restore 以及 WAL 归档、基础备份等内容都有详细说明。

MySQL 与 PostgreSQL 备份方式对比#

方式	MySQL	PostgreSQL
逻辑备份	`mysqldump`	`pg_dump`
全局逻辑备份	`mysqldump` 等	`pg_dumpall`
物理备份	有	有
日志恢复能力	Binlog 等	WAL
大型生产环境	通常需要专门备份方案	通常需要专门备份方案

因此：

备份命令只是第一步，真正重要的是“备份能不能恢复”。

恢复测试#

一个非常常见的错误是：

1
每天都有备份
2
↓
3
所以数据库安全

实际上更重要的问题是：

1
备份文件存在吗？
2
       ↓
3
完整吗？
4
       ↓
5
能恢复吗？
6
       ↓
7
恢复需要多久？
8
       ↓
9
恢复后的数据到哪个时间点？

所以数据库备份一定应该包含：

1
Backup
2
+
3
Restore Test

RPO 与 RTO#

数据库高可用和灾备中经常出现：

RPO#

Recovery Point Objective

表示：

可以接受最多丢失多少数据。

例如：

1
RPO = 5 min

意味着故障时希望：

1
最多损失约 5 分钟的数据变化

RTO#

Recovery Time Objective

表示：

希望在多长时间内恢复服务。

例如：

1
RTO = 30 min

意味着：

1
故障
2
↓
3
30 分钟内恢复服务

因此：

1
RPO
2
↓
3
最多丢多少数据
4

5
RTO
6
↓
7
最多停多久

MySQL 日志#

MySQL 的日志体系比较丰富。

常见日志包括：

1
Error Log
2
General Query Log
3
Slow Query Log
4
Binary Log

Error Log#

记录：

1
启动错误
2
崩溃
3
配置问题
4
严重异常

排查数据库：

1
启动失败
2
服务异常

时，首先就应该关注 Error Log。

Slow Query Log#

慢查询日志用于记录：

执行时间超过指定条件的查询。

它非常适合：

1
慢 SQL 分析

例如：

1
SQL
2
 ↓
3
执行 8 秒
4
 ↓
5
Slow Query Log

然后进一步：

1
EXPLAIN

检查执行计划。

Binary Log#

MySQL Binary Log（Binlog）非常重要。

它记录数据库中发生的：

1
数据修改事件

并广泛用于：

1
复制
2
增量恢复
3
数据同步

可以理解为：

1
Transaction
2
     │
3
     ▼
4
  Binlog
5
     │
6
     ├── Replica
7
     └── Recovery

PostgreSQL 日志#

PostgreSQL 常见日志用于记录：

1
启动 / 停止
2
连接
3
认证
4
错误
5
查询
6
检查点
7
恢复

具体日志行为由 PostgreSQL 的：

1
logging_collector
2
log_statement
3
log_min_duration_statement
4
log_min_messages

等配置控制。

官方文档中的 Error Reporting and Logging 对日志配置进行了详细说明。

PostgreSQL WAL#

PostgreSQL 非常重要的机制：

WAL（Write-Ahead Log）

其基本思想是：

1
数据修改
2
   │
3
   ▼
4
先写 WAL
5
   │
6
   ▼
7
之后再处理数据页面

这样数据库崩溃后可以根据 WAL 进行：

1
Crash Recovery

WAL 同时还是：

1
Streaming Replication
2
Point-in-Time Recovery

等机制的重要基础。

性能与索引#

为什么需要索引#

例如：

1
SELECT *
2
FROM users
3
WHERE email = 'alice@example.com';

如果：

1
users

有：

1
1000 万行

没有适当索引时，数据库可能需要扫描大量记录。

建立索引后，可以缩小查找范围。

因此：

1
Index
2
↓
3
减少需要检查的数据
4
↓
5
提高某些查询效率

MySQL 索引#

MySQL 中最常见的索引结构之一是：

1
B-Tree

例如：

1
CREATE INDEX idx_users_email
2
ON users(email);

查询：

1
SELECT *
2
FROM users
3
WHERE email = 'alice@example.com';

优化器可能选择：

1
Index Lookup

然后定位数据。

PostgreSQL 索引#

PostgreSQL 也支持：

1
B-tree
2
Hash
3
GiST
4
SP-GiST
5
GIN
6
BRIN

等不同索引类型。

其中最常用的仍然是：

1
B-tree

例如：

1
CREATE INDEX idx_users_email
2
ON users(email);

但是 PostgreSQL 的索引体系比简单的：

1
“只有 B+Tree”

更加丰富。

不同索引类型适合：

1
等值查询
2
范围查询
3
全文搜索
4
数组
5
JSON
6
空间数据
7
大范围顺序扫描

等不同场景。

官方文档：PostgreSQL Indexes。

EXPLAIN#

不能因为：

1
“建立了索引”

就认为：

1
“查询一定变快”

真正应该观察：

执行计划（Execution Plan）

MySQL：

1
EXPLAIN
2
SELECT *
3
FROM users
4
WHERE email = 'alice@example.com';

PostgreSQL：

1
EXPLAIN
2
SELECT *
3
FROM users
4
WHERE email = 'alice@example.com';

可以看到：

1
Seq Scan
2
Index Scan
3
Index Only Scan
4
Join
5
Cost
6
Rows

等信息。

全表扫描#

如果数据库决定：

1
Seq Scan

或者：

1
Full Table Scan

不一定表示数据库有问题。

有时候：

1
表很小

或者：

1
查询返回大量数据

全表扫描反而可能比使用索引更划算。

因此：

索引优化的核心不是“所有查询都必须走索引”，而是让优化器能够选择合适的访问路径。

联合索引#

例如：

1
CREATE INDEX idx_user
2
ON users(name, age);

可以用于某些涉及：

1
name
2
name + age

的查询。

但对于：

1
只查询 age

是否能够有效利用这个索引，要结合具体 DBMS 的优化器和执行计划判断。

因此不要机械记成：

1
有索引
2
↓
3
一定使用

慢查询排查#

数据库查询变慢时，可以形成：

1
慢查询
2
   ↓
3
找到 SQL
4
   ↓
5
EXPLAIN
6
   ↓
7
查看执行计划
8
   ↓
9
是否全表扫描？
10
   ↓
11
索引是否合理？
12
   ↓
13
数据量是否增长？
14
   ↓
15
是否存在锁等待？
16
   ↓
17
CPU / Memory / I/O

这样比直接：

1
“给字段加索引”

更加可靠。

数据库资源#

数据库性能不仅取决于 SQL。

还可能受到：

1
CPU
2
Memory
3
Disk I/O
4
Network
5
Connections
6
Locks
7
Cache

影响。

例如：

1
SQL 很快
2
但连接池耗尽

应用仍然可能：

1
请求超时

又例如：

1
SQL 没有问题

但：

1
磁盘 I/O 很慢

数据库仍然可能整体变慢。

因此：

数据库性能问题必须从 SQL、数据库内部状态和操作系统资源三个层次一起看。

MySQL 存储引擎#

MySQL 一个非常重要的概念是：

Storage Engine（存储引擎）

MySQL Server 的通用服务层和具体存储引擎之间存在分层。

常见存储引擎：

1
InnoDB

其中 InnoDB 是现代 MySQL 中最主要的事务型存储引擎。

可以简单理解：

1
MySQL Server
2
      │
3
      ▼
4
Storage Engine
5
      │
6
      ▼
7
Data / Index

这也是为什么 MySQL 的：

1
事务
2
锁
3
索引
4
日志

等行为不能完全脱离存储引擎理解。

PostgreSQL 的存储体系#

PostgreSQL 不采用与 MySQL InnoDB 完全相同的“可插拔存储引擎”模型。

它的核心数据管理由 PostgreSQL 本身的存储和执行架构负责。

因此：

1
MySQL
2
↓
3
Storage Engine 是非常重要的架构概念
4

5
PostgreSQL
6
↓
7
整体数据库引擎架构不同

这也是两者学习时不能简单套模板的地方。

MySQL 复制#

MySQL 可以通过：

Replication

让一个服务器从另一个服务器同步数据。

可以简单理解为：

1
Source
2
   │
3
   │ Binlog
4
   ▼
5
Replica
6
   │
7
   ▼
8
Replay

典型架构：

1
          Primary
2
             │
3
          Binlog
4
             │
5
       ┌─────┴─────┐
6
       ▼           ▼
7
   Replica 1   Replica 2

可以用于：

1
读扩展
2
备份辅助
3
故障切换基础

但：

Replication 不等于完整高可用。

还需要处理：

1
故障检测
2
角色切换
3
数据一致性
4
客户端重新连接

等问题。

PostgreSQL Streaming Replication#

PostgreSQL 常见复制方式：

Streaming Replication

可以简化成：

1
Primary
2
   │
3
   │ WAL
4
   ▼
5
Standby
6
   │
7
   ▼
8
Replay

Primary 持续产生：

1
WAL

Standby 接收并重放 WAL。

可以构建：

1
Primary
2
   │
3
   ├── Standby 1
4
   └── Standby 2

这样的复制结构。

主从复制并不等于高可用#

这是数据库运维中非常重要的一点。

假设：

1
Primary
2
   │
3
   ▼
4
Replica

即使有 Replica：

1
Primary 挂了

也不代表：

1
Replica 自动接管

因为完整高可用还需要：

1
故障检测
2
+
3
Leader Election / Failover
4
+
5
客户端切换
6
+
7
数据一致性
8
+
9
脑裂防护

等机制。

因此：

复制是高可用的基础能力之一，而不是高可用方案本身。

数据库高可用#

一个简单的高可用架构可以理解成：

1
                 Client
2
                   │
3
                   ▼
4
              Proxy / VIP
5
                   │
6
             ┌─────┴─────┐
7
             │           │
8
             ▼           ▼
9
          Primary      Standby
10
             │           ▲
11
             │           │
12
             └── Replication

如果：

1
Primary

发生故障：

1
Failover
2
   ↓
3
Standby
4
   ↓
5
Promote
6
   ↓
7
新的 Primary

客户端需要：

1
重新连接

因此一个真正可用的高可用方案一般还需要：

1
数据库
2
+
3
复制
4
+
5
故障检测
6
+
7
自动 / 半自动切换
8
+
9
客户端发现

MySQL 与 PostgreSQL 高可用思路#

方向	MySQL	PostgreSQL
主要复制基础	Binlog	WAL
常见复制	Source / Replica	Primary / Standby
日志	Binlog	WAL
故障切换	需要额外机制	需要额外机制
高可用	Replication + Failover	Streaming Replication + Failover

因此两套系统虽然：

1
实现方式不同

但运维思想高度相似：

1
主库
2
 ↓
3
复制日志
4
 ↓
5
备用节点
6
 ↓
7
故障检测
8
 ↓
9
切换
10
 ↓
11
恢复服务

数据库安全#

数据库安全不能只考虑：

1
用户名
2
密码

还应该包括：

1
监听地址
2
网络访问控制
3
数据库用户
4
权限
5
认证
6
TLS
7
日志
8
备份安全
9
密钥管理

例如：

1
Database
2
    │
3
    ├── 不必要的公网暴露
4
    ├── 弱密码
5
    ├── 过高权限
6
    └── 明文传输

都可能成为安全风险。

数据库不要直接暴露公网#

如果没有特殊需求：

1
Internet
2
   │
3
   ▼
4
Database :3306

通常不是好的设计。

更常见：

1
Internet
2
   │
3
   ▼
4
Nginx
5
   │
6
   ▼
7
Application
8
   │
9
   ▼
10
Database

也就是说：

数据库通常只需要对应用服务器开放，而不是对整个 Internet 开放。

因此数据库运维和 Linux 防火墙、网络管理是直接联系在一起的。

数据库故障排查#

当 Web 应用出现：

1
Database connection failed

可以建立如下思路：

1
应用
2
 ↓
3
数据库连接配置
4
 ↓
5
Host
6
 ↓
7
Port
8
 ↓
9
网络
10
 ↓
11
防火墙
12
 ↓
13
数据库监听
14
 ↓
15
用户名 / 密码
16
 ↓
17
权限
18
 ↓
19
数据库本身

典型连接故障#

Connection refused#

例如：

1
Connection refused

优先检查：

1
ss -lntp

确认数据库端口是否监听。

例如：

是否存在。

Timeout#

例如：

1
Connection timed out

更应该关注：

1
路由
2
防火墙
3
安全组
4
网络 ACL
5
链路

Authentication failed#

如果网络：

1
正常

端口：

1
正常

但认证失败：

1
Access denied
2
password authentication failed

那么重点关注：

1
用户名
2
密码
3
Host / Source
4
认证配置
5
权限

MySQL 日志排障#

例如 MySQL 启动失败：

1
systemctl status mysql

先看 systemd 状态。

再查看：

1
MySQL Error Log

重点关注：

1
配置错误
2
权限
3
数据目录
4
磁盘空间
5
端口冲突
6
InnoDB

例如：

1
Disk Full

可能导致：

1
数据库无法写入
2
日志无法增长
3
事务失败

PostgreSQL 日志排障#

PostgreSQL 同样可以：

1
systemctl status postgresql

然后查看对应日志。

重点关注：

1
认证
2
监听地址
3
端口
4
配置文件
5
WAL
6
恢复
7
磁盘
8
权限

如果出现：

1
database system is starting up

之类的信息，还需要结合当前数据库的：

1
Recovery
2
Replication
3
Startup

状态判断。

一个完整的数据库运维排障模型#

可以把前面的内容整合成：

1
                    Web Request
2
                         │
3
                         ▼
4
                    Application
5
                         │
6
                         ▼
7
                 Connection Pool
8
                         │
9
                         ▼
10
                  Database Connection
11
                         │
12
          ┌──────────────┼──────────────┐
13
          │              │              │
14
          ▼              ▼              ▼
15
       Network          Port           Auth
16
          │              │              │
17
          └──────────────┼──────────────┘
18
                         ▼
19
                        DBMS
20
                         │
21
              ┌──────────┼──────────┐
22
              │          │          │
23
              ▼          ▼          ▼
24
             SQL      Transaction   Lock
25
              │          │          │
26
              └──────────┼──────────┘
27
                         ▼
28
                     Optimizer
29
                         │
30
                         ▼
31
                       Index
32
                         │
33
                         ▼
34
                     Data / Cache
35
                         │
36
                         ▼
37
                       Disk

如果出现：

1
请求变慢

就可以逐层判断：

1
连接池？
2
   ↓
3
网络？
4
   ↓
5
数据库连接？
6
   ↓
7
锁？
8
   ↓
9
SQL？
10
   ↓
11
索引？
12
   ↓
13
磁盘？

而不是一看到数据库慢就：

1
“加 CPU”

或者：

1
“加索引”

MySQL 与 PostgreSQL 的对比#

项目	MySQL	PostgreSQL
类型	关系型数据库	关系型数据库
典型服务	`mysqld`	PostgreSQL server
默认端口	`3306`	`5432`
用户模型	User + Host	Role
常见客户端	`mysql`	`psql`
逻辑备份	`mysqldump`	`pg_dump`
关键日志	Binlog / Error / Slow	WAL / Error / Query Logs
常见索引	B-Tree	B-tree 等多种
复制基础	Binlog	WAL
典型复制	Source / Replica	Primary / Standby
权限管理	`GRANT` / `REVOKE`	`GRANT` / `REVOKE`
服务管理	systemd	systemd

这里最重要的不是：

1
谁更好

而是：

两者都是成熟的关系型数据库，但具体架构、配置和运维工具不同。

SQL 数据库系统的完整结构#

把这篇内容与上一篇的数据库架构结合起来，可以得到：

1
                        Web Application
2
                              │
3
                              ▼
4
                       Connection Pool
5
                              │
6
                              ▼
7
                    ┌─────────┴─────────┐
8
                    │                   │
9
                    ▼                   ▼
10
                  MySQL             PostgreSQL
11
                    │                   │
12
             ┌──────┼──────┐      ┌─────┼──────┐
13
             │      │      │      │     │      │
14
             ▼      ▼      ▼      ▼     ▼      ▼
15
            SQL   Txn   Index     SQL   Txn   Index
16
             │      │      │       │     │      │
17
             └──────┴──────┘       └─────┴──────┘
18
                    │                   │
19
                    ▼                   ▼
20
                 Storage             Storage
21
                    │                   │
22
                    ▼                   ▼
23
                   Disk                Disk

运维层面则是：

1
                   Database Operations
2
                           │
3
      ┌────────────────────┼────────────────────┐
4
      │                    │                    │
5
      ▼                    ▼                    ▼
6
    Install              Security             Backup
7
      │                    │                    │
8
      ▼                    ▼                    ▼
9
  systemd             User / Role         Logical Backup
10
      │               Privilege            Physical Backup
11
      ▼                    │                    │
12
   Config                  ▼                    ▼
13
      │                Network / TLS         Restore
14
      ▼                                         │
15
    Logs                                        ▼
16
      │                                        RPO/RTO
17
      ▼
18
 Troubleshooting
19
      │
20
      ├── Connection
21
      ├── SQL
22
      ├── Lock
23
      ├── Index
24
      ├── CPU
25
      ├── Memory
26
      └── I/O
27
                           │
28
                           ▼
29
                      High Availability
30
                           │
31
                   ┌───────┴───────┐
32
                   │               │
33
                Replication      Failover

数据库运维的核心思路#

学习 MySQL 和 PostgreSQL，不应该只记：

1
mysql 怎么安装
2
psql 怎么安装

更重要的是建立下面这套思维：

1
数据库有没有运行？
2
        ↓
3
监听在哪里？
4
        ↓
5
谁可以连接？
6
        ↓
7
谁拥有什么权限？
8
        ↓
9
数据如何备份？
10
        ↓
11
备份如何恢复？
12
        ↓
13
日志在哪里？
14
        ↓
15
SQL 为什么慢？
16
        ↓
17
索引是否合理？
18
        ↓
19
数据库是否受 CPU / Memory / I/O 限制？
20
        ↓
21
主库故障怎么办？

最终可以浓缩成：

1
安装
2
 ↓
3
配置
4
 ↓
5
权限
6
 ↓
7
连接
8
 ↓
9
SQL
10
 ↓
11
事务
12
 ↓
13
索引
14
 ↓
15
日志
16
 ↓
17
备份
18
 ↓
19
恢复
20
 ↓
21
复制
22
 ↓
23
高可用

这套知识已经覆盖了 Linux 运维岗位中最常见的数据库基础能力。

下一篇再继续学习：

1
NoSQL

就可以自然进入：

1
Redis
2
MongoDB

等非关系型数据库，而不会和 MySQL / PostgreSQL 的关系型数据库体系混在一起。

MySQL 与 PostgreSQL#

MySQL#

MySQL 是什么#

MySQL 安装#

Debian / Ubuntu#

RHEL 系#

MySQL 服务管理#

MySQL 初始安全配置#

MySQL 用户与权限#

创建用户#

授予权限#

MySQL 远程访问#

PostgreSQL#

PostgreSQL 是什么#

PostgreSQL 安装#

Debian / Ubuntu#

PostgreSQL 的 Cluster#

PostgreSQL 服务管理#

PostgreSQL 用户与 Role#

PostgreSQL 权限#

MySQL 与 PostgreSQL 权限模型对比#

数据库连接#

客户端连接数据库#

默认端口#

连接池#

数据库备份#

为什么需要备份#

MySQL 备份#

mysqldump#

MySQL 逻辑备份的特点#

MySQL 物理备份#

PostgreSQL 备份#

PostgreSQL 自定义格式备份#

PostgreSQL 物理备份#

MySQL 与 PostgreSQL 备份方式对比#

恢复测试#

RPO 与 RTO#

RPO#

RTO#

MySQL 日志#

Error Log#

Slow Query Log#

Binary Log#

PostgreSQL 日志#

PostgreSQL WAL#

性能与索引#

为什么需要索引#

MySQL 索引#

PostgreSQL 索引#

EXPLAIN#

全表扫描#

联合索引#

慢查询排查#

数据库资源#

MySQL 存储引擎#

PostgreSQL 的存储体系#

MySQL 复制#

PostgreSQL Streaming Replication#

主从复制并不等于高可用#

数据库高可用#

MySQL 与 PostgreSQL 高可用思路#

数据库安全#

数据库不要直接暴露公网#

数据库故障排查#

典型连接故障#

Connection refused#

Timeout#

Authentication failed#

MySQL 日志排障#

PostgreSQL 日志排障#

一个完整的数据库运维排障模型#

MySQL 与 PostgreSQL 的对比#

SQL 数据库系统的完整结构#

数据库运维的核心思路#

外部参考#