存储与数据库 on 扎塔-Zata

S3 兼容存储踩坑记：boto3 新默认校验和撞上 NotImplemented

Thu, 10 Sep 2026 23:58:52 +0800

一场"全线 500"的发布事故

用自家 CLI 发布一篇博客，服务端返回 500。第一反应：肯定是包格式不对——毕竟几分钟前刚被 422 拒过一次（一个 2.9MB 的自包含 HTML 超了单条目 2MiB 上限），说明接口是通的，可能是我 ZIP 打包的方式不合规范。

于是按标准流程排查：换 Markdown 源文件 + 图片资源重新打包、用最小草稿（三行文字的 md）测基本链路、HTML 单文件再试一遍……结果所有创建请求一律 500，draft 和 publish 两个端点无一幸免。

但诡异的是：登录正常，草稿列表正常，健康检查正常，公开博客列表也能刷出来。所有读路径全绿，所有写路径全红。

如果真是包格式问题，最小草稿不可能挂；如果是认证问题，读接口不可能全通。这不像"我的请求有问题"，更像"服务端某个环节坏了"。

422 和 500 之间隔着一道分界线

回头看现象，有一条隐藏的分界线：

超限的 index.html 报 422（校验错误，Zip entry exceeds the 2 MiB limit）
所有通过校验的请求报 500

后端是分层架构：API 层收包 → core 层的 BlogService.extract_zip_package 做校验（格式、大小、路径白名单、symlink）→ 校验通过后 upload_blog 把正文和附件逐个写入对象存储。

422 在校验层抛出，说明请求已经正常穿过 API 层；500 卡在校验通过后的第一步——put_object。把服务端日志拉出来，最底下赫然一行：

botocore.exceptions.ClientError: An error occurred (NotImplemented) when
calling the PutObject operation: Aws MultiChunkedEncoding
STREAMING-UNSIGNED-PAYLOAD-TRAILER is not supported.

问题根本不在博客业务，也不在包格式——是对象存储的写入挂了。博客发布只是撞在枪口上的第一个受害者：任何要往 S3 写东西的功能（博客、语音、知识库）此时全部阵亡。

先补一点背景：S3 兼容生态与请求编码

S3 API 是事实标准，但"兼容"是程度问题

AWS S3 的 REST API 已经是对象存储的事实标准，MinIO、Cloudflare R2、Backblaze B2、各家云厂商的兼容端点都实现了这套协议。自建 MinIO 时，客户端通过几个参数接入：

boto3.client(
 "s3",
 endpoint_url="http://your-minio:9000", # 指向自建端点，而非 aws
 region_name="us-east-1", # MinIO 通常随便填一个
 aws_access_key_id=...,
 aws_secret_access_key=...,
 config=boto3.session.Config(
 s3={"addressing_style": "path"}, # 关键：path-style
 ),
)

其中 addressing_style 决定 bucket 怎么进 URL：path 风格是 http://endpoint/bucket/key，virtual_hosted 风格是 http://bucket.endpoint/key。自建 MinIO 没法给每个 bucket 配域名泛解析，所以必须用 path-style——这是自建存储的第一个常识坑。

但"实现了 S3 API"不等于"实现了 AWS 最新加的每一个字段"。S3 协议在演进，兼容实现永远在追赶，追赶不上的时候，就会返回一个很直白的错误码：NotImplemented。

签名 V4 之下，请求体有三种"泳姿"

AWS 签名协议 V4 在传输 payload 时有这么几种形态：

形态	特点
signed payload	请求体整体参与签名计算，头里放完整哈希
`UNSIGNED-PAYLOAD`	请求体不参与签名，靠 TLS 保证完整性
`STREAMING-*`	请求体按 `aws-chunked` 分块流式传输，边传边签

而这次出事的 STREAMING-UNSIGNED-PAYLOAD-TRAILER 是最新的变体：分块流式 + 不签名 + trailer——即在所有数据块传完之后，再追加一个尾部块，携带整个请求体的 CRC32 校验和。这套机制是 AWS 2024 年底力推的"默认数据完整性"改造的一部分。

根因：boto3 1.36 改了一个默认值

2025 年 1 月，boto3 1.36.0 发布，官方 changelog 里有一条不起眼的变更：

Default value of request_checksum_calculation is changed from when_required to when_supported.

翻译成人话：

以前（when_required）：只有 API 明确要求校验和时才算。PutObject 不要求，所以请求体就是普通字节流，任何 S3 兼容实现都吃得下。
现在（when_supported）：只要 API 支持校验和（PutObject 正好支持），就默认给请求体算 CRC32，并用上面那套 STREAMING-UNSIGNED-PAYLOAD-TRAILER 编码传输。

于是新版 boto3 对旧 MinIO（以及一批没跟进的兼容端点）发出的每个 PutObject 都长成了它们看不懂的样子，对端的回应整齐划一：NotImplemented。

为什么是"部署之后"才炸？仓库里 pyproject.toml 写的是 boto3>=1.43.28，依赖锁在 1.43.28。上一版镜像构建时拉的依赖、和这次重新构建拉的依赖，中间隔着这次默认值变更——代码一行没改，重新构建镜像本身就成了变更。这也是"锁文件 + 常态化重新部署"模式的一个隐性代价：依赖漂移会以最意想不到的方式找上门。

修复：一行 Config，三个层次

修复本身轻得可笑，在创建 boto3 客户端的 Config 里显式把行为钉回旧默认：

# 修复前：跟随 SDK 默认，1.36+ 对 PutObject 附带流式校验尾
config=boto3.session.Config(s3={"addressing_style": addressing_style})

# 修复后：仅在 API 要求时才计算校验和
config=boto3.session.Config(
 s3={"addressing_style": addressing_style},
 request_checksum_calculation="when_required",
)

除了改代码，还有两条等价路径，按生效成本排序：

环境变量（不重新构建镜像，改完配置重启即生效）：给后端进程加 AWS_REQUEST_CHECKSUM_CALCULATION=when_required，botocore 会读这个变量；
代码 Config（本文做法）：写死在适配器里，不依赖部署环境是否记得配这个变量；
升级存储端：新版本 MinIO 已支持流式校验尾，升级后可以吃回新默认。但注意必须升到 2026-04 之后的补丁版本——这条 trailer 路径先后曝出 CVE-2025-31489、CVE-2026-40344 等认证绕过漏洞（签名校验不完整，持有任意 secret 即可上传），修复分别落在 RELEASE.2025-04-03T14-56-28Z 和 RELEASE.2026-04-11T03-20-12Z。对安全敏感的自建场景，when_required 依旧是更稳的答案。但"为了让客户端新默认能跑而去升级存储"这个依赖方向，在自建场景里通常不如反过来稳。

选代码层还有一个架构上的理由：全仓库只有一个创建 boto3 客户端的地方——infrastructure 层的对象存储适配器，博客、语音、知识库全部经由它读写。修一处，全站愈合；这也意味着这类坑永远值得修在适配器里，而不是散落在各调用方。

同类清扫：适配器里还埋着一个 ASCII 坑

顺着这次排查把对象存储适配器翻了一遍，发现它早已修过另一个"协议约束"类的问题，记录于此，因为它们本质上是同一类坑：S3 的某些约束不在文档第一页，而在 HTTP 协议的物理规则里。

S3 的用户元数据（x-amz-meta-*）走的是 HTTP header，而 RFC 7230 规定 header 值必须是 ASCII。存中文描述时，botocore 的 validate_ascii_metadata 会在发请求之前就拒绝你：

put_object(key=..., data=..., metadata={"title": "融入"}) # ParamValidationError

适配器里的解法是"写入时编码 + 侧车标记还原"：非 ASCII 值先 percent-encode，同时多写一个 <key>-encoding: utf-8-pct 的侧车键；读取时发现有侧车标记就 unquote 还原。不依赖任何带外信息，元数据自描述。

def _sanitize_s3_metadata(metadata):
 for key, value in metadata.items():
 if value.isascii():
 sanitized[key] = value
 else:
 sanitized[key] = quote(value, safe="") # 值编码
 sanitized[f"{key}-encoding"] = "utf-8-pct" # 侧车标记

