postgres slony-i 主节点表运行几天后无法写入
我设置 slony 将 3 个表从一台 opensuse pc（主节点）复制到另一台 opensuse pc（从节点）。一开始效果很好。运行几天后，突然出现错误信息 -
ERROR: Slony-I: Table euprofiles is内容复制且无法在订阅者节点上修改 - role=0
euprofiles is one of the table is being复制的slony。
我知道如果您尝试写入从节点的表，可能会出现此消息。但这里我只写入主节点。
有人看到类似的问题吗？
I set up slony to replicate 3 tables from one opensuse pc (master node) to another opensuse pc (slave node). It works well at first. After running for few days, it suddenly come out the error message of -
ERROR: Slony-I: Table euprofiles is replicated and cannot be modified on a subscriber node - role=0
euprofiles is one of the tables being replicated by slony.
I know that this message may occur if you are trying to write to the table of slave node. But here I am writing to master node only.
Does anyone see similar problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从来没有发生过这种情况。您确定正在连接到您认为正在连接的数据库吗？ Slony 可能有点难以设置等，但它不仅仅是随机地决定主设备现在是从设备。
如果你 psql 进入两个数据库并对每个数据库执行 \d euprofiles 他们会说什么？源表末尾应该有类似这样的内容：
触发器：
_slony_www_logtrigger_228 在对每行用户执行插入、删除或更新后执行过程 _slony_www.logtrigger('_slony_www', '228', 'kvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv')
并且目标表应该具有如下内容：
触发器：
_slony_www_denyaccess_228 在插入、删除或更新用户的每行执行过程之前 _slony_www.denyaccess('_slony_www')
如果它们看起来都像最后一个触发器，则存在一些问题。但我敢打赌你只是连接到了错误的服务器。我们希望事情就是这么简单。
Never had this happen. Are you certain you're connecting to the db you think you're connecting to? Slony may be a bit difficult to setup and such, but it doesn't just randomly decide a master is now a slave.
If you psql into the two databasesand do \d euprofiles on each what do they say? The source table should have something like this at the end:
Triggers:
_slony_www_logtrigger_228 AFTER INSERT OR DELETE OR UPDATE ON users FOR EACH ROW EXECUTE PROCEDURE _slony_www.logtrigger('_slony_www', '228', 'kvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv')
and the destination table should have something like this:
Triggers:
_slony_www_denyaccess_228 BEFORE INSERT OR DELETE OR UPDATE ON users FOR EACH ROW EXECUTE PROCEDURE _slony_www.denyaccess('_slony_www')
If they both look like this last trigger there's some problem. But I'm betting you're just connecting to the wrong server. Let's hope it's that simple.