HarperDB多区域部署实战：从零构建跨区域数据同步架构

1. 为什么 HarperDB 的多区域部署不是“开箱即用”，而是必须亲手搭的桥

HarperDB 是个挺有意思的数据引擎——它不像 PostgreSQL 那样靠主从复制撑起高可用，也不像 MongoDB 那样内置分片集群管理器。它的核心设计哲学是“轻量、嵌入友好、Schema-less 但强一致性”，这决定了它在单节点上跑得飞快、内存占用低、API 极简；可一旦你把“跨大洲用户低延迟读写”“故障自动转移”“区域级数据就近落库”这些需求摆到桌面上，HarperDB 就不会主动递给你一把现成的钥匙，而是把锁、图纸、螺丝刀和三份不同规格的螺栓都放在你面前，说：“来，自己焊一座桥。”

我第一次在 DigitalOcean 上试跑 HarperDB 多区域时，就栽在这个认知偏差上。我以为只要在纽约（NYC3）、法兰克福（FRA1）、班加罗尔（BLR1）各起一个 Droplet，装好 HarperDB，再点几下 Web UI 里的“Replication”开关，数据就能像水流一样自然漫过三个大洲。结果呢？Web UI 里那个 Replication 页面根本没出现“Add Remote Instance”按钮； harperdb.conf 里翻遍 replication 字段，只看到 enabled: true 和 port: 9925 这种本地监听配置；查官方文档，发现所谓“Replication”默认仅指 单机内多个 Schema 之间的同步 ，和跨网络、跨实例、跨区域完全不是一回事。

这才是 HarperDB 多区域部署的真实起点：它不提供“一键多活”，但提供了足够干净、可控、可编程的底层能力——包括基于 HTTP 的全量/增量同步 API、支持自定义函数（Custom Functions）注入业务逻辑、以及通过 harperdb_custom_functions 目录热加载 JS 函数的能力。换句话说，HarperDB 把“如何定义数据流向”“如何处理冲突”“如何验证同步状态”这些决策权，完整交还给了你。而 DigitalOcean 的价值，恰恰在于它用极简的 API、统一的 CLI（ doctl ）、标准化的 Droplet 镜像和全球 14 个区域的低延迟骨干网，把“搭桥”的物理成本压到了最低。

所以，当你看到标题《Setting up a Multi-Region Deployment of HarperDB on DigitalOcean》，它真正想说的是： 这不是一次安装，而是一次协议设计；不是配置服务，而是构建数据契约。 你需要决定：哪个区域是权威写入源（Authoritative Source）？当纽约和班加罗尔同时修改同一条用户地址记录，谁赢？同步失败时，是重试、告警、还是降级为本地缓存？Custom Functions 是用来做字段脱敏，还是生成审计日志，抑或触发下游通知？这些问题的答案，将直接决定你的 replication 配置文件长什么样、你的 custom_function.js 里 onWrite 回调怎么写、你的健康检查脚本每 30 秒 curl 哪个 endpoint。

提示：HarperDB 官方明确标注其“Multi-Region Replication”为 Community-Driven Pattern （社区驱动模式），而非 Enterprise Feature（企业版功能）。这意味着它没有商业支持 SLA，但有完整的开源实现路径——所有代码、配置、脚本，你都能在 GitHub 上找到原始参考，也能根据自己的业务规则彻底重写。这种“自由”背后，是责任，也是掌控力。

我后来在生产环境落地时，放弃了所有试图封装成“HarperDB-Multi-Region-Manager”工具的想法，转而用最朴素的方式：三个区域各一个 HarperDB 实例 + 一套独立的、用 Node.js 写的同步协调器（Sync Orchestrator），它不碰 HarperDB 内部状态，只通过标准 HTTP API 拉取变更、投递变更、记录位点、上报指标。这套方案上线半年，零数据丢失，平均跨区域同步延迟稳定在 800ms 以内（纽约→法兰克福实测 620ms，纽约→班加罗尔 790ms），而整套基础设施的月度账单，比同等规格的托管 MongoDB Atlas 多区域集群便宜 63%。

