Skip to content

repo sync #20349

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Octomerger merged 2 commits into from
Sep 1, 2022
Merged

repo sync #20349

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a381f88
Darthwillis/index management (#30431)
darthwillis Sep 1, 2022
943606c
Merge branch 'main' into repo-sync
Octomerger Sep 1, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 27 additions & 24 deletions content/admin/configuration/configuring-your-enterprise/site-admin-dashboard.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -131,46 +131,49 @@ Key | Description
{% ifversion ghes %}
## Indexing

GitHub's [code search][] features are powered by [ElasticSearch][]. This section of the site admin dashboard shows you the current status of your ElasticSearch cluster and provides you with several tools to control the behavior of searching and indexing. These tools are split into the following three categories.
GitHub's search features are powered by Elasticsearch. This section of the site admin dashboard shows you the current status of your Elasticsearch cluster and provides you with several tools to control search and index behavior.

[Code Search]: https://github.com/blog/1381-a-whole-new-code-search
[ElasticSearch]: http://www.elasticsearch.org/
For more information about code search, see "[Searching for information on {% data variables.product.prodname_dotcom %}](/search-github)." For more information about Elasticsearch, see the [Elasticsearch website](https://elastic.co).

### Code search
{% note %}

This allows you to enable or disable both search and index operations on source code.
**Note**: In normal use, site administrators do not need to create new indices or schedule repair jobs. For troubleshooting or other support purposes, {% data variables.contact.github_support %} may instruct you to run a repair job.

### Code search index repair
{% endnote %}

This controls how the code search index is repaired. You can
### Index management

- enable or disable index repair jobs
- start a new index repair job
- reset all index repair state
{% data variables.product.product_name %} reconciles the state of the search index with data on the instance automatically and regularly.

{% data variables.product.prodname_enterprise %} uses repair jobs to reconcile the state of the search index with data stored in a database (issues, pull requests, repositories, and users) and data stored in Git repositories (source code). This happens when
- Issues, pull requests, repositories, and users in the database
- Git repositories (source code) on disk

- a new search index is created;
- missing data needs to be backfilled; or
- old search data needs to be updated.
Your instance uses repair jobs to reconcile the data, and schedules a repair job in the background when the following events occur.

In other words, repair jobs are started as needed and run in the background鈥攖hey are not scheduled by site admins in any way.
- A new search index is created.
- Missing data needs to be backfilled.
- Old search data needs to be updated.

Furthermore, repair jobs use a "repair offset" for parallelization. This is an offset into the database table for the record being reconciled. Multiple background jobs can synchronize work based on this offset.
You can create a new index, or you can click on an existing index in the list to manage the index. You can perform the following operations on an index.

A progress bar shows the current status of a repair job across all of its background workers. It is the percentage difference of the repair offset with the highest record ID in the database. Don't worry about the value shown in the progress bar after a repair job has completed: because it shows the difference between the repair offset and the highest record ID in the database, it will decrease as more repositories are added to {% data variables.product.product_location %} even though those repositories are actually indexed.
- Make the index searchable.
- Make the index writable.
- Update the index.
- Delete the index
- Reset the index repair state.
- Start a new index repair job.
- Enable or disable index repair jobs.

You can start a new code-search index repair job at any time. It will use a single CPU as it reconciles the search index with database and Git repository data. To minimize the effects this will have on I/O performance and reduce the chances of operations timing out, try to run a repair job during off-peak hours first. Monitor your system's load averages and CPU usage with a utility like `top`; if you don't notice any significant changes, it should be safe to run an index repair job during peak hours, as well.
A progress bar shows the current status of a repair job across background workers. The bar is the percentage difference of the repair offset with the highest record ID in the database. You can ignore the value shown in the progress bar after a repair job has completed. The progress bar shows the difference between the repair offset and the highest record ID in the database, and will decrease as more repositories are added to {% data variables.product.product_location %} even though those repositories are actually indexed.

### Issues index repair
To minimize the effects on I/O performance and reduce the chances of operations timing out, run the repair job during off-peak hours. As the job reconciles the search index with database and Git repository data, one CPU will be used. Monitor your system's load averages and CPU usage with a utility like `top`. If you don't notice any significant increase in resource consumption, it should also be safe to run an index repair job during peak hours.

This controls how the [Issues][] index is repaired. You can
Repair jobs use a "repair offset" for parallelization. This is an offset into the database table for the record being reconciled. Multiple background jobs can synchronize work based on this offset.

[Issues]: https://github.com/blog/831-issues-2-0-the-next-generation
### Code search

This allows you to enable or disable both search and index operations on source code.

- enable or disable index repair jobs
- start a new index repair job
- reset all index repair state
{% endif %}
## Reserved logins

Expand Down