OceanBase Session ID 之谜

一. 写作原因

遇到了 3 个事情，让我想到要好好梳理一下 session id 的相关知识。

1. 发现一个事务中查到的 OceanBase 的 session id 会发生变化（其实也算没有变，原因下文会说）。
2. 查到的 session id 在使用 kill 命令时候报错找不到该 ID（不是因为 ID 真的不存在或者变化了）。
3. 通过不同的查询方式，查到很多和 session id 有关的 ID 值，没法在脑中组织成知识网络，不理解部分 ID 为什么这么设计。

session id 概述

session id 是用于描述客户端和数据库的访问链路的，OceanBase 数据库架构中使用了 ODP（一般也称为proxy，下文也用 proxy 指代），所以客户端对数据库的访问链路被拆成了两段，第一段是客户端和 ODP 之间的连接（Client session，下文用 C 连接指代），第二段是 ODP 和 OBServer 之间的连接（Server session，下文多用 S 连接指代）。

一个客户端的连接，会使用一个 C 连接，然后对应多个 S 连接，C 连接和 S 连接的对应关系是 1 : N。值得注意的是，在执行一条 SQL 的时候，同一时间，只有一个 S 连接在服务（先不考虑远程计划或分布式计划带来的二次路由）。

那么问题来了：用于定义 2 种连接的 Session id，却可以在官方文档中找到 10 种名词定义：

• ID
• session id
• client session id
• server session id
• connection id
• proxy_sessid
• cs_id
• server_sessid
• ss_id
• MASTER_SESSID

这是为什么呢？

二. 写作思路

开始研究这个主题的时候，是想要写一个 Session ID 的前世今生的，但在翻文档、找人聊、自己测之后，发现问题比以前更多了……

在几次草稿都被自己否了以后，我悟了 —— 追求细节和完备最终导致我无法搞定文章，一个理解框架才是我们需要的东西。通过这个框架可以串联起知识，然后遇到问题之后可以通过框架解决问题，这才是最有价值的。

三. session id 介绍

从一张图开始：

图中直观的展示了客户端（client）和数据库（ODP + OBServer）之间的链路关系。

为了方便下面的描述，我们把图中的 4 根连接线分别命名，client 和 ODP 之间的链路叫 C-1，ODP 分别连接 OBServer 的 3 个链路叫 S-1、S-2、S-3（下面没有特殊说明，都不考虑直连的情况）。

那么有一些事情需要大家能想清楚（可能会有点儿绕）：

1. C-1、S-1、S-2、S-3 都是独立的连接，背后会对应各自的 ID。而且一个连接两端的组件（比如 S-1 两端分别对应了 ODP 和 OBServer）可能对同个连接 S-1，给予不同的 ID。不同组件对 S-1 不同的 ID 编号这个事情，这么设计有很多种可能。大家能想到几种呢？
2. 一整个会话（包含 C-1、S-1、S-2、S-3），只要不断开，不结束，都是被独占的。其他的会话不可能共用里面的任何一条链路。
3. 单一个 SQL 的执行，只会使用一种组合，C-1 + S-X（这里的 S-X 就是指 3 条 S 中的其中一条）。也就是针对一个 SQL 只有一个 S 连接参与服务（这里不考虑二次路由）。
4. 同一个事务的不同 SQL，会使用到不同的连接组合，这也是 ODP 的事务内路由的功能，这样可以让更多的SQL 使用本地执行计划。
5. 查看会话的视图，习惯是一个会话是展示一行（因为在同一时刻，一个会话中只能执行一条 SQL）。其实 OceanBase 这里有 2 种展示模式，show processlist 是一个会话 C 连接的维度，show full processlist 就是展示 S 连接的维度（会有多条）。可以想见同一个会话中，最多也只有一条在工作，其他的都是 sleep。
6. 一个客户端第一次连接上数据库，返回连接成功，说明 C-1 + S-1 的链路已经建立了，这个时候其实 S-2 和 S-3 还不存在，直到 ODP 需要连接的时候才会建立连接。

