我们已经设置了一个带有读取池的allyDB示例。在我们的应用程序中，根据操作本身是不是SELECT，我们将数据库查询路由到主节点或读池。这一直运行良好；然而，我们偶尔会遇到一些错误，这些错误似乎是由于未将更改复制到读取池造成的。具体地说，就是：
- 我们使用到主节点的连接插入一条记录，并获得插入记录的主键。
- 我们尝试使用读取池使用主键来获取插入的记录。
- 后一个查询返回0行。
- 我们可以在事后检查数据库，看到记录确实存在。
我的理解是，副本服务器将等待任何相关的WAL日志处理完毕，然后再处理查询，以确保它们的状态始终与主节点同步。是否存在读池状态可能过时或与主节点不同步的情况？我们想了解什么可以解释我们所看到的行为，以及我们可以做些什么来补救它。
1条答案
按热度按时间eit6fx6z1#
AlloyDB读取池的实施(当前)与Postgres读取复制副本相同，因此会有延迟，具体取决于工作负载(例如，具有2个vCPU读取复制副本的64 vCPU主服务器可能永远赶不上)。主服务器和副本服务器的日志序列号将保持一致，但存在滞后。延迟有多大取决于工作负载和机器差异。我们正在对开箱即用的复制延迟进行一些改进，这样它就不会依赖于主服务器的负载。它正在积极地进行研究，但我不确定它具体什么时候能面世。