ApsaraDB for MongoDB:シャードノードの追加または削除の進行状況を表示する

手順1: balancerが有効かどうかの確認

シャードノードを追加または削除するために開始されたタスクの場合、バランサーが有効になった後にのみデータチャンクが移行されます。 balancerが無効の場合、次の問題が発生します。

• シャードノードが追加されている場合、データチャンクを新しいシャードノードに移行することはできません。 その結果、新しいシャードノードはビジネストラフィックを処理できません。

• シャードノードが削除されている場合、削除するノードのデータは移行できません。 この場合、ノードを削除するタスクはブロックされます。

バランサーを有効にして、データチャンクを期待どおりに移行できるようにする必要があります。 詳細については、「ApsaraDB For MongoDB balancerの管理」をご参照ください。

次のいずれかの方法を使用して、balancerが有効になっているかどうかを確認できます。

• 方法1: sh.status() コマンドを実行する

  次の例は、balancerを有効にしてsh.status() コマンドに対して返される出力を示しています。

  ...
    autosplit:
          現在有効: はい
    balancer:
          現在有効: はい
          現在実行中: はい
                  バランサーアクティブウィンドウは、サーバーの現地時間08:30〜11:30に設定されています
  ... 

  出力に「現在有効: いいえ」が表示されている場合、balancerは無効になります。

• 方法2: sh.getBalancerState() コマンドを実行する

  • コマンドに対してtrueが返された場合、balancerは有効になります。

  • コマンドに対してfalseが返された場合、balancerは無効になります。

ステップ2: バランサーのタイムウィンドウが短期間に及ぶかどうかを確認する

バランサーは、データチャンクの移行速度を管理します。 balancerは、指定された時間ウィンドウ内にのみデータチャンクを移行します。 指定された時間ウィンドウ内にデータチャンクが完全に移行されなかった場合、データ移行タスクは、移行が完了するまで次の時間ウィンドウで続行されます。 タイムウィンドウの期間が短い場合、シャードノードを追加または削除するタスクの進行が遅れます。 balancerの時間ウィンドウを変更する方法の詳細については、「ApsaraDB For MongoDB balancerの管理」をご参照ください。

バランサーのタイムウィンドウを確認するには、次のいずれかの方法を使用します。

• 方法1: sh.status() コマンドを実行する

  次の例は、コマンドに対して返される出力を示しています。 この例では、バランサーの時間ウィンドウは08:30から11:30 (現地時間) で、合計3時間です。

  ...
    autosplit:
          現在有効: はい
    balancer:
          現在有効: はい
          現在実行中: はい
                  バランサーアクティブウィンドウは、サーバーの現地時間08:30〜11:30に設定されています
  ... 

• 方法2: sh.getBalancerWindow() コマンドを実行する

  次の例は、コマンドに対して返される出力を示しています。 インスタンスに多数のシャードがある場合、このメソッドを使用して時間ウィンドウをより直感的に表示できます。

  { "start" : "08:30", "stop" : "11:30" }

ステップ3: タスクの進行状況を推定するために必要な情報を取得

タスクを評価する前に、balancerの操作結果と、移行するシャードテーブルのチャンク情報を取得する必要があります。 バランサーの操作結果には、移行されたチャンクの数と移行に失敗したチャンクの数に関する統計が含まれます。

次のいずれかの方法を使用して、上記の情報を取得できます。

• 方法1: sh.status() コマンドに対して返された出力を表示する

  sh.status() コマンドで返される出力では、balancerの最近の動作結果と、移行するシャードテーブルのチャンク情報に注目する必要があります。 バランサーの最近の操作結果の例を次に示します。

  ...
    balancer:
          移行がアクティブなコレクション: 
                  <db>.<collection> は9月27日水曜日2023 10:25:21 GMT + 0800 (CST) に始まりました
          過去5回の試行で失敗したバランサーラウンド: 0
          過去24時間の移行結果: 
                  300: 成功
    データベース:
  ... 

  次の例は、移行するシャードテーブルのチャンク情報を示しています。

  ...
  データベース:
  ...
      {"_id" : "<db>" 、"primary" : "d-xxxxxxxxxxxxxxx3" 、"partitioned" : true、"version" : { "uuid" : UUID("3409a337-c370-4425-ad72-8b8c6b0abd52") 、"lastMod" : 1 } }
            <db>.<コレクション>
                          シャードキー: { "<shard_key>" : "hashed"}
                          unique: false
                          バランシング: true
                          チャンク:
                                  d-xxxxxxxxxxxxxxx1 13630
                                  d-xxxxxxxxxxxxxxx2 13629
                                  d-xxxxxxxxxxxxxxx3 13652
                                  d-xxxxxxxxxxxxxxx4 13630
                                  d-xxxxxxxxxxxxxxx5 3719
                          印刷するにはチャンクが多すぎます。印刷を強制する場合は冗長を使用します
  ... 

  上記の例では、d-xxxxxxxxxxxxxxx5は追加されたシャードノードを示します。 パーティションテーブルが配置されているデータベースでgetShardDistributionコマンドを実行して、データチャンクの配布に関する情報を取得することもできます。 例：

  <db> を使用
  db.<collection>.getShardDistribution() 

