Dgraphクラスタ

Dgraphノードは、BDDクラスタ内に独自のクラスタを形成します。

Dgraphクラスタは問合せ処理に高可用性を提供します。1つのノードで障害が発生した場合は、別のノードが処理を続行します。問合せの負荷が追加のストレージを必要とせずにクラスタ全体に分散されるため、スループットも向上します。

Dgraphクラスタには任意の数のノードを含めることができますが、最適なパフォーマンスにするには、少なくとも3つのノードを使用することをお薦めします。

リーダー・ノードとフォロワ・ノード

Dgraphクラスタ内の各ノードは、2つのロール(リーダーおよびフォロワ)を持つことができます。

リーダー・ノードは特定のDgraphデータベース(つまり、特定のデータ・セット)の更新を受け取り、これを処理します。更新には、データベースへの完全な更新や増分更新、および管理や構成のための変更があります。指定されたDgraphは複数のデータベースのリーダーとなることができます。
データベースが更新されると、リーダーDgraphは他のノードに新しいバージョンがあることを通知し、それを使用開始できるようにします。すべてのDgraphノードは、それに対して開始された処理を完了するために、以前のバージョンのデータベースを使用し続けます。
フォロワ・ノードは、特定のデータベースのリーダーではない他のすべてのDgraphノードです。それらはそのデータベースに対する読取り専用の問合せを処理できますが、書き込むことはできません。

データベースがマウントされずに、すべてのノードが起動されます。マウントされていないデータベースが関与するWebサービス・リクエストをDgraphが受け取ると、Dgraphはデータベースをフォロワ・ノードとしてマウントしようとします(Dgraph Gatewayによってリーダーに指定されていない場合)。Dgraphは新しいデータベースが作成されると自動的にマウントします。

リーダーは、あるデータベースに対する最初の書込み操作(Studioからの変換など)が行われるときに、そのDgraphデータベースに対してDgraph Gatewayにより選出されます。その時点まではリーダーが存在しません。Dgraphデータベースにリーダーが指名されると、そのデータベースが稼働しているかぎりリーダーに留まります。

セッション・アフィニティ

Dgraph Gatewayは、セッション・アフィニティを使用してクライアント・リクエストをDgraphノードにルーティングします。エンド・ユーザーが問合せを発行すると、Studioは、HTTPヘッダーのリクエストのセッションIDを設定します。同じセッションIDのリクエストは、同じDgraphノードにルーティングされます。Dgraph GatewayでセッションIDが見つからない場合、リクエストをルーティングするDgraphノードを決定するためのラウンドロビン戦略に依存します。

セッション・アフィニティはリクエスト・ヘッダーのendeca-session-id-keyおよびendeca-session-id-typeプロパティにより、デフォルトで有効になっています。

ZooKeeperのロール

Hadoop ZooKeeperは、Dgraphのための多数のサービス(構成と管理、同期およびイベントの通知を含む)を提供しています。これらのメカニズムは、Dgraphノードまたはそれらの間の接続で障害が発生した場合でも、引き続き機能します。たとえば、リーダーDgraphで障害が発生した場合、ZooKeeperはDgraph Gatewayに通知し、Dgraph Gatewayは自動リーダー再選択処理を開始します。

Dgraphは、ZooKeeperが実行されていない場合でも開始できます(ただし、リクエストを処理できません)。一方、ZooKeeperが停止している場合は、Dgraph HDFSエージェントを起動できません。

Dgraphの高可用性を保証するには、ZooKeeperを奇数のノードで実行する必要があります。最低でも3つのノードをお薦めします。これにより、ZooKeeperのシングル・ポイント障害が防止されます。これらのノードはDgraphノードである必要はありません。