【问题标题】:AlloyDB read pool data appears to be staleAlloyDB 读取池数据似乎已过时
【发布时间】:2022-10-13 03:36:56
【问题描述】:

我们有一个设置了读取池的 AlloyDB 实例。在我们的应用程序中,我们将数据库查询路由到主节点或读取池,具体取决于操作本身是否为 SELECT。这一直运作良好;但是,我们偶尔会遇到似乎是更改未复制到读取池的结果的错误。具体来说:

  • 我们使用到主节点的连接插入一条记录,并获取插入记录的主键。
  • 我们尝试使用读取池使用主键获取插入的记录。
  • 后一个查询返回 0 行。
  • 我们可以在事后检查数据库并查看记录确实存在。

我的理解是,副本会等到处理完任何相关的 WAL 日志后再处理查询,以确保它们的状态始终与主节点同步。是否存在读取池状态可能过时或与主节点不同步的情况?我们想了解什么可以解释我们所看到的行为以及我们可以做些什么来补救它。

【问题讨论】:

    标签: postgresql google-alloydb


    【解决方案1】:

    AlloyDB 读取池的实现(当前)与 Postgres 只读副本相同,因此根据工作负载存在滞后(例如,具有 2 个 vCPU 只读副本的 64 vCPU 主数据库可能永远赶不上)。主副本和副本将与它所追赶的日志序列号保持一致,但那里有一个滞后。延迟多少取决于工作量和机器差异。我们也在对开箱即用的复制延迟进行一些改进,因此它不会依赖于主节点的负载。它正在积极进行中,但我不确定什么时候能完全实现。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2016-05-27
      • 2017-05-25
      • 2022-12-14
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多