尝试无限期地保持一个事务的开放以保持一个咨询锁是一个坏主意吗?对于我们的用例来说,它的功能似乎足够好,但是在性能测试中,长事务已经引起了很多人的注意。
我们的应用程序在一个连接到数据库的集群中有几个后端,并且可以使用某种互斥来确保最多其中一个后端负责一些家务。为此,我选择使用事务级建议锁,因为我们不控制环境,也不能排除外部连接池。
每个后端都会定期尝试获取锁。当它成功地获得锁时,它将周期性地重新执行相同的语句,以确保仍然持有锁(并防止启动空闲事务)。该后端将运行内务管理逻辑,直到后端被关闭,或者重新获取锁时出现问题,大概是为了防止与db的连接中断。
SELECT pg_try_advisory_xact_lock($1) as locked;**编辑:事务只用于持有此锁。据我理解,这使它保持MVCC友好。
发布于 2023-03-10 20:40:39
我使用了一个专用表(调用ot锁或后端)来插入包含服务器名称和时间戳的行。
如果丢失或时间戳太旧(例如10分钟),每个后端都会创建一行。
如果成功,它会定期更新(比如每2分钟更新一次),以保持控制。如果它倒下了,另一个可以接管。
一旦完成,它就擦除了这一行。
在每一个动作周期之前,后端检查它是否仍然负责。
你必须决定合适的时间期限。
https://dba.stackexchange.com/questions/324622
复制相似问题