PostgresSQLでのレプリケーション
レプリケーションでは、1つのデータベースサーバーであるソースからデータをコピーします。 、別のサーバーへのレプリカ 。レプリケーションは強力なデータベース機能であり、高可用性を提供し、ディザスタリカバリをサポートします。
また、テストとレポートの目的で使用するレプリカサーバーを作成して、本番のオンライントランザクション処理（OLTP）データベースの負荷を軽減することもできます。この投稿は、PostgreSQL®のさまざまなタイプのレプリケーションと、PostgreSQLデータベースのストリーミングレプリケーションを実装するために必要な手順を理解するのに役立ちます。
次に、PostgreSQLのレプリケーションモード、モデル、レプリケーションの種類を理解し、先行書き込みログについて学習します。
次の図は、PostgreSQLレプリケーションのモードを示しています。
非同期の場合 レプリケーションの場合、ソースサーバーはレプリカサーバーからのトランザクション完了の確認応答を待つ必要はありません。レプリケーショントランザクションはレプリカサーバーでキューに入れられ、処理が完了するまで2つのサーバーは指定された時間非同期のままになる可能性があります。
同期 モードレプリケーションでは、ソースサーバーは、各レプリケーショントランザクションが完了したというレプリカサーバーからの確認応答を待ってから続行します。ソースサーバーとレプリカサーバーの両方が常に使用可能である必要があります。レプリカからトランザクション失敗メッセージを受信した場合、ソースサーバーはそのトランザクションをロールバックします。このレプリケーションモードでは、ソースサーバーとレプリカサーバーは常に同期しています。欠点は、レプリカサーバーがダウンしたり、トランザクションを完了できなかったりすると、ソースサーバーがハング状態になることです。
単一ソースを使用 レプリケーションの場合、ソースサーバーは1つだけで、レプリカサーバーは1つ以上あります。ソースはレプリケーショントランザクションをすべてのレプリカに送信します。
レプリカサーバーは、ソースサーバーからの変更のみを受け入れることができます。ソースサーバー以外から変更を受け取った場合、レプリカはそれらのトランザクションをソースに複製しません。
マルチソース レプリケーションでは、複数のソースサーバーがあります。 1つのソースデータベースでテーブルの行が変更された場合、そのソースサーバーは、他のソースサーバーの対応するテーブルの行に変更を複製します。このモデルを成功させるには、競合解決スキームを採用して、重複する主キーやその他の問題を防ぐ必要があります。
レプリケーションには次の3つのタイプがあります。
- ストリーミングレプリケーション ：PostgreSQLは、このタイプのレプリケーションをバージョン9以降で使用できるようにしました。レプリカは、実行専用の選択クエリで使用できます。このタイプの主な要件は、ソースデータベースとレプリカデータベースが同じメジャーバージョンである必要があることです。
- カスケードレプリケーション ：PostgreSQL 9.2で導入された彼のタイプのレプリケーションでは、ソースサーバーから直接ではなく、スタンバイサーバーからレプリケーションを実行できます。これにより、ソースサーバーの負荷を軽減できます。
- 論理レプリケーション ：このタイプを使用して、選択したデータセットまたはデータベースオブジェクトを複製したり、PostgreSQLの異なるメジャーバージョン間で複製したりできます。非論理レプリケーションでは、書き込みにスタンバイサーバーを使用できますが、いくつかの制限があります。 Truncate、（lob、blob、clob）、シーケンス、スキーマ、DDLなどの大きなオブジェクトを複製することはできません。
ストリーミングレプリケーションの使用を開始する前に、先行書き込みログ（WAL）とその仕組みを理解する必要があります。
PostgreSQLでは、システムはデータベースに加えられた変更をデータファイルに保存する前にまずログファイルに保存します。これらの変更はWALレコードと呼ばれます。すべてのWALレコードには、ログシーケンス番号（LSN）と呼ばれる一意の番号があります。
PostgreSQLのストリーミングレプリケーションでは、レプリカデータベースサーバーはWALファイルを使用してソースデータベースサーバー上の変更をレプリケートします。
PostgreSQLデータベースでのストリーミングレプリケーションでは、3つの必須プロセスが重要な役割を果たします。
- WAL送信者
- WALレシーバー
- スタートアップ
WAL送信側プロセスはソースサーバーで実行されますが、WAL受信側プロセスとスタートアッププロセスはレプリカサーバーで実行されます。レプリケーションを開始すると、次のイベントが発生します。
- WALレシーバープロセスは、レプリカがWALデータをマスターに再生するまでLSNを送信します。
- ソースのWAL送信者プロセスは、WAL受信者から送信された最新のLSNに到達するまで、WALデータをレプリカに送信します。
- 次に、WAL受信者はWAL送信者から送信されたWALデータをWALセグメントに書き込みます。
- レプリカの起動プロセスは、WALセグメントに書き込まれたデータを再生します。
- 最後に、ストリーミングレプリケーションが開始されます。
ソースとonereplicaの間でPostgreSQLでストリーミングレプリケーションを設定する手順は次のとおりです。
まず、ソースサーバーとレプリカサーバーの両方にパスワードなしのSSH認証が構成されていることを確認する必要があります。そうでない場合は、ssh-keygenを使用して構成する必要があります 。
パスワードなしのSSH構成については、https：//linuxize.com/post/how-to-setup-passwordless-ssh-login/を参照してください。
Source node 192.168.24.28
Replica node 192.168.24.29
Username `postgres` on both source and replica.
両方のサーバーで次のコマンドを実行して、ファイアウォールを停止します。
$ sudo systemctl stop firewalld
$ sudo systemctl disable firewalld
-
ソースサーバーで、データディレクトリに移動します：
cd /var/lib/pgsql/11/data -
postgresql.confを編集します ファイルを作成し、次の変更を加えます。
archive_mode = on archive_command = ‘cp %p /var/lib/pgsql/archive/%f’ max_wall_senders = 5 wal_keep_segment =32 wal_level = replica listen_addresses = ‘*’ -
pg_hba.confにレプリカサーバーのIPアドレスエントリを追加します ：
host postgres postgres (ip_address)192.168.24.29/32 trust host replication postgres (ip_address)192.168.24.29/32 trust -
pg_hba.confのすべての変更について 、サービスをリロードします：
$ /usr/local/pgsql_11/bin/pg_ctl -D /var/lib/pgsql/11/ reload -
/ var / lib / pgsql / archive /を作成します アーカイブディレクトリが存在しない場合。
-
サーバーを再起動して変更を反映します。
レプリカサーバーの場合：
-
データディレクトリに移動し、サービスを停止します：
$ /usr/pgsql-11/bin/pg_ctl -D /var/lib/pgsql/11/data/ stop -
レプリカのデータディレクトリからすべてを削除し、次のコマンドを使用してソースへの接続を試みます。
$ /usr/pgsql-11/bin/psql -h 192.168.24.28 -
動作する場合は、レプリカからベースバックアップを開始します。
$ cd /var/lib/pgsql/11/data $ /usr/pgsql-11/bin/pg_basebackup -D /var/lib/pgsql/11/data/ -X fetch -h 192.168.24.28 -R -P
これらのコマンドは、すべてのデータをソースデータベースのデータディレクトリからreplicadataディレクトリにコピーし、 restorey.confを作成します。 ファイル。
基本バックアップが完了したら、 restorey.confを確認する必要があります ファイル。 restorey.confを備えたサーバー データディレクトリ内のファイルはレプリカサーバーであり、ソースサーバーの情報が含まれています。次の変更を行います：
Standby_mode = ‘on’
Primary_conninfo = ‘user=postgres host=192.168.24.28 port=5432’
ファイルは次のように表示されます。
$ Vi recovery.conf
Standby_mode = ‘on’
Primary_conninfo = ‘user=postgres passfile=’’/home/postgres/.pgpass’’ host=192.168.24.28 port=5432 sslmode=disable sslcompression=0 target_session_attrs=any’
次に、サーバーを起動して変更を検証します。
-
ソースにログインします：
/usr/local/pgsql_11/bin/psql Postgres=# Postgres=# Select * from pg_stat_replication; -[ RECORD 1 ]----+------------------------------ pid | 1934 usesysid | 26712 usename | postgres application_name | walreceiver client_addr | 192.168.24.29 client_hostname | client_port | 52143 backend_start | 2020-11-07 11:30:31.035614-05 backend_xmin | state | streaming sent_lsn | 0/50000E34 write_lsn | 0/50000E34 flush_lsn | 0/50000E34 replay_lsn | 0/50000E34 write_lag | flush_lag | replay_lag | sync_priority | 0 sync_state | async -
レプリカにログインします：
/usr/local/pgsql_11/bin/psql Postgres=# Postgres=# Select * from pg_is_in_recovery(); Pg_is_in_recovery ---------------------------------- t -
ソースからのOSレベルのコマンドで確認してください：
$ ps -ef|grep sender postgres 1934 1718 0 11:31 ? 00:00:00 postgres: wal sender process replicator 192.168.24.29(52143) streaming 0/50000E34 -
レプリカからのOSレベルのコマンドで確認します：
$ ps -ef|grep receiver postgres 1358 1748 0 11:31 ? 00:00:04 postgres: wal receiver process streaming 0/50000E34送信者と受信者のトランザクションは同じである必要があり、レプリカは常に読み取り専用モードです。
-
（オプション）デフォルトでは、レプリケーションは非同期モードです。同期レプリケーションに変更するには、ソースサーバーに移動し、 postgresql.confに次の変更を加えます。 ：
synchronous_standby_names=’*’ in次に、サービスを再起動します。
$ /usr/local/pgsql-11/bin/pg_ctl -D /var/lib/pgsql/11/ restart
この投稿では、レプリケーションの種類とストリーミングレプリケーションを設定する手順について説明します。通常、これを（特に分析で）使用して、プライマリサーバーの負荷を軽減するための読み取り専用レプリカを提供します。
高可用性環境が必要な場合や、プライマリがダウンした場合にホットスタンバイサーバーにフェイルオーバーする場合にも役立ちます。
データサービスの詳細をご覧ください。
コメントや質問をするには、[フィードバック]タブを使用します。私たちと会話を始めることもできます。
-
クリスマスの2日目に、ObjectRocketから次のようなものが提供されました。2つの高可用性PostgresSQLレプリカ
元々は2019年12月12日にObjectRocket.com/blogで公開されました ホリデーシーズンが近づいており、今シーズンはRackspace ObjectRocketの歴史における重要なマイルストーンの1周年を迎えます。2019年のホリデーシーズンにちょうど間に合うように、高可用性を導入しました。 （HA）ObjectRocketPostgreSQL®サービス。 ObjectRocketで提供するすべてのデータストアは本番ワークロード用に構築されており、すべてのクライアントにHAが必要です。 HAが重要な理由 HAという用語の場合 なじみがないので、HAが重要である理由を
-
WebLogicServer12cでのSSLの構成
この投稿では、Oracle®WebLogic®Server12c（12.1.2）でSSLを構成する方法について説明します。 概要 データと情報のセキュリティは、今日の世界の主要な関心事です。さまざまなアプリケーションが、ネットワークを介した安全な通信のためにSSL（Secure Socket Layer）プロトコルを使用しています。実際、これは最も広く使用されているネットワーク通信プロトコルの1つです。 SSLを使用するように構成されたWebLogicServerは、両方のID認証を提供します。 および転送中のデータ暗号化 2つのアプリケーションプログラム間の接続用。したがって、SSLを介