• 方法2: configデータベースから関連情報を直接読み取る

  チャンクの統計を照会し、シャードごとに集計します。 例：

  db.getSiblingDB("config").chunks.aggregate([{$group: {_id: "$shard", count: {$sum: 1 }}}])

  指定されたシャードのチャンクを照会し、名前空間ごとに集約します。 例：

  db.getSiblingDB("config").chunks.aggregate([{$match: {shard: "d-xxxxxxxxxxxxxx" }},{$ group: {_id: "$ns", count: {$sum: 1 }}}])

  前日に指定されたシャードノードに移行されたチャンクの数を照会します。 例：

  // チャンクを移行するシャードとしてdetails.toフィールドを指定します。
  // 時間フィールドをISODateタイプの時間範囲として指定します。
  db.getSiblingDB("config").changelog.find({"what" : "moveChunk.com mit", "details.to" : "d-xxxxxxxxxxxxx", "time" : {"$gte": ISODate("2023-09-26T00:00:00")}}).count() 

ステップ4: タスクの進行状況と完了時間の見積もり

シャードテーブルから移行されたチャンクの数と現在のシャードテーブルのデータの分布を取得した後、タスクの全体的な進行状況と予想完了時間を見積もることができます。

シャードノードを追加するとします。 シャードノードが追加される前は、チャンクの総数は変更されません。 さらに、シャードノードの数は変更されません。これは、シャードノードを追加または削除するタスクが開始されないことを示します。 シャードノードが追加されているとき、ビジネスワークロードは一定のままで、バランサーに関連するパラメーターはデフォルト値に設定されます。 次の情報はステップ3で示されている前述の例から得ることができます:

• 5つのシャードノードが追加されます。

• 300チャンクは、バランサーの時間ウィンドウ内に移行されます。

• 58,260チャンクは、<db>.<collection> シャードテーブルに含まれます。 チャンク数は、13,630 + 13,629 + 13,652 + 13,630 + 3,719 = 58,260の式に基づいて計算される。

上記の結果に基づいて、次の値を計算できます。

• チャンクがシャードに均等に分散されている場合、各シャードのチャンク数は11,652 (58,260/5 = 11,652) になります。

• 現在の移行速度に基づいて、移行が完了するまでにさらに26.4日かかります。 日数は次の式に基づいて計算されます :( 11,652 - 3,719)/300 ≒ 26.4。

• シャードノードを追加するタスクのプロセスは32% です (3,719/11,652 = 32%) 。

手順5: シャードノードが削除されているときにタスクがブロックされているかどうかを確認する

シャードノードを削除するために開始されたタスクがブロックされた場合、sh.status() コマンドから返される出力には、前の期間にチャンクの移行が成功したことを示すメッセージは含まれず、一部のチャンクは削除されるシャードノードから移行されません。 この場合、タスクは完了せず、ApsaraDB for MongoDBコンソールでインスタンスに対して実行されたO&M操作が影響を受けます。

次の例は、sh.status() コマンドに対して返される出力を示しています。

上記の問題は、ジャンボチャンクが原因である可能性があります。 これにより、シャードノードの削除が進行しなくなります。 次のコマンドを使用して、ジャンボチャンクが存在するかどうかを確認できます。

db.getSiblingDB("config").chunks.aggregate([{$match: {shard: "d-xxxxxxxxxxxxxx", jumbo:true }},{$ group: {_id: "$ns", count: {$sum: 1 }}}])

ほとんどの場合、ジャンボチャンクの発生は、ホットキーの存在を含む、不適切な、または不適切に選択されたシャードキー設計などの要因に起因する可能性があります。 次のいずれかの方法を使用して、クライアントで問題をトラブルシューティングできます。

• ApsaraDB for MongoDBインスタンスのメジャーエンジンバージョンが4.4の場合、refineCollectionShardKeyコマンドを実行してシャードキーの設計を最適化できます。 ジャンボチャンクに関連する問題に対処するには、元のシャードキーにサフィックスを追加して、キーのカーディナリティを高めることができます。

• ApsaraDB for MongoDBインスタンスのメジャーエンジンバージョンが5.0以降の場合、reshardCollectionコマンドを実行して、新しいシャードキーに基づいて指定されたシャードテーブルをリハードできます。 詳細については、「コレクションのリハード」をご参照ください。

• 一部のデータを確実に削除できる場合は、対応するジャンボチャンクからデータを削除できます。 これにより、ジャンボチャンクのサイズが小さくなります。 一部のデータが削除されると、ジャンボチャンクは通常のチャンクサイズに縮小され、balancerによって移動されます。

• chunkSizeパラメーターの値を大きくして、ジャンボチャンクを決定する条件を変更できます。 Alibaba Cloudテクニカルサポートからの提案に基づいて操作を実行することを推奨します。

上記の方法が機能しない場合は、 チケットを起票し、テクニカルサポートにお問い合わせください。