把它和这次的校验和坑放在一起看，S3 兼容存储的踩坑地图就清晰了：一类的坑源于"协议在演进，兼容端在追赶"（NotImplemented）；另一类源于"协议在收紧，客户端在把关"（ASCII 校验）。前者修客户端编码方式，后者修数据编码方式，但都该修在同一个适配器里。

验证

修复的验证分三层，也正好对应问题的影响面：

单元测试：对象存储适配器的元数据编解码测试全过，确认 Config 变更不影响既有行为；
影响面：全仓库搜索 boto3.client 只有适配器一处调用点——博客、语音、知识库三条业务线同时被这一行修复覆盖；
真实入口：重新部署后，用 CLI 以原来的命令重新发布那篇文章，一次通过，公开页面正常渲染。

顺带一提，之前 422 拒掉的那个 2.9MB 自包含 HTML，最后也没有硬塞进去，而是改用设计内的路径：Markdown 正文 + 图片平铺进 assets/ 打包上传。事后看这次事故像是两件事，其实共享同一个教训——别和平台默认值较劲，走它给你留的路。

几点收获

“兼容 S3"是一个光谱，不是一个开关。协议基础操作（对象增删改查）早就稳定，差异都藏在演进中的新特性里。判断一个兼容端点的成色，看它对最新协议扩展的支持比看 README 有用。
SDK 的默认值也是 API。boto3 这次变更完全符合语义化版本（major 没动，默认值动了），但对你来说行为就是变了。升级依赖 = 引入一次隐形变更，重新部署和改代码应该获得同级别的敬畏。
读写分离是天然的故障定位器。“读全绿、写全红"直接把嫌疑范围从整个 API 收窄到存储写入路径。分层架构平时的意义在排障时兑现：日志栈从 API 层一路穿到 botocore，每层只做一件事，所以每一栈帧都在缩小包围圈。
报错信息里最值钱的词是 NotImplemented。它不是"你错了”，而是"我们（实现方）还没做这个”——看到它就该去查协议演进和版本差异，而不是盯着自己的请求参数找茬。

数据库备份实战

Thu, 28 May 2026 14:55:07 +0800

前言

数据是企业的核心资产，数据库备份是数据安全的最后一道防线。本文将系统介绍 PostgreSQL 和 MySQL 的备份方法、自动化策略以及恢复演练流程。

一、PostgreSQL 备份

1.1 pg_dump 基础用法

pg_dump 是 PostgreSQL 最常用的逻辑备份工具，支持单数据库导出。

# 基本备份命令
pg_dump -h localhost -U postgres -d mydb > backup.sql

# 压缩备份（推荐）
pg_dump -h localhost -U postgres -d mydb -Fc > backup.dump

# 仅备份结构（不含数据）
pg_dump -h localhost -U postgres -d mydb --schema-only > schema.sql

# 仅备份数据（不含结构）
pg_dump -h localhost -U postgres -d mydb --data-only > data.sql

# 备份指定表
pg_dump -h localhost -U postgres -d mydb -t users -t orders > tables.sql

参数说明：

参数	说明
`-h`	数据库主机地址
`-U`	连接用户名
`-d`	数据库名称
`-Fc`	自定义格式压缩（推荐，支持并行恢复）
`-t`	指定备份的表

1.2 pg_dumpall 全库备份

备份整个 PostgreSQL 实例（所有数据库 + 全局对象）：

# 备份所有数据库和全局对象（角色、表空间等）
pg_dumpall -h localhost -U postgres > all_databases.sql

# 仅备份全局对象（角色定义）
pg_dumpall -h localhost -U postgres --globals-only > globals.sql

1.3 恢复方法

# 恢复 SQL 格式备份
psql -h localhost -U postgres -d mydb < backup.sql

# 恢复自定义格式备份（支持并行）
pg_restore -h localhost -U postgres -d mydb -j 4 backup.dump

# 恢复前创建新数据库
createdb -h localhost -U postgres mydb_restore
pg_restore -h localhost -U postgres -d mydb_restore backup.dump

二、MySQL 备份

2.1 mysqldump 基础用法

# 基本备份命令
mysqldump -h localhost -u root -p mydb > backup.sql

# 备份所有数据库
mysqldump -h localhost -u root -p --all-databases > all_databases.sql

# 备份指定表
mysqldump -h localhost -u root -p mydb users orders > tables.sql

# 仅备份结构
mysqldump -h localhost -u root -p mydb --no-data > schema.sql

# 仅备份数据
mysqldump -h localhost -u root -p mydb --no-create-info > data.sql

推荐参数组合：

# 生产环境推荐参数
mysqldump -h localhost -u root -p \
 --single-transaction \  # InnoDB 一致性快照
 --routines \  # 包含存储过程和函数
 --triggers \  # 包含触发器
 --events \  # 包含事件
 --master-data=2 \  # 记录 binlog 位置（用于主从同步）
 mydb > backup.sql

2.2 恢复方法

# 恢复数据库
mysql -h localhost -u root -p mydb < backup.sql

# 恢复所有数据库
mysql -h localhost -u root -p < all_databases.sql

三、其他 PostgreSQL 图形化工具

除了 Navicat，还有多种优秀的 PostgreSQL 客户端工具支持备份和恢复功能。

3.1 pgAdmin

pgAdmin 是 PostgreSQL 官方推荐的免费图形化管理工具：

安装方法：

# 使用 Homebrew 安装（macOS）
brew install --cask pgadmin4

# 或从官网下载：https://www.pgadmin.org/download/

备份步骤：

连接数据库服务器，选择目标数据库
右键点击数据库 →「备份」
配置备份选项：
- 格式：Custom（推荐）、Directory、Plain SQL、Tar
- 编码：UTF8（推荐）
- 中定义：选择「仅结构」或「结构和数据」
选择备份文件保存位置，点击「备份」

恢复步骤：

右键点击目标数据库 →「恢复」
选择备份文件（.backup 或 .dump）
配置恢复选项：
- 架构：选择要恢复的 schema
- 数据：选择要恢复的表
点击「恢复」执行

优点：

免费开源，官方推荐
功能全面，支持服务器管理
跨平台（Windows/macOS/Linux）

缺点：

界面较复杂，新手上手较难
大数据库备份可能较慢

3.2 DBeaver

DBeaver 是一款功能强大的免费数据库管理工具，支持 PostgreSQL 及多种数据库：

安装方法：

# 使用 Homebrew 安装（macOS）
brew install --cask dbeaver-community

# 或从官网下载：https://dbeaver.io/download/

备份步骤：

右键点击数据库 →「工具」→「备份数据库」
选择备份对象（整个库或指定表）
配置备份选项：
- 格式：SQL、Dump、CSV 等
- 选项：包含索引、触发器、外键等
保存备份文件

恢复步骤：

右键点击目标数据库 →「工具」→「恢复数据库」
选择备份文件
配置恢复选项
执行恢复

优点：

完全免费开源
支持 80+ 种数据库
界面友好，功能丰富
支持数据导出/导入

缺点：

功能较多，界面稍显复杂

3.3 DataGrip

JetBrains DataGrip 是一款专业的数据库 IDE（付费）：

安装方法：

# 使用 Homebrew 安装（macOS）
brew install --cask datagrip

# 或从官网下载：https://www.jetbrains.com/datagrip/download/

备份方式：

右键数据库 →「Dump to File」导出
使用 Database Diff 进行数据库同步备份

特点：

强大的 SQL 编辑和调试功能
支持多数据库管理
与 JetBrains 全家桶集成良好

3.4 HeidiSQL

HeidiSQL 主要用于 MySQL/MariaDB，但也支持 PostgreSQL：

备份：

右键数据库 →「导出数据库为 SQL」
支持自定义导出选项

特点：

免费、轻量级
Windows 专用

3.5 phpPgAdmin

基于 Web 的 PostgreSQL 管理工具：

特点：

浏览器访问，无需安装客户端
适合服务器管理
功能相对基础

3.6 Adminer

轻量级单文件数据库管理工具：

特点：

仅一个 PHP 文件，非常轻量
支持 PostgreSQL、MySQL、MongoDB 等
可直接通过 Web 访问

3.7 工具对比