这就是 HarperDB + DigitalOcean 组合的现实红利：你付出的是设计与编码时间，换来的却是对数据流每一毫秒、每一个字节的绝对主权。

2. DigitalOcean 基础设施选型：Droplet 规格、区域配对与网络拓扑的真实约束

很多人一上来就想用最小规格 Droplet（比如 $5/mo 的 1GB RAM + 1vCPU）跑 HarperDB 多区域，理由很朴素：“HarperDB 官网说 512MB 内存就能跑”。这话没错，但只适用于单节点开发测试。一旦开启跨区域复制、启用 Custom Functions、并承载真实业务流量，内存、磁盘 I/O 和网络带宽会立刻成为瓶颈。我在早期压测中就发现：一个 $5 Droplet 在持续写入 1000 条/秒、同时向另一区域同步时， swap 分区会在 12 分钟后被占满， harperdb 进程开始 OOM 被 kill——这不是 HarperDB 的 bug，而是资源规划失当的必然结果。

所以，多区域部署的第一步，不是写代码，而是画一张 数字世界的地理拓扑图 。我最终选定的三个区域是： New York (NYC3) 、 Frankfurt (FRA1) 、 Bangalore (BLR1) 。选择逻辑非常具体：

• NYC3 作为 Write-Authoritative Region（写权威区） ：我们 65% 的核心业务团队和支付网关位于北美东部，所有用户注册、订单创建、账户变更等强一致性操作，必须首先写入 NYC3。这里承担最高负载，也最需要资源冗余。
• FRA1 作为 Read-Optimized & Disaster Recovery Region（读优化与灾备区） ：欧洲用户访问延迟要求 < 150ms，FRA1 到巴黎、法兰克福、阿姆斯特丹的平均 RTT 是 22ms；同时，它与 NYC3 的跨大西洋链路成熟稳定（DigitalOcean 官方 SLA 99.99%），是理想的异地灾备节点。
• BLR1 作为 Edge Cache & Local Processing Region（边缘缓存与本地处理区） ：印度及东南亚用户占比 28%，BLR1 到孟买、新加坡的 RTT < 40ms；更重要的是，我们在这里运行大量 Custom Functions 做实时数据脱敏（如手机号掩码、邮箱域名替换），避免敏感数据跨洋传输。

基于这个角色分工，Droplet 规格不能一刀切：

注意： 绝对不要启用 DigitalOcean 的“Backups”功能 。HarperDB 的数据目录（ /opt/harperdb/data ）包含 WAL 日志、SSTables 和内存映射文件，直接对运行中的 HarperDB 目录做快照备份，极大概率导致数据损坏。正确的备份策略是：通过 HarperDB 的 /export API 导出 CSV/JSON，或使用 harperdb backup CLI 命令（需 HarperDB v3.5+），再将导出文件上传至 Spaces（DO 的 S3 兼容对象存储）。

网络层面，DigitalOcean 默认为每个 Droplet 分配一个公网 IPv4 和一个私有 IPv4（VPC 内网）。 多区域部署必须强制使用私有 IP 进行 HarperDB 实例间通信 。原因有三：

1. 安全性 ：HarperDB 的 replication API（ /replication endpoint）默认无认证，暴露在公网等于裸奔；
2. 性能 ：私有网络流量不经过公网路由，NYC3 ↔ FRA1 的私有网络延迟实测为 78ms，而公网平均为 112ms；
3. 成本 ：DigitalOcean 对私有网络流量 完全免费 ，而公网出站流量按 $0.01/GB 计费——跨区域同步每天轻松产生数十 GB 流量。

因此，在创建 Droplet 时，必须勾选 “ Enable Private Networking ”，并在 harperdb.conf 中将 host 配置项从 "0.0.0.0" 改为私有 IP（如 NYC3 的 10.116.0.2 ）。同时，在 DigitalOcean 控制台的 Networking → VPCs 中，确保三个区域的 Droplet 都加入同一个 VPC（例如命名为 harperdb-global-vpc ）。这是整个架构的网络基石，漏掉一步，后续所有同步配置都会失败。

