diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/administration/geo/replication/multiple_servers.md | 28 | ||||
| -rw-r--r-- | doc/administration/geo/replication/troubleshooting.md | 2 | ||||
| -rw-r--r-- | doc/administration/geo/setup/database.md | 2 | ||||
| -rw-r--r-- | doc/development/database/index.md | 10 | ||||
| -rw-r--r-- | doc/development/database/partitioning/int_range.md | 2 | ||||
| -rw-r--r-- | doc/update/index.md | 4 | ||||
| -rw-r--r-- | doc/user/project/repository/git_blame.md | 6 |
7 files changed, 37 insertions, 17 deletions
diff --git a/doc/administration/geo/replication/multiple_servers.md b/doc/administration/geo/replication/multiple_servers.md index 850ab9f0707..9298281561f 100644 --- a/doc/administration/geo/replication/multiple_servers.md +++ b/doc/administration/geo/replication/multiple_servers.md @@ -61,6 +61,9 @@ The following steps enable a GitLab site to serve as the Geo **primary** site. ### Step 1: Configure the **primary** frontend nodes +NOTE: +Avoid using [`geo_primary_role`](https://docs.gitlab.com/omnibus/roles/#gitlab-geo-roles) because it is intended for a single-node site. + 1. Edit `/etc/gitlab/gitlab.rb` and add the following: ```ruby @@ -126,14 +129,7 @@ NOTE: [NFS](../../nfs.md) can be used in place of Gitaly but is not recommended. -### Step 2: Configure PostgreSQL streaming replication - -Follow the [Geo database replication instructions](../setup/database.md). - -If using an external PostgreSQL instance, refer also to -[Geo with external PostgreSQL instances](../setup/external_database.md). - -### Step 3: Configure the Geo tracking database on the Geo **secondary** site +### Step 2: Configure the Geo tracking database on the Geo **secondary** site If you want to run the Geo tracking database in a multi-node PostgreSQL cluster, then follow [Configuring Patroni cluster for the tracking PostgreSQL database](../setup/database.md#configuring-patroni-cluster-for-the-tracking-postgresql-database). @@ -183,8 +179,20 @@ After making these changes, [reconfigure GitLab](../../restart_gitlab.md#reconfi If using an external PostgreSQL instance, refer also to [Geo with external PostgreSQL instances](../setup/external_database.md). +### Step 3: Configure PostgreSQL streaming replication + +Follow the [Geo database replication instructions](../setup/database.md). + +If using an external PostgreSQL instance, refer also to +[Geo with external PostgreSQL instances](../setup/external_database.md). + +After streaming replication is enabled in the secondary Geo site's read-replica database, then commands such as `gitlab-rake db:migrate:status:geo` will fail, until [configuration of the secondary site is complete](#step-7-copy-secrets-and-add-the-secondary-site-in-the-application), specifically [Geo configuration - Step 3. Add the secondary site](configuration.md#step-3-add-the-secondary-site). + ### Step 4: Configure the frontend application nodes on the Geo **secondary** site +NOTE: +Avoid using [`geo_secondary_role`](https://docs.gitlab.com/omnibus/roles/#gitlab-geo-roles) because it is intended for a single-node site. + In the minimal [architecture diagram](#architecture-overview) above, there are two machines running the GitLab application services. These services are enabled selectively in the configuration. @@ -364,3 +372,7 @@ application nodes above, with some changes to run only the `sidekiq` service: `sidekiq['enable'] = false`. These nodes do not need to be attached to the load balancer. + +### Step 7: Copy secrets and add the secondary site in the application + +1. [Configure GitLab](configuration.md) to set the **primary** and **secondary** sites. diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md index 6e60ae34a22..39fa04103db 100644 --- a/doc/administration/geo/replication/troubleshooting.md +++ b/doc/administration/geo/replication/troubleshooting.md @@ -337,7 +337,7 @@ sudo gitlab-rake gitlab:geo:check ``` - If you are running the secondary site on a single node for all services, then follow [Geo database replication - Configure the secondary server](../setup/database.md#step-2-configure-the-secondary-server). - - If you are running the secondary site's tracking database on its own node, then follow [Geo for multiple servers - Configure the Geo tracking database on the Geo secondary site](multiple_servers.md#step-3-configure-the-geo-tracking-database-on-the-geo-secondary-site) + - If you are running the secondary site's tracking database on its own node, then follow [Geo for multiple servers - Configure the Geo tracking database on the Geo secondary site](multiple_servers.md#step-2-configure-the-geo-tracking-database-on-the-geo-secondary-site) - If you are running the secondary site's tracking database in a Patroni cluster, then follow [Geo database replication - Configure the tracking database on the secondary sites](../setup/database.md#step-3-configure-the-tracking-database-on-the-secondary-sites) - If you are running the secondary site's tracking database in an external database, then follow [Geo with external PostgreSQL instances](../setup/external_database.md#configure-the-tracking-database) - If the Geo check task was run on a node which is not running a service which runs the GitLab Rails app (Puma, Sidekiq, or Geo Log Cursor), then this error can be ignored. The node does not need Rails to be configured. diff --git a/doc/administration/geo/setup/database.md b/doc/administration/geo/setup/database.md index b9c2a69eaf7..a9238a4142a 100644 --- a/doc/administration/geo/setup/database.md +++ b/doc/administration/geo/setup/database.md @@ -950,7 +950,7 @@ The Linux package automatically configures a tracking database when `roles(['geo If you want to run this database in a highly available configuration, don't use the `geo_secondary_role` above. Instead, follow the instructions below. -If you want to run the Geo tracking database on a single node, see [Configure the Geo tracking database on the Geo secondary site](../replication/multiple_servers.md#step-3-configure-the-geo-tracking-database-on-the-geo-secondary-site). +If you want to run the Geo tracking database on a single node, see [Configure the Geo tracking database on the Geo secondary site](../replication/multiple_servers.md#step-2-configure-the-geo-tracking-database-on-the-geo-secondary-site). A production-ready and secure setup for the tracking PostgreSQL DB requires at least three Consul nodes: two Patroni nodes, and one PgBouncer node on the secondary site. diff --git a/doc/development/database/index.md b/doc/development/database/index.md index c5969176d72..d014164c3ba 100644 --- a/doc/development/database/index.md +++ b/doc/development/database/index.md @@ -34,7 +34,7 @@ info: Any user with at least the Maintainer role can merge updates to this conte - [Different types of migrations](../migration_style_guide.md#choose-an-appropriate-migration-type) - [Migrations for multiple databases](migrations_for_multiple_databases.md) - [Migrations style guide](../migration_style_guide.md) for creating safe SQL migrations -- [Partitioning tables](table_partitioning.md) +- [Partitioning tables](partitioning/index.md) - [Post-deployment migrations guidelines](post_deployment_migrations.md) and [how to create one](post_deployment_migrations.md#creating-migrations) - [Running database migrations](database_debugging.md#migration-wrangling) - [SQL guidelines](../sql.md) for working with SQL queries @@ -42,6 +42,14 @@ info: Any user with at least the Maintainer role can merge updates to this conte - [Testing Rails migrations](../testing_guide/testing_migrations_guide.md) guide - [When and how to write Rails migrations tests](../testing_guide/testing_migrations_guide.md) +## Partitioning tables + +- [Overview](partitioning/index.md) +- [Date range](partitioning/date_range.md) +- [Hash](partitioning/hash.md) +- [Int range](partitioning/int_range.md) +- [List](partitioning/list.md) + ## Debugging - [Accessing the database](database_debugging.md#manually-access-the-database) diff --git a/doc/development/database/partitioning/int_range.md b/doc/development/database/partitioning/int_range.md index 7fbdd4da865..7556d40b46e 100644 --- a/doc/development/database/partitioning/int_range.md +++ b/doc/development/database/partitioning/int_range.md @@ -10,7 +10,7 @@ info: Any user with at least the Maintainer role can merge updates to this conte ## Description -Int range partition is a technique for dividing a large table into smaller, +Int range partitioning is a technique for dividing a large table into smaller, more manageable chunks based on an integer column. This can be particularly useful for tables with large numbers of rows, as it can significantly improve query performance, reduce storage requirements, and simplify maintenance tasks. diff --git a/doc/update/index.md b/doc/update/index.md index 9192d409d55..77e5a2e5130 100644 --- a/doc/update/index.md +++ b/doc/update/index.md @@ -218,9 +218,7 @@ crucial database schema and migration patches may be included in the latest patc Required upgrade stops are versions of GitLab that you must upgrade to before upgrading to later versions. Required upgrade stops allow required background migrations to finish. -During GitLab 16.x, we are scheduling required upgrade stops beforehand so users can better plan out appropriate upgrade stops and downtime when necessary. - -The first scheduled required upgrade stop has been announced for 16.3.x. When planning upgrades, take this into account. +During GitLab 16.x, we are scheduling required upgrade stops beforehand so you can better plan out appropriate upgrade stops and downtime when necessary. When planning upgrades, take this into account. ### Earlier GitLab versions diff --git a/doc/user/project/repository/git_blame.md b/doc/user/project/repository/git_blame.md index 7f333ec7b7f..ddf0d65bd0b 100644 --- a/doc/user/project/repository/git_blame.md +++ b/doc/user/project/repository/git_blame.md @@ -36,14 +36,16 @@ changes to light gray. ### View blame directly in the file view <!-- -When feature flags `graphql_git_blame` and `highlight_js_worker` are removed, +When `graphql_git_blame` feature flag is removed, delete this section and update the steps in "View blame for a file". --> -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/430950) in GitLab 16.7 [with flags](../../../administration/feature_flags.md) named `graphql_git_blame` and `highlight_js_worker`. Enabled by default. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/430950) in GitLab 16.7 [with flags](../../../administration/feature_flags.md) named `graphql_git_blame` and `highlight_js_worker`. Enabled by default. +> - Feature flag `highlight_js_worker` [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/432706) in GitLab 16.9. FLAG: On self-managed GitLab, by default this feature is available. +To hide the feature, an administrator can [disable the feature flag](../../../administration/feature_flags.md) named `graphql_git_blame`. On GitLab.com, this feature is available. When this feature is enabled, you can additionally view blame for a file directly from the file page. |