工具	类型	价格	跨平台	特点
Navicat	桌面应用	付费	Windows/macOS/Linux	功能全面，界面美观
pgAdmin	桌面应用	免费	全平台	官方推荐，功能强大
DBeaver	桌面应用	免费	全平台	开源社区活跃
DataGrip	IDE	付费	全平台	开发者友好
HeidiSQL	桌面应用	免费	Windows	轻量级
phpPgAdmin	Web 应用	免费	全平台	无需安装客户端
Adminer	Web 应用	免费	全平台	极轻量级

3.8 命令行工具补充

除了图形化工具，以下命令行工具也非常有用：

pg_dumpall（已介绍）：备份所有数据库

pg_dumpall -h localhost -U postgres > all.sql

psql（已介绍）：恢复 SQL 文件

psql -h localhost -U postgres -d mydb < backup.sql

pg_basebackup：物理备份（完整数据库复制）

# 创建物理备份
pg_basebackup -h localhost -U postgres -D /backup/base -Ft -z -P

# 恢复物理备份
pg_restore -d postgres /backup/base

Barman：企业级备份管理工具

# 配置备份服务器
barman check pg_server
barman backup pg_server
barman recover pg_server latest /var/lib/postgresql/data

四、Navicat 图形化备份

Navicat 是一款流行的数据库管理工具，支持 MySQL、PostgreSQL、SQL Server、Oracle 等多种数据库，提供直观的图形界面进行备份操作。

安装方法：

# 使用 Homebrew 安装 Navicat Premium（macOS）
brew install --cask navicat-premium

# 或安装 Navicat for PostgreSQL 专用版
brew install --cask navicat-for-postgresql

# 或从官网下载：https://www.navicat.com.cn/download/navicat-premium

4.1 PostgreSQL 备份

连接数据库：在左侧连接列表中选择 PostgreSQL 连接
开始备份：
- 右键点击目标数据库 → 选择「备份数据库」
- 或菜单栏选择「工具」→「备份数据库」
配置备份选项：
- 选择备份格式（建议选择「自定义」格式）
- 可选择要包含的对象（表、视图、函数等）
保存备份：点击「开始」后选择保存位置

4.2 MySQL 备份

连接数据库：在左侧连接列表中选择 MySQL 连接
数据同步（迁移备份）：
- 菜单栏选择「工具」→「数据同步」
- 源选择当前数据库
- 目标选择文件或另一个数据库
导出数据库：
- 右键数据库 →「转储 SQL 文件」→「结构和数据」或「仅结构」
- 自动生成 .sql 文件保存到本地

4.3 定时自动备份（Navicat Premium）

Navicat Premium 支持定时任务自动备份：

新建批处理作业：
- 菜单栏选择「工具」→「自动运行」或「计划」
- 点击「新建批处理作业」
添加备份任务：
- 从左侧拖拽「备份」任务到右侧流程区
- 选择连接和数据库
配置定时计划：
- 勾选「计划」选项卡
- 设置执行频率（每天、每周等）
- 设置执行时间
保存并启用：
- 保存批处理作业
- 勾选「启用」启动定时任务

4.4 Navicat Cloud 备份

Navicat Cloud 提供云端备份同步功能：

登录 Navicat Cloud：
- 菜单栏「文件」→「登录 Navicat Cloud」
- 输入账号密码
同步备份：
- 右键数据库 →「备份到 Navicat Cloud」
- 或通过「工具」→「同步」上传备份
恢复云端备份：
- 从 Navicat Cloud 下载备份文件
- 恢复到本地数据库

4.5 Navicat 恢复数据库

备份的最终目的是恢复，Navicat 提供了便捷的恢复功能：

PostgreSQL 恢复步骤：

右键点击目标数据库 → 选择「还原数据库」
选择备份文件（.backup 或 .dump 格式）
配置恢复选项：
- 仅还原结构：只恢复表结构，不恢复数据
- 仅还原数据：只恢复数据，表结构需已存在
- 结构和数据：完整恢复（推荐）
点击「开始」执行恢复

MySQL 恢复步骤：

运行 SQL 文件：
- 右键目标数据库 →「运行 SQL 文件」
- 选择之前导出的 .sql 备份文件
- 执行导入
数据同步恢复：
- 菜单栏「工具」→「数据同步」
- 源选择备份文件或备份库
- 目标选择要恢复的数据库
- 执行同步

恢复注意事项：

场景	注意事项
覆盖恢复	确保目标库已清空或删除，避免数据冲突
部分恢复	可选择仅恢复特定表，减少恢复时间
跨版本恢复	高版本备份可能无法恢复到低版本数据库
字符集问题	确保备份和恢复使用相同字符集，避免乱码

4.6 Navicat 备份注意事项

注意事项	说明
备份位置	建议保存到非系统盘，避免系统崩溃丢失
文件命名	包含日期时间，便于追溯（如 `mydb_20260528.sql`）
定期检查	定期验证备份文件能否正常恢复
大数据库	超大数据库建议使用命令行工具，性能更优
密码保护	敏感数据库建议设置备份文件密码

五、自动化备份脚本

5.1 PostgreSQL 自动备份脚本

#!/bin/bash
# pg_backup.sh - PostgreSQL 自动备份脚本

# 配置变量
PG_HOST="localhost"
PG_USER="postgres"
PG_PORT="5432"
BACKUP_DIR="/backup/postgresql"
RETENTION_DAYS=7
DATE=$(date +%Y%m%d_%H%M%S)

# 创建备份目录
mkdir -p $BACKUP_DIR

# 获取所有数据库列表
DATABASES=$(psql -h $PG_HOST -U $PG_USER -p $PG_PORT -t -c "SELECT datname FROM pg_database WHERE datistemplate = false;")

# 遍历备份每个数据库
for DB in $DATABASES; do
 DB=$(echo $DB | tr -d ' ')
 if [ -n "$DB" ]; then
 echo "正在备份数据库: $DB"
 pg_dump -h $PG_HOST -U $PG_USER -p $PG_PORT -d $DB -Fc > "$BACKUP_DIR/${DB}_${DATE}.dump"
 fi
done

# 清理过期备份
find $BACKUP_DIR -name "*.dump" -mtime +$RETENTION_DAYS -delete

echo "备份完成！"

5.2 MySQL 自动备份脚本

#!/bin/bash
# mysql_backup.sh - MySQL 自动备份脚本

# 配置变量
MYSQL_HOST="localhost"
MYSQL_USER="root"
MYSQL_PASS="your_password"
BACKUP_DIR="/backup/mysql"
RETENTION_DAYS=7
DATE=$(date +%Y%m%d_%H%M%S)

# 创建备份目录
mkdir -p $BACKUP_DIR

# 获取所有数据库列表
DATABASES=$(mysql -h $MYSQL_HOST -u $MYSQL_USER -p$MYSQL_PASS -e "SHOW DATABASES;" | grep -v Database | grep -v information_schema | grep -v performance_schema)

# 遍历备份每个数据库
for DB in $DATABASES; do
 echo "正在备份数据库: $DB"
 mysqldump -h $MYSQL_HOST -u $MYSQL_USER -p$MYSQL_PASS \
 --single-transaction --routines --triggers --events \
 $DB | gzip > "$BACKUP_DIR/${DB}_${DATE}.sql.gz"
done

# 清理过期备份
find $BACKUP_DIR -name "*.sql.gz" -mtime +$RETENTION_DAYS -delete

echo "备份完成！"

5.3 配置定时任务

# 编辑 crontab
crontab -e

# 每天凌晨 2 点执行备份
0 2 * * * /scripts/pg_backup.sh >> /var/log/pg_backup.log 2>&1
0 2 * * * /scripts/mysql_backup.sh >> /var/log/mysql_backup.log 2>&1

六、云存储备份

5.1 上传到 AWS S3

#!/bin/bash
# upload_to_s3.sh

BACKUP_DIR="/backup/postgresql"
S3_BUCKET="s3://your-bucket/database-backups"
DATE=$(date +%Y%m%d)

# 同步备份文件到 S3
aws s3 sync $BACKUP_DIR $S3_BUCKET/$DATE/ \
 --storage-class STANDARD_IA \
 --delete

# 设置生命周期规则自动清理旧备份（在 S3 控制台配置）

5.2 上传到 Cloudflare R2

# 使用 rclone 同步到 R2
rclone sync /backup/postgresql r2:your-bucket/database-backups/$(date +%Y%m%d)/

七、备份策略最佳实践

6.1 备份类型对比

