举例 架构 1-1-1，租户primary_zone 为zone1；zone2；zone3 。要停止zone1进行服务器修理。先将primary_zone切换到别的机器上，新的请求会转发到别的机器上，那旧的连接是等待事务执行完后再停进程，还是直接就停止进程了？
根据文档库中的信息，停止 OBProxy 时的行为和现有连接的事务处理方式如下：
-
OBProxy 停止对现有连接的影响
- 当您使用 OCP 停止 OBProxy 时，默认情况下，现有的连接可能会被中断。这是因为停止 OBProxy 操作会造成业务中断（见文档片段 3）。这意味着如果在停止 OBProxy 的时候存在正在进行的事务，这些事务将被迫终止。
-
针对特定情况下的事务处理
- 尽管默认行为是立即中断现有连接，包括正在执行中的事务，但在一些场景下为了确保服务连续性，通常希望等待现有事务完成后再进行 OBProxy 的停止操作。
- 对于您的具体例子中提到的情况——在一个
1-1-1架构下（即每个 Zone 只有一个 OBServer 节点），且租户的主要工作负载由三个不同的 Zone (zone1, zone2, zone3) 承担，当您需要停止某个 Zone（如 zone1）进行维护时，首先应通过调整租户的 primary_zone 设置来转移新进来的读写请求到其他可用的 Zone 上。这一步可以减少因停止 zone1 而造成的业务影响。 - 在此之后，关于是否等待当前所有活动事务完成再停止进程，基于提供的文档信息并没有明确说明自动机制来实现这一点。然而，考虑到实际操作的最佳实践以及避免数据不一致的风险，建议手动监控并等待活跃事务结束或达到可接受的安全状态后，再执行 OBProxy 或者 OBServer 的停止命令。这样做虽然增加了操作复杂度，但是能够最大限度地保证数据库的一致性和完整性。
-
事务状态与主备切换
- 另外值得注意的是，ODP (OceanBase Database Proxy) 维护了事务状态以确保事务内不切换 Server Session，从而保证事务一致性。如果在事务过程中发生 OBServer 故障，ODP 需要感知该状态并将未完成的事务关闭，并通知客户端（参见文档片段 5）。这种机制强调了在进行任何可能影响在线会话的操作前，确保所有事务已妥善处理的重要性。
综上所述，在您给出的情境下，最安全的做法是在转移 primary_zone 并确认没有新的请求到达即将停机的 Zone 后，密切监视现存事务直至其自然结束，然后再执行停止操作。直接停止可能会导致正在进行的事务被强行中断，进而造成数据不一致或其他潜在问题。
具体信息可参考以下文档: