Deploying an EDB Postgres Distributed example cluster on Linux hosts¶
TPAとPGDの紹介¶
さまざまなPostgres構成のインストールと管理を簡単に繰り返し行えるようにするために、TPAを作成しました。 TPAは、Postgresの作成とデプロイを調整します。このクイックスタートでは、最初にTPAをインストールします。 TPAが既にインストールされている場合は、これらの手順をスキップできます。 TPAを使用して、Postgresクラスターのさまざまな構成をデプロイできます。
PGDは、高いパフォーマンスと可用性を実現するように設計されたPostgresのマルチマスター複製実装です。 PGDのインストールは、TPAによって調整されます。 TPAを使用して、PGDデモンストレーションクラスターの構成ファイルを生成します。
TPA Linuxホストオプションを使用すると、任意のクラウドまたはVMプラットフォームのユーザーがTPAを使用してEDB Postgres Distributedを構成できます。 TPAから必要なのは、ターゲットシステムをLinuxオペレーティングシステムで構成し、SSHを使用してアクセスすることだけです。他のTPAプラットフォーム（DockerおよびAWS）とは異なり、Linuxホスト構成はターゲットマシンをプロビジョニングしません。展開することを決定した場所にそれらをプロビジョニングするのはあなた次第です。
このクラスターは、Linuxサーバーインスタンスを使用してクラスターのノードをホストします。ノードには、3つの複製データベースノード、3つの共ホスト接続プロキシ、および1つのバックアップノードが含まれます。 TPAは、必要なEDB Postgres Distributedソフトウェアと構成を各ノードにプロビジョニング、準備、デプロイできます。
前提条件¶
Linuxホストを構成する¶
このクイックスタートでは、4つのホストをプロビジョニングする必要があります。各ホストには supported Linux operating system がインストールされている必要があります。パスワードのプロンプトをなくすには、各ホストが証明書キーペアを使用してSSHアクセス可能である必要もあります。
どちらのクラウドまたはVMプラットフォームを使用する場合でも、各インスタンスにSSHでアクセスできること、および各インスタンスが他のインスタンスに接続できることを確認する必要があります。パブリックネットワークまたはクラウドプラットフォームのVPCを介して接続できます。オンプレミス VM は、ローカルネットワークを介して接続できます。
- これができない場合は、DockerまたはAWSのクイックスタートを検討することをお勧めします。これらの構成は、セットアップが簡単で、解体が迅速です。たとえば、
は、コンピューティングインスタンスを自動的にプロビジョニングし、それらのインスタンスのVPCを作成します。
Host name |
Public IP |
Private IP |
|---|---|---|
linuxhost-1 |
172.19.16.27 |
192.168.2.247 |
linuxhost-2 |
172.19.16.26 |
192.168.2.41 |
linuxhost-3 |
172.19.16.25 |
192.168.2.254 |
linuxhost-4 |
172.19.16.15 |
192.168.2.30 |
これらはIPアドレスの例です。クイックスタートを進めながら、自分のパブリックIPアドレスとプライベートIPアドレスに置き換えてください。
ホスト管理ユーザーを設定する¶
各マシンには、インストールに使用するユーザーアカウントが必要です。簡単にするために、すべてのホストで同じ名前のユーザーを使用します。各ホストで、パスワードの入力を求められずにホストにSSHできるようにユーザーも構成します。そのユーザーにホストでsudo特権を付与してください。 4つのホストで、ユーザーrockyはsudo特権ですでに構成されています。
準備¶
EDBアカウント¶
TPAとPGDの両方をインストールするには、EDBアカウントが必要です。
まだお持ちでない場合。サインアップすると、EDBのソフトウェアリポジトリへの試用版サブスクリプションが提供されます。
- 登録したら、
EDB Repos 2.0 ページに移動し、リポジトリトークンを取得できます。
このページに初めてアクセスしたときに、[ RequestAccess ]を選択してリポジトリトークンを生成します。 CopyToken アイコンを使用してトークンをコピーし、安全に保存します。
環境変数の設定¶
- まず、
EDB_SUBSCRIPTION_TOKEN環境変数を、 EDBアカウント ステップで取得したEDBリポジトリトークンの値に設定します。
export EDB_SUBSCRIPTION_TOKEN=<your-repo-token>
これを.bashrc
スクリプトまたは同様のシェルプロファイルに追加して、常に設定されるようにすることができます。
リポジトリを構成する¶
この例に必要なすべてのソフトウェアは、 EDB Postgres分散パッケージリポジトリから入手できます。スクリプトをダウンロードして実行し、 EDB Postgres分散リポジトリを構成します。このリポジトリには、TPAパッケージも含まれています。
curl -1sLf “https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/postgres_distributed/setup.deb.sh” | sudo -E bash
Trusted Postgres Architect（TPA）のインストール¶
- TPAを使用して、PGDをプロビジョニングおよびデプロイします。以前にTPAをインストールしたことがある場合は、
Next Steps with PGD に進むことができます。
TPAをインストールするための完全な手順は、 Trusted Postgres Architect documentation 、これもここに含まれています。
Linux環境¶
ホストプラットフォームとしての TPA supports several distributions of Linux 。これらの例はUbuntu 22.04用に書かれていますが、サポートされている他のプラットフォームでも手順は似ています。
TPAパッケージをインストールする¶
sudo apt install tpaexec
TPAの構成¶
次に、TPAのPython環境を構成するTPAを構成する必要があります。 setup
コマンドでtpaexec を呼び出します。
sudo /opt/EDB/TPA/bin/tpaexec setup
export PATH=$PATH:/opt/EDB/TPA/bin
export コマンドをシェルのプロファイルに追加できます。
TPAインストールのテスト¶
selftest
を実行して、TPAが正しくインストールされたことを確認できます。
tpaexec selftest
``` TPAがインストールされました。
## TPAを使用したPGDのインストール
### 構成ファイルの生成
:ref:`tpaexec configure <Deploying EDB Postgres Distributed using Trusted Postgres Architect>` コマンドを実行して、構成フォルダーを生成します。
tpaexec configure democluster –architecture PGD-Always-ON –platform bare –edb-postgres-advanced 15 –redwood –no-git –location-names dc1 –pgd-proxy-routing global –hostnames-unsorted
:ref:`PGD 5's Always On architectures <Choosing your architecture>` の構成を設定するPGD-Always-ONアーキテクチャ（`--architecture PGD-Always-ON` ）を指定します。デフォルトアーキテクチャの一部として、3つのデータノードでクラスターを構成し、3つの `PGD Proxy <https://www.enterprisedb.com/docs/pgd/latest/routing/proxy/>`_ サーバーとバックアップ用の1つの :ref:`Barman <Backup and recovery>` ノードを共ホストします。
Linuxホストの場合、「ベア」プラットフォーム（`--platform bare` ）をターゲットとしていることを指定します。 TPAは、展開中に各ホストで実行されているLinuxバージョンを判断します。サポートされているオペレーティングシステムの詳細については、 :ref:`the EDB Postgres Distributed compatibility table <Compatibility changes>` を参照してください。
データノードがOracle互換性（`--redwood` ）で `EDB Postgres Advanced Server v15 <https://www.enterprisedb.com/docs/epas/latest/>`_ （`--edb-postgres-advanced 15` ）を実行することを指定します。
`--location-names` を使用して、ノードの概念的な場所を`dc1` に設定します。次に、 `--pgd-proxy-routing` を`global` に設定して、プロキシルーティングがクラスター内のすべてのノードにトラフィックをルーティングできるようにします。
デフォルトでは、TPAは構成の変更をGitリポジトリにコミットします。この例では、それを行う必要はないため、`--no-git` フラグを渡します。
最後に、`--hostnames-unsorted` を渡して、ノードの反復可能なホスト名を生成するようにTPAに依頼します。それ以外の場合は、事前に定義された適切な単語のリストからホスト名をランダムに選択します。
このコマンドは、現在の作業ディレクトリに`democluster` というサブディレクトリを作成します。 TPAがクラスタの作成に使用する`config.yml` 構成ファイルが含まれています。次を使用して表示できます。
```shell
less democluster/config.yml
構成ファイルを編集して、管理ユーザー名、パブリックおよびプライベートIPアドレスなど、Linuxホストに関連する詳細を追加する必要があります。
構成の編集¶
好みのエディターを使用して、democluster/config.yml を開きます。
ansible_user: root を含む行を検索します。 root
を、SSHアクセスとsudo特権で構成したユーザーの名前に変更します。次の行に従ってください。
manage_ssh_hostkeys: yes
instance_defaults セクションは次のようになります。
edb_notranlate_7 次に、最初のノードkaboomの構成設定であるnode: 1
を検索します。
node: 1
行の後に、ノードのパブリックIPアドレスとプライベートIPアドレスを追加します。このノードのホストとしてlinuxhost-1
を使用します。以下をファイルに追加し、IPアドレスを置き換えます。各行の先頭を
node: 行の先頭に揃えます。
public_ip: 172.19.16.27
private_ip: 192.168.2.247
kaboomのエントリ全体は次のようになりますが、独自のIPアドレスを使用します。
- Name: kaboom
backup: kapok
location: dc1
node: 1
public_ip: 172.19.16.27
private_ip: 192.168.2.247
role:
- bdr
- pgd-proxy
vars:
bdr_child_group: dc1_subgroup
bdr_node_options:
route_priority: 100
``` 他の3つのノードでこのプロセスを繰り返します。
ノードkaftanの構成設定である`node: 2` を検索します。このノードには`linuxhost-2` を使用します。 IPアドレスを置き換えて、以下を追加します。
```yaml
public_ip: 172.19.16.26
private_ip: 192.168.2.41
ノードkaolinの構成設定であるnode: 3
を検索します。このノードにはlinuxhost-3 を使用します。
IPアドレスを置き換えて、以下を追加します。
public_ip: 172.19.16.25
private_ip: 192.168.2.254
最後に、ノードkapokの構成設定であるnode: 4
を検索します。このノードにはlinuxhost-4 を使用します。
IPアドレスを置き換えて、以下を追加します。
public_ip: 172.19.16.15
private_ip: 192.168.2.30
クラスターのプロビジョニング¶
次を実行できます。
tpaexec provision democluster
このコマンドは、クラスターをデプロイする準備をします。 （DockerやAWSなどの他のプラットフォームでは、このコマンドも必要なホストを作成します。Linuxホストを使用する場合、ホストはすでに構成されている必要があります。）
- Trusted Postgres Architectドキュメントの.. SeeAlso "Further reading"::
Linuxホストのこのプロセスの1つは、後でSSH操作のためにホストのキーペアを作成することです。これらのキーペアを作成したら、キーペアの公開部分をホストにコピーする必要があります。
ssh-copy-id でこれを行うことができ、democluster ID（-i
）と各ホストへのログインを提供します。この例では、これらはコマンドです。
ssh-copy-id -i democluster/id_democluster rocky@172.19.16.27
ssh-copy-id -i democluster/id_democluster rocky@172.19.16.26
ssh-copy-id -i democluster/id_democluster rocky@172.19.16.25
ssh-copy-id -i democluster/id_democluster rocky@172.19.16.15
これで、ホストを検証できるtpa_known_hosts
ファイルを作成できます。各ホスト（-H ）でssh-keyscan
を使用し、その出力をtpa_known_hosts に追加します。
ssh-keyscan -H 172.19.16.27 >> democluster/tpa_known_hosts
ssh-keyscan -H 172.19.16.26 >> democluster/tpa_known_hosts
ssh-keyscan -H 172.19.16.25 >> democluster/tpa_known_hosts
ssh-keyscan -H 172.19.16.15 >> democluster/tpa_known_hosts
クラスターをデプロイする¶
これで、クラスターをデプロイする準備が整いました。展開するには、次を実行します。
tpaexec deploy democluster
TPAは構成を適用し、必要なパッケージをインストールして、実際のEDB Postgres分散クラスターをセットアップします。
- Trusted Postgres Architectドキュメントの.. SeeAlso "Further reading"::
クラスターへの接続¶
これで、SSHを使用してクラスターのノードのいずれかにログインし、データベースに接続する準備が整いました。構成プロセスの一部では、キーを使用して、すべてのノードのSSHログインを設定します。
SSH構成を使用するには、前に tpaexec configure
コマンドで作成したdemocluster ディレクトリにいる必要があります。
cd democluster
そこから ssh -F ssh_config <hostname>
を実行してSSH接続を確立できます。クラスター内の最初のデータベースノードであるkaboomに接続します。
ssh -F ssh_config kaboom
__OUTPUT__
[rocky@kaboom ~]#
kaboomで、以前に構成したadminユーザーとansibleユーザーrockyとしてログインしていることに注意してください。
ここで、enterprisedbユーザーのIDを採用する必要があります。このユーザーは、クラスターのノードに接続するように事前構成され、承認されています。
sudo -iu enterprisedb
__OUTPUT__
enterprisedb@kaboom:~ $
psql コマンドを実行して、 bdrdb データベースにアクセスできます。
psql bdrdb
__OUTPUT__
psql (15.2.0, server 15.2.0)
Type "help" for help.
bdrdb=#
kaboomノードで実行されているPostgresデータベースに直接接続され、 SQLコマンドの発行を開始できます。
SQLクライアントを終了するには、 exit と入力します。
PGD CLIの使用¶
PGD CLIとしても知られるpgdユーティリティを使用すると、 EDB Postgres分散クラスターを制御および管理できます。すでにノードにインストールされています。
pgd check-health
を実行して、クラスターの状態を確認するために使用できます。
pgd check-health
__OUTPUT__
Check Status Message
- ---- ------ -------
ClockSkew Ok All BDR node pairs have clockskew within permissible limit
Connection Ok All BDR nodes are accessible
Raft Ok Raft Consensus is working correctly
Replslots Ok All BDR replication slots are working correctly
Version Ok All nodes are running same BDR versions
enterprisedb@kaboom:~ $
または、 pgd show-nodes
を使用して、クラスター内のデータを保持するノードを表示するようにPGDに依頼できます。
pgd show-nodes
__OUTPUT__
Node Node ID Group Type Current State Target State Status Seq ID
- --- ------- ----- ---- ------------- ------------ ------ ------
kaboom 2710197610 dc1_subgroup data ACTIVE ACTIVE Up 1
kaftan 3490219809 dc1_subgroup data ACTIVE ACTIVE Up 3
kaolin 2111777360 dc1_subgroup data ACTIVE ACTIVE Up 2
enterprisedb@kaboom:~ $
同様に、 pgd show-proxies を使用してプロキシ接続ノードを表示します。
pgd show-proxies
__OUTPUT__
Proxy Group Listen Addresses Listen Port
- ---- ----- ---------------- -----------
kaboom democluster [0.0.0.0] 6432
kaftan democluster [0.0.0.0] 6432
kaolin democluster [0.0.0.0] 6432
プロキシは、アプリケーションのデータノードのクラスターへの高可用性接続を提供します。コマンドpsql -h kaboom,kaftan,kaolin -p 6432 bdrdb
を使用して、プロキシに接続し、さらにデータベースに接続できます。
psql -h kaboom,kaftan,kaolin -p 6432 bdrdb
__OUTPUT__
psql (15.2.0, server 15.2.0)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.
bdrdb=#
クラスターを探索する¶
Connect to your database アプリケーションへ
実践的な演習付きの Explore failover
Understand conflicts を作成して監視することにより
*クラスターでの Next Steps with PGD
