关于session:OB运维-连接-kill-中的-sessionid

54次阅读

共计 2718 个字符,预计需要花费 7 分钟才能阅读完成。

作者:姚嵩

外星人 …

本文起源:原创投稿

* 爱可生开源社区出品,原创内容未经受权不得随便应用,转载请分割小编并注明起源。


背景:

通过 obproxy 连贯 OB 后,发现:

kill 命令使⽤ show processlist 中的 ID 能执⾏胜利,

使⽤ information_schema.processlist

或者 oceanbase.__all_virtual_processlist 中的 ID 进⾏ kill 是失败的。

于是就进⾏了各种连贯测试,解惑两个问题:

  1. kill 中 session_id 的起源;
  2. 是否能够⼀次性⼲掉⼀个租户的所有连贯;

测试阐明:

阐明:

session_id 是 kill 语句的参数,session_id 和下⽂中的 ID 是同⼀对象;

视图 information_schema.processlist 的数据来源于表 oceanbase.__all_virtual_processlist。

登陆命令阐明(以本⼈测试的环境为例):

登陆 observer:

mysql -uroot@sys -p -P2881 -h ${oberver_ip} -c -A oceanbase

登陆 obproxy:

mysql -uroot@sys#yjn_test -p -P2883 -h ${obproxy_ip} -c -A oceanbase

测试案例

登陆某个 observer 的节点:

⽬标:

确认 observer 上

show processlist

表 information_schema.processlist

表 oceanbase.__all_virtual_processlist

获取的 ID 是否雷同?

执⾏语句:

show processlist ;
select * from information_schema.processlist ;
select id,user,host,db,command,time,state,info from oceanbase.__all_virtual_processlist ;

后果:

3 个语句取得的 ID 是雷同的,能够通过上⾯ 3 种⽅式获取 session_id;

登陆某个 obproxy 节点:

⽬标:

确认 obproxy 上

show processlist

表 information_schema.processlist

表 oceanbase.__all_virtual_processlist

获取的 ID 是否雷同?

执⾏语句:

show processlist ;
select * from information_schema.processlist ;
select id,user,host,db,command,time,state,info from oceanbase.__all_virtual_processlist ;

后果:

information_schema.processlist 和 oceanbase.__all_virtual_processlist 中的 ID ⼀致;

show processlist 中的记录和上⾯ 2 表的 ID 不⼀致,执⾏ kill 语句的时候,采⽤的是 show processlist 中的 ID。

通过 observer 和通过 obproxy 登陆看到的 oceanbase.__all_virtual_processlist 的数据是⼀致的;

登陆集群内不同 observer 的节点:

⽬标:

确认⽤户登陆⼀个 observer 是否能看到登陆其余 observer 的 session 信息?

通过不同 observer 登陆查看 session 信息(super 权限⽤户登陆):

后果:

在⼀个 observer 上能够看到其余 observer 的登陆信息;

登陆不同的 obproxy(他们连贯雷同的 OB):

⽬标:

确认⽤户登陆⼀个 obproxy 是否能看到登陆其余 obproxy 的 session 信息?

执⾏语句:

show processlist ;

通过不同 obproxy 登陆查看 session 信息:

后果:

在⼀个 obproxy 上通过 show processlist 语句不能看到其余 obproxy 的 session 信息;

测试总结:

1. 视图 information_schema.processlist 的数据来源于 表 oceanbase.__all_virtual_processlist;

命令 “show create table information_schema.processlist \G” 能够确认。

2. 表 oceanbase.__all_virtual_processlist 中记录的是所有到 OB 的连贯信息;

客户可能直连 observer,也可能是通过 obproxy 连贯 OB,所有连贯信息都会记录到表中;

3.show processlist 查看的是客户端连贯到软件的信息,所以当通过 obproxy 连贯 OB 时,show processlist 展现的是连贯到 obproxy 的信息,⽽不是连贯到 OB 的信息;

当直连 obsever 时,show processlist 展现的是连贯 OB 的信息;

4.obproxy 相当于 observer 的客户端,所以连贯不同的 obproxy,执⾏ show processlist 看到的连贯信息是不同的,它们是互相独⽴的;

释疑:

问题 1:

kill 中 session_id 的起源?

答案 1:

OB 中的 kill 命令是为了⼲掉⼀个 session 或者⼲掉这个 session 对应的 SQL 语句。

为了这个⽬的,能够⼲掉前侧连贯(指来源于客户端的连贯),或者⼲掉后侧连贯(连贯到后侧的连贯)。

通过 show processlist 查看前侧连贯,即查看客户端到软件 (例如: obproxy) 的连贯 ID;

也能够直连 observer,通过 oceanbase.__all_virtual_processlist 查看后侧连贯。

在执⾏ kill 命令时,能够通过任意⽅式连贯 OB,并通过 show processlist 获取连贯 ID;

也能够通过直连后侧的 observer,通过 oceanbase.__all_virtual_processlist 表获取连贯 ID;

问题 2:

是否能够⼀次性⼲掉⼀个租户的所有连贯;

答案 2:

因为前侧连贯通过 show processlist 只能查看以后客户端到软件的连贯信息,查不到其余前侧的连贯信息。例如:客户通过多个 obproxy 连贯 OB,如果咱们连贯其中⼀个 obproxy 执⾏ show processlist 获取的连贯是不全的。

咱们能够直连 observer,并执⾏以下 SQL,失去⼲掉租户 tenant_ys 的所有连贯的命令:

select concat('kill',id,';') from oceanbase.__all_virtual_processlist where tenant='tenant_ys' ;

正文完
 0