diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2023-09-20 14:18:08 +0300 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2023-09-20 14:18:08 +0300 |
| commit | 5afcbe03ead9ada87621888a31a62652b10a7e4f (patch) | |
| tree | 9918b67a0d0f0bafa6542e839a8be37adf73102d /doc/administration/postgresql | |
| parent | c97c0201564848c1f53226fe19d71fdcc472f7d0 (diff) | |
Add latest changes from gitlab-org/gitlab@16-4-stable-eev16.4.0-rc42
Diffstat (limited to 'doc/administration/postgresql')
| -rw-r--r-- | doc/administration/postgresql/database_load_balancing.md | 6 | ||||
| -rw-r--r-- | doc/administration/postgresql/replication_and_failover.md | 2 |
2 files changed, 4 insertions, 4 deletions
diff --git a/doc/administration/postgresql/database_load_balancing.md b/doc/administration/postgresql/database_load_balancing.md index f8b6be1fb21..d640dbe9341 100644 --- a/doc/administration/postgresql/database_load_balancing.md +++ b/doc/administration/postgresql/database_load_balancing.md @@ -182,9 +182,9 @@ To configure these options with a hosts list, use the following example: ```ruby gitlab_rails['db_load_balancing'] = { - 'hosts' => ['primary.example.com', 'secondary1.example.com', 'secondary2.example.com'] - 'max_replication_difference' => 16777216 # 16 MB - 'max_replication_lag_time' => 30 + 'hosts' => ['primary.example.com', 'secondary1.example.com', 'secondary2.example.com'], + 'max_replication_difference' => 16777216, # 16 MB + 'max_replication_lag_time' => 30, 'replica_check_interval' => 30 } ``` diff --git a/doc/administration/postgresql/replication_and_failover.md b/doc/administration/postgresql/replication_and_failover.md index c547e5c3638..a1fc8c49ee3 100644 --- a/doc/administration/postgresql/replication_and_failover.md +++ b/doc/administration/postgresql/replication_and_failover.md @@ -1086,7 +1086,7 @@ Reverting the PostgreSQL upgrade with `gitlab-ctl revert-pg-upgrade` has the sam `gitlab-ctl pg-upgrade`. You should follow the same procedure by first stopping the replicas, then reverting the leader, and finally reverting the replicas. -### Near zero downtime upgrade of PostgreSQL in a Patroni cluster (Experimental) +### Near zero downtime upgrade of PostgreSQL in a Patroni cluster **(EXPERIMENT)** Patroni enables you to run a major PostgreSQL upgrade without shutting down the cluster. However, this requires additional resources to host the new Patroni nodes with the upgraded PostgreSQL. In practice, with this |