Hologresでのシャードレベルレプリケーションの使用 - Hologres

このトピックでは、Hologres でシャードレベルレプリケーションを使用する方法について説明します。

仕組み

Hologres V1.1 以降では、テーブルグループのレプリカ数を設定することで、テーブルグループのクエリ同時実行性と可用性を向上できます。テーブルグループの作成時にレプリカ数を指定するか、既存のテーブルグループのレプリカ数を変更することで、レプリケーションを有効化できます。追加されたレプリカはインメモリのコピーであり、ストレージコストは発生しません。

レプリカ数の詳細：

データはシャードに分散されます。各シャードはデータのサブセットを管理します。すべてのシャードを合わせることで、完全なデータセットを構成します。
デフォルトでは、各シャードのレプリカは 1 つのみです。つまり、replica_count = 1 です。このレプリカがリーダーシャードです。レプリカ数を増やすことで、同一データに対して複数のレプリカを作成できます。これらの追加レプリカはフォロワーシャードです。
書き込みリクエストはリーダーシャードが処理します。読み取りリクエストは、リーダーシャードとフォロワーシャードを含むすべてのレプリカに負荷分散されます。フォロワーシャードにクエリする場合、10 ms から 20 ms のデータレイテンシーが発生することがあります。
同一のワーカーノードに同一シャードの複数レプリカが配置されることを防ぐアンチアフィニティポリシーにより、replica_count の値はワーカーノード数を超えてはなりません。Hologres V1.3.53 以降では、この上限を超えるとエラーが報告されます。インスタンス仕様ごとのワーカーノード数については、Instance management をご参照ください。
ワーカーノード全体で計算負荷のバランスを取るために、レプリカ数を増やす場合はシャード数を減らしてください。最適なパフォーマンスは、shard_count * replica_count = recommended shard count for the instance のときに得られます。
Hologres は V1.3.45 以降、クエリに対する高可用性 (HA) をサポートしています。
インスタンスの監視ページに次の内容が表示される場合：

インスタンス全体のリソース使用率は高くない一方で、一部のワーカーノードのリソース使用率が高く、他は低い状態です。これは、クエリ分散が不均一であり、ほとんどのクエリが少数のシャードのみで処理されていることが原因である可能性があります。この場合は、レプリカ数を増やしてレプリカをより多くのワーカーに分散できます。この方法により、リソース使用率と 1 秒あたりのクエリ数 (QPS) を効果的に改善できます。
説明
- リーダーシャードとフォロワーシャード間のメタデータ同期にはリソースが消費されます。レプリカが多いほど消費されるリソースも増えます。そのため、リソース使用率の偏りがクエリ分散の偏りに起因することを確認できない場合、この方法で QPS を増やすことは推奨しません。
- また、リーダーシャードとフォロワーシャードの間にはミリ秒レベルのデータレイテンシーがあります。
レプリカ数を増やすと、同一のクエリ条件下で各ワーカーのリソースがより均等に使用されます。次の図に示します。

制限事項

シャードレベルレプリケーションは、Hologres V1.1 以降でのみサポートされています。

説明
現在のインスタンスバージョンは、Hologres コンソールのインスタンス詳細ページで確認できます。インスタンスが V0.10 より前の場合は、アップグレード手順についてInstance upgrades をご参照いただくか、Hologres DingTalk グループに参加してサポートを受けてください。詳細については、「How to get online support?」をご参照ください。
replica_count はワーカーノード数以下である必要があります。インスタンスのワーカーノード数は、Hologres コンソールのインスタンス詳細ページで確認できます。

シャードレプリケーションの管理

現在のデータベース内のテーブルグループの照会
次のステートメントを使用して、現在のデータベース内にあるテーブルグループを表示します：
```
select * from hologres.hg_table_group_properties;
```

既存テーブルグループのレプリカ数の照会

例

select property_value from hologres.hg_table_group_properties where tablegroup_name = 'table_group_name' and property_key = 'replica_count';

パラメーター

パラメーター	説明
table_group_name	対象テーブルグループの名前。
replica_count	固定のパラメーター名です。変更しないでください。

レプリケーションの有効化

例

次のステートメントを使用して、テーブルグループのレプリカ数を調整します：

