Cluster bootstrapping

HARPを使用するには、最小限のメタデータがDCSに存在する必要があります。クラスターを「ブートストラップ」するプロセスとは、本質的に、ノード、場所、およびその他のランタイム構成を一度にまたはリソースごとに初期化することを意味します。

このプロセスは、 harpctl apply コマンドによって制御されます。詳細については、 harpctl command-line tool を参照してください。

DCSを設定し、ブートストラップの前に機能することを確認します。

重要

これらの例の一部またはすべてを単一のYAMLドキュメントに組み合わせて、一度に適用できます。

クラスター全体のブートストラップ

一部の設定はクラスター全体に適用され、ブートストラップ中に指定できます。現在、これは event_sync_interval ランタイム指示子にのみ適用されますが、他の人は後で追加される可能性があります。

フォーマットは次のとおりです。

cluster:
  name: mycluster
  event_sync_interval: 100

そのファイルの名前付けがcluster.yml であると仮定すると、次のように適用します。

harpctl apply cluster.yml

クラスター名がDCSでまだ定義されていない場合、これもその値を初期化します。

重要

ここで指定されたクラスター名パラメーターは、常に config.yml で指定されたクラスター名をオーバーライドします。ブートストラップファイルは、クラスターまたはその大規模な構成の一部をブートストラップするために必要なすべての要素を提供することが前提です。 config.yml ファイルは、主にHARPマネージャー、 HARPプロキシ、または`harpctl` の実行を制御することを目的としています。

ロケーションブートストラップ

すべてのHARPノードは、最大1つの場所に関連付けられます。この場所は、単一のデータセンター、複数の基になるサーバーで構成されるグループ化されたリージョン、Amazonアベイラビリティーゾーンなどです。これは、 HARPがノードをグループ化して、その場所のノードを1つだけがリードマスターとして表すことができるようにする論理構造です。

したがって、1つ以上の場所を初期化する必要があります。このフォーマットは次のとおりです。

cluster:
  name: mycluster

locations:
  - location: dc1
  - location: dc2

そのファイルの名前付けがlocations.yml であると仮定すると、次のように適用します。

harpctl apply locations.yml

クラスターの操作を実行するときは、名前をプリアンブルとして含めて、変更が適切な場所に送られるようにします。

ロケーションがブートストラップされると、簡単な検査で表示されます。

> harpctl get locations

Cluster   Location Leader Previous Leader Target Leader Lease Renewals
- ------   -------- ------ --------------- ------------- --------------
mycluster dc1                                           <nil>
mycluster dc2                                           <nil>

どちらの場所もHARPによって認識され、ノードとプロキシの割り当てに使用できます。

ノードのブートストラップ

HARPノードは名前付きクラスターに存在し、名前が指定されている必要があります。これを超えて、他のすべての設定は動的であり、 HARPとの相互作用に影響を与える可能性があるため、DCSに保持されます。このため、

で説明されている1つ以上のランタイム指示子を使用して各ノードをブートストラップします。

ノードのブートストラップ中に、いくつかの必須フィールドがあります。

  • name

  • location

  • dsn

  • pg_data_dir

その他はすべてオプショナルであり、クラスターに依存する場合があります。一度に複数のノードをブートストラップできるため、一般的にこのフォーマットは次の構造に適合します。

cluster:
  name: mycluster

nodes:
  - name: node1
    location: dc1
    dsn: host=node1 dbname=bdrdb user=postgres
    pg_data_dir: /db/pgdata
    leader_lease_duration: 10
    priority: 500

そのファイルの名前付けがnode1.yml であると仮定すると、次のように適用します。

harpctl apply node1.yml

ノードがブートストラップされると、簡単な検査で表示されます。

> harpctl get nodes

Cluster     Name  Location Ready Fenced Allow Routing Routing Status Role    Type Lock Duration
- ------     ----  -------- ----- ------ ------------- -------------- ----    ---- -------------
mycluster   bdra1 dc1      true  false  true          ok             primary bdr  30

プロキシブートストラップ

ロケーションやノードとは異なり、プロキシは、ロケーション内のすべてのプロキシに適用される構成テンプレートを提供することもできます。これらは、global 指定の下でDCSに保存されます。各プロキシには名前がインスタンスとして存在する必要がありますが、一部の設定で特定のオーバーライドが必要な場合を除き、これ以上のカスタマイズは必要ありません。

これは、クラスターのデフォルトの構成設定が同じであるプロキシが複数存在する可能性があり、すべてのプロキシに対してこれらの値を繰り返す必要がないためです。

さらに、プロキシテンプレートをブートストラップするときは、接続の割り当て用に少なくとも1つのデータベースを定義します。これらの注意事項を念頭に置いて、このフォーマットは次のとおりです。

cluster:
  name: mycluster

proxies:
  monitor_interval: 5
  default_pool_size: 20
  max_client_conn: 1000
  database_name: bdrdb
  instances:
    - name: proxy1
    - name: proxy2
      default_pool_size: 50

これにより、2つのプロキシ（proxy1 とproxy2 ）のHARPが構成されます。 proxy2 のみにカスタムdefault_pool_size がありますが、それ以外の場合はグローバル設定を使用します。

そのファイルの名前付けがproxy.yml であると仮定すると、次のように適用します。

harpctl apply proxy.yml

プロキシテンプレートがブートストラップされると、簡単な検査で表示されます。

> harpctl get proxies

Cluster   Name   Pool Mode Auth Type Max Client Conn Default Pool Size
- ------   ----   --------- --------- --------------- -----------------
mycluster global session   md5       1000            20
mycluster proxy1 session   md5       1000            20
mycluster proxy2 session   md5       1000            50