Chris Hinshaw's questions

我继承了一个运行 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

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

我正在尝试在 postgres 8.4 机器上运行 vacuum 完整分析，其中 autovacuum 似乎无法跟上。数据库很大，负载很重。

问题始于 postgres 拒绝更新，因为它没有事务。我唯一的选择是让我们的业务脱机并进行手动吸尘。

问题是它需要很长时间，我一直在寻找一种可靠的方法来加速它。我不想在数据库处于未知状态时任意更改配置文件。

这是服务器的 postgres.conf 配置。

listen_addresses = '*'
port = 5476
max_connections = 1000

### logging
log_destination = 'syslog'

constraint_exclusion = partition

### work_mem for vacuuming
maintenance_work_mem = 128MB        # min 1MB
                                    # DEFAULT 16MB

# -----------------------------
# CHANGE THESE DEPENDING ON SYSTEM
# VALUES BASED ON 2G RAM
# -----------------------------

### RAM * 1/4
shared_buffers = 512MB              # min 128kB or max_connections*16kB
                                  # DEFAULT: 24MB
#### very import. all work happens here, needs to be as big as possible

temp_buffers = 64MB
#### session-local buffers used to access temporary tables on a per-session basis

### not more than RAM / connections
work_mem = 20MB                   # min 64kB
                                  # DEFAULT: 1MB
#### used for sorting in memory

### raise this if log complains or to reduce checkpoints
wal_buffers = 3MB                 # min 32kB
                                  # DEFAULT: 64kB
checkpoint_segments = 16          # in logfile segments, min 1, 16MB each
                                  # DEFAULT: 3
#### stores changes to shared buffer. higher value = fewer checkpoints/flushes

### RAM * 2/3
effective_cache_size = 1365MB
                                  # DEFAULT: 128MB
#### size of largest possible object

### multiplied defaults by 0.2
cpu_tuple_cost = 0.002                  # (same)
cpu_index_tuple_cost = 0.001            # (same)
cpu_operator_cost = 0.0005              # (same)
#### do this. based on older slower hardware.

### milliseconds vacuum will delay when its cost reaches threshold
vacuum_cost_delay = 20            # default = 0

# -----------------------------
# OPTIONAL DEBUG/LOGGING PARAMS
# -----------------------------

### uncomment the following 6 lines to enable query logging
#silent_mode = on
#log_min_duration_statement = 0
#log_duration = on
#log_statement = 'none'

任何有关我可以做些什么来尽快备份此服务器的想法都将不胜感激。

编辑

这是我们收到的确切错误消息，对此深表歉意。

ERROR:  database is not accepting commands to avoid wraparound data loss in database "live"