类型	说明	优点	缺点
全量备份	备份所有数据	恢复简单快速	占用空间大，耗时长
增量备份	仅备份变化数据	占用空间小	恢复需要全量+所有增量
差异备份	备份自上次全量后的变化	恢复比增量快	比增量占用更多空间

6.2 推荐策略

生产环境推荐备份策略：

┌─────────────────────────────────────────────────────┐
│ 周日：全量备份 │
│ 周一~周六：增量备份 │
│ 保留周期：至少 4 周 │
│ 异地备份：同步到云存储（S3/R2/OSS） │
│ 恢复演练：每月至少 1 次 │
└─────────────────────────────────────────────────────┘

6.3 备份验证清单

备份文件是否完整生成
备份文件大小是否合理
备份是否按时执行（检查 cron 日志）
异地备份是否同步成功
定期进行恢复演练

八、数据恢复（命令行）

命令行恢复是生产环境中最重要的技能，本节详细介绍 PostgreSQL 和 MySQL 的恢复操作。

7.1 PostgreSQL 恢复详解

基础恢复命令：

# 恢复 SQL 格式备份（纯文本）
psql -h localhost -U postgres -d mydb < backup.sql

# 恢复自定义格式备份（.dump 文件）
pg_restore -h localhost -U postgres -d mydb backup.dump

# 并行恢复（加快大数据库恢复速度）
pg_restore -h localhost -U postgres -d mydb -j 4 backup.dump

创建新数据库恢复：

# 1. 创建新数据库
createdb -h localhost -U postgres mydb_new

# 2. 恢复数据到新数据库
pg_restore -h localhost -U postgres -d mydb_new backup.dump

恢复前清理目标库：

# 如果目标库存在且要完全覆盖，先删除
dropdb -h localhost -U postgres mydb

# 重新创建数据库
createdb -h localhost -U postgres mydb

# 恢复数据
pg_restore -h localhost -U postgres -d mydb backup.dump

选择性恢复（仅恢复指定表）：

# 列出备份中的所有对象
pg_restore -l backup.dump

# 仅恢复特定表
pg_restore -h localhost -U postgres -d mydb -t users backup.dump
pg_restore -h localhost -U postgres -d mydb -t orders backup.dump

# 仅恢复存储过程
pg_restore -h localhost -U postgres -d mydb -P -t function_name backup.dump

恢复前检查选项：

# 先检查备份文件内容（不执行恢复）
pg_restore --help # 查看所有选项

# 不带数据恢复（仅检查结构）
pg_restore -h localhost -U postgres -d mydb --schema-only backup.dump

# 恢复到另一个表空间
pg_restore -h localhost -U postgres -d mydb --tablespace=new_space backup.dump

7.2 MySQL 恢复详解

基础恢复命令：

# 恢复单个数据库
mysql -h localhost -u root -p mydb < backup.sql

# 恢复所有数据库（备份时包含 CREATE DATABASE 语句）
mysql -h localhost -u root -p < all_databases.sql

# 恢复压缩备份（gzip 格式）
gunzip < backup.sql.gz | mysql -h localhost -u root -p mydb

# 或使用 zcat
zcat backup.sql.gz | mysql -h localhost -u root -p mydb

指定字符集恢复：

# 如果有字符集问题，指定字符集
mysql -h localhost -u root -p --default-character-set=utf8mb4 mydb < backup.sql

# 或在 SQL 文件开头设置
mysql -h localhost -u root -p --init-command="SET NAMES utf8mb4" mydb < backup.sql

覆盖恢复（先清空后导入）：

# 1. 删除并重建数据库
mysql -h localhost -u root -p -e "DROP DATABASE IF EXISTS mydb; CREATE DATABASE mydb;"

# 2. 恢复数据
mysql -h localhost -u root -p mydb < backup.sql

选择性恢复（仅恢复指定表）：

# 方法1：使用 sed 提取指定表
sed -n '/DROP TABLE.*`表名`;/,/UNLOCK TABLES;/p' backup.sql > table.sql
mysql -h localhost -u root -p mydb < table.sql

# 方法2：使用 mysqlimport（需要先创建空表）
mysqlimport -h localhost -u root -p mydb table_data.txt

# 方法3：使用 mydumper 并行导出/导入指定表
mydumper -h localhost -u root -p -o /backup/tables -t users -t orders
myloader -h localhost -u root -p -d /backup/tables -o mydb

表结构与数据分离恢复：

# 仅恢复表结构
mysql -h localhost -u root -p mydb < schema.sql

# 仅恢复数据（表结构需已存在）
mysql -h localhost -u root -p mydb --init-command="SET foreign_key_checks=0; SET unique_checks=0; SET SESSION tx_isolation='READ-UNCOMMITTED';" < data.sql

7.3 恢复高级技巧

时间点恢复（PITR）：

PostgreSQL 支持基于时间点的恢复：

# 1. 停止 PostgreSQL
sudo systemctl stop postgresql

# 2. 备份当前数据目录
sudo cp -r /var/lib/postgresql/data /var/lib/postgresql/data.bak

# 3. 恢复到指定时间点
PGDATA=/var/lib/postgresql/data pg_restore -P --clean --create --dbname=postgres backup.dump

# 或编辑 postgresql.conf 设置恢复目标时间
# recovery_target_time = '2026-05-28 10:00:00'

MySQL binlog 恢复：

# 1. 确定恢复时间点
mysqlbinlog --start-datetime="2026-05-28 10:00:00" --stop-datetime="2026-05-28 12:00:00" mysql-bin.000001 > recovery.sql

# 2. 应用恢复
mysql -h localhost -u root -p mydb < recovery.sql

增量备份恢复：

# PostgreSQL WAL 归档恢复
# 1. 恢复基础全量备份
pg_restore -h localhost -U postgres -d postgres backup.dump

# 2. 应用 WAL 文件
psql -h localhost -U postgres -d mydb < 000000010000000000000001
psql -h localhost -U postgres -d mydb < 000000010000000000000002

跨服务器恢复：

# PostgreSQL：恢复远程数据库
pg_dump -h remote_host -U postgres -d mydb | pg_restore -h localhost -U postgres -d mydb

# MySQL：远程到本地
mysqldump -h remote_host -u root -p mydb | mysql -h localhost -u root -p mydb

7.4 恢复检查清单

执行恢复前务必检查以下项目：

检查项	操作
备份文件完整性	检查文件大小和校验和
磁盘空间	确认目标磁盘有足够空间
数据库版本	确保备份和目标版本兼容
字符集	确认字符集设置一致
连接权限	确认恢复账号有足够权限
依赖关系	检查存储过程、触发器依赖
外键约束	恢复时关闭外键检查可加速

九、恢复演练

恢复演练是备份策略中最容易被忽视但最重要的环节！

9.1 演练脚本

#!/bin/bash
# restore_drill.sh - 恢复演练脚本

BACKUP_FILE="/backup/postgresql/mydb_20260528_020000.dump"
TEST_DB="mydb_drill_test"
PG_HOST="localhost"
PG_USER="postgres"

echo "=== 数据库恢复演练开始 ==="
echo "时间: $(date)"

# 1. 创建测试数据库
echo "1. 创建测试数据库: $TEST_DB"
dropdb -h $PG_HOST -U $POSTGRES_USER $TEST_DB 2>/dev/null || true
createdb -h $PG_HOST -U $PG_USER $TEST_DB

# 2. 执行恢复
echo "2. 执行恢复..."
pg_restore -h $PG_HOST -U $PG_USER -d $TEST_DB $BACKUP_FILE

# 3. 验证数据
echo "3. 验证数据完整性..."
TABLE_COUNT=$(psql -h $PG_HOST -U $PG_USER -d $TEST_DB -t -c "SELECT count(*) FROM information_schema.tables WHERE table_schema = 'public';")
echo " 恢复表数量: $TABLE_COUNT"

# 4. 清理测试数据库
echo "4. 清理测试数据库..."
dropdb -h $PG_HOST -U $PG_USER $TEST_DB

echo "=== 恢复演练完成 ==="

9.2 演练报告模板

数据库恢复演练报告
==================
日期：2026-05-28
演练人员：张三

备份文件：mydb_20260528_020000.dump
备份大小：1.2 GB

演练结果：
- 恢复耗时：3分28秒
- 表数量：45
- 数据完整性：✓ 通过
- 应用连接测试：✓ 通过

