18.04前書き本番用にアプリケーションを設定する場合、データベースの複数のコピーを配置しておくと便利なことがよくあります。データベースコピーの同期を維持するプロセスは、replicationと呼ばれます。レプリケーションは、大量の同時読み取り操作に対して高可用性の水平スケーリングを提供し、読み取りレイテンシーを削減します。地理的に分散したデータベースサーバー間でのピアツーピアレプリケーションも可能です。PostgreSQLは、高度に拡張可能で、ACID(Atomicity、Consistency、Isolation、Durability)およびSQL標準に準拠したオープンソースのオブジェクトリレーショナルデータベースシステムです。replicationのサポートが導入されました。論理レプリケーションスキームでは、高レベルの書き込み操作がmasterデータベースサーバーから1つ以上のreplicaデータベースサーバーにストリーミングされます。物理レプリケーションスキームでは、代わりにバイナリ書き込み操作がマスターからレプリカにストリーミングされ、元のコンテンツのバイト単位の正確なコピーが生成されます。オフロードレポート、パッチ適用、アップグレードなど、データの特定のサブセットを対象とする場合、論理レプリケーションは速度と柔軟性を提供します。10を使用して論理レプリケーションを構成します。一方のサーバーはマスターとして機能し、他方のサーバーはレプリカとして機能します。チュートリアルの終わりまでに、論理レプリケーションを使用して、マスターサーバーからレプリカにデータをレプリケートできるようになります。前提条件このチュートリアルを実行するには、次のものが必要です。2つのUbuntu18.04サーバー(db-masterとdb-replicaという名前を付けます)は、それぞれ通常のユーザーアカウントとsudo権限でセットアップされます。tutorialに従います。プライベートネットワーキングを使用すると、データベースをパブリックインターネットに公開することに伴うセキュリティリスクなしにサーバー間の通信が可能になります。18.04のステップ1に従って、両方のサーバーにPostgreSQL10がインストールされました。==ステップ1—論理レプリケーション用のPostgreSQLの設定サーバー間の論理複製を有効にするために変更する必要があるいくつかの構成設定があります。パブリックネットワーク経由でデータを公開することはセキュリティリスクであるため、パブリックインターフェイスではなくプライベートネットワークインターフェイスでリッスンするようにPostgresを構成します。次に、db-replicaへのレプリケーションを許可するように適切な設定を構成します。db-masterで、メインサーバー構成ファイルである/etc/postgresql/10/main/postgresql.confを開きます。/etc/postgresql/10/main/postgresql.conf次の行を見つけます。on;...#を削除してコメントを解除し、db_master_private_ip_addressを追加してプライベートネットワークでの接続を有効にします。[.note]#Note:この手順とそれに続く手順では、サーバーのパブリックIPではなく、サーバーのprivateIPアドレスを使用してください。データベースサーバーをパブリックインターネットに公開することは、かなりのセキュリティリスクです。db_master_private_ip_address'...これにより、db-masterは、ループバックインターフェイスに加えて、プライベートネットワーク上の着信接続をリッスンします。次に、次の行を見つけます。Log(WAL)レベルをlogicalに設定するように変更します。これにより、ログ内のエントリの量が増え、特定のデータセットの不一致または変更を抽出するために必要な情報が追加されます。logical...このログのエントリはレプリカサーバーによって消費され、マスターからの高レベルの書き込み操作の複製が可能になります。ファイルを保存して閉じます。次に、許可されたホスト、認証、およびデータベースへのアクセスを制御するファイルである/etc/postgresql/10/main/pg_hba.confを編集しましょう。/etc/postgresql/10/main/pg_hba.conf最後の行の後に、db-replicaからの着信ネットワーク接続を許可する行を追加しましょう。db-replicaのプライベートIPアドレスを使用し、すべてのユーザーとデータベースからの接続を許可するように指定します。md5着信ネットワーク接続は、パスワードハッシュ(md5)によって認証されたdb-replicaから許可されるようになります。ファイルを保存して閉じます。次に、db-replicaからdb-masterのポート5432へのトラフィックを許可するようにファイアウォールルールを設定しましょう。5432最後に、PostgreSQLサーバーを再起動して、変更を有効にします。postgresql論理レプリケーションを許可するように構成を設定したら、データベース、ユーザーロール、およびテーブルの作成に進むことができます。==ステップ2—データベース、ユーザーロール、およびテーブルの設定レプリケーション設定の機能をテストするために、データベース、テーブル、ユーザーロールを作成しましょう。サンプルテーブルを使用してexampleデータベースを作成します。これを使用して、サーバー間の論理レプリケーションをテストできます。専用ユーザーを作成し、データベースとテーブルの両方に対する特権を割り当てます。promptを開きます。psql両方のホストにexampleという名前の新しいデータベースを作成します。example;[.note]#Note:これらのコマンドの最後の;は必須です。対話型セッションでは、PostgreSQLはセミコロンで終了するまでSQLコマンドを実行しません。メタコマンド(\qや\cなどのバックスラッシュで始まるコマンド)は、psqlクライアント自体を直接制御するため、このルールは免除されます。documentation。#を参照してください。\connectメタコマンドを使用して、各ホストで作成したデータベースに接続します。example両方のホストに任意のフィールドを持つwidgetsという名前の新しいテーブルを作成します。(id));db-replicaのテーブルは、対応するdb-masterと同一である必要はありません。テーブルのdb-masterに存在するすべての列が含まれている必要があります。NULLまたはその他の制約があってはなりません。実行すると、レプリケーションは失敗します。db-masterで、REPLICATIONオプションとログインパスワードを使用して新しいユーザーロールを作成しましょう。REPLICATION属性は、レプリケーションに使用されるすべてのロールに割り当てる必要があります。ユーザーをsammyと呼びますが、これを独自のユーザー名に置き換えることができます。my_passwordも必ず独自の安全なパスワードに置き換えてください。'my_password';後でdb-replicaを使用してレプリケーションを設定するため、パスワードをメモしておきます。引き続きdb-masterで、作成したばかりのユーザーロールにexampleデータベースに対する完全な特権を付与します。sammy;次に、データベースに含まれるすべてのテーブルに対する特権をユーザーに付与します。schemaは、テーブルが自動的に配置される各データベースのデフォルトスキーマです。これらの権限を設定すると、exampleデータベース内のテーブルをレプリケーションで使用できるようにすることに進むことができます。==ステップ3—パブリケーションの設定Publicationsは、PostgreSQLがテーブルをレプリケーションに使用できるようにするために使用するメカニズムです。データベースサーバーは、特定のパブリケーションに関連付けられたレプリカサーバーの接続およびレプリケーションステータスを内部的に追跡します。db-masterで、subscribersに送信されるデータのマスターコピーとして機能するパブリケーションmy_publicationを作成します。この場合はdb-replicaです。db-masterで、my_publicationというパブリケーションを作成します。my_publication;以前に作成したwidgetsテーブルを追加します。widgets;パブリケーションを配置したら、そこからデータをプルするサブスクライバーを追加できます。==ステップ4—サブスクリプションの作成Subscriptionsは、既存のパブリケーションに接続するためにPostgreSQLによって使用されます。パブリケーションは、異なるレプリカサーバー間で多くのサブスクリプションを持つことができ、レプリカサーバーはサブスクライバーとの独自のパブリケーションを持つこともできます。db-masterで作成したテーブルのデータにアクセスするには、前の手順で作成したパブリケーションmy_publicationのサブスクリプションを作成する必要があります。db-replicaで、my_subscriptionというサブスクリプションを作成しましょう。SUBSCRIPTIONコマンドはサブスクリプションに名前を付け、CONNECTIONパラメーターはパブリッシャーへの接続文字列を定義します。この文字列には、マスターサーバーの接続の詳細とログイン資格情報が含まれます。これには、前に定義したユーザー名とパスワード、およびexampleデータベースの名前が含まれます。繰り返しになりますが、db-masterのプライベートIPアドレスを使用し、my_passwordを自分のパスワードに置き換えることを忘れないでください。my_publication;サブスクリプションを確認する次の出力が表示されます。SUBSCRIPTIONサブスクリプションを作成すると、PostgreSQLは既存のデータをマスターからレプリカに自動的に同期します。この場合、widgetsテーブルが空であるため、同期するデータはありませんが、これは、既存のデータベースに新しいサブスクリプションを追加するときに便利な機能です。サブスクリプションを設定したら、widgetsテーブルにデモデータを追加してセットアップをテストしましょう。==ステップ5—テストとトラブルシューティングマスターとレプリカ間のレプリケーションをテストするために、widgetsテーブルにデータを追加して、正しくレプリケートされることを確認しましょう。db-masterで、次のデータをwidgetsテーブルに挿入します。3.80);db-replicaで、次のクエリを実行して、このテーブルのすべてのエントリをフェッチします。widgets;次のように表示されます。エントリはdb-masterからdb-replicaに正常に複製されました。今後、すべてのINSERT、UPDATE、およびDELETEのクエリは、サーバー間で一方向に複製されます。レプリカサーバーでの書き込みクエリに関する注意点の1つは、それらがマスタサーバーに複製されないことです。PostgreSQLは現在、サーバー間のデータが異なる場合の競合を解決するための限定的なサポートを提供しています。競合がある場合、レプリケーションは停止し、PostgreSQLはデータベース管理者が手動で問題を修正するまで待機します。そのため、ほとんどのアプリケーションはすべての書き込み操作をマスターサーバーに指示し、読み取りを利用可能なレプリカサーバーに分散します。これで、両方のサーバーでpsqlプロンプトを終了できます。\q\qセットアップのテストが終了したので、自分でデータを追加および複製できます。トラブルシューティングレプリケーションが機能していないように思われる場合、最初のステップとして、db-replicaのPostgreSQLログでエラーの可能性を確認することをお勧めします。/var/log/postgresql/postgresql-10-main.logレプリケーションが機能しなくなる一般的な問題を次に示します。プライベートネットワークが両方のサーバーで有効になっていないか、サーバーが異なるネットワークにあります。db-masterは、正しいプライベートネットワークIPで接続をリッスンするように構成されていません。db-masterの先行書き込みログレベルが正しく構成されていません(logicalに設定する必要があります)。db-masterは、正しいdb-replicaプライベートIPアドレスからの着信接続を受け入れるように構成されていません。UFWのようなファイアウォールは、ポート5432で着信PostgreSQL接続をブロックしています。db-masterとdb-replicaの間に不一致のテーブル名またはフィールドがあります。sammyデータベースロールに、db-master上のexampleデータベースにアクセスするために必要な権限がありません。sammyデータベースロールにdb-masterのREPLICATIONオプションがありません。sammyデータベースロールに、db-masterのwidgetsテーブルにアクセスするために必要な権限がありません。テーブルはdb-masterのパブリケーションに追加されませんでした。既存の問題を解決した後、複製が自動的に行われます。ない場合は、次のコマンドを使用して既存のサブスクリプションを削除してから、再作成します。10を正常にインストールし、それらの間の論理レプリケーションを構成しました。これで、レプリカサーバーを追加して、水平読み取りスケーリング、高可用性、PostgreSQLデータベースの地理的分布を試すために必要な知識が得られました。SUBSCRIPTIONコマンドの手動エントリを参照してください。