summaryrefslogtreecommitdiff
path: root/lib/gitlab/background_migration.rb
Commit message (Collapse)AuthorAgeFilesLines
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-02-121-0/+8
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-01-101-0/+14
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2019-10-161-1/+1
|
* Add methods to check dead and retrying jobsosw-schedule-multiple-mr-assignees-ff-auto-enablingOswaldo Ferreira2019-04-081-6/+22
| | | | | It adds two methods for checking if a background job (for a given class) has dead or retrying jobs.
* Consume remaining MigrateApproverToApprovalRulesInBatchMark Chao2019-02-021-4/+11
| | | Allow `steal` to handle dead jobs.
* Check if specific type of background migration are doneMark Chao2019-01-081-0/+13
| | | | Useful for checking progress.
* Enable frozen string for lib/gitlab/*.rbgfyoung2018-10-221-0/+2
|
* Respond to DB health in background migrationsYorick Peterse2018-08-061-1/+5
| | | | | | | | | | | | | | | | | | | This changes the BackgroundMigration worker so it checks for the health of the DB before performing a background migration. This in turn allows us to reduce the minimum interval, without having to worry about blowing things up if we schedule too many migrations. In this setup, the BackgroundMigration worker will reschedule jobs as long as the database is considered to be in an unhealthy state. Once the database has recovered, the migration can be performed. To determine if the database is in a healthy state, we look at the replication lag of any replication slots defined on the primary. If the lag is deemed to great (100 MB by default) for too many slots, the migration is rescheduled for a later point in time. The health checking code is hidden behind a feature flag, allowing us to disable it if necessary.
* Remove obsolete argument from bg migrations codeGrzegorz Bizon2017-07-181-1/+1
|
* Simplify background migrations stealing codeGrzegorz Bizon2017-07-171-15/+3
| | | | | Simply re-raise an exception when it occurs, but guarantee that no background migration is lost in the process.
* Fix off-by-one error in background migration retriesfix/gb/process-scheduled-background-migrationsGrzegorz Bizon2017-07-171-5/+10
|
* Recover from all exceptions when stealing bg migrationGrzegorz Bizon2017-07-171-4/+22
| | | | | It also makes it possible to gracefully retry a migration in order to avoid problems like deadlocks.
* Catch exceptions when stealing background migrationsGrzegorz Bizon2017-07-141-1/+6
|
* Avoid race condition when stealing a background migrationGrzegorz Bizon2017-07-141-3/+1
| | | | | | We first pop a job from the Sidekiq queue / scheduled set and only if this has been successfully deleted we process the job. This makes it possible to minimize a possibility of a race condition happening.
* Fix mocks in background migrations specsGrzegorz Bizon2017-07-131-1/+0
|
* Implement draining scheduled sets of background migrationsGrzegorz Bizon2017-07-131-7/+12
|
* Extract background migratons queue class methodGrzegorz Bizon2017-07-111-2/+5
|
* Enable Style/DotPosition Rubocop :cop:Grzegorz Bizon2017-06-211-2/+2
|
* Add the ability to perform background migrationsYorick Peterse2017-06-121-0/+31
Background migrations can be used to perform long running data migrations without these blocking a deployment procedure. See MR https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11854 for more information.
View Lorry Controller Status