结论：备份有效，恢复流程正常。

十、常见问题

Q1: 备份时数据库是否需要停服？

不需要。 PostgreSQL 的 pg_dump 和 MySQL 的 mysqldump --single-transaction 都支持在线热备份，不会阻塞业务。

Q2: 大数据库备份太慢怎么办？

PostgreSQL：使用 -j 参数并行备份/恢复
MySQL：考虑使用 mydumper 工具并行导出
超大数据库建议使用物理备份工具（pg_basebackup、XtraBackup）

Q3: 如何备份 Docker 中的数据库？

# PostgreSQL
docker exec postgres pg_dump -U postgres mydb > backup.sql

# MySQL
docker exec mysql mysqldump -u root -pPassword mydb > backup.sql

总结

备份是刚需：没有备份的数据库就是在裸奔
自动化是关键：手动备份一定会被遗忘
异地备份是保障：服务器挂了，备份还在
演练是验证：没测试过的备份等于没有备份
监控是补充：备份失败要及时告警

记住：数据无价，备份先行！

Object Storage (对象存储服务)

Tue, 03 Mar 2026 15:36:55 +0800

Backblaze B2 与 Cloudflare R2 全方位对比分析

Backblaze B2 和 Cloudflare R2 都是目前市场上非常受欢迎且兼容 S3 API 的对象存储服务。它们都以比 Amazon S3 更具性价比作为主打优势，但在定价逻辑和底层架构上存在显著区别。

以下是基于最新数据的核心对比：

核心定位差异

Backblaze B2：传统的“中心化”对象存储。主打极低的存储成本和简单的计费模式，是数据备份、归档和大容量媒体存储的理想选择。
Cloudflare R2：基于“边缘网络”的对象存储。主打零下行流量费和与 Cloudflare 边缘计算的深度集成，非常适合需要频繁读取、分发数据的应用。

价格对比（核心决胜点）

计费项目	Backblaze B2	Cloudflare R2	优势方
基础存储费	$6/TB/月 ($0.006/GB)	$15/TB/月 ($0.015/GB) (标准层) $10/TB/月 ($0.010/GB) (低频层)	B2 胜 (便宜60%)
下行流量费	每月免费额度为总存储量的3倍，超出后 $0.01/GB。	永远 $0 (完全免费)	R2 胜
写入 API 费	完全免费 (上传文件不计费)。	免费100万次/月，超出后 $4.50/百万次。	B2 胜
读取 API 费	免费2500次/天，超出后 $0.004/万次。	免费1000万次/月，超出后 $0.36/百万次。	平局 (都很便宜)
免费额度	前10GB存储免费	前10GB存储免费	平局

价格维度的注意点：

R2 的 API 写入成本：如果你的业务是写入海量小文件（例如日志收集、IoT数据），R2 高达 $4.50/百万次的写入费用可能带来较高成本。而 B2 写入是完全免费的。
R2 的低频层：虽然存储费降到 $10/TB，但有30天最短存储期要求，且读取时会收取**$0.01/GB 的数据检索费**。B2 则没有任何最短存储时长或最小文件限制。

性能与网络架构

Cloudflare R2：在性能与延迟方面占优。它依托 Cloudflare 庞大的全球 CDN 边缘节点构建。请求数据时，R2 会动态地在离用户最近的节点处理，实现全球范围内的低延迟访问。
Backblaze B2：采用传统的区域化存储架构（主要区域在美国西部、美国东部和欧洲）。如果用户在远离这些数据中心的地方（如亚洲），直接访问的物理延迟可能较高。

生态与高级特性

S3 兼容性：两者都提供了优秀的 S3 API 兼容性，大部分支持 Amazon S3 的备份软件（如 Restic, Veeam, AWS CLI）都可以直接无缝切换。
计算集成：R2 与 Cloudflare Workers 无缝集成，极度适合构建 Serverless 全栈应用。
带宽联盟：B2 与 Cloudflare、Fastly 等 CDN 有合作。如果将 Cloudflare CDN 置于 B2 之前，从 B2 传输到 Cloudflare 网络的流量是完全免费的。

总结：你应该怎么选？

什么时候该选 Backblaze B2？

数据备份与归档：你需要存放几十 TB 甚至 PB 级的备份数据（如 NAS 备份、数据库快照），且读取频率不高。B2 每月 $6/TB 的价格能节省大量成本。
写多读少、海量小文件：因为 B2 没有写入 API 费用，也没有最小文件体积限制。
经典的 “B2 + Cloudflare CDN” 组合玩家：你可以将 B2 作为源站，搭配 Cloudflare 的免费 CDN。这样既能享受 B2 的极低存储费，又能利用 Cloudflare 的分发网络和免流量费优势。（注意：Cloudflare 对免费版有大文件/纯媒体分发的服务条款限制，需视具体业务而定。）

什么时候该选 Cloudflare R2？

高频下行读取（大流量应用）：如果你的存储量不大（比如几百GB），但每月会产生数TB甚至数十TB的下载流量（例如播客音频、软件安装包分发、高频访问的图床）。R2 的零流量费优势明显。
全球化前端 / Serverless 架构：适合搭配 Cloudflare Workers 构建现代 Web 应用，需要极低的读写延迟和极致的边缘计算体验。
想要避免流量账单风险：R2 的定价简单可预测，无需担心突然爆发的流量或恶意盗刷流量导致的高额费用，零下行流量费提供了很高的安全感。

PostgreSQL

Tue, 30 Dec 2025 12:27:59 +0800

安装

PG数据库安装

Docker (最快方式):

docker run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d -p 5432:5432 postgres

Linux (Ubuntu/Debian):

sudo apt update
sudo apt install postgresql postgresql-contrib

Windows/Mac: 推荐直接去官网下载 PostgreSQL Installer。

相关工具的安装

navicat for PG lite

连接 (使用命令行 psql)

PostgreSQL 安装后会创建一个默认的超级用户，叫 postgres。

在 Linux/Mac 终端中登录：

# 切换到 postgres 用户并启动 psql 工具
sudo -u postgres psql

登录成功后： 你会看到提示符变成 postgres=#，这表示你已经是超级管理员了。

基础操作实战 (CRUD)

以下命令请在 psql 命令行或图形化客户端的 SQL 编辑器中执行。**注意：SQL 语句末尾必须加分号 ;**。

数据库操作

-- 创建一个新数据库
CREATE DATABASE my_app;

-- 切换/连接到这个数据库 (psql 专用指令，非 SQL)
\c my_app
-- 提示符会变为 my_app=#

创建表 (Create Table)

PostgreSQL 的数据类型非常丰富。

SERIAL: 相当于 MySQL 的 AUTO_INCREMENT（自增主键）。
TEXT: PG 中推荐使用 TEXT 代替 VARCHAR，性能几乎一样但没有长度限制。

