问题现象

问题分析

先来说说服务器模式。这里的服务器模式主要是对于服务器的角色、职责和工作状态的一种描述。

DM数据库有以下三种模式：

• Normal模式
  • 通常是独立的、常规的服务器。这种模式下提供正常的数据库服务，操作没有限制，可以正常生成本地归档。
• Primary模式
  • 提供正常的数据库服务，处理主要的业务逻辑和数据操作。操作有极少限制。
• Standby模式
  • 作为冗余的备份服务器，可以执行数据库备份、查询等只读数据库操作。

通常在应用服务客户端或者中间件，会有配置项，它定义了应用程序在连接数据库时的优先级策略，特别是在涉及到数据库集群架构的情况下。

LOGIN_MODE用于应用客户端指定优先登录的服务器模式，当应用客户端连接到数据库服务器时，服务端会验证自身模式与应用服务需要的模式是否匹配，若不对应，会返回错误信息。LOGIN_MODE 有以下几个选项：

• 0：优先连接 PRIMARY 模式的库，NORMAL 模式次之，最后选择 STANDBY 模式；
• 1：只连接主库；
• 2：只连接备库；
• 3：优先连接 STANDBY 模式的库，PRIMARY 模式次之，最后选择 NORMAL 模式；
• 4：优先连接 NORMAL 模式的库，PRIMARY 模式次之， 最后选择 STANDBY 模式。

回到问题开始，数据库服务器部署采用单机架构，Normal模式，怀疑是客户端配置了不合适的LOGIN_MODE导致这个问题。

查看dm_svc.conf文件，如下：

LOGIN_MODE=1配置表示应用只连接Primary模式的库，显然这里应用客户端和数据库服务端是不对应的。

将LOGIN_MODE=(1) 去掉，问题就迎刃而解了。

下面来看看LOGIN_MODE各个配置项适用场景。

• 0模式：适合在大多数情况下需要读写访问主库的应用程序，但在主库不可用时仍然能够自动切换到备库或普通库继续工作。
• 1模式：适合保证业务读写都在主库，例如对于某些需要强一致性的事务性操作。
• 2 模式：适合只需要读操作的场景，特别是在读多写少的应用中，这样可以减轻主库的负担。
• 3 模式：适合优先使用备库进行读操作，但需要在备库不可用时自动切换到主库的情况。
• 4 模式：适合需要首先利用普通模式的库进行操作，但在普通模式不可用时也可以接受主库或备库的连接。

通过这种配置，系统能够根据具体需求灵活选择连接的数据库模式，确保系统的高可用性和资源的最优利用。