对于DBA而言，确保数据库的高可用性、容灾等能力是其日常工作中需要持续思考和关注的重要事项。一方面，可以利用数据库自身所具备的功能来实现这些目标；若数据库本身不提供相应功能，DBA则需寻找其他工具来增强数据库的高可用性和容灾能力。OceanBase作为一款分布式数据库产品，天生就具备了高可用的特性；而在容灾方面，OceanBase也提供了主备租户的功能，通过物理日志的同步，确保两个租户之间的数据保持一致。在较早的版本，假如出现主备切换的情况，需要用户修改连接串去连接新的主租户，这会影响很多业务场景的体验。

因此，如何做到即使发生了主备切换，对业务也是透明无感知的，就成了一个迫切需求。而在最新的版本上，OceanBase 推出了 Service_name (服务名) 的功能，通过服务名连接 OceanBase 集群的业务租户，服务名会自动识别当前哪个租户是主，哪个是备，从而将请求自动路由到主租户上。具体原理如下。

原理介绍

OceanBase 数据库中主备租户路由的基本框架如下图。用户通过特定的连接串登录 OBProxy，OBProxy 识别主备租户登录，通过向 OCP 获取相关的租户信息，完成自动路由到主租户，并发往对应的 OBServer 节点。OBServer 节点将校验对应的租户信息，校验通过后 OBProxy 进行建连，完成整个登录流程。

注意事项：

主备租户路由功能需 OCP、OBProxy、OceanBase 数据库三者配合使用，缺一不可。使用主备租户路由功能时，要求 OCP 需为 V4.3.1 或之后版本，OBProxy 需为 V4.3.1 或之后版本，OceanBase 数据库需为 V4.2.4 或之后的系列版本。

创建主备租户

那么在介绍完原理之后，具体如何使用 service_name 来实现业务的透明无感知切换呢？下面就简单创建一个环境来做个演示，帮助大家有个更深层次的理解。

这里首先需要创建一个主备租户关系，可以在不同的集群，也可以在同一个集群，关于主备租户的搭建，具体可以参考官网文档：物理备库容灾。本次实验是分别创建两个单副本的 OceanBase 集群，然后分别再创建一个主租户和备租户，具体信息如下：

角色	集群名	IP地址	租户名
集群A	obcluster	xx.xx9.12	obtest
集群B	obcluster_bak	xx.xx204.3	obtest
OBProxy	hongbo_zx	xx.xx9.12、xx.xx204.3	--

首先打开OCP，在集群A上创建空的主租户，租户模式为MySQL模式，租户名为obtest，这里服务名可选，我们先空着，后续再添加服务名。

接着在集群B上创建备租户，创建备租户时，选择要同步的主集群和主租户，然后再填写租户名称为obtest，这里也可以选择不同的租户名。同样服务名这里选择后面再添加，因为主租户是空租户，因此不需要再通过备份恢复的方式来创建备租户。

创建完成之后，可以在OCP上检查下主备租户的情况，可以看到在集群B上，租户obtest为备租户。

主备租户同步测试

接着我们尝试测试下主备租户的同步情况，这里在主租户的test库下创建一张表，然后写入一条数据，看下在备租户上能否同步过去。

连接备租户，然后登录到test库下，可以看到创建的oceanbase表和数据都同步过来，说明主备租户同步是正常的。

创建OBProxy

接着，为集群A和集群B创建OBProxy，这里需要创建的OBProxy可以同时连接到集群A和集群B，因此启动方式需要为ConfigUrl模式，并选择可连接的OceanBase集群，将obcluster和obcluster_bak选中。然后填写其他OBProxy集群名、root@proxysys密码等信息。

添加服务名

OBProxy创建完成之后，接着就给租户添加服务名，在OCP上进到主租户中，在概览页面找到添加服务名进行添加。

这里添加服务名为 service_obtest，并且选择同步变更主备租户服务名，这样，在备租户上，也有了相同的服务名。

从OCP上可以看到，备租户上已经有了这个服务名。

通过服务名测试连接

登录每个集群的sys租户查询系统表，可以看到service_name和业务租户已经绑定

SELECT t.tenant_id, t.tenant_name
FROM oceanbase.CDB_OB_SERVICES AS s JOIN DBA_OB_TENANTS AS t
ON s.tenant_id = t.tenant_id WHERE s.service_name = "service_obtest";