CREATE TABLE users (
 id SERIAL PRIMARY KEY,
 username TEXT NOT NULL,
 email TEXT UNIQUE NOT NULL,
 age INT,
 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

插入数据 (Insert)

-- 插入单条数据
INSERT INTO users (username, email, age)
VALUES ('zhang_san', 'zhang@example.com', 25);

-- 插入多条数据
INSERT INTO users (username, email, age)
VALUES
('li_si', 'li@example.com', 30),
('wang_wu', 'wang@example.com', 22);

查询数据 (Select)

-- 查询所有
SELECT * FROM users;

-- 条件查询
SELECT username, email FROM users WHERE age > 24;

-- 排序与限制
SELECT * FROM users ORDER BY age DESC LIMIT 1;

更新与删除 (Update & Delete)

-- 更新
UPDATE users SET age = 26 WHERE username = 'zhang_san';

-- 删除
DELETE FROM users WHERE age < 20;

进阶功能 (PG 的杀手锏)

这是大家选择 PG 而不是 MySQL 的主要原因：对 JSON 的原生支持。你可以把它当成 MongoDB 来用。

创建包含 JSON 的表

假设我们要存用户的“配置信息”，每个人的配置都不一样，且经常变动。

CREATE TABLE user_configs (
 user_id INT,
 config JSONB -- JSONB 是二进制存储的 JSON，查询速度极快
);

插入 JSON 数据

INSERT INTO user_configs (user_id, config)
VALUES (1, '{"theme": "dark", "notifications": true, "tags": ["admin", "editor"]}');

查询 JSON 内部的字段

PG 提供了特殊的运算符 -> 和 ->>。

-- 查询 theme 是 dark 的用户
SELECT * FROM user_configs WHERE config->>'theme' = 'dark';

-- 甚至可以查询 JSON 数组中是否包含某个值
SELECT * FROM user_configs WHERE config->'tags' ? 'admin';

第五步：常用的 psql 快捷指令 (作弊条)

如果你使用命令行工具 psql，这些指令必须背下来（注意这些指令前面是反斜杠 \，且不需要分号）：

指令	作用	对应 MySQL
`\l`	列出所有数据库	`SHOW DATABASES;`
`\c dbname`	切换到指定数据库	`USE dbname;`
`\dt`	列出当前库下的所有表	`SHOW TABLES;`
`\d tablename`	查看表结构详细信息	`DESC tablename;`
`\q`	退出 psql	`EXIT;`
`\timing`	开启/关闭查询计时	(无)

概念

知识点

PostgreSQL（常被简称为 Postgres 或 PG）是一个功能非常强大的开源数据库。对于刚接触它的人来说，最主要的门槛在于它的架构概念和命令行工具与 MySQL 略有不同。

这是一个从 0 到 1 的详细上手教程。

在使用之前，需要理解 PG 的层级结构，这比 MySQL 多了一层：

MySQL: 实例 (Instance) -> 数据库 (Database/Schema) -> 表 (Table)
PostgreSQL: 实例 (Instance) -> 数据库 (Database) -> 模式 (Schema) -> 表 (Table)
注：默认情况下，一切都会放在名为 public 的模式下，所以初学者可以暂时忽略“模式”这一层，当作它不存在。

redis

Fri, 17 Oct 2025 11:26:56 +0800

# Redis 常用命令总结（适用于 apt install redis/redis-server 安装的场景，包括容器内）

```bash
# 1. 最简单直接启动（前台运行，用于测试）
redis-server

# 2. 使用配置文件后台启动（推荐方式）
redis-server /etc/redis/redis.conf

# 3. 带常用参数直接启动（不依赖配置文件）
redis-server --port 6379 --daemonize yes --protected-mode no

# 4. 检查 Redis 是否正常运行
redis-cli ping # 返回 PONG 表示成功
redis-cli -p 6379 ping

# 5. 优雅停止 Redis（强烈推荐，会自动保存数据）
redis-cli shutdown # 默认执行 SAVE
redis-cli -p 6379 shutdown

# 6. 不保存数据直接停止
redis-cli shutdown nosave

# 7. 强制杀死进程（不推荐，可能丢数据）
kill -9 $(pidof redis-server)
pkill -9 redis-server

# 8. 重启 Redis
redis-cli shutdown && redis-server /etc/redis/redis.conf

# 9. 使用 service 管理（你在容器里通过 apt 安装后直接可用！）
service redis-server start # 启动
service redis-server stop # 停止
service redis-server restart # 重启
service redis-server status # 查看状态

# 10. 等价的更短写法（很多系统都支持）
service redis start
service redis stop
service redis restart
service redis status

# 11. 直接调用 init 脚本（永远有效）
/etc/init.d/redis-server start
/etc/init.d/redis-server stop
/etc/init.d/redis-server restart
/etc/init.d/redis-server status

# 12. 查看进程
ps aux | grep redis
pgrep -fl redis

什么是 Redis？

Redis (Remote Dictionary Server) 是一个开源的、使用 C 语言编写的、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库，并提供多种语言的 API。

它通常被称为“数据结构服务器”，因为值（value）可以是字符串 (String)、哈希 (Hash)、列表 (List)、集合 (Set) 和有序集合 (Sorted Set) 等类型。

Redis 的主要特点：

速度快： 数据存储在内存中，读写速度非常快。
数据类型丰富： 支持多种复杂的数据结构。
持久化： 可以将内存中的数据保存到磁盘中，重启时可以再次加载进行使用。
原子性： Redis 的所有操作都是原子性的，要么执行成功，要么执行失败，不会出现中间状态。
丰富的特性： 支持发布/订阅、事务、Lua 脚本等功能。

常见应用场景：

缓存： 这是 Redis 最常见的用途，用于缓存数据库查询结果、网页、或任何可以被缓存的数据，以减轻数据库压力。
计数器： 利用 Redis 原子性的 INCR 命令可以轻松实现高并发的计数功能，例如文章阅读量、点赞数。
会话存储： 存储用户的会话信息（Session），实现分布式系统的会话共享。
排行榜： 使用有序集合（Sorted Set）可以轻松实现实时更新的排行榜。
消息队列： 使用列表（List）的 LPUSH 和 RPOP 命令可以实现简单的消息队列。

第一步：安装 Redis

你可以通过以下几种方式安装 Redis：

1. 在 Linux (Ubuntu/Debian) 上安装

使用包管理器是最简单的方式：

sudo apt update
sudo apt install redis-server

安装完成后，Redis 服务会自动启动。你可以使用以下命令检查服务状态：

sudo systemctl status redis-server

使用 Docker 安装 (推荐，跨平台)

如果你安装了 Docker，这是最简单且最干净的安装方式，适用于任何操作系统。

docker run --name my-redis -p 6379:6379 -d redis

这个命令会从 Docker Hub 下载最新的 Redis 镜像，并在后台运行一个名为 my-redis 的容器，将容器的 6379 端口映射到你主机的 6379 端口。

如果你在一个docker内开发，另一个docker容器安装redis

本地mac上_运行一个redis容器_然后想要在另一个容器中使用这个redis怎么做

第二步：连接到 Redis

安装并启动 Redis 后，你可以使用 redis-cli (Redis Command Line Interface) 连接到它。

如果你是直接在系统上安装的 Redis，直接在终端输入：

redis-cli

如果你是通过 Docker 安装的，你需要进入到容器内部：

docker exec -it my-redis redis-cli

连接成功后，你会看到类似下面的提示符：

127.0.0.1:6379>

现在，你可以开始输入 Redis 命令了。

测试连接：

输入 PING 命令，如果服务器正常运行，它会返回 PONG。

127.0.0.1:6379> PING
PONG

如果你的redis是安装在另外一个容器，使用如下

# 1. 进入你的应用容器
docker exec -it <你的应用容器名> bash # 或者 sh

# 2. 在容器内部，更新包列表并安装
root@<container-id>:/# apt-get update
root@<container-id>:/# apt-get install redis-tools -y

# 3. 现在你可以使用了
root@<container-id>:/# redis-cli -h my-redis
my-redis:6379> PING
PONG

第三步：学习基本命令和数据结构

Redis 是一个 Key-Value 数据库。每个 Key 都有一个与之关联的 Value。下面是 Redis 最核心的五种数据结构及其常用命令。

字符串 (String)

这是最基本的数据类型，一个 key 对应一个 value。

SET key value: 设置一个键值对。

127.0.0.1:6379> SET username "gemini"
OK

GET key: 获取一个键的值。
```
127.0.0.1:6379> GET username
"gemini"
```

DEL key: 删除一个键。

127.0.0.1:6379> DEL username
(integer) 1

INCR key: 将 key 中储存的数字值增一（如果 key 不存在，则初始化为 0 再执行 INCR 操作）。
```
127.0.0.1:6379> SET page_views 100
OK
127.0.0.1:6379> INCR page_views
(integer) 101
```

2. 哈希 (Hash)

Hash 是一个 string 类型的 field 和 value 的映射表，它非常适合用于存储对象。

HSET key field value: 将哈希表 key 中的字段 field 的值设为 value。
```
127.0.0.1:6379> HSET user:1 name "Alice" age 25
(integer) 2
```
HGET key field: 获取哈希表 key 中给定字段 field 的值。
```
127.0.0.1:6379> HGET user:1 name
"Alice"
```

HGETALL key: 获取在哈希表中指定 key 的所有字段和值。

127.0.0.1:6379> HGETALL user:1
1) "name"
2) "Alice"
3) "age"
4) "25"

HDEL key field: 删除哈希表 key 中的一个或多个指定字段。
```
127.0.0.1:6379> HDEL user:1 age
(integer) 1
```

3. 列表 (List)

List 是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。

LPUSH key element [element ...]: 将一个或多个值插入到列表头部。
```
127.0.0.1:6379> LPUSH tasks "task1" "task2"
(integer) 2
```
RPUSH key element [element ...]: 将一个或多个值插入到列表尾部。
```
127.0.0.1:6379> RPUSH tasks "task3"
(integer) 3
```
LRANGE key start stop: 获取列表指定范围内的元素。(0 是第一个元素, -1 是最后一个元素)。
```
127.0.0.1:6379> LRANGE tasks 0 -1
1) "task2"
2) "task1"
3) "task3"
```
LPOP key: 移出并获取列表的第一个元素。
```
127.0.0.1:6379> LPOP tasks
"task2"
```
RPOP key: 移出并获取列表的最后一个元素。
```
127.0.0.1:6379> RPOP tasks
"task3"
```

4. 集合 (Set)

Set 是 String 类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据。

SADD key member [member ...]: 向集合添加一个或多个成员。
```
127.0.0.1:6379> SADD tags "database" "nosql" "redis"
(integer) 3
```

SMEMBERS key: 返回集合中的所有成员。

127.0.0.1:6379> SMEMBERS tags
1) "redis"
2) "nosql"
3) "database"

SISMEMBER key member: 判断 member 元素是否是集合 key 的成员。

127.0.0.1:6379> SISMEMBER tags "redis"
(integer) 1
127.0.0.1:6379> SISMEMBER tags "mysql"
(integer) 0

SREM key member [member ...]: 移除集合中一个或多个成员。
```
127.0.0.1:6379> SREM tags "nosql"
(integer) 1
```

5. 有序集合 (Sorted Set / ZSET)

和 Set 一样，Sorted Set 也是 string 类型元素的集合，且不允许重复的成员。不同的是每个元素都会关联一个 double 类型的分数（score）。Redis 正是通过分数来为集合中的成员进行从小到大的排序。

ZADD key score member [score member ...]: 向有序集合添加一个或多个成员，或者更新已存在成员的分数。
```
127.0.0.1:6379> ZADD leaderboard 100 "player1" 250 "player2" 50 "player3"
(integer) 3
```
ZRANGE key start stop [WITHSCORES]: 通过索引区间返回有序集合成指定区间内的成员（按分数从小到大）。
```
127.0.0.1:6379> ZRANGE leaderboard 0 -1 WITHSCORES
1) "player3"
2) "50"
3) "player1"
4) "100"
5) "player2"
6) "250"
```
ZREVRANGE key start stop [WITHSCORES]: 返回有序集中指定区间内的成员，通过索引，分数从高到低。
```
127.0.0.1:6379> ZREVRANGE leaderboard 0 1 WITHSCORES
1) "player2"
2) "250"
3) "player1"
4) "100"
```
ZREM key member [member ...]: 移除有序集合中的一个或多个成员。
```
127.0.0.1:6379> ZREM leaderboard "player3"
(integer) 1
```

第四步：一些通用的重要命令

KEYS pattern: 查找所有符合给定模式的 key。注意： 在生产环境中要慎用，因为它会遍历所有的键，可能会阻塞服务器。
```
127.0.0.1:6379> KEYS *
1) "tasks"
2) "user:1"
3) "page_views"
...
```
EXPIRE key seconds: 为给定的 key 设置过期时间，以秒计。当 key 过期后，它会被自动删除。这对于实现缓存非常有用。
```
127.0.0.1:6379> SET cache_data "some important data"
OK
127.0.0.1:6379> EXPIRE cache_data 60 // 60秒后过期
(integer) 1
```
TTL key: 以秒为单位，返回给定 key 的剩余生存时间 (Time To Live)。
```
127.0.0.1:6379> TTL cache_data
(integer) 55 // (还剩55秒)
```
FLUSHDB: 删除当前数据库里的所有数据。极度危险，请谨慎使用！
FLUSHALL: 删除所有数据库里的所有数据。极度危险，请谨慎使用！

第五步：在你的代码中使用 Redis

redis-cli 是一个很好的学习和调试工具，但在实际应用中，你需要在你的编程语言中通过 Redis 客户端库来连接和操作 Redis。

几乎所有主流语言都有成熟的 Redis 客户端库。例如：

Python: redis-py
Java: Jedis, Lettuce
Node.js: node-redis, ioredis
Go: go-redis
PHP: phpredis

Python 示例 (redis-py)

安装库:
```
pip install redis
```

连接和使用:

import redis

# 连接到本地 Redis 服务
r = redis.Redis(host='localhost', port=6379, db=0, decode_responses=True)

# 使用 String
r.set('foo', 'bar')
print(r.get('foo')) # 输出: bar

# 使用 Hash
r.hset('user-session:123', mapping={
 'name': 'John',
 'surname': 'Smith',
 'company': 'Redis',
 'age': 29
})
print(r.hgetall('user-session:123'))

总结和后续学习

恭喜你！你已经完成了 Redis 的入门。你现在应该知道如何安装、连接 Redis，并使用其核心数据结构进行基本操作。

下一步可以学习：

Redis 持久化： 了解 RDB 和 AOF 两种持久化方式的区别和配置。
Redis 事务： 学习 MULTI 和 EXEC 命令来执行一组原子操作。
发布/订阅 (Pub/Sub)： 探索 Redis 的消息发布和订阅功能。
Redis 安全： 学习如何为 Redis 设置密码和配置安全的网络访问。
Redis 集群： 了解主从复制 (Replication)、哨兵 (Sentinel) 和集群 (Cluster) 模式以实现高可用和扩展性。

一些操作

Redis未授权访问漏洞处理

漏洞描述：Redis 未授权访问漏洞
Redis 未授权访问漏洞是一个非常严重的安全问题，它通常是因为 Redis 服务器直接暴露在公网或内网中，并且**没有配置密码认证**导致的。攻击者可以利用这个漏洞读取、修改甚至删除数据，更严重的情况下，可以利用 Redis 的一些特性（如写入 `authorized_keys` 或计划任务文件）来获取服务器的控制权。

以下是处理和防御 Redis 未授权访问漏洞的主要步骤和措施：

### 1\. 启用密码认证（最重要）

在 Redis 配置文件中设置一个**强密码**，启用认证功能。

 * **修改配置文件：** 找到 `redis.conf` 文件（通常在 `/etc/redis/` 或 `/etc/redis/redis.conf`）。
 * **设置密码：** 找到或添加 `requirepass` 这一行，并设置一个复杂的密码。
 ```conf
 requirepass yourStrongPasswordHere
 ```
 *记得替换 `yourStrongPasswordHere` 为你设置的实际密码。*
 * **重启 Redis：** 更改配置后，需要重启 Redis 服务使其生效。
 ```bash
 # 例如：
 sudo systemctl restart redis
 # 或者
 sudo service redis-server restart
 ```
 * **验证：** 使用 `redis-cli` 连接后，尝试执行命令，会提示需要认证。
 ```bash
 redis-cli
 > PING
 (error) NOAUTH Authentication required.
 > AUTH yourStrongPasswordHere
 OK
 > PING
 PONG
 ```

### 2\. 限制网络访问（网络隔离）

Redis 本身的设计是运行在受信任的环境中，因此不应该直接暴露给公网。

 * **绑定本地或私有 IP：** 仅允许 Redis 监听应用的服务器 IP 或本地回环地址（`127.0.0.1`）。在 `redis.conf` 中修改 `bind` 选项：
 * **仅允许本地访问：**
 ```conf
 bind 127.0.0.1
 ```
 * **允许特定内网 IP 访问：** 绑定内网 IP 地址。
 ```conf
 bind 127.0.0.1 192.168.1.100 # 替换为你的应用服务器IP
 ```
 * **配置防火墙：** 使用防火墙（如 `iptables`, `ufw`, 安全组等）限制对 Redis 端口（默认是 6379）的访问，**只允许**信任的应用服务器 IP 地址连接。
 * **网络分段：** 将 Redis 服务器放在一个独立的、只有应用服务器能访问的私有网络段中。

### 3\. 启用保护模式（Protected Mode）

Redis 3.2.0 及更高版本引入了保护模式（Protected Mode）。

 * **检查配置：** 在 `redis.conf` 中确保 `protected-mode` 设置为 `yes`。
 ```conf
 protected-mode yes
 ```
 *在默认配置下，如果 Redis 没有设置密码且绑定了非本地回环地址，保护模式会自动开启，阻止外部连接，仅响应本地回环地址（`127.0.0.1`）的请求。*

### 4\. 禁用或重命名危险命令

为了防止攻击者利用 Redis 的配置命令进行恶意操作（如写入 `authorized_keys`），可以考虑禁用或重命名一些高风险命令。

 * **禁用或重命名 `CONFIG` 命令：** 在 `redis.conf` 中添加：
 ```conf
 # 禁用 CONFIG 命令
 rename-command CONFIG ""
 # 或者重命名（推荐，防止应用端需要用到）
 rename-command CONFIG aRandomStringForConfig
 ```
 * 其他高危命令如 `FLUSHALL`、`FLUSHDB`、`SAVE`、`BGSAVE` 也可以根据需要进行限制。

### 5\. 使用低权限用户运行 Redis

不要使用 `root` 用户运行 Redis 服务。创建一个专门的低权限用户来运行 Redis 进程，即使被攻击者攻破，也能限制其在系统上的权限。

### 总结加固：

1. **设置强密码（`requirepass`）。**
2. **限制网络访问（`bind` 和防火墙）。**
3. **确保 `protected-mode yes`。**
4. **禁用或重命名高危命令（`CONFIG`）。**
5. **使用低权限用户运行。**

本地mac上_运行一个redis容器_然后想要在另一个容器中使用这个redis怎么做

在 Mac 本地上，要让一个容器（应用容器）连接到另一个容器（Redis 容器），最推荐和最现代的方法是使用自定义的 Docker 网络。

这能确保容器之间可以通过一个稳定且易于记的主机名（即你的 Redis 容器名）进行通信，而不需要关心动态变化的 IP 地址。

这里是详细的步骤，分为两种主要方法：

方法一：使用 Docker CLI 命令（推荐）

这是最基础和最清晰的方法，分为三步：

1. 创建一个自定义的 Docker 网络

首先，创建一个新的“桥接”网络。所有需要相互通信的容器都应该连接到这个网络。

docker network create my-app-network

my-app-network 是你给这个网络起的名字，可以自定义。

2. 启动 Redis 容器并连接到该网络

在运行 Redis 容器时，使用 --network 参数指定它加入你刚创建的网络。同时，使用 --name 给它一个固定的名字（例如 my-redis），这个名字将作为它在网络内部的主机名。

docker run -d \
 --name my-redis \
 --network my-app-network \
 redis

-d：在后台运行。
--name my-redis：将容器命名为 my-redis。
--network my-app-network：将其连接到 my-app-network。
注意：我在这里没有使用 -p 6379:6379。因为你的应用容器在同一个网络中，它可以直接通过 6379 端口访问 Redis。只有当你需要从 Mac 主机（例如通过 redis-cli 或桌面 GUI）访问这个 Redis 时，才需要添加 -p 6379:6379 来将端口暴露给主机。

3. 启动你的应用容器并连接到同一网络

现在，启动你的第二个容器（例如一个 Node.js、Python 或 Java 应用），并同样将它连接到 my-app-network。

docker run -it \
 --network my-app-network \
 <你的应用镜像名>

4. 在应用中连接 Redis

在你的应用代码中，连接 Redis 的主机地址不再是 localhost 或 127.0.0.1，而是你在第二步中为 Redis 容器设置的名字：my-redis。

Redis 连接字符串示例：redis://my-redis:6379

Docker 会自动将 my-redis 这个主机名解析为 Redis 容器在 my-app-network 网络中的内部 IP 地址。

方法二：使用 Docker Compose（更简单的多容器管理）

如果你需要同时管理 Redis 和你的应用两个（或更多）容器，使用 docker-compose 是一个更简单、更可维护的方法。它会自动为你创建和管理网络。

在你的项目根目录创建一个 docker-compose.yml 文件。

在该文件中定义你的两个服务（app 和 redis）：

version: '3.8' # 使用一个较新的版本

services:
 # 你的应用程序服务
 app:
 build: .  # 假设你的 Dockerfile 在当前目录
 # 或者使用 image: <你的应用镜像名>
 ports:
 - "8080:80" # 举例：将你应用的80端口映射到主机的8080
 environment:
 # 关键：在这里注入 Redis 的主机名
 - REDIS_HOST=my-redis
 - REDIS_PORT=6379
 # 确保你的应用在 redis 启动后再启动
 depends_on:
 - my-redis

 # 你的 Redis 服务
 my-redis: # 服务的名字
 image: redis
 # 你可以保留这个名字，也可以不写
 container_name: my-redis-container
 # 如果需要从主机访问，取消下面这行的注释
 # ports:
 # - "6379:6379"

# Docker Compose 会自动创建一个默认网络
# 并将 app 和 my-redis 两个服务都加入其中

在 docker-compose.yml 文件所在的目录中，运行以下命令：
```
docker-compose up -d
```

Docker Compose 会自动完成所有操作：

创建一个名为 项目目录名_default 的网络。
启动名为 my-redis 的 Redis 服务。
启动你的 app 服务。
在 app 容器内部，可以直接使用主机名 my-redis（即 services: 下定义的服务名）来连接到 Redis。

补充：连接到 Mac 主机上的 Redis

如果你的意思是 Redis 没有运行在容器里，而是直接安装在你的 Mac 电脑上，而你想从一个 Docker 容器里去连接它，那么情况有所不同。

在这种情况下，你不能使用 localhost（因为 localhost 在容器内部指的是容器自己）。你需要使用一个特殊的 DNS 名称：host.docker.internal。

连接地址：host.docker.internal:6379

host.docker.internal 是 Docker for Mac 提供的一个特殊地址，它会解析为你 Mac 主机的 IP 地址。

存储与数据库 on 扎塔-Zata

S3 兼容存储踩坑记：boto3 新默认校验和撞上 NotImplemented

一场"全线 500"的发布事故

422 和 500 之间隔着一道分界线

先补一点背景：S3 兼容生态与请求编码

S3 API 是事实标准，但"兼容"是程度问题

签名 V4 之下，请求体有三种"泳姿"

根因：boto3 1.36 改了一个默认值

修复：一行 Config，三个层次

同类清扫：适配器里还埋着一个 ASCII 坑

验证

几点收获

数据库备份实战

前言

一、PostgreSQL 备份

1.1 pg_dump 基础用法

1.2 pg_dumpall 全库备份

1.3 恢复方法

二、MySQL 备份

2.1 mysqldump 基础用法

2.2 恢复方法

三、其他 PostgreSQL 图形化工具

3.1 pgAdmin

3.2 DBeaver

3.3 DataGrip

3.4 HeidiSQL

3.5 phpPgAdmin

3.6 Adminer

3.7 工具对比

3.8 命令行工具补充

四、Navicat 图形化备份

4.1 PostgreSQL 备份

4.2 MySQL 备份

4.3 定时自动备份（Navicat Premium）

4.4 Navicat Cloud 备份

4.5 Navicat 恢复数据库

4.6 Navicat 备份注意事项

五、自动化备份脚本

5.1 PostgreSQL 自动备份脚本

5.2 MySQL 自动备份脚本

5.3 配置定时任务

六、云存储备份

5.1 上传到 AWS S3

5.2 上传到 Cloudflare R2

七、备份策略最佳实践

6.1 备份类型对比

6.2 推荐策略

6.3 备份验证清单

八、数据恢复（命令行）

7.1 PostgreSQL 恢复详解

7.2 MySQL 恢复详解

7.3 恢复高级技巧

7.4 恢复检查清单

九、恢复演练

9.1 演练脚本

9.2 演练报告模板

十、常见问题

Q1: 备份时数据库是否需要停服？

Q2: 大数据库备份太慢怎么办？

Q3: 如何备份 Docker 中的数据库？

总结

Object Storage (对象存储服务)

Backblaze B2 与 Cloudflare R2 全方位对比分析

总结：你应该怎么选？

PostgreSQL

安装

基础操作实战 (CRUD)

概念

知识点

推荐的图形化客户端 (GUI)

redis

目录

什么是 Redis？

一些操作

Redis未授权访问漏洞处理

本地mac上_运行一个redis容器_然后想要在另一个容器中使用这个redis怎么做