Linux 上实现 Informix 高可用的主流架构
- HDR（High Availability Data Replication）：基于数据库日志的主-备复制。主机处理写，备机默认只读；主机故障时备机可接管。适用于同城双活/快速切换。
- SDS（Shared Disk Secondary）：多实例共享同一SAN/NAS磁盘，备机可快速接管，适合写压力较高、切换要快的联机交易场景。
- RSS（Remote Standalone Secondary）：面向广域网的异步复制，强调灾备与远距离容灾能力。
- CLR（Continuous Log Restore）：在网络不佳或离线场景，通过持续逻辑日志恢复实现近实时恢复与回放。
- 以上技术共同目标是提供数据冗余、自动故障转移、复制与负载分担、监控告警等能力，保障业务连续性。
典型架构与适用场景
| 方案 |
拓扑关系 |
数据路径 |
切换速度 |
主要优点 |
典型场景 |
| HDR |
主 ↔ 备（1 对 1/1 对多） |
日志传输 |
快（取决于日志应用） |
切换简单、备机可读、同城双活 |
核心交易、要求 RTO/RPO 较低 |
| SDS |
多实例共享磁盘 |
共享存储 |
很快（磁盘已就绪） |
接管快、对网络时延不敏感 |
高写并发、低切换时延 |
| RSS |
主 → 远端备 |
异步日志 |
受网络影响 |
远距离容灾、带宽友好 |
异地灾备、园区级容灾 |
| CLR |
主 → 恢复实例 |
逻辑日志回放 |
取决于回放进度 |
网络不稳/离线可用 |
备份与近实时恢复、演练 |
落地实施步骤
- 规划与容量
- 明确 RTO/RPO 目标；选择 HDR/SDS/RSS/CLR 的组合；准备主备节点的主机名、IP、磁盘、网络与存储（SAN/NAS）。
- 安装与基础配置
- 安装相同版本的 IBM Informix Dynamic Server（IDS）；统一时区与时间同步（如 NTP）；配置 sqlhosts 与网络连通（TCP/SSL）。
- 复制/共享存储配置
- HDR：在主库启用日志、初始化备库、建立 HDR 连接、校验复制状态；
- SDS：配置共享磁盘与实例参数，确保备机可快速接管；
- RSS：配置异步复制通道与带宽/压缩策略；
- CLR：建立日志备份与连续恢复流程。
- 切换与演练
- 制定并定期演练主备切换/故障接管流程；验证应用重连、事务一致性与数据完整性。
- 监控与告警
- 使用 onstat、onmode 等内置工具结合 Zabbix/Nagios 建立监控与阈值告警，覆盖复制延迟、磁盘/CPU/IO、连接数等关键指标。
关键配置与运维要点
- 复制一致性参数
- 在 HDR/SDS/RSS 部署中，确保主备 onconfig 关键参数一致，如：ROOTNAME、ROOTPATH、ROOTSIZE、LOGFILES、LOGSIZE、DYNAMIC_LOGS、DRAUTO、DRINTERVAL、DRTIMEOUT，以减少切换风险与数据不一致。
- 存储与网络
- 共享存储需具备冗余与一致性（SAN/NAS 最佳实践）；跨机房链路建议低时延/高带宽并做好带宽与压缩规划。
- 监控与备份
- 建立以 onstat/onmode 为核心的性能与健康巡检；定期执行 ontape 全量/增量备份，并进行备份校验与恢复演练，确保关键时刻可恢复。
- 稳定性优化
- 结合业务进行 内存/大页、SSD、RAID、内核参数、文件系统挂载选项 等调优，降低抖动与故障概率。
常见误区与建议
- 仅依赖应用层重试而不建设数据库层的 HDR/SDS/RSS，难以满足低 RTO/RPO 要求。
- 主备硬件/参数差异过大或时区不同步，导致复制与切换异常。
- 忽视定期切换演练与备份校验，真实故障时才发现恢复流程不可行。
- 建议以业务目标（RTO/RPO）反推架构，优先选择 HDR/SDS 满足同城高可用，配合 RSS/CLR 构建异地容灾与近实时恢复能力。