Move and update Database Load Balancing docs

doc/administration/index.md

@@ -31,8 +31,6 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 ### Installing GitLab
 
 - [Install](../install/index.md): Requirements, directory structures, and installation methods.
-  - [Database load balancing](database_load_balancing.md): Distribute database queries among multiple database servers.
-  - [Omnibus support for log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-shipping-gitlab-enterprise-edition-only).
 - [Reference architectures](reference_architectures/index.md): Add additional resources to support more users.
   - [Installing GitLab on Amazon Web Services (AWS)](../install/aws/index.md): Set up GitLab on Amazon AWS.
 - [Geo](geo/index.md): Replicate your GitLab instance to other geographic locations as a read-only fully operational version.
@@ -79,6 +77,8 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 - [Enabling and disabling features flags](feature_flags.md): how to enable and
   disable GitLab features deployed behind feature flags.
 - [Application settings cache expiry interval](application_settings_cache.md)
+- [Database Load Balancing](postgresql/database_load_balancing.md): Distribute database queries among multiple database servers.
+- [Omnibus support for log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-shipping-gitlab-enterprise-edition-only).
 
 #### Customizing GitLab appearance
 

doc/administration/logs.md

@@ -830,7 +830,7 @@ are generated in a location based on your installation method:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/15442) in GitLab 12.3.
 
-Contains details of GitLab [Database Load Balancing](database_load_balancing.md).
+Contains details of GitLab [Database Load Balancing](postgresql/database_load_balancing.md).
 Depending on your installation method, this file is located at:
 
 - Omnibus GitLab: `/var/log/gitlab/gitlab-rails/database_load_balancing.log`

doc/administration/monitoring/performance/performance_bar.md

@@ -26,11 +26,10 @@ From left to right, the performance bar displays:
   details for each query:
   - **In a transaction**: shows up below the query if it was executed in
     the context of a transaction
-  - **Role**: shows up when [database load
-    balancing](../../database_load_balancing.md) is enabled. It shows
-    which server role was used for the query. "Primary" means that the query
-    was sent to the read/write primary server. "Replica" means it was sent
-    to a read-only replica.
+  - **Role**: shows up when [Database Load Balancing](../../postgresql/database_load_balancing.md)
+    is enabled. It shows which server role was used for the query.
+    "Primary" means that the query was sent to the read/write primary server.
+    "Replica" means it was sent to a read-only replica.
   - **Config name**: shows up only when the
     `GITLAB_MULTIPLE_DATABASE_METRICS` environment variable is set. This is
     used to distinguish between different databases configured for different

doc/development/licensed_feature_availability.md

@@ -29,7 +29,7 @@ project.feature_available?(:feature_symbol)
 ## Restricting global features (instance)
 
 However, for features such as [Geo](../administration/geo/index.md) and
-[Load balancing](../administration/database_load_balancing.md), which cannot be restricted
+[Database Load Balancing](../administration/postgresql/database_load_balancing.md), which cannot be restricted
 to only a subset of projects or namespaces, the check is made directly in
 the instance license.
 

doc/development/merge_request_performance_guidelines.md

@@ -160,10 +160,10 @@ query. This in turn makes it much harder for this code to overload a database.
 
 ## Use read replicas when possible
 
-In a DB cluster we have many read replicas and one primary. A classic use of scaling the DB is to have read-only actions be performed by the replicas. We use [load balancing](../administration/database_load_balancing.md) to distribute this load. This allows for the replicas to grow as the pressure on the DB grows.
+In a DB cluster we have many read replicas and one primary. A classic use of scaling the DB is to have read-only actions be performed by the replicas. We use [load balancing](../administration/postgresql/database_load_balancing.md) to distribute this load. This allows for the replicas to grow as the pressure on the DB grows.
 
 By default, queries use read-only replicas, but due to
-[primary sticking](../administration/database_load_balancing.md#primary-sticking), GitLab uses the
+[primary sticking](../administration/postgresql/database_load_balancing.md#primary-sticking), GitLab uses the
 primary for some time and reverts to secondaries after they have either caught up or after 30 seconds.
 Doing this can lead to a considerable amount of unnecessary load on the primary.
 To prevent switching to the primary [merge request 56849](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56849) introduced the
@@ -187,7 +187,7 @@ Internally, our database load balancer classifies the queries based on their mai
 - Sidekiq background jobs
 
 After the above queries are executed, GitLab
-[sticks to the primary](../administration/database_load_balancing.md#primary-sticking).
+[sticks to the primary](../administration/postgresql/database_load_balancing.md#primary-sticking).
 To make the inside queries prefer using the replicas,
 [merge request 59086](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/59086) introduced
 `fallback_to_replicas_for_ambiguous_queries`. This MR is also an example of how we redirected a

doc/development/scalability.md

@@ -123,8 +123,7 @@ the read replicas. [Omnibus ships with Patroni](../administration/postgresql/rep
 
 #### Load-balancing
 
-GitLab EE has [application support for load balancing using read
-replicas](../administration/database_load_balancing.md). This load balancer does
+GitLab EE has [application support for load balancing using read replicas](../administration/postgresql/database_load_balancing.md). This load balancer does
 some actions that aren't traditionally available in standard load balancers. For
 example, the application considers a replica only if its replication lag is low
 (for example, WAL data behind by less than 100 MB).

doc/development/sidekiq_style_guide.md

@@ -574,7 +574,7 @@ of reading a stale record is non-zero due to replicas potentially lagging behind
 
 When the number of jobs that rely on the database increases, ensuring immediate data consistency
 can put unsustainable load on the primary database server. We therefore added the ability to use
-[database load balancing for Sidekiq workers](../administration/database_load_balancing.md#load-balancing-for-sidekiq).
+[Database Load Balancing for Sidekiq workers](../administration/postgresql/database_load_balancing.md).
 By configuring a worker's `data_consistency` field, we can then allow the scheduler to target read replicas
 under several strategies outlined below.