回到上面很多的名词问题，这里给出一个初步的解释：

• 连接的类型是只有 2 种，C 连接和 S 连接。
• 描述他们的不同编码（小编理解这里的 “编码” 就是序号或者 ID 的含义） 一共 4 种，其他的名词都是这 4 种的其中一种的指代。
  • cs_id：这是由 proxy 生成的用于描述 C 连接的编码，也是我们最常见的 session id 表述之一，show processlist 里的 ID 列通常指代的就是这个 cs_id（注意是通常）。
  • proxy_sessid：这也是由 proxy 生成的用于描述 C 连接的编码，编码比较长一些，在 proxy 和 OBServer 建立连接的时候，proxy 会告诉 OBServer，我上游服务的 C 连接的编码就是这个。（注意 proxy 没有告诉下游编码是 cs_id，而是 proxy_sessid 。简单的记忆就是，同样一个 C 连接，对客户端 proxy 使用 cs_id ，对 OBServer 端则使用 proxy_sessid。挺住，别晕。
  • server_sessid：由 OBServer 生成的用于描述 S 连接的编码，在整个 OceanBase 集群内是唯一的，也是 OBServer 中用的很多的编码，比如 OB_LOCKS 视图中用的就是这个。
  • ss_id：由 proxy 生成的用于描述 S 连接的编码，用到这个编码的地方非常少，了解即可。

总结：proxy 生成了 3 个编码，包括 cs_id、proxy_sessid、ss_id。其中 cs_id 和 ss_id 偏向于 proxy 内部使用，proxy_sessid 会传递给 OBServer，在 OBServer 的日志中可能会有查询的需求。OBServer 生成了一个编码，即 server_sessid，用于定义 S 连接的 session id。如果是直连的情况，则只有 server_sessid，因为其他 3 个都是在 proxy 体系下使用的。

如果你能绕清楚，那就继续来到下一关，先和这些 session 相关名词混个脸熟：

• ID：在不同的查询场景下，这个列有时显示的是 cs_id 值，有时是 server_sessid 值。
• session id：泛指 session 的编码，出现在 OceanBase 官方文档各处，一般查表中没有这个字段。
• client session id：一种新版本的 cs_id，后面会介绍为什么需要重新设计 cs_id。有时也指代 C 连接。
• server session id：就是 server_sessid ，有时也指代 S 连接。
• connection id：MySQL 租户使用函数 connection_id() 查询获得，就是 server_sessid。需要注意的是使用 obclient 连接 proxy 时候，登陆信息中会有输出 Your Mysql connection id is xxx，这里显示的 id 是 cs_id。

• MASTER_SESSID：这个比较特殊，指的是分布式查询中的主 server_sessid，不属于 S 连接（本文暂不讨论）。

四. 查询 session id 的例子

下面是模拟的一个例子，大家通过这个例子可以更好的理解相关概念。

架构中一个客户端连接了一个 proxy，然后 proxy 连接了后面的 2 个 OBServer。

也就是 C-1 ，对应了后面的 S-1 和 S-2 。

在确保 C-1，S-1，S-2 都被启用过以后，执行下面这些命令：

show proxysession;show proxysession attribute;show processlist;show full processlist;select connection_id();select * from gv$ob_session;select * from gv$ob_processlist;

分别得到下面的结果：

• show proxysession;
  • 这里的 id 就是 cs_id。
  • 直连是无法执行这个命令的（需要有 proxy）。

• show proxysession attribute; 这里就是查看这个 cs_id 的明细了。这个 cs_id 对应了 2 个 server_sessid ，分别是 3221550874 和 3221876366，它们的区别在 info 这个列：
  • last used ss 指的就是我执行这个查询 SQL 是用的这个 S 连接。
  • ss pool 就是已经建立了这个 S 连接，之前是用到过的。

