10.2409.1へのアップグレード後

注意以前のバージョンから上位バージョンまたは最新バージョンにアップグレードする場合は、アップグレード後のページに記載されている各中間リリースのアップグレード後の手順を確実に完了してください。ページにバージョンが表示されていない場合は、そのリリースにはアップグレード後の手順が必要ないことを意味します。

Sterling Intelligent PromisingのSearch APIとAggregation APIの両方で空の値のクエリを有効にするには、supplyとdemandのElasticsearchインデックスのインデックスを再作成する必要があります。

このタスクについて

ElasticsearchAPI リクエストは、以下のいずれかのツールを使って実行することができます：

Kibana Dev tools：Elasticsearchクラスタに対して直接 API リクエストを実行できる Kibana の組み込みツールです。
HTTP クライアント：Postman や cURL のようなツールを使用すると Elasticsearchに HTTP リクエストを送信することができます。

手順

Elasticsearchのサプライインデックスを再インデックスする手順
1. logstash-supplyサーバーのレプリカカウントを0に更新することで、'Elasticsearch供給インデックスへのデータロードを停止し、'logstash-supply StatefulSetのレプリカが完全に0にスケールダウンするまで待つ。次の例はプロダクション・モードである。
```
logstashServers:
  - active: true
    names:
      - logstash-supply
    replicaCount: 0
```
2. 'Sterling Intelligent Promising命名規則に沿ったパターンを使用して、ソース・インデックスを識別するために既存のインデックスを取得する。以下のコマンドは'supplies-<tenant_id>-*パターンに一致するインデックスを検索し、ソース・インデックスの正しい<previous_date_id>を特定できるようにします。
```
GET _cat/indices/supplies-<tenant_id>-*?v
```
  以下のサンプル出力では、「supplies-<tenant_id>-<previous_date_id>」が既存のソース・インデックスです。
```
health status index                           uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   supplies-<tenant_id>-<previous_date_id> abcdefghijklmnop 2   1          100            0      5.2mb          5.2mb
   
```
3. 該当するテナントに対して供給先Elasticsearchインデックスを作成し、適切な設定で現在の日付を'yyyy-MM-dd形式で接尾辞に付けます。
```
PUT supplies-<tenant_id>-<current_date_id>
{
  "settings": {
    "index": {
      "number_of_shards": 2,  
      "number_of_replicas": 0,
      "refresh_interval" : "-1"
    }
  }
}
```
  - <tenant_id>はデフォルトであり、SIPEnvironmentで設定される。
  - <current_date_id> の例は '2024-10-24 。
4. Elasticsearchasynchronous reindexing API を使用し、シャード数に基づいた自動スライシングで、ソースインデックスから新しく作成されたデスティネーションインデックスにデータをコピーします。
  - 次の例で定義されている<source_index>は、ステップ2で検索されたインデックスで、'supplies-<tenant_id>-<previous_date_id>である。
  - 次の例で定義されている<destination_index>は、ステップ3で作成されたインデックスで、'supplies-<tenant_id>-<current_date_id>である。
```
POST _reindex?slices=auto&wait_for_completion=false
{
  "source": {
    "index": "<source_index>"
  },
  "dest": {
    "index": "<destination_index>"
  }
}
```
  期待される反応
```
{
  "task" : "<task_id>"
}
```
5. タスクAPIを使用して、インデックス再作成タスクのステータスを監視する。
```
GET _tasks/<task_id>
```
  <task_id>の例は'5Eahw9KaTCStcX4GYoqNPA:1191199である。
  再インデックス作成タスクが完了したら、合計、更新、作成、削除、バッチ、version_conflicts、no-ops、再試行、スライスなどのタスク統計情報をチェックする。これらの統計が期待に沿ったものであることを確認し、正しい記録数と競合がないことを確認する。
6. インデックスの再作成が完了したら、リフレッシュ間隔を再度有効にし、必要なレプリカ数を設定する。
```
PUT <destination_index>/_settings
{
  "index": {
    "number_of_replicas": 1,
    "refresh_interval" : "1s"
  }
}
```
  1. データがレプリカにコピーされ、インデックスのステータスが緑色になるまで待つ。
```
GET <destination_index>/_stats
```
  2. シャードの合計、成功、失敗のステータスをチェックする。
    期待される反応
```
  "_shards" : {
    "total" : 4,
    "successful" : 2,
    "failed" : 0
  }
  ....
```
  3. ソースElasticsearchsupplies インデックスの予想レコード数を取得します。
```
GET <source_index>/_search?track_total_hits=true
```
  4. <expected_count_of_records> の値を取得する。