最后，关于操作系统镜像： 必须选用 Ubuntu 22.04 LTS（x64） 。HarperDB 官方仅对 Ubuntu 20.04/22.04 提供 .deb 安装包和完整兼容性测试。我曾尝试在 Debian 12 上安装，虽能启动，但在启用 Custom Functions 时，Node.js 的 fs.watch() 在某些内核版本下失效，导致函数热更新不生效——这种底层差异，只有长期维护的 LTS 发行版才能规避。

3. HarperDB 核心配置解剖：从 harperdb.conf 到自定义同步协议的落地细节

HarperDB 的配置文件 harperdb.conf 看似简单，但多区域部署中，每一行配置都牵涉到数据一致性、安全边界和运维可观测性。它不是一份静态清单，而是一份 数据契约的法律文本 。下面我逐行拆解 NYC3（写权威区）的生产级配置，并说明为什么这样写、不这样写的后果是什么。

{
  "port": 9925,
  "https_port": 9926,
  "host": "10.116.0.2",
  "https": {
    "enabled": true,
    "key_path": "/etc/ssl/private/harperdb-nyc3.key",
    "cert_path": "/etc/ssl/certs/harperdb-nyc3.crt"
  },
  "authentication": {
    "enabled": true,
    "admin_user": "admin",
    "admin_pass": "sha256_hash_of_your_strong_password"
  },
  "replication": {
    "enabled": true,
    "port": 9925,
    "host": "10.116.0.2"
  },
  "custom_functions": {
    "enabled": true,
    "path": "/opt/harperdb/custom_functions"
  },
  "logging": {
    "level": "info",
    "file": "/var/log/harperdb/harperdb.log",
    "max_file_size": 10485760,
    "max_files": 5
  }
}

3.1 HTTPS 与认证：不是可选项，而是数据主权的底线

"https": { "enabled": true, ... } 这一行，常被开发者忽略，认为“内部 VPC 通信，HTTP 够用了”。但这是危险的认知。HarperDB 的 replication 协议、Custom Functions 的 onWrite 回调、甚至 /health 健康检查，全部走同一端口（ port: 9925 ）。如果禁用 HTTPS，意味着：

• 所有同步数据（包括可能含 PII 的用户信息）以明文在 VPC 内传输；
• 任何能接入该 VPC 的其他 Droplet（比如一个被攻陷的监控代理），都能抓包看到完整 SQL 查询和返回结果；
• 更严重的是，HarperDB 的 onWrite 函数接收的 event 对象中， event.data 字段就是原始 JSON，HTTPS 是唯一能防止中间人篡改的屏障。

因此，我为每个区域生成了独立的 TLS 证书（使用 Let's Encrypt 的 certbot + DNS 插件，为 harperdb-nyc3.internal 、 harperdb-fra1.internal 等内部域名签发），并严格配置 "key_path" 和 "cert_path" 。证书必须由可信 CA 签发，自签名证书会导致 Custom Functions 的 fetch() 调用（用于调用其他区域 API）因 SSL 验证失败而中断。

"authentication": { "enabled": true, ... } 同理。HarperDB 的 Basic Auth 是粗粒度的，但它构成了第一道防线。 admin_pass 必须是 SHA256 哈希值（用 echo -n "your_password" | sha256sum 生成），而非明文。我还在生产环境中额外启用了 IP 白名单（通过 Nginx 反向代理前置），只允许 FRA1 和 BLR1 的私有 IP 访问 NYC3 的 /replication 和 /function endpoint。

3.2 Replication 配置的真相：它只是“监听器”，不是“同步器”

这是 HarperDB 多区域部署中最大的概念陷阱。 "replication": { "enabled": true, "port": 9925, "host": "10.116.0.2" } 这段配置， 只表示“本实例愿意接受来自其他 HarperDB 实例的同步连接请求”，它本身不发起任何同步动作。 官方文档称之为 “Replication Listener”。

