1--- 2stage: Enablement 3group: Geo 4info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments 5type: howto 6--- 7 8# Geo sites Admin Area **(PREMIUM SELF)** 9 10You can configure various settings for GitLab Geo sites. For more information, see 11[Geo documentation](../../administration/geo/index.md). 12 13On either the primary or secondary site: 14 151. On the top bar, select **Menu > Admin**. 161. On the left sidebar, select **Geo > Nodes**. 17 18## Common settings 19 20All Geo sites have the following settings: 21 22| Setting | Description | 23| --------| ----------- | 24| Primary | This marks a Geo site as **primary** site. There can be only one **primary** site. | 25| Name | The unique identifier for the Geo site. It's highly recommended to use a physical location as a name. Good examples are "London Office" or "us-east-1". Avoid words like "primary", "secondary", "Geo", or "DR". This makes the failover process easier because the physical location does not change, but the Geo site role can. All nodes in a single Geo site use the same site name. Nodes use the `gitlab_rails['geo_node_name']` setting in `/etc/gitlab/gitlab.rb` to lookup their Geo site record in the PostgreSQL database. If `gitlab_rails['geo_node_name']` is not set, the node's `external_url` with trailing slash is used as fallback. The value of `Name` is case-sensitive, and most characters are allowed. | 26| URL | The instance's user-facing URL. | 27 28The site you're currently browsing is indicated with a blue `Current` label, and 29the **primary** node is listed first as `Primary site`. 30 31## Secondary site settings 32 33**Secondary** sites have a number of additional settings available: 34 35| Setting | Description | 36|---------------------------|-------------| 37| Selective synchronization | Enable Geo [selective sync](../../administration/geo/replication/configuration.md#selective-synchronization) for this **secondary** site. | 38| Repository sync capacity | Number of concurrent requests this **secondary** site makes to the **primary** site when backfilling repositories. | 39| File sync capacity | Number of concurrent requests this **secondary** site makes to the **primary** site when backfilling files. | 40 41## Geo backfill 42 43**Secondary** sites are notified of changes to repositories and files by the **primary** site, 44and always attempt to synchronize those changes as quickly as possible. 45 46Backfill is the act of populating the **secondary** site with repositories and files that 47existed *before* the **secondary** site was added to the database. Because there may be 48extremely large numbers of repositories and files, it's not feasible to attempt to 49download them all at once; so, GitLab places an upper limit on the concurrency of 50these operations. 51 52How long the backfill takes is dependent on the maximum concurrency, but higher 53values place more strain on the **primary** site. From [GitLab 10.2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3107), 54the limits are configurable. If your **primary** site has lots of surplus capacity, 55you can increase the values to complete backfill in a shorter time. If it's 56under heavy load and backfill reduces its availability for normal requests, 57you can decrease them. 58 59## Using a different URL for synchronization 60 61The **primary** site's Internal URL is used by **secondary** sites to contact it 62(to sync repositories, for example). The name Internal URL distinguishes it from 63[External URL](https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-the-external-url-for-gitlab), 64which is used by users. Internal URL does not need to be a private address. 65 66Internal URL defaults to external URL, but you can also customize it: 67 681. On the top bar, select **Menu > Admin**. 691. On the left sidebar, select **Geo > Nodes**. 701. Select **Edit** on the site you want to customize. 711. Edit the internal URL. 721. Select **Save changes**. 73 74WARNING: 75We recommend using an HTTPS connection while configuring the Geo sites. To avoid 76breaking communication between **primary** and **secondary** sites when using 77HTTPS, customize your Internal URL to point to a load balancer with TLS 78terminated at the load balancer. 79 80WARNING: 81Starting with GitLab 13.3 and [until 13.11](https://gitlab.com/gitlab-org/gitlab/-/issues/325522), 82if you use an internal URL that is not accessible to the users, the 83OAuth authorization flow does not work properly, because users are redirected 84to the internal URL instead of the external one. 85 86## Multiple secondary sites behind a load balancer 87 88In GitLab 11.11, **secondary** sites can use identical external URLs if 89a unique `name` is set for each Geo site. The `gitlab.rb` setting 90`gitlab_rails['geo_node_name']` must: 91 92- Be set for each GitLab instance that runs `puma`, `sidekiq`, or `geo_logcursor`. 93- Match a Geo site name. 94 95The load balancer must use sticky sessions to avoid authentication 96failures and cross-site request errors. 97 98<!-- ## Troubleshooting 99 100Include any troubleshooting steps that you can foresee. If you know beforehand what issues 101one might have when setting this up, or when something is changed, or on upgrading, it's 102important to describe those, too. Think of things that may go wrong and include them here. 103This is important to minimize requests for support, and to avoid doc comments with 104questions that you know someone might ask. 105 106Each scenario can be a third-level heading, e.g. `### Getting error message X`. 107If you have none to add when creating a doc, leave this section in place 108but commented out to help encourage others to add to it in the future. --> 109