同样的，这个命令在直连时候是无法执行的，因为这个命令只有 proxy 能处理。

• show processlist;
  • 使用 proxy 的时候，这个 ID 是 cs_id。需要注意 show processlist 在 proxy 的语境下，就是查这个 proxy 上的 session，以 C 连接的视角（也就是一个客户端连接就显示一条）。
  • 使用直连时候，这个 ID 是 server_sessid。

• show full processlist;
  • 这个就是查看所有的 S 连接了，这里的 ID 是 server_sessid。
  • 图中标蓝的部分都属于同一个 C 连接，可以对照 show proxysession attribute 的内容看。

• select connection_id();
  • 查到的是执行这个 SQL 的 S 连接，是 server_sessid。

• select * from gv$ob_session;
  • 这里标蓝的部分都属于同一个 C 连接，它们拥有同一个 proxy_sessid，按理只有 2 个 S 连接，为什么有 4 条数据对应 4 个 ID 呢？
  • 你会发现 4 个 ID 中有 2 个是前面例子中出现过的 server_sessid，而剩下的 2 个是新 server_sessid。
  • 注意看 info，PX DFO EXECUTING 意思是分布式的执行。因为 gv$ob_session 的查询需要去所有的 OBServer 上看相关信息，所以实际执行这个 proxy_sessid 的 SQL 的 OBServer，建立新的连接（S 连接背后对应的新的分布式执行连接），分别查询了 OBServer 的内部信息。
  • 我们可以通过其他列（比如TRACE_ID，HOST等）的信息来理解。

这也可以看到，实际上 OceanBase 数据库等访问连接是比较复杂的，这个案例中连接分了 3 段，第一段是客户端到 proxy，第二段是 proxy 到 OBServer，第三段是 OBServer到 OBServer（自己也需要重新访问自己的）。

• select * from gv$ob_processlist;
  • 这里和 show full processlist 的结果是一样的。
  • ID 代表的是 server_sessid，不会展示 S 连接后续的连接（有别于 gv$ob_session 视图）。

如果能坚持看完上面这些例子，要么你已经对 session id 的情况有了全面的了解，要么你已经彻底晕菜。没关系，如果晕了，可以先收藏，后面遇到问题时再有的放矢地看。

如果你能坚持看到这里的话，那我们就继续再说一个与 session id 配套的命令 —— kill。

五. session id 与 kill 命令

kill 后面跟的是 session id，执行后这个会话就会被杀死，执行的 SQL 会停止，之前锁定的资源也将释放。

但是因为 session id 本身的复杂性，kill 命令的实现，也有不同的逻辑。我们一般会使用取到的 ID 列中的值来作为 kill 后跟随的编码，那么可能是 cs_id 或者是 server_sessid。

还有一些特点，大家理解一下：

1. 执行 kill 的 session 本身除了可以杀自己，还可以杀别的 session。
2. kill 在 ODP 4.2.3 版本之前（以下称为不透传 kill），是由 proxy 自己执行的，直接从 proxy 侧断开相关 session 的 C 连接和 S 连接。
3. kill 在 ODP 4.2.3 版本开始（以下称为透传 kill），会把 kill 信息转交给 OBServer 去执行，然后通过错误码告诉 proxy，proxy 再断开相关 C 连接和 S 连接。
4. proxy 本身是无状态的，看不到其他 proxy 中的 cs_id。
5. cs_id 是 proxy 内部对 C 连接的编码，OBServer 对 C 连接的认知是 proxy_sessid。

不透传 kill 的情况，做了个表格：

*\组件(列)ID(行)*	proxy （C 连接在此 proxy）	proxy （C 连接不在此 proxy）	直连 （不区分 S 连接是不是在这台 OBServer 上）
cs_id	认识，可以 kill。	不认识，因为 proxy 无状态，无法 kill。 或者恰巧有个一样的 cs_id，kill 错。	不认识，根本没有 cs_id 信息。
server_sessid（主）	认识，可以 kill。	可以认识，但是不归这个 proxy 管，无法 kill。	认识，kill 成功，proxy 感知后，后续把对应的 C 连接断开。
server_sessid（非主）	认识，可以 kill。	可以认识，但是不归这个 proxy 管，无法 kill。	多种情况，比较复杂。