真正的同步行为，必须由 外部协调器（Sync Orchestrator）主动发起 。协调器的工作流程是：

1. 定期（如每 5 秒）向 NYC3 的 /system/health API 发起 GET 请求，确认其 status: "ok" ；
2. 若健康，调用 NYC3 的 /replication/get_changes API，传入上一次同步的 last_sequence_number ，获取增量变更列表（返回 JSON 数组，每条含 table , operation , data , sequence_number ）；
3. 将变更列表 POST 到 FRA1 的 /replication/apply_changes endpoint；
4. 记录本次同步的 last_sequence_number 到本地持久化存储（如 SQLite DB）；
5. 对 BLR1 执行同样流程，但增加 Custom Functions 过滤逻辑（见下节）。

这个流程的关键参数，全部藏在 HarperDB 的 API 文档深处：

• /replication/get_changes 的 last_sequence_number 是一个 64 位整数，从 1 开始递增，全局唯一。它不是时间戳，不能用 Date.now() 替代；
• /replication/apply_changes 的请求体必须是 Content-Type: application/json ，且 data 字段必须是 未序列化的原始 JSON 对象数组 ，不是字符串；
• 如果 apply_changes 返回 409 Conflict ，表示目标库已存在更高 sequence_number 的同表同主键记录，此时必须触发冲突解决逻辑（如“写权威区胜出”）。

提示：HarperDB 的 get_changes API 默认只返回最近 1000 条变更。如果你的同步协调器宕机 2 小时，再启动时会丢失中间变更。解决方案是：在协调器中实现“全量快照回滚”机制——当检测到 last_sequence_number 断层 > 5000，自动触发 /export API 导出 NYC3 全量数据，再导入 FRA1/BLR1。这增加了复杂度，但保障了最终一致性。

3.3 Custom Functions：让数据在流动中“变形”的手术刀

Custom Functions 是 HarperDB 多区域部署的灵魂。它让数据不再是冷冰冰的比特流，而是在跨区域旅程中，能按需“变形”、“脱敏”、“增强”的活体。以我们的用户表 users 为例，在 NYC3 写入的原始数据是：

{
  "id": "usr_abc123",
  "email": "alice@example.com",
  "phone": "+1-555-123-4567",
  "address": "123 Main St, New York, NY 10001"
}

但我们不希望 FRA1 和 BLR1 的数据库里也存着完整的邮箱和手机号——这违反 GDPR 和印度 PDPA 法规。于是，我们在 NYC3 的 /opt/harperdb/custom_functions/users_mask.js 中编写：

exports.onWrite = async function(event) {
  if (event.table === 'users') {
    // 仅对写入 NYC3 的数据进行脱敏，FRA1/BLR1 的同步数据已脱敏，不再二次处理
    if (event.operation === 'insert' || event.operation === 'update') {
      const data = event.data;
      // 使用正则进行确定性脱敏：邮箱保留前3后2，手机号保留后4位
      if (data.email) {
        const [local, domain] = data.email.split('@');
        data.email = `${local.substring(0, 3)}***@${domain.substring(0, 2)}**`;
      }
      if (data.phone) {
        data.phone = `***-***-${data.phone.slice(-4)}`;
      }
      // 地址只保留城市和国家
      if (data.address) {
        const cityMatch = data.address.match(/, ([^,]+), [A-Z]{2} \d{5}/);
        data.address = cityMatch ? `${cityMatch[1]}, USA` : 'New York, USA';
      }
      // 更新 event.data，此修改将写入 NYC3 本地库
      event.data = data;
    }
  }
};

这段代码的关键在于 onWrite 的执行时机： 它在数据写入 NYC3 本地磁盘之前执行，且修改后的 event.data 会作为最终版本被同步到其他区域。 这意味着 FRA1 和 BLR1 收到的，已经是脱敏后的数据，它们的 Custom Functions 不需要再做一遍——既节省资源，又避免重复脱敏导致数据不可逆。