```
  "hits" : {
    "total" : {
      "value" : <expected_count_of_records>,
      "relation" : "eq"
    }
  }
```
  5. 出力先のElasticsearchsupplies インデックスの実際のレコード数を取得します。
```
GET <destination_index>/_search?track_total_hits=true
```
  6. <expected_count_of_records>と<actual_count_of_records>を比較する。
```
  "hits" : {
    "total" : {
      "value" : <actual_count_of_records>,
      "relation" : "eq"
    }
  }
```
7. 新しいデスティネーション・インデックスのエイリアスを更新し、古いソース・インデックスのエイリアスを削除する。以下の例の 'supplies-<tenant_id>は、Elasticsearch提供するエイリアスです。
```
POST _aliases
{
  "actions": [
    {
      "add": {
        "index": "<destination_index>",
        "alias": "supplies-<tenant_id>",
        "is_write_index": true
      }
    },
    {
      "remove": {
        "index": "<source_index>",
        "alias": "supplies-<tenant_id>"
      }
    }
  ]
}
```
  Elasticsearchsupplies エイリアスが、宛先のElasticsearchsupplies インデックスを指しているかどうかを確認します。
```
GET _alias/supplies-<tenant_id>
```
  期待される反応
```
{
  "<destination_index>" : {
    "aliases" : {
      "supplies-<tenant_id>" : {
        "is_write_index" : true
      }
    }
  }
}
```
8. 検証が完了したら、古いソース・インデックスを削除する。
```
DELETE <source_index>
```
9. Elasticsearch供給インデックスへのデータロードを開始するには、Logstash 供給サーバーのレプリカカウントを必要な数に更新し、'logstash-supply StatefulSet のレプリカが完全にスケールアップされるまで待ちます。次の例はプロダクション・モードである。
```
logstashServers:
  - active: true
    names:
      - logstash-supply
    replicaCount: 2
```
Elasticsearchdemand インデックスを再インデックスする手順
1. Elasticsearchdemand インデックスへのデータロードを停止するには、'logstash-demandサーバのレプリカカウントを 0 に更新し、'logstash-demand StatefulSetレプリカが完全にスケールダウンして 0 になるまで待ちます。次の例はプロダクション・モードである。
```
logstashServers:
  - active: true
    names:
      - logstash-demand
    replicaCount: 0
```
2. 'Sterling Intelligent Promising命名規則に沿ったパターンを使用して、ソース・インデックスを識別するために既存のインデックスを取得する。以下のコマンドは'demands-<tenant_id>-*パターンに一致するインデックスを検索し、ソース・インデックスの正しい<previous_date_id>を特定できるようにします。
```
GET _cat/indices/demands-<tenant_id>-*?v
```
  以下のサンプル出力では、「demands-<tenant_id>-<previous_date_id>」が既存のソース・インデックスです。
```
health status index                           uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   demands-<tenant_id>-<previous_date_id> abcdefghijklmnop 2   1          100            0      5.2mb          5.2mb
```
3. 該当するテナントに対して、デスティネーションElasticsearchdemandインデックスを作成し、適切な設定で現在の日付を'yyyy-MM-ddフォーマットでサフィックスします。
```
PUT demands-<tenant_id>-<current_date_id>
{
  "settings": {
    "index": {
      "number_of_shards": 2,  
      "number_of_replicas": 0,
      "refresh_interval" : "-1"
    }
  }
}
```
  - <tenant_id>はデフォルトであり、SIPEnvironmentで設定される。
  - <current_date_id> の例は '2024-10-24 。
4. Elasticsearchasynchronous reindexing API を使用し、シャード数に基づいた自動スライシングで、ソースインデックスから新しく作成されたデスティネーションインデックスにデータをコピーします。
  - 次の例で定義されている<source_index>は、ステップ2で検索されるインデックスで、'demands-<tenant_id>-<previous_date_id>である。
  - 次の例で定義されている<destination_index>は、ステップ3で作成されたもので、'demands-<tenant_id>-<current_date_id>である。
```
POST _reindex?slices=auto&wait_for_completion=false
{
  "source": {
    "index": "demands-<tenant_id>-<previous_date_id>"
  },
  "dest": {
    "index": "demands-<tenant_id>-<current_date_id>"
  }
}
```
  期待される反応