-- テーブルグループのレプリカ数を調整します。
call hg_set_table_group_property ('<table_group_name>', 'replica_count', '<replica_count>');

パラメーター

パラメーター

説明

hg_set_table_group_property

テーブルグループの replica_count を変更します。

table_group_name：変更するテーブルグループの名前。
replica_count：テーブルグループの目的のレプリカ数。値はワーカーノード数を超えてはなりません。一般的な値は 2 です。
デフォルトは 1 (レプリケーション無効) です。1 より大きい値を指定するとレプリケーションが有効になります。

レプリケーションの無効化

例

-- レプリケーションを無効化するために replica_count を変更します。
call hg_set_table_group_property ('table_group_name', 'replica_count', '1');

パラメーター

パラメーター

説明

hg_set_table_group_property

テーブルグループの replica_count を変更します。

table_group_name：変更するテーブルグループの名前。
replica_count：テーブルグループの目的のレプリカ数。
デフォルトは 1 (レプリケーション無効) です。1 より大きい値を指定するとレプリケーションが有効になります。

読み込みステータスの確認
複数のレプリカを設定した後、次の SQL ステートメントを実行して、各ワーカーにおけるシャードの読み込みステータスを確認できます：
```
SELECT * FROM hologres.hg_worker_info;
```
説明
ワーカーがシャードのメタデータの読み込みを完了するまで、worker_id 列が空になる場合があります。

クエリ結果には worker_id、table_group_name、shard_id 列のほか、olap_replica_2 に加えて olap_replica_2_tg_inte など、他のテーブルグループのシャード分散情報も含まれます。

olap_replica_2 テーブルグループでは、shard_id が 0 と 1 の 2 つのシャードがあり、各シャードのデータのコピーが7tn8k および 9c8sl の両ワーカーに存在します。

高可用性とスループットのためのクエリルーティング

動作

複数のシャードレプリカを設定すると、次の図のように、シャードのレプリカが複数のワーカーに読み込まれます。その後、クエリは処理のために、いずれかのワーカーにあるシャードレプリカへランダムにルーティングされます。
ポイントクエリ (固定プランのクエリ) のシナリオでは、可能な限り結果を返せるようにリトライメカニズムが用意されています。一定時間内にクエリが結果を返さない場合、別のワーカー上のレプリカに対してリトライされます。

パラメーター

hg_experimental_query_replica_mode：クエリに応答するシャードのポリシーを指定します。

ユースケース

デフォルト

タイプ

有効な値

例

すべてのクエリ

leader_follower

TEXT

leader_follower (デフォルト)：リーダーシャードとフォロワーシャードの両方を、一定の比率でクエリ応答に使用することを示します。
leader_only：リーダーシャードのみをクエリ応答に使用することを示します。この設定では、replicas > 1 であっても、スループットのスケールアウトや高可用性の実現はできません。
follower_only: クエリへの応答にフォロワーシャードのみが使用されるように指定します。スループットを向上させ、高可用性を確保するために two or more follower shards が存在することを保証するには、replicas > 3 が必要です。

-- セッションレベルの設定
SET hg_experimental_query_replica_mode = leader_follower;

-- データベースレベルの設定
ALTER DATABASE <database_name> 
SET hg_experimental_query_replica_mode = leader_follower;

hg_experimental_query_replica_leader_weight：クエリに応答するリーダーシャードの重みを指定します。

ユースケース

デフォルト

タイプ

有効な値

例

すべてのクエリ

100

INT

最大：10000
最小：1
デフォルト：100

-- セッションレベルの設定
SET hg_experimental_query_replica_leader_weight = 100;

-- データベースレベルの設定
ALTER DATABASE <database_name> 
SET hg_experimental_query_replica_leader_weight = 100;

テーブルのテーブルグループの replica_count が 1 より大きく、かつクエリが OLAP のポイントクエリである場合、リーダーシャードとフォロワーシャードは、hg_experimental_query_replica_mode と hg_experimental_query_replica_leader_weight の設定に基づき、特定の比率でクエリに応答します。これは次のシナリオで発生します：