Custom Functions 的调试极其痛苦，因为错误日志只写入 /var/log/harperdb/harperdb.log ，且堆栈信息不完整。我的经验是：在函数开头强制添加 console.log('onWrite triggered for', event.table, event.operation); ，并用 curl -X POST http://10.116.0.2:9925/function/test 手动触发测试事件，观察日志。千万别等到同步失败才去查。

4. 同步协调器（Sync Orchestrator）实战：用 200 行 Node.js 代码构建可靠数据管道

HarperDB 自身不提供跨实例同步器，这既是挑战，也是优势——你可以用最熟悉的语言、最顺手的工具链，打造完全贴合业务需求的数据管道。我最终选择 Node.js（v18.17.0）编写同步协调器，核心原因有三：1）HarperDB 的 Custom Functions 本身就是 JS，生态无缝；2） node-fetch 库对 HTTP API 调用异常简洁；3） sqlite3 模块能以极小开销持久化同步位点（ last_sequence_number ），无需引入 Redis 或 Kafka 等重型依赖。

整个协调器的核心逻辑，浓缩在 sync-engine.js 的 200 行代码中。下面我带你逐段解析，这不是伪代码，而是生产环境正在运行的真实片段。

4.1 初始化与配置加载：把“哪里同步到哪里”刻进代码

const fs = require('fs');
const path = require('path');
const fetch = require('node-fetch');

// 从环境变量或 config.json 加载区域配置
const CONFIG = {
  SOURCE: {
    host: '10.116.0.2', // NYC3 私有 IP
    port: 9925,
    https: true,
    auth: 'YWRtaW46cGFzc3dvcmQxMjM=' // Base64 encoded admin:password
  },
  TARGETS: [
    {
      name: 'fra1',
      host: '10.116.0.3', // FRA1 私有 IP
      port: 9925,
      https: true,
      auth: 'YWRtaW46cGFzc3dvcmQxMjM='
    },
    {
      name: 'blr1',
      host: '10.116.0.4', // BLR1 私有 IP
      port: 9925,
      https: true,
      auth: 'YWRtaW46cGFzc3dvcmQxMjM='
    }
  ],
  POLL_INTERVAL_MS: 5000,
  MAX_RETRY: 3
};

// SQLite 数据库存储每个 target 的 last_sequence_number
const sqlite3 = require('sqlite3').verbose();
const db = new sqlite3.Database('./sync_state.db');
db.run(`CREATE TABLE IF NOT EXISTS sync_state (
  target TEXT PRIMARY KEY,
  last_sequence_number INTEGER,
  updated_at DATETIME DEFAULT CURRENT_TIMESTAMP
)`);

这段初始化代码看似平淡，却埋着关键设计：

• SOURCE 和 TARGETS 的分离，清晰界定了数据流向（单写多读），避免环形同步；
• auth 字段使用 Base64 编码而非明文密码，降低日志泄露风险；
• POLL_INTERVAL_MS: 5000 是平衡延迟与负载的黄金值：太短（如 1000ms）会导致 NYC3 的 /get_changes API 被高频轮询，增加 CPU 压力；太长（如 30000ms）则跨区域延迟超标。5 秒是实测后兼顾性能与体验的阈值；
• MAX_RETRY: 3 是容错底线：网络抖动时，协调器会重试 3 次，第 4 次失败则写入告警日志并暂停该 target 同步，避免雪崩。

4.2 核心同步循环：拉取、过滤、投递、更新位点的原子操作

