web-dev-qa-db-ja.com

スレーブを取得できません-レプリケーションサーバーが起動します

レプリケーションサーバーが起動しません。私はここの指示に従いました：
http://opensourcedbms.com/dbms/setup-replication-with-postgres-9-2-on-centos-6redhat-el6Fedora/

同様にPostgres Wikiを含む他のいくつかの場所も同じ情報を持っています。

これが起こることです：
/9.2/dataフォルダーの完全バックアップを実行して、それをレプリケーション/スレーブサーバーに移動し、解凍します。 PostgreSQLとpgAdminを起動して、すべてのデータに問題なくアクセスできます。

次に、スレーブサーバーのpg_hba.confおよびpostgresql.confを編集する手順に移動します。起動しようとすると、失敗します（赤のエラー[fail]。理由を示すログがどこにも見つかりません。

データフォルダーにpostmaster.pidがないことも確認しました。

また、ログファイルが見つかりません。構成でログファイルを「アクティブ化」する必要がありますか？

だから、もし誰かが私の漠然とした説明を暗闇で試してみたいと思ったら、私はどんな提案も聞きたいです。それが役立つ場合は、Pastebinにconfファイルを置くことができます。

postgresqlreplication
4
Detox

ホットスタンバイをセットアップする手順

まず、PostgresqlデータディレクトリとWAL（ログの書き込み）ディレクトリのマウントポイントを決定します。パフォーマンスのために、$PGDATAおよびpg_xlogディレクトリは別のボリュームにある必要があります。

以下の例では、次のように定義されています。

  • $ PGDATAは「マスター」クラスターで、/ pgdata/9.3/dataにあります（例：192.168.10.0）。
  • 「スレーブ」（別名「ホットスタンバイ」）は、（たとえば）192.168.10.1の/pgdata/9.3/dataにあります。
  • スレーブのWALステージング領域は/ pgdata/WAL_Archiveになります。これは、マスターの archive_command からWALセグメントが送信される場所です。理想的には、$ PGDATAとは別のボリュームにあります。

仮定：

  1. マスタークラスタは正常に稼働しています。
  2. スレーブクラスターはまだありません。
  3. すべての操作を「postgres」OSユーザー（rootではありません）として実行しています。
  4. 両方のサーバー間のSSHが機能している
  5. 少なくともPostgreSQL 9.2を使用している
  6. pg_hba.confおよびpostgresql.confは$ PGDATA /にあります。そうでない場合は、以下の手順を場所に合わせて変更してください。
  7. 別のサーバーにスレーブを設定しています。
  8. サーバーが同じネットワーク上にない場合（たとえば、異なるコロケーション）、転送する前に、マスターの "archive_command" rsync で "-z"フラグを使用して圧縮します。
  9. これらのコマンドはLinux用ですが、いくつかのコマンドの置換を使用すると、Windowsでも機能するはずです。

スレーブで、マスターのログファイルを保持するステージングディレクトリを作成します。

mkdir -p /pgdata/WAL_Archive
chown postgres:postgres /pgdata/WAL_Archive

マスターで$PGDATA/postgresql.confを編集します

wal_level = hot_standby
archive_mode = on
                    ## /pgdata/WAL_Archive is a staging directory on the slave
archive_command = 'rsync -W -az %p postgres@$SLAVE_IP_HERE:/pgdata/WAL_Archive/'
max_wal_senders = 5
wal_keep_segments = 5000   # If you have the room, to help the pg_basebackup
                           # not fail due to WAL segments being removed from master.
                           # For clusters will very little traffic, 100 is probably fine

マスターで、レプリケーションロールを作成します。これは pg_basebackup を介してスレーブにコピーされます。 「レプリケーション」ロールのパスワードを設定します

psql -U postgres -d postgres -c "CREATE USER replication WITH replication ENCRYPTED PASSWORD 'changeme' LOGIN"

マスター$ PGDATA/pg_hba.confを変更して、スレーブのIPに対してレプリケーションユーザーを有効にします。

# TYPE DATABASE USER ADDRESS METHOD
#hostssl    replication     replication     $SLAVE_IP_HERE/32       md5
Host    replication     replication     $SLAVE_IP_HERE/32       md5

マスタークラスターを再起動して、postgresql.confへの変更を取得します。これは、クラスターのスーパーユーザーとして実行されます。

例えば：

pg_ctl -D $PGDATA restart -m fast
## The master cluster MUST be restarted before the pg_basebackup command is executed.

スレーブで、$ HOMEからpg_basebackupコマンドを発行して、マスターからホットスタンバイのセットアップを開始します。

