PostgreSQL流式复制

 

我试图在一台机器上设置两台PostgreSQL服务器并执行流式复制。 我已经成功了一次，但是当我试过后再次完全一样的步骤它不工作..这些步骤如下：我有$ PGDATA =家庭/ PostgreSQL的/ 9.1 /数据和$ STANDBY =家庭/ PostgreSQL的/ 9.1 / DATA2

  • 设置两个节点：

    • initdb -D $PGDATA

    initdb -D $STANDBY

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

  • 在pg_hba.conf的主节点中添加允许待机连接的部分：

    • host replication repuser 127.0.0.1/0 md5

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

    • max_wal_senders = 1

    archive_mode = on

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

    wal_level = archive

    wal_keep_segments = 32

  • 启动主节点并执行基本备份：

    • 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文件都被归档

  • 在备用（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"'

  • 启动主节点，然后启动备用节点 - 复制应该启动，待机应该赶上主节点。 这正是第一次发生的事情。 现在，当我启动备用服务器时，出现： “地址已被使用”错误。 当然，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在哪里改变了一段时间，但半小时它不再。

    我确信有一件事我必须第一次完成，而不是写下来或什么，但是我完全不知道它是什么。 我将不胜感激任何帮助。

    我仔细检查了上面发布的步骤，发现了您发布的确切错误，但我能够解决问题。

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

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

  • 在rsync与主服务器进行rsync之前，删除备用服务器中的所有文件和文件夹。
  • 在master的postgresql.conf中，将wal_level设置为hot_standby而不是归档，并将hot_standby设置为on。

    • 您的备用数据库正在不断恢复，这正是流式复制在PostgreSQL中的工作原理。 您是否能够登录待机并运行查询？ 如果是这样，恭喜，它正在工作。 如果不是，请发布相反的结果。

    链接地址: http://www.djcxy.com/p/77381.html

    上一篇: PostgreSQL Streaming Replication

    下一篇: Postgresql replication in rails with data