1展開アーキテクチャ
2ホスト構成
（ホストID20）
sed -ir "s/#*max_replication_slots.*/max_replication_slots= 10/" $PGDATA/postgresql.conf
sed -ir "s/#*max_wal_senders.*/max_wal_senders = 10/" $PGDATA/postgresql.conf
sed -ir "s/#*wal_level.*/wal_level = replica/" $PGDATA/postgresql.conf
sed -ir "s/#*archive_mode.*/archive_mode = on/" $PGDATA/postgresql.conf
sed -ir "s/#*archive_command.*/archive_command = 'test ! -f \${PGHOME}\/archive\/%f \&\& cp %p \${PGHOME}\/archive\/%f'/" $PGDATA/postgresql.conf
3アーカイブ回復
（ID21）
3.1基本バックアップ（マスタ動作）
注1：データベースがアーカイブを行うinitdbを使用した場合は、エラーを取得します
WALファイル、別のデータベースからです：LOGシステム
注2：なぜアーカイブを？
ストリームは、連続レプリケーションは、ファイルベースのアーカイブを使用していない場合は、バックアップコンピュータはWALセグメントを受信する前に、サーバーは、これらの古いWALセグメントを回復することができます。この問題が発生した場合は、バックアップ・マシンは、新しいベースバックアップの初期化からにする必要があります。古いWALセグメントが早すぎるバックアップコピーのスロットマシンとして再利用するかに配置されないことを確実にするために価値の高い、十分にwal_keep_segmentsを設定することにより、このような状況を回避することができます。バックアップマシンはWALアーカイブにアクセスすることができます設定する場合は、アーカイブが十分な時間を維持することができるため、バックアップ・マシンのバックアップマシンは常にホストコンピュータに追いつくためにアーカイブを使用することができ、これらのソリューションを必要としません。
ステップ1：設定のpg_hba.confのチャンネル
ステップ2：pg_basebackup -Fp -P -x -D ~/app/data/pg_root21 -l basebackup21
3.2の設定アーカイブ回復
cp $PGHOME/share/recovery.conf.sample ./recovery.conf
sed -ir "s/#*standby_mode.*/standby_mode= on/" $PGDATA/recovery.conf
sed -ir "s/#*restore_command.*/restore_command = 'cp \/home\/gaomingjie\/app\/pgsql20\/archive\/%f %p'/" $PGDATA/recovery.conf
準備マシンログ（最新ログのノンストップ）：
cp: cannot stat `/home/gaomingjie/app/pgsql20/archive/000000010000000000000004': No such file or directory
cp: cannot stat `/home/gaomingjie/app/pgsql20/archive/000000010000000000000004': No such file or directory
cp: cannot stat `/home/gaomingjie/app/pgsql20/archive/000000010000000000000004': No such file or directory
cp: cannot stat `/home/gaomingjie/app/pgsql20/archive/000000010000000000000004': No such file or directory
cp: cannot stat `/home/gaomingjie/app/pgsql20/archive/000000010000000000000004': No such file or directory
LOG: restored log file "000000010000000000000004" from archive
cp: cannot stat `/home/gaomingjie/app/pgsql20/archive/000000010000000000000005': No such file or directory
cp: cannot stat `/home/gaomingjie/app/pgsql20/archive/000000010000000000000005': No such file or directory
cp: cannot stat `/home/gaomingjie/app/pgsql20/archive/000000010000000000000005': No such file or directory
プロセスステータス：
/home/gaomingjie/app/pgsql21/bin/postgres
\_ postgres: startup process recovering 000000010000000000000005
\_ postgres: checkpointer process
\_ postgres: writer process
4非同期レプリケーションの流れ
（ID22）
デフォルト下流のレプリケーションでは、この場合には、非同期では、プライマリサーバ上のトランザクションが見えるとバックアップサーバーの変化との間に若干の遅れがあるとなっコミット。しかし、はるかに小さい方法でファイルベースのログシッピングよりも、この遅延は、前提バックアップサーバの容量は、通常は1秒未満の負荷遅れに追いつくために十分なされています。コピーフローでは、データ損失ウィンドウを減らすために無archive_timeoutを。そしてtcp_keepalives_countプライマリサーバへの貢献はすぐに切断された接続を気づいtcp_keepalives_intervalキープアライブソケットオプションをサポートするシステム、設定tcp_keepalives_idle、オン。
4.1基本バックアップ（マスタ動作）
ステップ1：設定のpg_hba.confのチャンネル
良いコピーのアクセス権限を設定し、それがWALストリームからのアクセスに必要な権限情報を抽出することは容易であるため、信頼されるユーザーのみが、WALストリームを読み取ることができるように、非常に重要です。バックアップサーバとしてのアカウントは、メインサーバにスーパーユーザーまたは複製権限の認証を持っている必要があります。私たちは、専用のユーザーアカウントを作成するためにコピーをお勧めしますレプリケーションとLOGIN権限を持っています。レプリケーションの権限は非常に高い特権を与えるが、それは、ユーザーがプライマリシステム上で任意のデータを変更することはできません。また、あなたはスーパーユーザ権限ができますが。
配置方法1（本例中不使用这种配置方法）:
pg_hba.conf:
host replication gaomingjie 127.0.0.1/32 trust
配置方法2(创建用户后使用密码校验)：
create role foo login replication password 'server@123';
pg_hba.conf:
host replication foo 127.0.0.1/32 md5
ステップ2：pg_basebackup -Fp -P -x -D ~/app/data/pg_root22 -l basebackup22
4.2フロー重複パラメータの設定
cp $PGHOME/share/recovery.conf.sample ./recovery.conf
sed -ir "s/#*standby_mode.*/standby_mode= on/" $PGDATA/recovery.conf
sed -ir "s/#*primary_conninfo.*/primary_conninfo= 'host=127.0.0.1 port=9420 user=foo password=server@123'/" $PGDATA/recovery.conf
ログ情報
LOG: database system was shut down in recovery at 2017-04-27 11:46:42 CST
LOG: entering standby mode
LOG: redo starts at 0/6000028
LOG: consistent recovery state reached at 0/7000000
LOG: started streaming WAL from primary at 0/7000000 on timeline 1
プロセスの状態
/home/gaomingjie/app/pgsql22/bin/postgres
\_ postgres: startup process recovering 000000010000000000000007
\_ postgres: checkpointer process
\_ postgres: writer process
\_ postgres: wal receiver process streaming 0/7000140
4.3フローは、レプリケーションの状態を監視
重要な健康指標の流れのコピーは、レコードのWAL番号を生成しますが、プライマリサーバ上でバックアップサーバに適用されていません。あなたはヒステリシスを計算するために、現在のプライマリサーバーの比較を介して受信した最後のWAL WAL位置とバックアップサーバを書くことができます。
彼らは、取得するために、マスターサーバーとスタンバイサーバー上のpg_current_xlog_locationのpg_last_xlog_receive_location上で別々に使用することができます。最後WALロケーションバックアップサーバーはまたpsコマンド表示の状態を使用した状態でプロセスWAL受信プロセスに表示されます。
あなたはできるpg_stat_replication WAL送信者のプロセスを取得するには、リストビューを。マスターサーバーと大きな負荷の下でドメインsent_location、間pg_current_xlog_location大きな差と上位sent_locationのpg_last_xlog_receive_locationとの違いは、ネットワーク・サーバを示している可能性があり、およびバックアップまたはスタンバイサーバ遅延は大きな負荷がかかっています。
postgres=# select * from pg_stat_replication;
-[ RECORD 1 ]----+-----------------------------
pid | 11715
usesysid | 16393
usename | foo
application_name | walreceiver
client_addr | 127.0.0.1
client_hostname |
client_port | 51930
backend_start | 2017-04-27 14:12:57.43909+08
backend_xmin |
state | streaming
sent_location | 0/8000610
write_location | 0/8000610
flush_location | 0/8000610
replay_location | 0/8000610
sync_priority | 0
sync_state | async
5ホットスタンバイ非同期転送バスの流れ（主カスケード）
（ID23）
5.1基本バックアップ（マスタ動作）
ステップ1：設定権限
create role foo login replication password 'server@123';
pg_hba.conf:
host replication foo 127.0.0.1/32 md5
ステップ2：pg_basebackup -Fp -P -x -D ~/app/data/pg_root23 -l basebackup23
第三段階：マスターノードは、転送バスフローを作成します
SELECT * FROM pg_create_physical_replication_slot('node_slot_23');
SELECT * FROM pg_replication_slots;
-[ RECORD 1 ]-------+-------------
slot_name | node_slot_23
plugin |
slot_type | physical
datoid |
database |
active | f
active_pid |
xmin |
catalog_xmin |
restart_lsn |
confirmed_flush_lsn |
パラメータをコピーストリームの設定5.2
sed -ir "s/#*hot_standby.*/hot_standby= on/" $PGDATA/postgresql.conf
cp $PGHOME/share/recovery.conf.sample ./recovery.conf
sed -ir "s/#*standby_mode.*/standby_mode= on/" $PGDATA/recovery.conf
sed -ir "s/#*primary_conninfo.*/primary_conninfo= 'host=127.0.0.1 port=9420 user=foo password=server@123'/" $PGDATA/recovery.conf
sed -ir "s/#*primary_slot_name.*/primary_slot_name= 'node_slot_23'/" $PGDATA/recovery.conf
ログ情報
LOG: entering standby mode
LOG: redo starts at 0/9000028
LOG: consistent recovery state reached at 0/A000060
LOG: invalid record length at 0/A000060: wanted 24, got 0
LOG: database system is ready to accept read only connections
LOG: started streaming WAL from primary at 0/A000000 on timeline 1
プロセスの状態
/home/gaomingjie/app/pgsql23/bin/postgres
\_ postgres: startup process recovering 00000001000000000000000A
\_ postgres: checkpointer process
\_ postgres: writer process
\_ postgres: stats collector process
\_ postgres: wal receiver process
溝をコピーマスターノードステータスの問い合わせの流れ
psql
psql (9.6.0)
Type "help" for help.
postgres=# \x
Expanded display is on.
postgres=# SELECT * FROM pg_replication_slots;
-[ RECORD 1 ]-------+-------------
slot_name | node_slot_23
plugin |
slot_type | physical
datoid |
database |
active | t
active_pid | 14799
xmin |
catalog_xmin |
restart_lsn | 0/B001148
confirmed_flush_lsn |
psql -U foo -W "dbname=postgres replication=database"
Password for user foo:
psql (9.6.0)
Type "help" for help.
postgres=> IDENTIFY_SYSTEM;
systemid | timeline | xlogpos | dbname
---------------------+----------+-----------+----------
6413518490021561706 | 1 | 0/B001148 | postgres
(1 row)
5.3溝ストリームレプリケーションの概念
コピースロットは、彼らはすべてのバックアップマシンWALセグメントを受信する前に、マスターが削除されていないことを確認するために自動化された方法を提供し、マスターが競合を削除しなくてもバックアップマシンオフならば、ラインの回復につながる可能性があります同様に開きます。
スロットをコピーする代わりに、wal_keep_segmentsを防止するためにも使用することができるように、古いWALセグメントを削除し、又は使用は、アーカイブに格納されたセグメントにarchive_command。しかしながら、これらの方法は、多くの場合、必要なWALセグメントよりももたらす予約、及び必要性を知られている唯一のスロット予約期間をコピーします。これらの方法のうちの1つの利点は、要件はpg_xlog内のスペースのための境界を提供しますが、現在はコピースロットを使用しないことです。
同様に、hot_standby vacuum_defer_cleanup_age保護と関連する行が除去され真空ではないが、後者の必要が既に高い値に設定されるようにしながら、バックアップ・マシンの間の保護を提供しない前者の缶は、オフにされる適切な保護を提供します。これらの欠点を克服するためにタンクをコピーします。
転送バスを照会し、操作する5.4
各コピースロットは名前が小文字、数字、およびアンダースコア文字を含めることができ、名前を持っています。既存の溝をコピーし、その状態はビューpg_replication_slotsで見ることができます。
pg_create_physical_replication_slot
pg_drop_replication_slot
pg_create_logical_replication_slot
pg_logical_slot_get_changes
pg_logical_slot_peek_changes
pg_logical_slot_get_binary_changes
pg_logical_slot_peek_binary_changes
pg_replication_origin_create
pg_replication_origin_drop
pg_replication_origin_oid
pg_replication_origin_session_setup
pg_replication_origin_session_reset
pg_replication_origin_session_is_setup
pg_replication_origin_session_progress
pg_replication_origin_xact_setup
pg_replication_origin_xact_reset
pg_replication_origin_advance
pg_replication_origin_progress
pg_logical_emit_message
準備6非同期カスケード
（ID24）
6.1基本バックアップ（操作マスタノード23）
pg_basebackup -U foo -W -Fp -P -x -D ~/app/data/pg_root24 -l basebackup24
注：この接続は、23ベースのバックアップを行います。
6.2フロー重複パラメータの設定
sed -ir "s/#*standby_mode.*/standby_mode= on/" $PGDATA/recovery.conf
sed -ir "s/#*primary_conninfo.*/primary_conninfo= 'host=127.0.0.1 port=9423 user=foo password=server@123'/" $PGDATA/recovery.conf
ログ情報
LOG: database system was interrupted while in recovery at log time 2017-04-28 11:13:33 CST
HINT: If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target.
LOG: entering standby mode
LOG: redo starts at 0/B00D958
LOG: consistent recovery state reached at 0/B00DA38
LOG: invalid record length at 0/B00DA38: wanted 24, got 0
LOG: database system is ready to accept read only connections
LOG: started streaming WAL from primary at 0/B000000 on timeline 1
プロセスの状態
/home/gaomingjie/app/pgsql23/bin/postgres
\_ postgres: startup process recovering 00000001000000000000000B
\_ postgres: checkpointer process
\_ postgres: writer process
\_ postgres: stats collector process
\_ postgres: wal receiver process streaming 0/B00DBF8
\_ postgres: wal sender process foo 127.0.0.1(58019) streaming 0/B00DBF8
/home/gaomingjie/app/pgsql24/bin/postgres
\_ postgres: startup process recovering 00000001000000000000000B
\_ postgres: checkpointer process
\_ postgres: writer process
\_ postgres: stats collector process
\_ postgres: wal receiver process streaming 0/B00DBF8
7ホットスタンバイ同期ストリームの複製（オープンアーカイブ）
（ID25）
同期レプリケーションを要求する場合、それは、プライマリサーバとバックアップサーバ上の提出は、ディスク上のトランザクション・ログに書き込まれたことを示す肯定応答を受信するまで、各提出の書き込みトランザクションを待ちます。データが失われることを唯一の可能性は、同時にプライマリサーバとバックアップサーバが崩壊しています。システム管理者のみが、二つのサーバと管理の関係を配置するが、これは、持続性のより高いレベルを提供することができます。修正のための要求は、ユーザーが信頼を失うことはありません向上しますが、不必要に要求トランザクションの応答時間を向上させます。最小待ち時間がメインサーバとバックアップサーバ間の時間を前後です。読み取り専用トランザクションおよびトランザクションのロールバックは、返信バックアップサーバーを待つ必要はありません。トランザクションは、子供をコミット応答バックアップサーバーを待つ必要があり、唯一のトップ層は待つ必要が提出されていません。最終的な提出メッセージを待たずに長時間実行操作（例えば、データのロードやインデックスの建物）。すべての2フェーズ・コミットのアクションは、準備と提出を含め、待ち時間に要請しました。
7.1基本バックアップ（操作マスタノード20）
ステップ1：設定権限
create role foo login replication password 'server@123';
pg_hba.conf:
host replication foo 127.0.0.1/32 md5
ステップ2：pg_basebackup -U foo -W -Fp -P -x -D ~/app/data/pg_root25 -l basebackup25
注：この接続は、20ベースのバックアップを行います。
第三段階：変更synchronous_standby_namesパラメータ。
sed -ir "s/#*synchronous_standby_names.*/synchronous_standby_names= '1 (s1)'/" $PGDATA/postgresql.conf
7.2フロー重複パラメータの設定
sed -ir "s/#*hot_standby.*/hot_standby= on/" $PGDATA/postgresql.conf
cp $PGHOME/share/recovery.conf.sample ./recovery.conf
sed -ir "s/#*standby_mode.*/standby_mode= on/" $PGDATA/recovery.conf
sed -ir "s/#*primary_conninfo.*/primary_conninfo= 'application_name=s1 host=127.0.0.1 port=9420 user=foo password=server@123'/" $PGDATA/recovery.conf
sed -ir "s/#*archive_mode.*/archive_mode = always/" $PGDATA/postgresql.conf
sed -ir "s/#*archive_command.*/archive_command = 'test ! -f \${PGHOME}\/archive\/%f \&\& cp %p \${PGHOME}\/archive\/%f'/" $PGDATA/postgresql.conf
マスターノードのログ情報
LOG: standby "s1" is now a synchronous standby with priority 1
デュアルマスターノードステータスの問い合わせ
postgres=# select * from pg_stat_replication where application_name='s1';
-[ RECORD 1 ]----+------------------------------
pid | 23543
usesysid | 16393
usename | foo
application_name | s1
client_addr | 127.0.0.1
client_hostname |
client_port | 48481
backend_start | 2017-04-28 14:45:03.051153+08
backend_xmin |
state | streaming
sent_location | 0/E0000D0
write_location | 0/E0000D0
flush_location | 0/E0000D0
replay_location | 0/E0000D0
sync_priority | 1
sync_state | sync
7.3関連パラメータ
synchronous_commit
| 値 | 手段 |
|---|---|
| remote_apply | レコードは、バックアップサーバが応答メッセージを送信します再生するために提出されている場合は、トランザクションが見えるようになります。あなたは、バックアップ、同期として優先順位リストsynchronous_standby_namesマスターサーバーからバックアップサーバーを選択した場合は、確認がトランザクション・レコードをコミット待って解放する時期を決定する応答メッセージの同期バックアップからバックアップサーバーや他のに従って受信されています。これらのパラメータは、管理者がバックアップ準備を同期させる必要があるサーバーを指定することができます。主にホストコンピュータ上で同期レプリケーションの設定に注意してください。バックアップサーバーの命名は、ホストコンピュータ、下流バックアップサーバーのレプリケーション何のカスケードを使用して、ホストコンピュータに直接接続する必要があります。 remote_apply各コミット原因現在の同期、バックアップサーバは、彼らがユーザーのクエリに取引が見えるようになり、トランザクションを、再生していたことを報告するまで待機します。最も単純なケースでは、これは、部屋を出る均衡因果負荷と一致しています。リクエストが速いシャットダウンしている場合、ユーザーが待って停止します。ただし、非同期レプリケーションを使用する前に、現在のすべての未解決でWALレコードを接続されたバックアップサーバに送信され、サーバが完全にシャットダウンしません。 |
| remote_write | 各提出に結果として得られる記述されたレコードを受信し、独自のオペレーティングシステムが設置されていることを確認するためにそれを提出するが、データがバックアップサーバ上のディスクにブラッシングされるのを待つようにしていないバックアップサーバを待っています。この配置は弱いポイントでより永続的な保護を提供します：それはPostgreSQLのクラッシュではないが、バックアップサーバは、クラッシュのオペレーティングシステムの場合にデータを失う可能性があります。それはトランザクションの応答時間を短縮することができますので、しかし、実際には、便利な設定です。プライマリサーバおよびバックアップサーバがクラッシュしてメインサーバーデータベースはながら破損場合にのみ、データの損失が発生します。 |