シナリオ 1: テーブルのテーブルグループの replica_count が 1 より大きく、かつ hg_experimental_query_replica_mode=leader_follower の場合、システムはクエリをリーダーシャードとフォロワーシャードにルーティングします。ルーティングは重み付けシステムに基づいています。リーダーシャードの重みは hg_experimental_query_replica_leader_weight パラメーターによって定義され、デフォルト値は 100 です。デフォルトでは、各フォロワーシャードの重みも 100 です。たとえば、replica_count=4 の場合、各シャードには 1 つのリーダーシャードと 3 つのフォロワーシャードがあります。クエリがいずれかのシャードにルーティングされる確率は 25% です。
シナリオ2：テーブルのテーブルグループの replica_count が 1 より大きく、かつ hg_experimental_query_replica_mode=leader_only の場合、システムは replica_count の値に関係なく、リーダーシャードのみを使用してクエリに応答します。
シナリオ3：テーブルのテーブルグループの replica_count が 1 より大きく、かつ hg_experimental_query_replica_mode='follower_only' の場合、システムはフォロワーシャードのみを使用してクエリに応答します。デフォルトでは、クエリに応答する各フォロワーシャードの重みは 100 です。たとえば replica_count=4 の場合、1 つのリーダーシャードと 3 つのフォロワーシャードがあります。この場合、クエリに応答するのは 3 つのフォロワーシャードのみで、各フォロワーシャードにルーティングされる確率は 3 分の 1 です。

hg_experimental_query_replica_fixed_plan_ha_mode：ポイントクエリ (固定プランのクエリ) のシナリオにおける高可用性モードを指定します。

ユースケース

デフォルト

タイプ

有効な値

例

ポイントクエリ (固定プランのクエリ)

any

TEXT

any (デフォルト)： hg_experimental_query_replica_mode で定義されたシャード範囲と、hg_experimental_query_replica_leader_weight で定義された重みに基づいて、クエリをシャードレプリカにランダムに分散します。
leader_first：この設定は、hg_experimental_query_replica_mode が leader_follower に設定されている場合にのみ有効になります。クエリを優先的にリーダーシャードへ送信し、タイムアウトなどでリーダーシャードが利用できない場合にのみフォロワーシャードへフォールバックします。
off：クエリは 1 回のみ実行され、リトライは行われません。

-- セッションレベルの設定
SET hg_experimental_query_replica_fixed_plan_ha_mode = any;

-- データベースレベルの設定
ALTER DATABASE <database_name> 
SET hg_experimental_query_replica_fixed_plan_ha_mode = any;

hg_experimental_query_replica_fixed_plan_first_query_timeout_ms：ポイントクエリ (固定プランのクエリ) の高可用性モードにおける初回クエリのタイムアウトを指定します。タイムアウトが発生した場合、別の利用可能なシャードにクエリが送信され、リトライされます。たとえば、hg_experimental_query_replica_fixed_plan_first_query_timeout_ms=60 は、クエリが 60 ms 以内に結果を返さない場合に、システムが別のワーカーでクエリをリトライすることを示します。

ユースケース

デフォルト

タイプ

有効な値

例

すべてのクエリ

INT

最大：10000
最小：0
デフォルト：60

-- セッションレベルの設定
SET hg_experimental_query_replica_fixed_plan_first_query_timeout_ms = 60;

-- データベースレベルの設定
ALTER DATABASE <database_name> 
SET hg_experimental_query_replica_fixed_plan_first_query_timeout_ms = 60;

ユースケース

ユースケース1：複数レプリカによる高スループット

シナリオ：監視から、インスタンス全体のリソース使用率は高くない一方で、一部のワーカーノードのリソース使用率が高く、他のワーカーノードが十分に利用されていないことを確認できます。これは、クエリ分散が不均一であり、ほとんどのクエリが少数のシャードで処理されていることが原因である可能性があります。この場合は、シャードレプリカ数を増やしてレプリカをより多くのワーカーに配置することで、リソース使用率と QPS を効果的に改善できます。
手順：
1. レプリカ数を増やします：
  
  たとえば、データベースに tg_replica という名前のテーブルグループがある場合、次の SQL ステートメントを使用してレプリカ数を 2 に設定できます。
```
-- 'tg_replica' テーブルグループのレプリカ数を 2 に設定します。
call hg_set_table_group_property ('tg_replica', 'replica_count', '2');
```
  システムは次のデフォルト設定を使用します：
  - hg_experimental_query_replica_mode=leader_follower
  - hg_experimental_query_replica_leader_weight=100
  レプリカ数を増やすと、システムはリーダーシャードとフォロワーシャードをホストするワーカーノードにクエリをランダムに分散します。これにより、クエリホットスポットが原因で QPS を増やせない問題を解消できます。
