問題タブ [repmgr]

セットアップした PostgreSQL 9.4 クラスターのフェイルオーバーをテストしているときに、このエラーに出くわしました。ここでは、スレーブを新しいマスターに昇格させようとしています:

pg_logical/snapshotsdir は実際にはマスターノードに存在し、空です。

UPDpg_logical/snapshots :空のディレクトリを手動で作成したところpg_logical/mappings、サーバーは文句なしに起動しました。repmgr standby clone同期中にこのディレクトリを省略しているようです。しかし、このディレクトリの目的が知りたいだけなので、疑問は残ります。セットアップに何かが欠けている可能性があります。単にグーグルで検索しても意味のある結果は得られませんでした。

既存の Postgresql 9.3 2 ノード ストリーミング レプリケーション クラスタに repmgr を追加する準備をしています。

以前は、主なビジネスに影響を与える深刻な問題がありました。問題は、マスターとスレーブ間の遅延でした。次のように構成を調整することで解決しました。

マスター postgresql 構成:

スレーブの recovery.conf:

slave1 は master から NFS 経由で /walshare をマウントします。

同期コミットを有効にすることで、マスターとスレーブ間の遅延の問題を最終的に解決しました。

いいえ、管理タスクとフェイルオーバーを容易にするために、repmgr によって管理されるように現在のクラスターを再構成したいと考えています。

新しい VM (PG-9.4 を使用) を作成し、データベースを古いクラスターから新しいクラスターに移行する予定です。

pg_xlog のディスク容量の問題を回避するために、pg_xlog ディレクトリを PGDATA 論理ボリュームと同じボリューム グループの別の論理ボリュームに配置することにしました。

私の質問は次のとおりです。

1. そのrepmgrは同期コミットをネイティブにアクティブにしますか、それともマスターのpostgresql.confに手動で追加する必要がありますか?
2. 同期コミットをオンにすると、スレーブが応答しない場合にマスターが失敗します。repmgr はどのように状況を管理しますか?
3. repmgr が新しいスレーブ (クローン マスター) を作成するとき、/var/lib/pgsql/9.4/data/pg_xlog を削除して、新しいスレーブを再作成しますか?
4. pgsqllv と pgxloglv を同じボリューム グループに配置しても、I/O パフォーマンスに影響はありませんか? pg_xlog には専用ディスクを使用する必要がありますか?
5. repmgr の公式ドキュメント、wal_keep_segments = 5000 に従い、pg_xlog で 80 GB が必要です。80 GB は固定です。または、pg_xlog のディスク領域の増加を管理するために、100 GB 以上の論理ボリュームを作成する必要がありますか?

あなたの助けに感謝します、

repmgr では、マスター サーバーを登録しましたが、スタンバイ サーバーでは、マスター バックアップをスタンバイ データ ディレクトリに正常に複製しました。しかし、スタンバイサーバーの起動中にクローンを作成した後、次のエラーが発生しました。

この問題で助けてください。

レプリケーションに repmgr を使用しています。マスター ノードを repmgr に正常に登録しました。マスターノードのクローン作成に成功し、スタンバイサーバーを開始しました。しかし、問題は、repmgr にスタンバイ ノードを登録できないことです。

バージョン repmgr 2.0beta1 (PostgreSQL 9.3.2) を使用しています。OS: Ubuntu 14.04 LTS

スタンバイ ノードの登録中。

このエラーが発生しました。

スタンバイ Postgres LOG: (log_connections=on、log_disconnections=on の場合)

ログに「クライアントからデータを受信できませんでした: ピアによって接続がリセットされました」というエラーが表示されました。

マスター Postgres LOG:(log_connections=on、log_disconnections=on を使用)

このログにはスタンバイ接続に関する詳細はないと思います。(よくわかりません bcoz わかりません)

マスター repmgr.conf:

スタンバイ repmgr.conf

マスター & スタンバイ postgres.conf

マスター & スタンバイ pg_hba.conf

スタンバイ ノードのクラスタの詳細:

マスター ノードのクラスタの詳細:

この問題で私を助けてください。

2 つのノード (Master と Satndby) のセットアップに成功しました。私のバージョンは repmgr 2.0 (PostgreSQL 9.3.6) です。

