《GBase 8s 高可用四部曲》 前两部介绍了南大通用GBase 8s数据库（gbase database）的HAC 同城守护、RHAC 异地保命，它们都是"一主多备"的接力赛——主节点跑，备节点 standby。但如果你的业务需要 所有节点同时读写同一份数据 ，还要保证强一致，怎么办？SSC就是答案： 数据只有一份，全员一起上。
一份数据，全员读写
SSC 的核心思路简单粗暴： 所有计算节点共享同一套存储设备 ——部署在磁盘阵列或逻辑卷管理器上，数据只有一份，不存在复制延迟。写入节点写逻辑日志，通过 SMX 协议 把日志序列号（LSN）同步给其他各节点；其他节点收到 LSN 后从共享磁盘读取对应日志，在内存 buffer 中重做，不写回磁盘——既保证了数据一致性，又避免了重复落盘的开销。
这种架构下， 任意节点都可以读写 ，是真正意义上"全员出战"的多活架构。
弹性扩容：查询多了？加节点就行
SSC 最强悍的能力之一是 横向扩展 。业务数据量涨了，查询压力大了？往集群里新增 SSC 辅节点，处理能力跟着线性上涨—— 高容量 OLAP 分析操作、大量并发查询 都能扛住。
更妙的是 容错机制 ：某个辅节点宕机，其他节点自动接管其负载，业务无感知；只有主节点宕机时才触发故障转移， 5 秒内完成切换 。这意味着集群规模越大，单点故障的影响越小—— 节点即战力，越多越好 。
对比 RAC：简单即正义
提到共享存储多活，很多人第一时间想到 Oracle RAC。两者看起来相似，但底层逻辑截然不同：
一句话总结： SSC 用"逻辑日志+共享存储"实现了多活，架构简洁、辅节点容错、扩展灵活 ；RAC 用"共享内存+双主同步"实现了多活，架构复杂、高写入下容易性能衰减。国产替换选 SSC，简单即正义。
适用场景：核心业务的最佳拍档
SSC 不是全能的，但在这几个场景里就是 最优解 ：
1、核心交易 ：针对强一致性场景，全局事务保障数据不丢不乱，辅节点同步扛查询。
2、中大型库（2TB~100TB） ：共享存储免复制延迟，查询多了加节点，弹性扩展。
3、国产替换 RAC + 两地三中心 ：架构简洁、扩展灵活，搭配 HAC + RHAC 实现同城高可用 + 异地容灾 + 横向扩展，一套组合拳打天下。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/69979120/viewspace-3173158/ ，如需转载，请注明出处，否则将追究法律责任。
最新文章
- GBase 8a MPP集群个人电脑安装环境分析
- 南大通用GBase 8c分布式数据库部署选型容易被忽略的因素
- 南大通用GBase 8c分布式数据库部署形态选型依据
- GBase 8c数据库不同部署形态多维度对比（下）
- GBase 8c数据库不同部署形态多维度对比（上）
- 世界统计日 | GBase数据库让每一次决策都“有数可依”（下）
- 世界统计日 | GBase数据库让每一次决策都“有数可依”（上）
- 南大通用GBase 8c数据库不同部署形态的架构差异（上）
- 南大通用GBase 8s数据库TPC-H仅21.34秒，跑出列存真实力（下）
- GBase 8s数据库TPC-H仅21.34秒，跑出列存真实力（上）
