Introducing safeguards to Jira index

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

プラットフォームについて: サーバーと Data Center のみ。この記事は、サーバーおよび Data Center プラットフォームのアトラシアン製品にのみ適用されます。

課題関連のエンティティのインデックス作成を改善

Check What's changed in Jira after the implementation of indexing limits for common questions related to indexing limits and differences in the way Jira works since the update. 

JRASERVER-73874 - 課題詳細を取得中... ステータス

Starting from 8.22.2 (backported to 8.20.12), Jira will index only topN (can be set to 500, 1000, or 10_000) of the following issue-related entities: comments, changehistory, and worklog. Any reindexing operation that triggers full issue reindex, including full foreground reindex and indexer#reindex(issue, all), will reindex a limited number of topN of related entities.

This feature is enabled by default with a limit set to 1000 related entities (comments, changehistory, and worklog). However, based on specific use cases, Jira admins can change default topN values for these entities by setting a system property to the desired limit. System property names for issue entities:

  • For comments: jira.safeguards.indexing.issue.comments
  • For change history items: jira.safeguards.indexing.issue.changelogs
  • For worklogs: jira.safeguards.indexing.issue.worklogs

It’s also possible to disable the feature by setting the corresponding system property to -1.

tip/resting Created with Sketch.

As part of the feature, we’ve added stats to help you gather information around the indexing of issue-related entities. You can find more details here: Jira indexing-limits stats.

Introducing limits to change items indexing 

Jira 8.22.3 also introduces updates to the way indexing works. In this release, we’ve extended the functionality of Safeguards in Jira index that changes the default behavior of change items indexing.

Change items with unsupported fields will be filtered out before they’re collected into change groups. As a result, when there’s a group of change items with unsupported fields only, it won’t be indexed. So, no document will be created for it in the database.

The feature is enabled by default with the limit of six fields in the change items index:

  • Assignee
  • Fix Version
  • Priority
  • Reporter
  • Resolution
  • Status

In specific use cases, Jira administrators can change the default behavior. For example, when there’s a need to use the UpdatedBy JQL function, Jira administrator can configure the following system property: jira.safeguards.indexing.issue.changelogs.do.not.filter.out.unsupported.fields.

Consider the following:

  • If this system property isn’t set up, change items with unsupported fields will be filtered out. This is the default behavior.
  • If this system property is set to "true", unsupported fields won’t be filtered out.
  • The number of indexed change groups will be limited to DEFAULT_INDEXING_LIMIT.
  • To enable the old search functionality for historical changes, use the mentioned system property along with jira.safeguards.indexing.issue.changelogs (it defines how many groups should be indexed).  

If unsupported fields aren’t filtered out, this may cause performance degradation for large issues. You can identify issues with large change items and change groups by running a database query. For details, see Retrieve issue change history from database in Jira server

最終更新日: 2022 年 12 月 6 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.