async function syncLoop() {
  try {
    // Step 1: 拉取 NYC3 的增量变更
    const changes = await fetchChanges(CONFIG.SOURCE);
    if (!changes || changes.length === 0) return;

    // Step 2: 并行投递到所有 targets
    const promises = CONFIG.TARGETS.map(target => 
      applyChangesToTarget(target, changes)
    );
    
    // Step 3: 等待所有投递完成，任一失败则整体回滚（实际是记录失败，不阻塞其他）
    const results = await Promise.allSettled(promises);
    
    // Step 4: 更新位点 —— 仅当所有 targets 都成功时才更新！这是保证一致性的关键
    const allSuccess = results.every(r => r.status === 'fulfilled');
    if (allSuccess && changes.length > 0) {
      const lastSeq = changes[changes.length - 1].sequence_number;
      await updateLastSequenceNumber(lastSeq);
      console.log(`✅ Synced ${changes.length} changes. Last sequence: ${lastSeq}`);
    } else {
      console.warn(`⚠️  Partial failure. ${results.filter(r => r.status === 'rejected').length} targets failed.`);
      // 记录失败详情到日志，供告警系统消费
      results.forEach((r, i) => {
        if (r.status === 'rejected') {
          console.error(`❌ Target ${CONFIG.TARGETS[i].name} failed:`, r.reason);
        }
      });
    }
  } catch (error) {
    console.error('🚨 Sync loop error:', error);
  }
}

// 拉取变更的健壮实现
async function fetchChanges(source) {
  let url = `http${source.https ? 's' : ''}://${source.host}:${source.port}/replication/get_changes`;
  url += `?last_sequence_number=${await getLastSequenceNumber()}`;

  for (let i = 0; i < CONFIG.MAX_RETRY; i++) {
    try {
      const res = await fetch(url, {
        method: 'GET',
        headers: {
          'Authorization': `Basic ${source.auth}`
        }
      });
      if (res.ok) {
        return await res.json();
      } else if (res.status === 404) {
        // HarperDB 404 表示无新变更，正常情况
        return [];
      } else {
        throw new Error(`HTTP ${res.status} from ${url}`);
      }
    } catch (err) {
      if (i === CONFIG.MAX_RETRY - 1) throw err;
      console.warn(`Retry ${i + 1}/${CONFIG.MAX_RETRY} for fetchChanges...`);
      await new Promise(r => setTimeout(r, 1000 * (i + 1))); // 指数退避
    }
  }
}

这段代码的精妙之处在于 updateLastSequenceNumber 的调用时机： 它只在 Promise.allSettled 确认所有 targets 都成功应用变更后才执行。 这确保了“位点推进”与“数据落地”是原子的。如果 FRA1 成功而 BLR1 失败，位点不会推进，下次循环会重新拉取这批变更，直到 BLR1 也成功。这牺牲了部分吞吐量，但换取了强最终一致性。

fetchChanges 中的 404 处理是 HarperDB 的特殊约定：当 last_sequence_number 已是最新，API 返回 404 而非空数组。很多开发者误以为是错误，其实这是 HarperDB 的“无新数据”信号，必须正确捕获，否则协调器会疯狂报错。

4.3 Custom Functions 的协同：在投递前做最后一道数据加工

FRA1 和 BLR1 的同步逻辑并非简单转发。BLR1 作为边缘处理区，需要在数据抵达时，再执行一次本地 Custom Functions（如生成用户画像标签）。但 HarperDB 的 apply_changes API 不会触发目标库的 onWrite 函数——它绕过所有钩子，直接写入 SSTable。

解决方案是： 在协调器投递前，主动调用 NYC3 的 Custom Function 进行预处理。 我们在 NYC3 部署了一个名为 pre_sync_transform 的函数：

// /opt/harperdb/custom_functions/pre_sync_transform.js
exports.execute = async function(params) {
  const { table, data } = params;
  if (table === 'users') {
    // 为 BLR1 添加本地处理字段
    data.blr_local_tag = 'INDIA_USER';
    data.blr_last_sync = new Date().toISOString();
  }
  return data;
};

然后在 applyChangesToTarget 函数中，对发往 BLR1 的每条变更，先调用此函数：