スタンバイ repmgr.conf

マスタースタンバイ repmgr.conf

スタンバイ ノード (Postgressql サービス) を停止すると、次の repmgrd ログ ファイルを取得しました。

スクリプトを実行していません...助けてください...

2 台のサーバーを使用して postgres レプリケーション構成を作成しようとしています。この手順は、Ubuntu 14.04 での RepMgr および PgBouncer を使用した PostgreSQL 9.4 レプリケーションに似ています 。レプリケーション構成として repmgr + pgbouncer を使用しています。2 つのホスト dhost1 と dhost2 があるとします。Repmgr メタデータ データベースはrepmgrdbで、ユーザーはrepmgr_userです。
dhost1 には pgbouncer と Repmgr の構成があり、マスターです。dbhost1 の Repmgr の構成を以下に示します。

dhost2 にも Repmgr の構成があり、スレーブ モードになっています。その構成は以下に記載されています

マスターに正常に登録でき、cluster show コマンドでマスターを確認できます。

スレーブ側ではpg_basebackup、コマンドでマスターを複製する方法を使用しています

上記のコマンドでは、以下のエラーが発生します。

また、とpostgresの間のユーザーにパスワードなしの ssh を設定しました。dhost1dhost2

pg_basebackupまた、私はコマンドから取ることができました

私はpostgresqlレプリケーションの初心者です。答えを教えてください。

Postgresql と Pgpool II のセットアップは初めてです。Pgpool と Repmgr を使用して Postgresql HA/負荷分散を構成しました。

リンクをたどってセットアップを行いました。

マスター ノードを停止すると、フェイルオーバーが正常に行われ、スレーブ ノードが新しいマスター ノードとして機能します。
フェイルオーバー後、障害が発生したノードを手動で復旧し、新しいマスター ノードと同期する必要があります。

回復プロセスを自動化したい。

pgpool ノードのpgpool.confファイルには、パラメーターrecovery_1st_stage_commandが含まれています。ソースをオンラインで検索したところ、Pgpool ノードの構成ファイル pgpool.conf にパラメーター 「recovery_1st_stage_command」を設定する必要があることがわかりました。

パラメータrecovery_1st_stage_command = 'basebackup.sh'を設定しました。スクリプト'basebackup.sh'ファイルを両方の Postgresql ノードのデータ ディレクトリ'/var/lib/pgsql/9.4/data' の下に配置しました。

また、ディレクトリ「/var/lib/pgsql/9.4/data」の下の両方のデータベースノードにスクリプト「pgpool_remote_start」を配置しました。

また、両方のデータベース ノードで pgpool 拡張機能 pgpool_recovery と pgpool_adm を作成しました。

マスター ノードが停止すると、フェイルオーバーが発生しますが、復旧スクリプト「basebackup.sh」は実行されません。
pgpool ログを確認し、デバッグ レベルも有効にしました。スクリプトが実行されたかどうかはまだわかりません。

故障したノードの自動オンライン復旧を手伝ってください。私が使用したスクリプトを見つけてください。

basebackup.sh

pgpool_remote_start スクリプト。

ありがとう。

クラウド環境で Postgresql クラスターを構築したい (はい、それが悪い考えであることはわかっていますが、それは問題ではありません)。参考までに、Docker化されたPostgresqlを使用しています（https://github.com/paunin/postgres-docker-clusterを参照）が、それは問題でも問題でもありません。

そのため、ストリーミング レプリケーションを使用して 2 つの Postgresql 9.5 をインストールしました。各ホストに repmgr 3.2.1 がインストールされ、正しく構成されています。

次のケースには問題があります。

1. マスターを止め、
2. スレーブのフェールオーバーを待ちます -> OK,
3. 古いマスターを再起動します -> Ko で示されたクラスターに 2 つのマスターがありrepmgr cluster show、古いマスターを強制的にスレーブにする解決策が見つかりません。

私が見つけた唯一の醜い解決策は、古いマスターのすべてのデータを削除して再起動することです。これを行うと、予想どおりスレーブになりました（ただし、完全な再同期が必要です...）。

古いマスターを強制的にスレーブにすることはできないようですのでご注意ください。repmgr standby registerそれが言うように動作しません：

どんな助けでも大歓迎です。