OB的用户名形如 user_name@tenant_name#cluster_name,如果想更彻底的兼容MySQL,就需要把@后面的部分想办法去掉。
研究了OBProxy的配置,发现两个参数: proxy_tenant_name 和 proxy_cluster,
配置好默认的租户名和集群名后,proxy_tenant_name有效,proxy_cluster似乎不起作用。
请问还有其他方式可以实现不用输入tenant和cluster呢?
OB的用户名形如 user_name@tenant_name#cluster_name,如果想更彻底的兼容MySQL,就需要把@后面的部分想办法去掉。
研究了OBProxy的配置,发现两个参数: proxy_tenant_name 和 proxy_cluster,
配置好默认的租户名和集群名后,proxy_tenant_name有效,proxy_cluster似乎不起作用。
请问还有其他方式可以实现不用输入tenant和cluster呢?
ob是租户间隔离的,obproxy是无状态的可以接入多套ob集群
proxy_tenant_name 用于设置云租户和 proxy_cluster这个参数是啥没有查询到
以rslist方式启动的obproxy可以不带集群名(当obproxy的参数 enable_full_username为False),普通租户名是必须带的
可以使用cluster_name.tenant_name.user_name 代替
OB 兼容性其中之一是兼容 MySQL,兼容 MySQL 只是 SQL 语法功能兼容,目的是为了方便 MySQL 数据库上业务数据能平滑迁移过来。 并不是为了做一个 不一样的 MySQL 数据库。所以,越往后,用 MySQL 的思维方式来要求 OB 会变得不合理。
OB 目前租户的用户名格式确实有点长,有 username@tenant#cluster
和 cluster:tenant:username
,对于程序用户名长一些问题不大,只是用户自己不习惯一点。 通过变化 tenant ,可以连接到集群中不同的租户。如果站在多个业务数据库实例角度去想,很容易理解这个好处。如果只是单纯的看一个数据库,觉得这么写太麻烦,也有一点道理。
OB 公有云里售卖租户实例时就支持简单的用户名和 IP 就可以连接到对应的租户上。用户使用简单,只是 OBCloud 在 链路上做了一些转换,自动将用户简单的用户名改为实际真实的用户(上面说的格式)。这个还是为了尽可能争取 MySQL 业务迁移到 OB 上。OB 线下版本没有刻意去做这个功能(以后做不做也不清楚),这并不是迁移的障碍。(看到另外一个帖子: 通过OCP安装obproxy为什么需要带#集群名称 - 社区问答- OceanBase社区-分布式数据库 里面提到设置 odp 参数,可以免去用户名里写集群名,但是租户名还是要有的。特别是多租户的时候,不写租户名有一定风险。)
OB 4.2.2(还是 4.2.4?) 后新增了一种服务名
的概念,大概用户名会变为 username@service_name
这种形式连接租户实例。当租户发生主备切换(dataguard
主备切换,不是三副本的主备副本切换),应用是不用修改连接字符串的。而对于传统的 MySQL 就么有这个功能。 传统 MySQL 主从切换后,除非应用连接的是 VIP(VIP 可以漂移或者转换后端路由),否则应用多半是要改连接字符串(改IP)。 MySQL MGR 倒不用让业务修改连接 IP 就可以实现后端 MySQL 主从切换。不过 MGR 做的只是 OB 主集群的三副本类似的事情,且功能稳定性、性能远不及 OB 的 Paxos。MGR 对 OB 或 TiDB 毫无优势,这点连接优势也就不值一提了。
也许将来会有问题问 MySQL 是否可以像 OB(MySQL)一样有某个用法
应该可以吧?