3主一读副本，假设我现在给只读副本进行写操作，他是不是通过rootservice把写操作传入主副本操作，还是直接在当前副本写入。
1 个赞
仅提供读服务不会进行写
通过ODP使用自己定制的 Parser 模块解析出 DML 语句中的数据库名、表名和 Hint。
ODP 根据用户的请求 SQL 获取该 SQL 涉及的副本位置。先尝试从本地缓存中获取路由表，其次是全局缓存，如果都没有获取到，最后会发起异步任务去向 OBServer 查询路由表。
2 个赞
1 个赞
副本写入应该是有任务自动分发呢吧
2 个赞
在一个三节点集群中：
主副本（Leader 副本）：
主副本是唯一能够提供写服务的副本。
所有的写操作（如 INSERT、UPDATE、DELETE 等）都必须由主副本处理。
主副本在事务提交时，会将事务日志同步到两个备副本（Follower 副本），并通过 Paxos 协议表决事务是否提交成功。
备副本（Follower 副本）：
备副本默认只能提供读服务，并且是强一致性读。
如果需要让备副本承担部分读请求（即弱一致性读），可以通过 SQL Hint 实现，例如使用 /*+ read_consistency(weak) */。
备副本不能直接处理写操作。任何对备副本的写请求都会被拒绝或转发到主副本进行处理。
在OceanBase 的架构中，RootService 负责管理分区的元数据和副本的角色分配。当客户端向只读副本发送写请求时，RootService 会引导该请求路由到主副本。
主副本完成写操作后，会将事务日志同步到备副本，以保证数据的一致性。
4 个赞
目前发现直连只读副本可以写入数据，没有被拒绝，那就是RootService把请求路由到主副本执行了是吗？假设我现在想把一些轻量的写业务伴随多读业务放在只读副本上是否可行呢。
2 个赞
是通过2881直连的只读副本吗，没有拒绝就说明是RS把请求路由到主副本执行了，只读副本只能承载读请求。
你的需求，只需要部署obporxy服务即可完成，也就是通过2883端口连接数据库，obproxy服务路自动路由接收到的请求，分发给对应副本执行。
2 个赞
，，，
1 个赞
嗯嗯 主要我不想再加个ob所以我这么尝试的 发现没有报错 因此我就来这问问呢这样是否可行 
1 个赞
根据文档库中的信息，可以对您的问题进行如下解答：
-
只读副本的写操作机制
根据文档片段 5 和片段 4 的描述，OceanBase 数据库的只读副本（Follower）本身并不支持直接写入操作。所有写操作必须在主副本（Leader）上完成，然后通过日志流（Log Stream）将 Redo 日志同步到只读副本。因此，当您尝试在只读副本上执行写操作时，实际上是 OBProxy 或 Root Service 将请求路由到了主副本执行。这符合 OceanBase 的设计原则，即写操作只能在 Leader 上完成。文档依据：
- 片段 4 提到，“Tablet 的 DML 和强一致性查询只在其对应的日志流的主副本上进行。”
- 片段 5 进一步说明了只读副本的功能定位，“弱一致性读是在异步复制的数据同步方式下的一种常见选择，Leader 在写入时不需要关注 Follower 的数据回放进度。”
-
是否可以在只读副本上放置轻量写业务
您提到希望通过只读副本承载一些轻量的写业务，以避免增加额外的 OBServer 节点。这种做法虽然在测试中没有报错，但从架构设计和性能角度考虑，不建议这样做。原因如下：- 写操作本质上仍然会路由到主副本执行，因此并不会减轻主副本的压力。相反，由于增加了 OBProxy 或 Root Service 的路由开销，可能会导致整体性能下降。
- 只读副本的主要目的是分担读压力，而不是承担写操作。如果需要更多的写能力，建议通过扩展主副本或增加 OBServer 节点来实现。
-
实际测试结果与文档的一致性
您提到直连只读副本可以写入数据且没有被拒绝，这可能是因为 OBProxy 或 Root Service 自动将请求路由到了主副本。这种行为是预期的，并不代表只读副本本身支持写操作。如果您希望明确区分读写流量，可以通过配置 SQL 路由策略（如强一致性读、弱一致性读等）来优化请求分配。 -
建议的解决方案
如果您希望减少 OBServer 的数量但又需要支持更多的写业务，可以考虑以下方案：- 使用单日志流事务优化（参考片段 8），尽量将多表写操作集中在同一日志流 Leader 上，从而提升写性能。
- 如果写业务确实较轻量，可以通过合理配置 Locality 和 Primary Zone 来优化资源分配，确保主副本所在的机器负载均衡。
总结：
- 当前的行为是正常的，写操作会被路由到主副本执行。
- 不建议将写业务放在只读副本上，因为这不会真正减轻主副本的压力，反而可能增加系统复杂度。
- 如果需要扩展写能力，请考虑增加 OBServer 节点或优化事务模型。
如有进一步疑问，欢迎继续咨询！
更多信息请查看:
3 个赞
当前节点数足够，不用再添加observer，如果环境没有obproxy服务，还需要部署个obrpoxy服务（代理）
2 个赞
学习
可行但是方法不当。
可行是因为 OBServer 都有 SQL 路由功能，不当是因为 OBServer 路由成本比 OBProxy 路由成本高多了。