```
{
  "task" : "<task_id>"
}
```
5. タスクAPIを使用して、インデックス再作成タスクのステータスを監視する。
```
GET _tasks/<task_id>
```
  <task_id>の例は'5Eahw9KaTCStcX4GYoqNPA:1191199である。
  再インデックス作成タスクが完了したら、合計、更新、作成、削除、バッチ、version_conflicts、no-ops、再試行、スライスなどのタスク統計情報をチェックする。これらの統計が期待に沿ったものであることを確認し、正しい記録数と競合がないことを確認する。
6. インデックスの再作成が完了したら、リフレッシュ間隔を再度有効にし、希望のレプリカ数を設定する。
```
PUT demands-<tenant_id>-<current_date_id>/_settings
{
  "index": {
    "number_of_replicas": 1,
    "refresh_interval" : "1s"
  }
}
```
  1. データがレプリカにコピーされ、インデックスのステータスが緑色になるまで待つ。
```
GET demands-<tenant_id>-<current_date_id>/_stats
```
  2. シャードの合計、成功、失敗のステータスをチェックする。
    期待される反応
```
  "_shards" : {
    "total" : 4,
    "successful" : 2,
    "failed" : 0
  }
  ....
```
  3. ソースElasticsearchdemand インデックスの予想レコード数を取得します。
```
GET <source_index>/_search?track_total_hits=true
```
  4. <expected_count_of_records> の値を取得する。
```
  "hits" : {
    "total" : {
      "value" : <expected_count_of_records>,
      "relation" : "eq"
    }
  }
```
  5. 出力先のElasticsearchdemand インデックスの実際のレコード数を取得します：
```
GET <destination_index>/_search?track_total_hits=true
```
  6. <expected_count_of_records>と<actual_count_of_records>を比較する。
```
  "hits" : {
    "total" : {
      "value" : <actual_count_of_records>,
      "relation" : "eq"
    }
  }
```
7. 新しいデスティネーション・インデックスのエイリアスを更新し、古いソース・インデックスのエイリアスを削除する。以下の例の 'demand-<tenant_id>はElasticsearchのデマンドエイリアスです。
```
POST _aliases
{
  "actions": [
    {
      "add": {
        "index": "<destination_index>",
        "alias": "demands-<tenant_id>",
        "is_write_index": true
      }
    },
    {
      "remove": {
        "index": "<source_index>",
        "alias": "demands-<tenant_id>"
      }
    }
  ]
}
```
  Elasticsearchdemands エイリアスが宛先のElasticsearchdemands インデックスを指しているかどうかを確認します。
```
GET _alias/supplies-<tenant_id>
```
  期待される反応
```
{
  "demands-<tenant_id>-<current_date_id>" : {
    "aliases" : {
      "demands-<tenant_id>" : {
        "is_write_index" : true
      }
    }
  }
}
```
8. 検証が完了したら、古いソース・インデックスを削除する。
```
DELETE <source_index>
```
9. Elasticsearchのデマンドインデックスにデータのロードを開始するには、Logstash のデマンドサーバーのレプリカカウントを希望の数に更新し、'logstash-demand StatefulSetレプリカが完全にスケールアップされるまで待ちます。次の例はプロダクション・モードである。
```
logstashServers:
  - active: true
    names:
      - logstash-demand
    replicaCount: 2
```
Inventory Visibilityと Rules サービス間のルールの同期を効果的に行うための手順。以下の手順は、'Sterling Intelligent Promisingがプロダクションモードまたはフレキシブルモードでデプロイされている場合にのみ適用されます。したがって、開発モードでは何もする必要はない。
1. SIPEnvironmentカスタムリソースの'serverPropertiesに'RULES_TRIGGER_TOPIC環境変数を追加する。この環境変数の値は、既存のconfigMapから読み込まれる。したがって、以下の例に示すように、既存のconfigMapで使用されているのと同じconfigMap値を使用する。
```
  serverProperties:
    envVars:
      - groupName: ruletriggertopic
        propertyRef:
          - name: RULES_TRIGGER_TOPIC
            valueFrom:
              configMapKeyRef:
                key: rules-trigger-topic
                name: iv-kafka-configs
```
2. ステップ1で設定した変更を保存します。
3. IVServiceGroupの'property下に'ruletriggertopic'groupNameを設定し、カスタムリソースを保存する。このステップは、RulesTriggerConsumerバックエンドサーバーが'RULES_TRIGGER_TOPIC環境変数を使用することを確認するのに役立つ。
```
- active: true
  names:
    - 'RulesTriggerConsumer:5'
  property:
    envVars: ruletriggertopic
```
  RulesTriggerConsumerポッドが再起動しました。
4. RulesTriggerConsumerポッドにエラーがないことを確認して、先に進みます。