async function applyChangesToTarget(target, changes) {
  // 如果是 BLR1，先对每条 change 执行预处理
  let processedChanges = changes;
  if (target.name === 'blr1') {
    processedChanges = await Promise.all(
      changes.map(async change => {
        const res = await fetch(
          `https://${CONFIG.SOURCE.host}:${CONFIG.SOURCE.port}/function/pre_sync_transform`,
          {
            method: 'POST',
            headers: {
              'Content-Type': 'application/json',
              'Authorization': `Basic ${CONFIG.SOURCE.auth}`
            },
            body: JSON.stringify({ table: change.table, data: change.data })
          }
        );
        return { ...change, data: await res.json() };
      })
    );
  }

  // 再 POST 到 target
  const res = await fetch(
    `https://${target.host}:${target.port}/replication/apply_changes`,
    {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'Authorization': `Basic ${target.auth}`
      },
      body: JSON.stringify(processedChanges)
    }
  );
  if (!res.ok) throw new Error(`Apply failed: ${res.status} ${await res.text()}`);
}

这个设计让 Custom Functions 的能力延伸到了同步管道中，实现了“数据在哪里产生，就在哪里定义其形态”的理念。它比在 BLR1 本地写 onWrite 更安全，因为预处理逻辑由 NYC3 统一控制，版本一致，无脑同步。

5. 生产就绪：监控、告警、故障演练与日常巡检的硬核 checklist

多区域部署上线不是终点，而是运维长跑的起点。HarperDB 的轻量特性，意味着它不会像传统数据库那样提供丰富的内置监控指标。我们必须自己动手，把“数据是否在流动”“流动是否健康”“流动是否合规”变成可量化、可告警、可追溯的事实。以下是我在生产环境坚持执行的硬核 checklist，每一条都来自血泪教训。

5.1 必须部署的 5 个监控维度与对应命令

注意：所有 curl 命令必须加 -k （跳过证书验证）和 -u （Basic Auth），因为这是在服务器本地执行，安全性由 VPC 和防火墙保障。生产环境严禁在脚本中硬编码密码，应使用 vault 或 doctl secrets 注入。

5.2 故障演练：每月一次的“拔网线”测试

自动化监控只能告诉你“坏了”，而故障演练能告诉你“怎么修”。我坚持每月最后一个周五下午，执行一次完整的“区域隔离”演练：

1. 模拟 NYC3 宕机 ：在 NYC3 Droplet 上执行 sudo systemctl stop harperdb ，并 iptables -A OUTPUT -p tcp --dport 9925 -j DROP 模拟网络中断；
2. 验证 FRA1 是否接管 ：手动修改 FRA1 的 harperdb.conf ，将 replication.enabled 设为 false ，并临时启用其 onWrite 函数，使其能接受写入（需提前准备好切换脚本）；
3. 检查 BLR1 数据一致性 ：在 BLR1 上执行 SELECT COUNT(*) FROM users WHERE blr_local_tag = 'INDIA_USER'; ，确认新写入数据已正确打标；
4. 恢复 NYC3 ：启动服务，等待同步协调器自动追平位点，验证 last_sequence_number 差值归零；
5. 回滚写入权限 ：将写入权限切回 NYC3，确认所有区域数据最终一致。

这个演练过程暴露出过三次关键问题：1）FRA1 的 Custom Functions 没有预热，首次写入时 V8 引擎编译耗时 2.3 秒；2）BLR1 的 sync_state.db 文件权限错误，协调器无法写入位点；3）DNS 解析缓存导致 NYC3 恢复后，协调器仍尝试连接旧 IP。每一次修复，都让系统更健壮一分。

5.3 日常巡检：一份 5 分钟就能完成的运维清单

每天上午 10 点，我花 5 分钟执行这份清单，它比任何 fancy 的 Grafana Dashboard 都管用：

• 查日志 ： tail -n 50 /var/log/harperdb/harperdb.log \| grep -E "(ERROR|WARN)" —— 重点关注 CustomFunctionError 和 ReplicationError ；
• 查磁盘 ： df -h /opt/harperdb/data —— HarperDB 的 data 目录增长最快，预留空间必须 > 20%；
• 查同步位点 ： sqlite3 ./sync_state.db "SELECT target, last_sequence_number, datetime(updated_at) FROM sync_state;" —— 确认三个 target 的 `last_sequence