接着，使用服务名进行数据库连接，这里的连接规则是 <用户名>@SERVICE:SERVICE_NAME， 因此根据实际情况，连接租户的用户信息部分就是 root@service:service_obtest。从下面图中可以看出，通过这个服务名连接业务租户之后，默认是连接到了集群A上的obtest租户，因为目前obtest租户的主在集群A上。

主备切换

主备切换有两种方式，一种是failover，一种是switchover。switchover一般是无损切换，即主备租户都正常情况下，切换主备角色；failover一般是当主租户出现故障，无法快速恢复数据库，需要切换到备租户上先恢复业务服务。这种情况下，是有损的，可能会丢失一部分业务数据。

日常切换

在这里两种场景都做一个演示，首先进行switchover。在OCP上，进入到主租户的概览页面，右上角"..."中选择日常切换

然后会提示具体切换信息，确认无误之后，点击开始切换即可

在任务中心会生成切换的任务，可以看到10秒左右就完成了切换，这里没有持续做压测，实际对业务的影响肯定是远小于这个时间的。

再次在OCP上检查租户状态，可以看到集群A的obtest租户，已经变成了备租户

再次通过命令行进行连接，可以看到，此时连接obtest租户，已经是在集群B上，说明切换是成功的，连接也没有问题。

故障切换

经过日常切换之后，obtest租户的主目前在集群B上，此时模拟集群故障，直接使用 kill -9 将集群B的进程 kill 掉，此时主租户将无法提供服务，需要将备租户切换为主，然后提供业务服务。

在集群A的 obtest 租户下，通过在右上角"..."选择容灾切换，会强制将备租户变更为主

此时会弹出提示框，需要输入新主租户服务名，因为要保证业务不修改连接串，所以这里服务名需保持一致，然后点容灾切换

切换会生成一个任务，查看任务可以看到，7秒左右就将备租户拉起成功

此时再用同样的服务名连接租户，可以看到，连接的集群已经自动切换到集群A，说明切换已经完成，业务可以正常访问

这里需要注意一点，原主租户因为故障无法访问，当集群和租户恢复之后，此时该租户的服务名和当前新主租户的服务名是一样的，因此最好是把这个服务名删除或者修改个别的服务名，虽然OCP会做一层保护，防止通过同样的服务名连接到这个租户，但是最好还是人为做一些保护，防止出现业务同时连两个租户，出现脑裂情况。等重新配置好主备关系之后，再将服务名修改回来即可。

OBProxy 路由

最后，再摘抄一部分官网上对于 Service Name 路由策略的介绍，让大家对整个功能有个更深入的认识：

OBProxy 支持配置 Service Name 登录后，支持主租户的自动路由能力。具体如下：

• 路由重试：当后端发生 Switchover/Failover 时，OBProxy 根据协商的错误码，主动重试可用租户列表（支持跨集群重试）。切换到主租户重试时将不会返回错误，从而实现业务无感知的路由切换。

需要注意的是，在以下类型的 SQL 请求中，OBProxy 不支持切换租户/重试请求，会返回 OceanBase 数据库的错误码：

• • 事务中路由：OBProxy 不会切换租户，依然将请求发往事务开启的租户。
  • 临时表路由：OBProxy 会发往上一个请求的节点。
  • 依赖上一条 SQL 的执行结果：如 found_rows()、row_count() 等函数，需要发往上一个请求的节点。
  • LOAD FILE 导数场景：不支持切换租户。
  • CURSOR/PIECES 场景：客户端使用 CURSOR/PIECES 流式获取/上传数据时，所有请求会强制路由到统一节点。
• 自动找主：发生路由重试时，表示缓存的主租户信息错误，OBProxy 将根据租户列表，主动获取对应 OBServer 节点的租户角色，找到主租户并更新缓存信息。
• 定时刷新：OBProxy 会间隔一段时间（由 config_server_refresh_interval 控制，默认 60s），更新 Service Name 相关路由信息，保证缓存信息不会落后太久。
• 高可用：当用户使用 Service Name 登录后，OBProxy 会定时将缓存信息写入磁盘，在 OCP 不可用时仍然提供自动路由能力。

官方关于Service Name的介绍可参考：主备租户自动路由