4

我正在尝试在一台机器上设置两个 PostgreSQL 服务器并执行流复制。我已经成功了一次，但是当我再次尝试按照完全相同的步骤时它不起作用..这些是步骤：我有 $PGDATA = home/postgresql/9.1/data 和 $STANDBY = home/postgresql/9.1 /数据2

  1. 设置两个节点：

initdb -D $PGDATA

initdb -D $STANDBY

  1. 在主节点中创建一个用于复制的用户。我在 pgAdmin 中这样做（它确实具有超级用户权限）

  2. 在 pg_hba.conf 的主节点中添加允许备用连接的部分：

host replication repuser 127.0.0.1/0 md5

  1. 在 postgresql.conf 设置的主节点中：

max_wal_senders = 1

archive_mode = on

archive_command = 'cp %p ~/postgresql/backup/archivedir/%f'

wal_level = archive

wal_keep_segments = 32

  1. 启动主节点并进行基本备份：

psql -d dellstore2 -c "SELECT pg_start_backup('backup for replication', true)"

rsync -av ${PGDATA}/ $STANDBY --exclude postmaster.pid

psql -d dellstore2 -c "select pg_stop_backup()"

pg_stop_backup 说一切都很好，所有的 WAL 文件都被归档了

  1. 在备用（data2）节点中，我使用以下命令创建 recovery.conf：

standby_mode = 'on'

primary_conninfo = 'host=127.0.0.1 port=5432 user=repuser password=haslo'

trigger_file = '/home/michau/postgresql/replication.trigger'

restore_command = 'cp /home/michau/postgresql/backup/archivedir/%f "%p"'

  1. 启动主节点，然后启动备用节点——复制应该开始，备用应该赶上主节点。这正是第一次发生的事情。现在，当我启动待机时，我得到：“地址已在使用中”错误。当然，standby 和 master 都具有在 postgresql.conf 中指定的相同端口（它们具有完全相同的 postgresql.conf 文件）。如果我将待机端口更改为 5433，那么我会得到：

LOG: database system was shut down in recovery at 2012-06-12 19:48:01 CEST

LOG: entering standby mode

cp: cannot stat /home/michau/postgresql/backup/archivedir/000000010000000000000007: No such file or directory

LOG: consistent recovery state reached at 0/7000070

LOG: record with zero length at 0/7000070

cp: cannot stat /home/michau/postgresql/backup/archivedir/000000010000000000000007: No such file or directory

LOG: streaming replication successfully connected to primary

LOG: redo starts at 0/7000070

它就挂在这里。运行 ps -ef | grep postgresql 产生：

michau 2491 1898 0 19:46 pts/0 00:00:00 postgres -D /home/michau/postgresql/9.1/data

michau 2493 2491 0 19:46 ? 00:00:01 postgres: writer process

michau 2494 2491 0 19:46 ? 00:00:00 postgres: wal writer process

michau 2495 2491 0 19:46 ? 00:00:00 postgres: autovacuum launcher process

michau 2496 2491 0 19:46 ? 00:00:00 postgres: archiver process last was 000000010000000000000008

michau 2497 2491 0 19:46 ? 00:00:00 postgres: stats collector process

michau 2571 2214 0 19:49 pts/1 00:00:00 postgres -D /home/michau/postgresql/9.1/data2

michau 2572 2571 0 19:49 ? 00:00:01 postgres: startup process recovering 000000010000000000000009

michau 2575 2571 0 19:49 ? 00:00:01 postgres: writer process

michau 2578 2571 0 19:49 ? 00:00:02 postgres: wal receiver process streaming 0/99782DC

michau 2579 2491 0 19:49 ? 00:00:00 postgres: wal sender process repuser 127.0.0.1(42142) streaming 0/99782DC

michau 2586 2491 0 19:51 ? 00:00:00 postgres: michau postgres ::1(49941) idle

michau 2587 2491 0 19:51 ? 00:00:01 postgres: michau dellstore2 ::1(49942) idle

恢复中的 0000000010000009 会发生一段时间的变化，但半小时后就不再变化了。

我确定有些事情我必须是第一次做的，但没有写下来或其他什么，但我完全不知道它是什么。我将不胜感激任何帮助。

4

2 回答 2

3

我完成了您在上面发布的步骤，我得到了您发布的确切错误，但我能够解决问题。

我试图将您的步骤与本网站 http://www.debian-administration.org/article/How_to_setup_Postgresql_9.1_Streaming_Replication_Debian_Squeeze中发布的步骤合并

除了您发布的步骤之外，我还从我提供的站点中添加了 2 个步骤。2个步骤如下：

  • 在从主服务器 rsync 之前删除备用服务器中的所有文件和文件夹。
  • 在 master 的 postgresql.conf 中，将 wal_level 设置为 hot_standby 而不是 archive 并将 hot_standby 设置为 on。
于 2012-10-29T08:14:30.457 回答
0

您的备用服务器在不断恢复，这正是 PostgreSQL 中流式复制的工作方式。您是否能够登录到备用服务器并运行查询？如果是这样，恭喜，它正在工作。如果没有，请发布发生的情况。

于 2012-09-08T06:26:02.443 回答