事务日志持久性配置

配置项作用 #

index.translog.durability 配置项控制事务日志（Translog）的持久化策略。事务日志用于在崩溃恢复时防止数据丢失，此配置决定何时将事务日志写入磁盘。

配置项类型 #

该配置项为动态配置，可以在运行时通过索引设置 API 进行修改。

默认值 #

request（每个请求后 fsync）

是否必需 #

可选配置项（有默认值）

可选值 #

配置格式 #

# 默认配置（推荐生产环境）
index.translog.durability: request

# 异步持久化（高性能场景）
index.translog.durability: async

相关配置项 #

工作原理 #

事务日志持久化过程：

┌─────────────────────────────────────────────────────────────────┐
│                 文档写入与 Translog 持久化流程                    │
└─────────────────────────────────────────────────────────────────┘

客户端请求 (index/bulk/delete)
    │
    ▼
写入内存缓冲区
    │
    ▼
写入 Translog (内存)
    │
    ├── request 模式                  ───┐
    │   │                                │
    │   └── 立即 fsync 到磁盘            │
    │       │                           │
    │       └── 确认写入成功             │
    │           │                       │
    │           ▼                       │
    │       返回成功响应                  │
    │                                    │
    └── async 模式                   ───┘
        │
        └── 定期 fsync (sync_interval)
            │
            └── 期间数据可能丢失

模式对比 #

request 模式（默认） #

工作流程：

请求到达
    │
    ▼
写入 Translog 内存
    │
    ▼
fsync() 到磁盘  ← 阻塞等待
    │
    ▼
返回成功响应

特点：

• ✅ 最高数据安全性
• ✅ 崩溃后最多丢失一个请求的数据
• ❌ 每个请求都需要磁盘 fsync
• ❌ 性能较低

适用场景：

• 生产环境（默认）
• 数据不能丢失
• 金融交易系统
• 用户生成内容

async 模式 #

工作流程：

请求到达
    │
    ▼
写入 Translog 内存
    │
    ▼
立即返回成功响应
    │
    ▼
后台定期 fsync (默认 5s)
    │
    ▼
写入磁盘

特点：

• ✅ 高性能，低延迟
• ✅ 批量 fsync 减少磁盘操作
• ❌ 可能丢失最多 sync_interval 时间的数据
• ❌ 崩溃恢复时可能丢失已确认的写入

适用场景：

• 批量数据导入
• 日志/指标数据
• 可容忍数据丢失的场景
• 临时测试环境

使用场景 #

1. 生产环境（推荐） #

index.translog.durability: request

数据安全优先，确保每个写入操作都持久化到磁盘。

2. 批量导入优化 #

# 导入前切换为异步
PUT /my_index/_settings
{
  "index.translog.durability": "async",
  "index.translog.sync_interval": "10s"
}

# 执行批量导入
# ...

# 导入后恢复为 request
PUT /my_index/_settings
{
  "index.translog.durability": "request"
}

3. 日志/指标数据 #

# 允许少量数据丢失以换取性能
index.translog.durability: async
index.translog.sync_interval: 30s

4. 金融/关键数据 #

# 最高安全性
index.translog.durability: request

使用示例 #

创建索引时设置：

PUT /my_index
{
  "settings": {
    "index.translog.durability": "request"
  }
}

动态修改：

# 切换为异步模式
PUT /my_index/_settings
{
  "index.translog.durability": "async"
}

# 切换回同步模式
PUT /my_index/_settings
{
  "index.translog.durability": "request"
}

配合 sync_interval 使用：

# async 模式时调整同步间隔
PUT /my_index/_settings
{
  "index.translog.durability": "async",
  "index.translog.sync_interval": "10s"
}

数据丢失风险评估 #

async 模式风险示例：

时间线:
00:00 - 请求 A 写入 (确认成功)
00:01 - 请求 B 写入 (确认成功)
00:02 - 请求 C 写入 (确认成功)
00:03 - 请求 D 写入 (确认成功)
       ↓
       未 fsync，数据在内存中
       ↓
00:04 - 节点崩溃
       ↓
结果: A、B、C、D 全部丢失

推荐设置建议 #

性能影响分析 #

性能对比：

request 模式:
每次写入: [写入] → [fsync] → [确认]
延迟: ~5-20ms/操作

async 模式:
每次写入: [写入] → [确认]
后台: [累积 5s] → [批量 fsync]
延迟: ~1-5ms/操作

与其他配置的关系 #

# 持久化配置组合
index.translog.durability: request    # 或 async
index.translog.sync_interval: 5s      # async 模式生效
index.translog.generation.threshold: 128mb
index.translog.flush.threshold_size: 512mb

配置说明：

• durability: 决定何时 fsync
• sync_interval: async 模式下的同步频率
• generation.threshold: translog 世代大小阈值
• flush.threshold_size: 触发 flush 的阈值

批量导入最佳实践 #

# 步骤 1: 优化为异步模式
PUT /my_index/_settings
{
  "index.translog.durability": "async",
  "index.translog.sync_interval": "60s",
  "index.refresh_interval": "-1",
  "index.number_of_replicas": 0
}

# 步骤 2: 执行批量导入
# (使用 bulk API，每批 5000-10000 文档)

# 步骤 3: 导入完成，确保数据持久化
POST /_flush

# 步骤 4: 恢复安全配置
PUT /my_index/_settings
{
  "index.translog.durability": "request",
  "index.refresh_interval": "1s",
  "index.number_of_replicas": 1
}

监控建议 #

# 查看 translog 配置
GET /my_index/_settings?filter_path=*.index.translog.*

# 查看索引统计
GET /my_index/_stats/translog?pretty

# 查看节点 translog 统计
GET /_nodes/stats/indices/translog?pretty

关键指标：

常见问题 #

问题 1：写入性能差

可能原因： 使用 request 模式，每个请求都 fsync

解决方案：

# 临时切换为 async（可接受数据丢失）
PUT /my_index/_settings
{
  "index.translog.durability": "async"
}

问题 2：节点崩溃后数据丢失

原因： 使用 async 模式

解决方案：

# 恢复为 request 模式
PUT /my_index/_settings
{
  "index.translog.durability": "request"
}

问题 3：是否应该使用 async？

决策树：

是否可以容忍数据丢失？
    │
    ├── 否 → 使用 request
    │
    └── 是 → 是否需要极致性能？
              │
              ├── 是 → 使用 async
              └── 否 → 仍建议 request

注意事项 #

1. 动态更新：此配置为动态配置，可在线修改
2. 数据安全：async 模式可能导致已确认的写入在崩溃时丢失
3. 生产环境：生产环境建议使用 request 模式
4. 性能权衡：request 牺牲性能换取安全，async 牺牲安全换取性能
5. 监控重要：async 模式需要监控 sync_interval 和数据积压
6. 配合设置：与 refresh_interval、replicas 等配置配合使用