diff options
| -rw-r--r-- | doc/administration/high_availability/gitlab.md | 5 | ||||
| -rw-r--r-- | doc/development/background_migrations.md | 8 | ||||
| -rw-r--r-- | doc/user/profile/personal_access_tokens.md | 2 |
3 files changed, 14 insertions, 1 deletions
diff --git a/doc/administration/high_availability/gitlab.md b/doc/administration/high_availability/gitlab.md index 0d9c10687f2..637d44d2823 100644 --- a/doc/administration/high_availability/gitlab.md +++ b/doc/administration/high_availability/gitlab.md @@ -122,6 +122,11 @@ need some extra configuration. from running on upgrade. Only the primary GitLab application server should handle migrations. +1. **Optional** Configure host keys. Copy all contents(primary and public keys) inside `/etc/ssh/` on + the primary application server to `/etc/ssh` on all secondary servers. This + prevents false man-in-the-middle-attack alerts when accessing servers in your + High Availability cluster behind a load balancer. + 1. Run `sudo gitlab-ctl reconfigure` to compile the configuration. ## Troubleshooting diff --git a/doc/development/background_migrations.md b/doc/development/background_migrations.md index 46c5baddb9c..16195cbbbdf 100644 --- a/doc/development/background_migrations.md +++ b/doc/development/background_migrations.md @@ -296,10 +296,18 @@ for more details. ## Best practices +1. Make sure to know how much data you're dealing with 1. Make sure that background migration jobs are idempotent. 1. Make sure that tests you write are not false positives. 1. Make sure that if the data being migrated is critical and cannot be lost, the clean-up migration also checks the final state of the data before completing. +1. Make sure to know how much time it'll take to run all scheduled migrations +1. When migrating many columns, make sure it won't generate too many + dead tuples in the process (you may need to directly query the number of dead tuples + and adjust the scheduling according to this piece of data) +1. Make sure to discuss the numbers with a database specialist, the migration may add + more pressure on DB than you expect (measure on staging, + or ask someone to measure on production) [migrations-readme]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/spec/migrations/README.md [issue-rspec-hooks]: https://gitlab.com/gitlab-org/gitlab-ce/issues/35351 diff --git a/doc/user/profile/personal_access_tokens.md b/doc/user/profile/personal_access_tokens.md index 601db5f424d..25d6c34409c 100644 --- a/doc/user/profile/personal_access_tokens.md +++ b/doc/user/profile/personal_access_tokens.md @@ -48,7 +48,7 @@ the following table. | `api` | Grants complete access to the API (read/write) ([introduced][ce-5951] in GitLab 8.15). Required for accessing Git repositories over HTTP when 2FA is enabled. | | `read_registry` | Allows to read [container registry] images if a project is private and authorization is required ([introduced][ce-11845] in GitLab 9.3). | | `sudo` | Allows performing API actions as any user in the system (if the authenticated user is an admin) ([introduced][ce-14838] in GitLab 10.2). | -| `read_repository` | Allows read-access to the repository through git clone). | +| `read_repository` | Allows read-access to the repository through git clone. | [2fa]: ../account/two_factor_authentication.md [api]: ../../api/README.md |