Commit c71688db authored by Amy Qualls's avatar Amy Qualls

Merge branch 'selhorn-note-that-3' into 'master'

Docs: removed 'note that' phrase

See merge request gitlab-org/gitlab!67076
parents 1f56f09a 4d4ef58b
...@@ -161,7 +161,7 @@ If the **primary** and **secondary** nodes have a checksum verification mismatch ...@@ -161,7 +161,7 @@ If the **primary** and **secondary** nodes have a checksum verification mismatch
![Project administration page](img/checksum-differences-admin-project-page.png) ![Project administration page](img/checksum-differences-admin-project-page.png)
1. Go to the project's repository directory on both **primary** and **secondary** nodes 1. Go to the project's repository directory on both **primary** and **secondary** nodes
(the path is usually `/var/opt/gitlab/git-data/repositories`). Note that if `git_data_dirs` (the path is usually `/var/opt/gitlab/git-data/repositories`). If `git_data_dirs`
is customized, check the directory layout on your server to be sure: is customized, check the directory layout on your server to be sure:
```shell ```shell
......
...@@ -94,7 +94,7 @@ follow these steps to avoid unnecessary data loss: ...@@ -94,7 +94,7 @@ follow these steps to avoid unnecessary data loss:
1. Until a [read-only mode](https://gitlab.com/gitlab-org/gitlab/-/issues/14609) 1. Until a [read-only mode](https://gitlab.com/gitlab-org/gitlab/-/issues/14609)
is implemented, updates must be prevented from happening manually to the is implemented, updates must be prevented from happening manually to the
**primary**. Note that your **secondary** node still needs read-only **primary**. Your **secondary** node still needs read-only
access to the **primary** node during the maintenance window: access to the **primary** node during the maintenance window:
1. At the scheduled time, using your cloud provider or your node's firewall, block 1. At the scheduled time, using your cloud provider or your node's firewall, block
......
...@@ -79,7 +79,7 @@ follow these steps to avoid unnecessary data loss: ...@@ -79,7 +79,7 @@ follow these steps to avoid unnecessary data loss:
1. Until a [read-only mode](https://gitlab.com/gitlab-org/gitlab/-/issues/14609) 1. Until a [read-only mode](https://gitlab.com/gitlab-org/gitlab/-/issues/14609)
is implemented, updates must be prevented from happening manually to the is implemented, updates must be prevented from happening manually to the
**primary**. Note that your **secondary** node still needs read-only **primary**. Your **secondary** node still needs read-only
access to the **primary** node during the maintenance window: access to the **primary** node during the maintenance window:
1. At the scheduled time, using your cloud provider or your node's firewall, block 1. At the scheduled time, using your cloud provider or your node's firewall, block
......
...@@ -101,12 +101,12 @@ From the perspective of a user performing Git operations: ...@@ -101,12 +101,12 @@ From the perspective of a user performing Git operations:
- The **primary** site behaves as a full read-write GitLab instance. - The **primary** site behaves as a full read-write GitLab instance.
- **Secondary** sites are read-only but proxy Git push operations to the **primary** site. This makes **secondary** sites appear to support push operations themselves. - **Secondary** sites are read-only but proxy Git push operations to the **primary** site. This makes **secondary** sites appear to support push operations themselves.
To simplify the diagram, some necessary components are omitted. Note that: To simplify the diagram, some necessary components are omitted.
- Git over SSH requires [`gitlab-shell`](https://gitlab.com/gitlab-org/gitlab-shell) and OpenSSH. - Git over SSH requires [`gitlab-shell`](https://gitlab.com/gitlab-org/gitlab-shell) and OpenSSH.
- Git over HTTPS required [`gitlab-workhorse`](https://gitlab.com/gitlab-org/gitlab-workhorse). - Git over HTTPS required [`gitlab-workhorse`](https://gitlab.com/gitlab-org/gitlab-workhorse).
Note that a **secondary** site needs two different PostgreSQL databases: A **secondary** site needs two different PostgreSQL databases:
- A read-only database instance that streams data from the main GitLab database. - A read-only database instance that streams data from the main GitLab database.
- [Another database instance](#geo-tracking-database) used internally by the **secondary** site to record what data has been replicated. - [Another database instance](#geo-tracking-database) used internally by the **secondary** site to record what data has been replicated.
......
...@@ -286,9 +286,9 @@ The two most obvious issues that can become apparent in the dashboard are: ...@@ -286,9 +286,9 @@ The two most obvious issues that can become apparent in the dashboard are:
- You are using a custom certificate or custom CA (see the [troubleshooting document](troubleshooting.md)). - You are using a custom certificate or custom CA (see the [troubleshooting document](troubleshooting.md)).
- The instance is firewalled (check your firewall rules). - The instance is firewalled (check your firewall rules).
Please note that disabling a **secondary** site stops the synchronization process. Disabling a **secondary** site stops the synchronization process.
Please note that if `git_data_dirs` is customized on the **primary** site for multiple If `git_data_dirs` is customized on the **primary** site for multiple
repository shards you must duplicate the same configuration on each **secondary** site. repository shards you must duplicate the same configuration on each **secondary** site.
Point your users to the [Using a Geo Site guide](usage.md). Point your users to the [Using a Geo Site guide](usage.md).
......
...@@ -204,7 +204,7 @@ successfully, you must replicate their data using some other means. ...@@ -204,7 +204,7 @@ successfully, you must replicate their data using some other means.
|[Server-side Git hooks](../../server_hooks.md) | [No](https://gitlab.com/groups/gitlab-org/-/epics/1867) | No | No | | |[Server-side Git hooks](../../server_hooks.md) | [No](https://gitlab.com/groups/gitlab-org/-/epics/1867) | No | No | |
|[Elasticsearch integration](../../../integration/elasticsearch.md) | [No](https://gitlab.com/gitlab-org/gitlab/-/issues/1186) | No | No | | |[Elasticsearch integration](../../../integration/elasticsearch.md) | [No](https://gitlab.com/gitlab-org/gitlab/-/issues/1186) | No | No | |
|[GitLab Pages](../../pages/index.md) | [No](https://gitlab.com/groups/gitlab-org/-/epics/589) | No | Via Object Storage provider if supported. **No** native Geo support (Beta). | | |[GitLab Pages](../../pages/index.md) | [No](https://gitlab.com/groups/gitlab-org/-/epics/589) | No | Via Object Storage provider if supported. **No** native Geo support (Beta). | |
|[Dependency proxy images](../../../user/packages/dependency_proxy/index.md) | [No](https://gitlab.com/gitlab-org/gitlab/-/issues/259694) | No | No | Blocked on [Geo: Secondary Mimicry](https://gitlab.com/groups/gitlab-org/-/epics/1528). Note that replication of this cache is not needed for Disaster Recovery purposes because it can be recreated from external sources. | |[Dependency proxy images](../../../user/packages/dependency_proxy/index.md) | [No](https://gitlab.com/gitlab-org/gitlab/-/issues/259694) | No | No | Blocked on [Geo: Secondary Mimicry](https://gitlab.com/groups/gitlab-org/-/epics/1528). Replication of this cache is not needed for Disaster Recovery purposes because it can be recreated from external sources. |
|[Vulnerability Export](../../../user/application_security/vulnerability_report/#export-vulnerability-details) | [Not planned](https://gitlab.com/groups/gitlab-org/-/epics/3111) | No | | Not planned because they are ephemeral and sensitive. They can be regenerated on demand. | |[Vulnerability Export](../../../user/application_security/vulnerability_report/#export-vulnerability-details) | [Not planned](https://gitlab.com/groups/gitlab-org/-/epics/3111) | No | | Not planned because they are ephemeral and sensitive. They can be regenerated on demand. |
#### Limitation of verification for files in Object Storage #### Limitation of verification for files in Object Storage
......
...@@ -154,7 +154,7 @@ the **primary** database. Use the following as a guide. ...@@ -154,7 +154,7 @@ the **primary** database. Use the following as a guide.
1. Generate an MD5 hash of the desired password for the database user that the 1. Generate an MD5 hash of the desired password for the database user that the
GitLab application uses to access the read-replica database: GitLab application uses to access the read-replica database:
Note that the username (`gitlab` by default) is incorporated into the hash. The username (`gitlab` by default) is incorporated into the hash.
```shell ```shell
gitlab-ctl pg-password-md5 gitlab gitlab-ctl pg-password-md5 gitlab
...@@ -203,7 +203,7 @@ the **primary** database. Use the following as a guide. ...@@ -203,7 +203,7 @@ the **primary** database. Use the following as a guide.
geo_postgresql['enable'] = false geo_postgresql['enable'] = false
## ##
## Disable all other services that aren't needed. Note that we had to enable ## Disable all other services that aren't needed. We had to enable
## geo_secondary_role to cause some configuration changes to postgresql, but ## geo_secondary_role to cause some configuration changes to postgresql, but
## the role enables single-node services by default. ## the role enables single-node services by default.
## ##
...@@ -241,7 +241,7 @@ Configure the tracking database. ...@@ -241,7 +241,7 @@ Configure the tracking database.
1. Generate an MD5 hash of the desired password for the database user that the 1. Generate an MD5 hash of the desired password for the database user that the
GitLab application uses to access the tracking database: GitLab application uses to access the tracking database:
Note that the username (`gitlab_geo` by default) is incorporated into the The username (`gitlab_geo` by default) is incorporated into the
hash. hash.
```shell ```shell
......
...@@ -242,7 +242,7 @@ the tracking database on port 5432. ...@@ -242,7 +242,7 @@ the tracking database on port 5432.
1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) 1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
1. The reconfigure should automatically create the database. If needed, you can perform this task manually. Note that this task (whether run by itself or during reconfigure) requires the database user to be a superuser. 1. The reconfigure should automatically create the database. If needed, you can perform this task manually. This task (whether run by itself or during reconfigure) requires the database user to be a superuser.
```shell ```shell
gitlab-rake geo:db:create gitlab-rake geo:db:create
......
...@@ -952,7 +952,7 @@ result as you did at the start. For example: ...@@ -952,7 +952,7 @@ result as you did at the start. For example:
{enforced="true",status="ok"} 4424.985419441742 {enforced="true",status="ok"} 4424.985419441742
``` ```
Note that `enforced="true"` means that authentication is being enforced. `enforced="true"` means that authentication is being enforced.
## Pack-objects cache **(FREE SELF)** ## Pack-objects cache **(FREE SELF)**
...@@ -1076,7 +1076,7 @@ cache hit and the average amount of storage used by cache files. ...@@ -1076,7 +1076,7 @@ cache hit and the average amount of storage used by cache files.
Entries older than `max_age` get evicted from the in-memory metadata Entries older than `max_age` get evicted from the in-memory metadata
store, and deleted from disk. store, and deleted from disk.
Note that eviction does not interfere with ongoing requests, so it is OK Eviction does not interfere with ongoing requests, so it is OK
for `max_age` to be less than the time it takes to do a fetch over a for `max_age` to be less than the time it takes to do a fetch over a
slow connection. This is because Unix filesystems do not truly delete slow connection. This is because Unix filesystems do not truly delete
a file until all processes that are reading the deleted file have a file until all processes that are reading the deleted file have
......
...@@ -195,7 +195,7 @@ instructions only work on Omnibus-provided PostgreSQL: ...@@ -195,7 +195,7 @@ instructions only work on Omnibus-provided PostgreSQL:
``` ```
Replace `<PRAEFECT_SQL_PASSWORD_HASH>` with the hash of the password you generated in the Replace `<PRAEFECT_SQL_PASSWORD_HASH>` with the hash of the password you generated in the
preparation step. Note that it is prefixed with `md5` literal. preparation step. It is prefixed with `md5` literal.
1. The PgBouncer that is shipped with Omnibus is configured to use [`auth_query`](https://www.pgbouncer.org/config.html#generic-settings) 1. The PgBouncer that is shipped with Omnibus is configured to use [`auth_query`](https://www.pgbouncer.org/config.html#generic-settings)
and uses `pg_shadow_lookup` function. You need to create this function in `praefect_production` and uses `pg_shadow_lookup` function. You need to create this function in `praefect_production`
......
...@@ -80,7 +80,7 @@ GitLab displays your link in the **Menu > Admin > Monitoring > Metrics Dashboard ...@@ -80,7 +80,7 @@ GitLab displays your link in the **Menu > Admin > Monitoring > Metrics Dashboard
When setting up Grafana through the process above, no scope shows in the screen at When setting up Grafana through the process above, no scope shows in the screen at
**Menu >** **{admin}** **Admin > Applications > GitLab Grafana**. However, the `read_user` scope is **Menu >** **{admin}** **Admin > Applications > GitLab Grafana**. However, the `read_user` scope is
required and is provided to the application automatically. Note that setting any scope other than required and is provided to the application automatically. Setting any scope other than
`read_user` without also including `read_user` leads to this error when you try to log in using `read_user` without also including `read_user` leads to this error when you try to log in using
GitLab as the OAuth provider: GitLab as the OAuth provider:
......
...@@ -48,7 +48,7 @@ lookups via database lookup. ...@@ -48,7 +48,7 @@ lookups via database lookup.
As part of [setting up Geo](../geo/index.md#setup-instructions), As part of [setting up Geo](../geo/index.md#setup-instructions),
you are required to follow the steps outlined below for both the primary and you are required to follow the steps outlined below for both the primary and
secondary nodes, but note that the `Write to "authorized keys" file` checkbox secondary nodes, but the `Write to "authorized keys" file` checkbox
only needs to be unchecked on the primary node since it is reflected only needs to be unchecked on the primary node since it is reflected
automatically on the secondary if database replication is working. automatically on the secondary if database replication is working.
......
...@@ -41,7 +41,7 @@ which you can set it up: ...@@ -41,7 +41,7 @@ which you can set it up:
the Pages daemon is installed, so you must share it through the network. the Pages daemon is installed, so you must share it through the network.
- Run the Pages daemon in the same server as GitLab, listening on the same IP - Run the Pages daemon in the same server as GitLab, listening on the same IP
but on different ports. In that case, you must proxy the traffic with but on different ports. In that case, you must proxy the traffic with
a load balancer. If you choose that route note that you should use TCP load a load balancer. If you choose that route, you should use TCP load
balancing for HTTPS. If you use TLS-termination (HTTPS-load balancing), the balancing for HTTPS. If you use TLS-termination (HTTPS-load balancing), the
pages can't be served with user-provided certificates. For pages can't be served with user-provided certificates. For
HTTP it's OK to use HTTP or TCP load balancing. HTTP it's OK to use HTTP or TCP load balancing.
......
...@@ -41,7 +41,7 @@ which you can set it up: ...@@ -41,7 +41,7 @@ which you can set it up:
the Pages daemon is installed, so you must share it through the network. the Pages daemon is installed, so you must share it through the network.
1. Run the Pages daemon in the same server as GitLab, listening on the same IP 1. Run the Pages daemon in the same server as GitLab, listening on the same IP
but on different ports. In that case, you must proxy the traffic with but on different ports. In that case, you must proxy the traffic with
a load balancer. If you choose that route, note that you should use TCP load a load balancer. If you choose that route, you should use TCP load
balancing for HTTPS. If you use TLS-termination (HTTPS-load balancing), the balancing for HTTPS. If you use TLS-termination (HTTPS-load balancing), the
pages aren't able to be served with user-provided certificates. For pages aren't able to be served with user-provided certificates. For
HTTP, it's OK to use HTTP or TCP load balancing. HTTP, it's OK to use HTTP or TCP load balancing.
......
...@@ -889,7 +889,7 @@ with: ...@@ -889,7 +889,7 @@ with:
sudo gitlab-ctl stop patroni sudo gitlab-ctl stop patroni
``` ```
Note that stopping or restarting Patroni service on the leader node will trigger the automatic failover. If you Stopping or restarting Patroni service on the leader node will trigger the automatic failover. If you
want to signal Patroni to reload its configuration or restart PostgreSQL process without triggering the failover, you want to signal Patroni to reload its configuration or restart PostgreSQL process without triggering the failover, you
must use the `reload` or `restart` sub-commands of `gitlab-ctl patroni` instead. These two sub-commands are wrappers of must use the `reload` or `restart` sub-commands of `gitlab-ctl patroni` instead. These two sub-commands are wrappers of
the same `patronictl` commands. the same `patronictl` commands.
...@@ -1015,7 +1015,7 @@ Here are a few key facts that you must consider before upgrading PostgreSQL: ...@@ -1015,7 +1015,7 @@ Here are a few key facts that you must consider before upgrading PostgreSQL:
- Upgrading PostgreSQL creates a new data directory with a new control data. From Patroni's perspective - Upgrading PostgreSQL creates a new data directory with a new control data. From Patroni's perspective
this is a new cluster that needs to be bootstrapped again. Therefore, as part of the upgrade procedure, this is a new cluster that needs to be bootstrapped again. Therefore, as part of the upgrade procedure,
the cluster state (stored in Consul) is wiped out. Once the upgrade is completed, Patroni the cluster state (stored in Consul) is wiped out. Once the upgrade is completed, Patroni
bootstraps a new cluster. **Note that this changes your _cluster ID_**. bootstraps a new cluster. **This changes your _cluster ID_**.
- The procedures for upgrading leader and replicas are not the same. That is why it is important to use the - The procedures for upgrading leader and replicas are not the same. That is why it is important to use the
right procedure on each node. right procedure on each node.
......
...@@ -21,7 +21,7 @@ There are 3 things that are checked to determine integrity. ...@@ -21,7 +21,7 @@ There are 3 things that are checked to determine integrity.
1. Check for `config.lock` in the repository directory. 1. Check for `config.lock` in the repository directory.
1. Check for any branch/references lock files in `refs/heads`. 1. Check for any branch/references lock files in `refs/heads`.
It's important to note that the existence of `config.lock` or reference locks The existence of `config.lock` or reference locks
alone do not necessarily indicate a problem. Lock files are routinely created alone do not necessarily indicate a problem. Lock files are routinely created
and removed as Git and GitLab perform operations on the repository. They serve and removed as Git and GitLab perform operations on the repository. They serve
to prevent data integrity issues. However, if a Git operation is interrupted these to prevent data integrity issues. However, if a Git operation is interrupted these
......
...@@ -683,8 +683,6 @@ To make this work with Sentinel: ...@@ -683,8 +683,6 @@ To make this work with Sentinel:
] ]
``` ```
Note that:
- Redis URLs should be in the format: `redis://:PASSWORD@SENTINEL_PRIMARY_NAME`, where: - Redis URLs should be in the format: `redis://:PASSWORD@SENTINEL_PRIMARY_NAME`, where:
- `PASSWORD` is the plaintext password for the Redis instance. - `PASSWORD` is the plaintext password for the Redis instance.
- `SENTINEL_PRIMARY_NAME` is the Sentinel primary name set with `redis['master_name']`, - `SENTINEL_PRIMARY_NAME` is the Sentinel primary name set with `redis['master_name']`,
...@@ -731,7 +729,7 @@ redis_master_role['enable'] = true # enable only one of them ...@@ -731,7 +729,7 @@ redis_master_role['enable'] = true # enable only one of them
redis_replica_role['enable'] = true # enable only one of them redis_replica_role['enable'] = true # enable only one of them
# When Redis primary or Replica role are enabled, the following services are # When Redis primary or Replica role are enabled, the following services are
# enabled/disabled. Note that if Redis and Sentinel roles are combined, both # enabled/disabled. If Redis and Sentinel roles are combined, both
# services are enabled. # services are enabled.
# The following services are disabled # The following services are disabled
......
...@@ -345,7 +345,7 @@ Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`. ...@@ -345,7 +345,7 @@ Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`.
The Internal Load Balancer is used to balance any internal connections the GitLab environment requires The Internal Load Balancer is used to balance any internal connections the GitLab environment requires
such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster). such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster).
Note that it's a separate node from the External Load Balancer and shouldn't have any access externally. It's a separate node from the External Load Balancer and shouldn't have any access externally.
The following IP will be used as an example: The following IP will be used as an example:
......
...@@ -347,7 +347,7 @@ Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`. ...@@ -347,7 +347,7 @@ Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`.
The Internal Load Balancer is used to balance any internal connections the GitLab environment requires The Internal Load Balancer is used to balance any internal connections the GitLab environment requires
such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster). such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster).
Note that it's a separate node from the External Load Balancer and shouldn't have any access externally. It's a separate node from the External Load Balancer and shouldn't have any access externally.
The following IP will be used as an example: The following IP will be used as an example:
......
...@@ -346,7 +346,7 @@ Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`. ...@@ -346,7 +346,7 @@ Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`.
The Internal Load Balancer is used to balance any internal connections the GitLab environment requires The Internal Load Balancer is used to balance any internal connections the GitLab environment requires
such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster). such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster).
Note that it's a separate node from the External Load Balancer and shouldn't have any access externally. It's a separate node from the External Load Balancer and shouldn't have any access externally.
The following IP will be used as an example: The following IP will be used as an example:
...@@ -2086,7 +2086,7 @@ but with smaller performance requirements, several modifications can be consider ...@@ -2086,7 +2086,7 @@ but with smaller performance requirements, several modifications can be consider
- Combining select nodes: Some nodes can be combined to reduce complexity at the cost of some performance: - Combining select nodes: Some nodes can be combined to reduce complexity at the cost of some performance:
- GitLab Rails and Sidekiq: Sidekiq nodes can be removed and the component instead enabled on the GitLab Rails nodes. - GitLab Rails and Sidekiq: Sidekiq nodes can be removed and the component instead enabled on the GitLab Rails nodes.
- PostgreSQL and PgBouncer: PgBouncer nodes can be removed and the component instead enabled on PostgreSQL with the Internal Load Balancer pointing to them instead. - PostgreSQL and PgBouncer: PgBouncer nodes can be removed and the component instead enabled on PostgreSQL with the Internal Load Balancer pointing to them instead.
- Reducing the node counts: Some node types do not need consensus and can run with fewer nodes (but more than one for redundancy). Note that this will also lead to reduced performance. - Reducing the node counts: Some node types do not need consensus and can run with fewer nodes (but more than one for redundancy). This will also lead to reduced performance.
- GitLab Rails and Sidekiq: Stateless services don't have a minimum node count. Two are enough for redundancy. - GitLab Rails and Sidekiq: Stateless services don't have a minimum node count. Two are enough for redundancy.
- Gitaly and Praefect: A quorum is not strictly necessary. Two Gitaly nodes and two Praefect nodes are enough for redundancy. - Gitaly and Praefect: A quorum is not strictly necessary. Two Gitaly nodes and two Praefect nodes are enough for redundancy.
- Running select components in reputable Cloud PaaS solutions: Select components of the GitLab setup can instead be run on Cloud Provider PaaS solutions. By doing this, additional dependent components can also be removed: - Running select components in reputable Cloud PaaS solutions: Select components of the GitLab setup can instead be run on Cloud Provider PaaS solutions. By doing this, additional dependent components can also be removed:
......
...@@ -354,7 +354,7 @@ Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`. ...@@ -354,7 +354,7 @@ Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`.
The Internal Load Balancer is used to balance any internal connections the GitLab environment requires The Internal Load Balancer is used to balance any internal connections the GitLab environment requires
such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster). such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster).
Note that it's a separate node from the External Load Balancer and shouldn't have any access externally. It's a separate node from the External Load Balancer and shouldn't have any access externally.
The following IP will be used as an example: The following IP will be used as an example:
......
...@@ -338,7 +338,7 @@ Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`. ...@@ -338,7 +338,7 @@ Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`.
The Internal Load Balancer is used to balance any internal connections the GitLab environment requires The Internal Load Balancer is used to balance any internal connections the GitLab environment requires
such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster). such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster).
Note that it's a separate node from the External Load Balancer and shouldn't have any access externally. It's a separate node from the External Load Balancer and shouldn't have any access externally.
The following IP will be used as an example: The following IP will be used as an example:
......
...@@ -45,7 +45,7 @@ session by running: ...@@ -45,7 +45,7 @@ session by running:
ActiveRecord::Base.connection.execute('SET statement_timeout TO 0') ActiveRecord::Base.connection.execute('SET statement_timeout TO 0')
``` ```
Note that this change only affects the current Rails console session and will This change only affects the current Rails console session and will
not be persisted in the GitLab production environment or in the next Rails not be persisted in the GitLab production environment or in the next Rails
console session. console session.
...@@ -213,7 +213,7 @@ downtime. Otherwise skip to the next section. ...@@ -213,7 +213,7 @@ downtime. Otherwise skip to the next section.
exit exit
``` ```
Note that if the Puma process terminates before you are able to run these If the Puma process terminates before you are able to run these
commands, GDB will report an error. To buy more time, you can always raise the commands, GDB will report an error. To buy more time, you can always raise the
Puma worker timeout. For omnibus users, you can edit `/etc/gitlab/gitlab.rb` and Puma worker timeout. For omnibus users, you can edit `/etc/gitlab/gitlab.rb` and
increase it from 60 seconds to 600: increase it from 60 seconds to 600:
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment