☰

Oracle 19c 数据库会话在使用 Azure 负载均衡器时不稳定

tag-icon • tag-icon azure load-balancing oracle
Oracle 19c 数据库会话在使用 Azure 负载均衡器时不稳定

我们正在尝试在 Azure 中使用 Oracle 数据库实现 HA 设置，具体内容如下DBAKevlar 的白皮书和Azure 中的 Oracle HA - 选项。我们的设置包括 2 个可用区域中的 Oracle Data Guard 对（主数据库和备用数据库）、第 3 个区域中的观察者以及 Azure 负载均衡器。Oracle 数据库对处于 FSFO 模式，因此如果主数据库发生故障，它将自动故障转移。Azure LB 监视 Oracle 侦听器以确定主数据库的位置。SQL Net 客户端连接到 Azure LB，然后连接到主数据库。

无论是使用 Oracle 19c 数据库和 Oracle 11g 客户端还是 Oracle 11g 数据库和 Oracle 19c 客户端，都可以完美运行，只要客户端需要，就可以建立连接并保持打开状态。

当客户端和数据库都是 19c 时，问题就开始了：仍然可以建立连接，初始查询也可以正常执行，但几分钟后数据库会话就会注销，即使客户端没有采取任何操作，与 Azure LB 的连接仍然保持正常。由于客户端不知道连接已注销，下一个查询会导致 sqlnet 等待答案，直到发生超时（15 分钟），之后会出错。

如果我们取出负载均衡器，19c 客户端与 19c 数据库的连接是稳定的，不会自发注销。这表明问题出在 Azure 负载均衡器上。

为了确保问题不在于 DataGuard/FSFO，我们仅使用一个独立数据库和一个 Azure 负载均衡器测试了相同的场景。没有 Data Guard，没有 FSFO，数据库会话仍然消失，而从客户端来看，与 LB 的客户端连接保持打开状态。

我们没有能力监控 Azure LB 本身上的会话，因此我们无法知道它是否主动关闭连接。

我无法确定注销发生的原因。如果一方是 11g 而另一方是 19C，为什么不发生注销？19c Oracle Net 驱动程序是否与 Azure 负载均衡器交互？Azure LB 是否检测到 Oracle 19c 组合并采取不同的行动？任何提示都将不胜感激。

答案1

Azure LB 监控 Oracle 侦听器以确定主数据库的位置。SQL Net 客户端连接到 Azure LB，然后连接到主数据库。

为什么不使用 Oracle 的透明网络基板（转移性神经性神经病）告诉客户两个都主数据库和备用数据库，并让他们处理弄清楚需要与哪一个进行通信的麻烦？这样，您就可以使用所有 Oracle“内容”。

这是您在客户端机器上要使用的东西。

(DESCRIPTION =
  (ADDRESS_LIST =
    (FAILOVER=YES)
    (LOAD_BALANCE=NO)
    (ADDRESS = (PROTOCOL=TCP)(PORT=????)(HOST=Primary-Server))
    (ADDRESS = (PROTOCOL=TCP)(PORT=????)(HOST=Standby-Server))
  )
  (CONNECT_DATA =
    (SERVICE_NAME=Service-Name)
    (SERVER=DEDICATED)
    (FAILOVER_MODE = (TYPE=SELECT)(METHOD=BASIC)(RETRIES=20)(DELAY=3))
  )
)

两个服务器均显示出来，由于设置为“故障转移”，因此所有连接均与主服务器建立...除非主服务器死机，在这种情况下客户端将尝试备用服务器。如果您知道主服务器将停机一段时间，则可以撤消条目。

“技巧”是Service-Name，只有基本的随时查看数据库。（请确保不使此服务名称与任何一个数据库名称！）

答案2

是的，那将是一种替代方案，TAF 也是如此。但是，两者都需要使用 Oracle TNS，而并非所有客户端都具有该功能。所描述的解决方案是由外部顾问提出的，是一种包罗万象的解决方案。它还有一个额外的好处，即配置在一个地方（LB），而不是在每个客户端上。

如果您拥有 Oracle 企业版，则可以使用 Oracle 连接管理器。连接管理器是带有连接管理器服务的 Oracle 客户端安装，它充当数据库连接的代理。数据库在连接管理器（remote_listener 参数）上注册其服务，连接管理器是外部客户端的目标。无需复杂的 TNS 连接字符串。连接管理器包含在企业版中。

答案3

想知道您是否已成功解决问题？我们刚刚在 Azure 中部署了一个主动/被动集群，使用 LB 作为前端，并希望在投入生产时避免此类问题。

答案4

最终，我们始终没有找到解决问题的办法。最后，我们认为 Azure LB 解决方案不可行，因此放弃了这个想法。

在测试过程中，我们还发现 FSFO 虽然本身很可靠，但对于我们的需求来说太脆弱了。具体来说，当故障转移数据库本身在恢复前一个主数据库期间发生故障时，该数据库将丢失并发生中断。我们还偶然发现，多备用环境中的故障​​转移会使所有剩余的备用数据库失效，从而使新的主数据库成为唯一实例。这对我们的业务来说风险太大，我们也放弃了使用 FSFO 的想法。

我们当前的方向是将我们的集群从 Azure 中取出，并将其恢复为 RAC 数据库，无论是在云中的 Exadata 上还是在靠近 Azure DC 的 DC 中的自有硬件上。

相关内容