## --Host=IP_OF_MASTER  -> The master's IP
## --pgdata=$PGDATA     -> The slave's $PGDATA directory
## --xlog-method=stream -> Opens a second connection to the master to stream the WAL segments rather than pulling them all at the end
## --password will Prompt for the replication role's password
## Without compression, "stream" gets the changes via the same method as Streaming Replication

time pg_basebackup --pgdata=$PGDATA --Host=IP_OF_MASTER --port=5432 --username=replication --password --xlog-method=stream --format=plain --progress --verbose

## Alternate version with compression, note "--xlog --gzip --format=tar"
#time pg_basebackup --pgdata=$PGDATA --Host=IP_OF_MASTER --port=5432 --username=replication --password --xlog --gzip --format=tar --progress --verbose

スレーブで、pg_basebackupが正常に完了した後、$ PGDATA/postgresql.confを編集します

hot_standby = on #off               # "on" allows queries during recovery
max_standby_archive_delay = 15min   # max delay before canceling queries,
                                    # set to hours if backups will be taken from here
max_standby_streaming_delay = 15min # max delay before canceling queries
hot_standby_feedback = on #off

スレーブで$PGDATA/recovery.confを作成します。

standby_mode = on

## To promote the slave to a live database, issue "touch /tmp/promote_db"
## Warning: If multiple slaves share the same /tmp/ directory,
##          then the trigger file must be named uniquely, else multiple slaves
##          could attempt to be promoted in the presence of the trigger file.
trigger_file = '/tmp/promote_db_slave'

## Host can be the master's IP or hostname
primary_conninfo = 'Host=IP_OF_MASTER port=5432 user=replication password=CHANGEME'

## Log the standby WAL segments applied to a standby.log file
## TODO: Add the standby.log to a log rotator
## The paths must be explicitly defined, including the path to pg_archivecleanup
restore_command = 'cp /pgdata/WAL_Archive/%f "%p" 2>>/pgdata/9.3/data/pg_log/standby.log'

## XXX: If multiple slaves share the staging WAL directory,
##      do not use pg_archivecleanup as WAL segments could be removed
##      before being applied to other slaves.
archive_cleanup_command = '/usr/pgsql-9.3/bin/pg_archivecleanup /pgdata/WAL_Archive %r'

## On hot standby clusters, set to 'latest' to switch to the newest timeline in the archive
recovery_target_timeline = 'latest'

スレーブは今すぐ開始する準備ができているはずです。最適な方法でスレーブのクラスターを起動します。

pg_ctl -D $PGDATA start

以下は、テスト用に何度もスタンバイを再作成するときに実行するコマンドです。これらを/root/recreate_standby.shというスクリプトに追加します。 rootとして実行しますが、これは必要ありません。postgresとして実行する場合は、「Sudo su-postgres -c」コマンドを削除してください。

#!/bin/bash

## This script runs on the standby.
## Executed as root, else remove the "Sudo - postgres -c" commands.
## Assumes you have a valid recovery.conf saved at
## $PGDATA/../recovery.conf.bkp

export PGDATA=/path/to/data/dir     ## Must be set correctly
export PGPORT=5432
export MASTER=192.168.x.x            ## IP or Host entry for the master Postgresql server
export PGBIN=/usr/pgsql-9.3/bin

service postgresql-9.3 stop -m immediate

if [ $? != 0 ]; then
    service postgresql-9.3 start
    echo "Could not shut down PostgreSQL. Aborting."
    exit 1
fi

rm -rf $PGDATA

if [ $? != 0 ]; then
    echo "Could not remove the PostgreSQL $PGDATA dir. Aborting."
    exit 1
fi

## If the replication role is not set to "trust" in the master's
## pg_hba.conf file, the password will need to be passed into the command below,
## and "--no-password" will need to be removed or revised to be "--password"
su - postgres -c "$PGBIN/pg_basebackup --pgdata=$PGDATA --Host=$MASTER --port=$PGPORT --username=replication --no-password --xlog-method=stream --format=plain --progress --verbose"

su - postgres -c "cp -p $PGDATA/../recovery.conf.bkp $PGDATA/recovery.conf"

service postgresql-9.3 start

su - postgres -c "$PGBIN/pg_isready -U postgres -p $PGPORT -t2"

while [ $? != 0 ]; do
  echo "Sleep 1 second, check if slave is up yet. If not, sleep again."
  sleep 1;
  su - postgres -c "$PGBIN/pg_isready -U postgres -p $PGPORT -t2"
done

su - postgres -c "$PGBIN/psql -d postgres -U postgres -qXc 'select pg_is_in_recovery() as is_pg_in_recovery'"

exit 0

詳細については、現在のPostgresqlドキュメント：

17
bma