先说建议：就是如果用的是 proxy，那就不要使用直连方式去 kill。

如果遇到 kill 不掉（可能是因为 F5 这样的负载均衡把 kill 语句路由到了其他无法处理的 proxy），就多执行几遍，一般总有一次 kill 成功的（成功一次就算 kill 成功了）。虽然上面的表格中写了有可能 kill 错，但是概率很低。

因为上面不透传的情况，会遇到各种的问题。后来 OceanBase 研发对 kill 进行了重新设计。主要解决了 2 个问题：

1. C 连接不归 proxy 管的问题（现在统一交给后面的 OBServer 执行，然后相关的 proxy 就可以收到来自 OBServer 的返回码后，处理断开 C 连接了）。
2. cs_id 可能在不同的 proxy 之间重复的问题（启用新设计的 client session id 替代 cs_id，通过合理编码来使其具有唯一性），另外 client session id 也将在 proxy 和 OBServer 之间建立连接的时候告诉 OBServer，这样 OBServer 就都认识了。

透传 kill 的情况，也做了一张对应表格：

*\组件(列)ID(行)*	proxy （C 连接在此 proxy）	proxy （C连接不在此 proxy）	直连 （不区分 S 连接是不是在这台 OBServer 上）
client session id	认识，可以 kill。	可以认识（问 OBServer 嘛）然后透传给 OBServer执行，可以kill。不会有重复问题	认识，可以 kill。
server_sessid（主）	认识，可以 kill。	可以认识，透传，可以 kill。	认识，kill 成功，效果就等于 proxy 把 kill 透传了。
server_sessid（非主）	认识，可以 kill。	可以认识，透传，可以 kill。	多种情况，比较复杂。

透传以后，是不是情况好多了？但我的建议依然还是建议都使用 proxy 来管理 kill，（而且2个组件都升级到新的使用 client session id 的版本）按照常用情况来管理，问题最少。

值得一提的是，透传后的情况表格漏掉了很多情况，你看出来了吗？原因就是这个时候 proxy 和 OBServer 面对 kill 命令都有 2 套逻辑，这里的例子都是新 proxy 逻辑对新 OBServer 逻辑，还有老 proxy 逻辑对新 OBServer 逻辑和新 proxy 逻辑对老 OBServer 逻辑的情况。

理想中是要列出所有情况的，但这篇文章的作者今川说他偷懒不想整理其他情况了，那我们还是选择原谅吧~

六. 总结

最后返回文章开头的问题，为什么要使用这么多的名词来管理 2 种连接。

1. 最大的原因还是分布式的架构引入的复杂性决定的。而且 proxy 被设计成无状态的，在前面还加入 F5 这样的负载均衡组件，也增加了管理难度。
2. 数据库软件复杂度很高，多个团队协作开发，必然有一些东西是不统一的，并且存在冗余设计，否则沟通成本将被无限放大。
3. 数据库软件是一个不断演进的系统，有些东西虽然现在看来已经没有用了，但是也不能去掉，作为兼容性的一部分长久留在代码中。如同我们的 DNA，很多序列都是不表达的，没什么用处，但是是人类演进过程中的一部分也就被保存在 DNA 中了。

七. 后续

还有一个出现在 proxy 日志中，用于指代 C 连接的代码 sm_id，相关的信息比较少。sm_id 是 proxy 中的 proxy_sm 模块对 cs_id 的指代。只在日志中出现，由于数据库里没有视图查到这个信息，我认为主要是给 proxy_sm 模块研发使用的。一般排查日志可以通过 trace_id 来过滤。