2. ワーカーがシャードを読み込んでいるかを確認します：
  
  次のコマンドを使用して、ワーカーにシャードが読み込まれているかを確認します：
```
SELECT * FROM hologres.hg_worker_info WHERE table_group_name = 'tg_replica';
```
  結果には、worker_id、table_group_name、shard_id 列が含まれます。
  
  出力で、同一の shard_id が複数の worker_id に読み込まれていることが確認できれば、設定は成功です。

ユースケース2：複数レプリカによる高可用性

シナリオ：単一シャードのフェールオーバーによって発生するクエリ失敗を防止します。
手順：
1. レプリカ数を増やします：
  
  たとえば、データベースに tg_replica という名前のテーブルグループがある場合、次の SQL ステートメントを使用してレプリカ数を 2 に設定できます。
```
-- 'tg_replica' テーブルグループのレプリカ数を 2 に設定します。
call hg_set_table_group_property ('tg_replica', 'replica_count', '2');
```
  システムは次のデフォルト設定を使用します：
  - hg_experimental_query_replica_mode=leader_follower
  - hg_experimental_query_replica_fixed_plan_ha_mode=any
  - hg_experimental_query_replica_fixed_plan_first_query_timeout_ms=60
  レプリカ数を増やした後：
  
  OLAP シナリオでは、システムはリーダーシャードとフォロワーシャードをホストするワーカーノードにクエリをランダムに分散します。Master プロセスは各シャードの可用性を定期的にチェックし、利用できないシャードをクエリ候補リストから自動的に削除します。シャードが再び利用可能になると、リストに再追加されます。利用できないシャードの検出には 5 秒、対応するワーカーをフロントエンド (FE) から削除するには 10 秒かかります。そのため、検出と復旧のプロセス中は最大 15 秒間クエリ失敗が発生する可能性があります。その後、クエリは通常どおり再開します。
  
  固定プランのクエリのシナリオでは、リトライメカニズムにより、ワーカーのフェールオーバー中でもクエリ失敗を防止できます。ただし、応答時間が増加する場合があります。
  
  書き込み後の読み取り整合性に敏感で、リーダーシャードとフォロワーシャード間のレイテンシーを許容できない固定プランのクエリのシナリオでは、hg_experimental_query_replica_fixed_plan_ha_mode パラメーターを leader_first に設定できます。これは、固定プランのクエリでは常にリーダーシャードを優先してクエリ応答に使用することを意味します。リーダーシャードへのクエリがタイムアウトした場合に、フォロワーシャードがクエリ応答に使用されます。
  
  説明
  この場合、固定プランのシナリオでは、クエリホットスポットによる QPS ボトルネックを解消できません。
2. ワーカーがシャードを読み込んでいるかを確認します：
  
  次のコマンドを使用して、ワーカーにシャードが読み込まれているかを確認します：
```
SELECT * FROM hologres.hg_worker_info WHERE table_group_name = 'tg_replica';
```
  同一のシャードが複数のワーカーに読み込まれていることが確認できれば、設定は成功です。

トラブルシューティング

問題：ユースケース1の説明どおりにパラメーターを設定した後も、クエリがフォロワーシャードに分散されません。Hologres コンソールに表示されるワーカー負荷は、複数レプリカを設定する前と同じく高いままです。
Hologres V1.3 より前のバージョンでは、フォロワーシャードがクエリに参加できるかどうかを制御するために、hg_experimental_enable_read_replica GUC パラメーターが使用されます。このパラメーターはデフォルトで無効です。次の SQL ステートメントを使用して、このパラメーターが有効かどうかを確認できます。返される値がonの場合は有効で、offの場合は無効です。
```
SHOW hg_experimental_enable_read_replica;
```
この問題を解決するには、hg_experimental_enable_read_replica が無効の場合、次の SQL ステートメントを使用してデータベースレベルで有効にします。
```
ALTER DATABASE <database_name> SET hg_experimental_enable_read_replica = on;
```
database_name をデータベース名に置き換えてください。