主页 / dba / 问题 / 156719
Accepted
Chris Hinshaw
Asked: 2016-11-30 15:15:01 +0800 CST

Slony-I 复制停止工作

  • 772

我继承了一个运行 postgres 8.4 和 slony 1.2.21 的 5 节点 postgres 集群。我们正在将应用程序迁移到所有新代码，并且不想对集群进行很少的维护。昨天我们决定从集群中移除两个未被使用的节点。我们为集群中的两个节点使用了 slonik 脚本DROP NODE。这似乎工作正常，我们今天关闭了节点。但是我今天早上注意到我们的收集写入的主数据库没有将更改复制到其余服务器。我已经尝试了我能想到的一切，但似乎没有任何效果。

当我运行查询以收集状态时，我发现自昨天以来事件没有得到确认。st_last_received 根本没有改变。

 st_origin | st_received | st_last_event |      st_last_event_ts      | st_last_received |    st_last_received_ts     | st_last_received_event_ts  | st_lag_num_events |              now              
-----------+-------------+---------------+----------------------------+------------------+----------------------------+----------------------------+-------------------+-------------------------------
        25 |          24 |      26196903 | 2016-11-29 17:39:06.859051 |         26187885 | 2016-11-29 12:51:45.396619 | 2016-11-28 11:11:48.909855 |              9018 | 2016-11-29 17:39:07.247598-05
        25 |          27 |      26196903 | 2016-11-29 17:39:06.859051 |         26187885 | 2016-11-28 11:11:49.203193 | 2016-11-28 11:11:48.909855 |              9018 | 2016-11-29 17:39:07.247598-05
        25 |          26 |      26196903 | 2016-11-29 17:39:06.859051 |         26187885 | 2016-11-28 11:11:50.253235 | 2016-11-28 11:11:48.909855 |              9018 | 2016-11-29 17:39:07.247598-05

我首先在所有节点上重新启动了 slony 守护进程，随后多次这样做。我已将调试设置为 4 级以进行调试日志记录，并梳理了它们而没有发现任何问题。

我查看了所有.sl_表，寻找任何可能告诉我为什么它不起作用的东西。

对于重要的复制集，我们的配置如下。

select * from _ads.sl_set;
 set_id | set_origin | set_locked |   set_comment   
--------+------------+------------+-----------------
      1 |         25 |            |  mgt tables


select * from _ads.sl_subscribe ;
 sub_set | sub_provider | sub_receiver | sub_forward | sub_active 
---------+--------------+--------------+-------------+------------
       1 |           25 |           26 | t           | t
       1 |           25 |           27 | t           | t
       2 |           25 |           27 | t           | t
       1 |           25 |           24 | t           | t


select * from _ads.sl_listen ;
 li_origin | li_provider | li_receiver 
-----------+-------------+-------------
        24 |          24 |          25
        26 |          26 |          25
        27 |          27 |          25
        27 |          25 |          26
        26 |          25 |          27
        27 |          25 |          24
        24 |          25 |          27
        24 |          25 |          26
        26 |          25 |          24
        26 |          24 |          25
        27 |          26 |          25
        26 |          27 |          25
        24 |          26 |          25
        27 |          24 |          25
        24 |          27 |          25
        25 |          25 |          24
        25 |          25 |          26
        25 |          25 |          27

将不胜感激任何建议帮助或关于在哪里查看的想法。我现在完全处于恐慌模式。

postgresql slony

1 个回答

  1. Best Answer

    好吧，这是一场噩梦，但我们想通了，但我们解决了问题。我们能够使用 slonik DROP NODE 命令删除服务器。有一段时间，slony 服务反复出现段错误。我们必须在所有从节点上删除节点，然后再次添加和订阅它们。这导致表被删除，然后它运行一个副本集来恢复表。它又开始工作了。由于这是一个破坏性的操作，我们非常犹豫要不要在这些上运行 DROP NODE。但是，复制服务器再次按预期运行。

    我非常期待永久关闭此服务。

    • 0

相关问题