Add primary key to audit enqueued table #456
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In some circumstances it is useful or even necessary for tables to have a primary key, eg Blue / Green deployment.
The
que_scheduler_audit_enqueued
does not have a primary key, so this PR adds one. This will require a migration so a new major version of que-scheduler is required. Note this may be a DB intensive operation that can take some time if you have been running que-scheduler for a while. Unless you are running the "cleanup job" (QueSchedulerAuditClearDownJob
), you will have 1 row per job scheduled enqueued since the audit started.Use a migration like so:
The scheduler will pause until the migration to version 8 is completed, as the table will be locked. It may also mean that one que worker will be paused waiting to access that table if it takes so long that the "scheduler run" happens ("on the minute"). This may be fine if you have only tens or hundreds of thousands of rows. If you have millions, and don't wish to have any scheduler pause, it may be best to run a clear down with
QueSchedulerAuditClearDownJob
first (and maybe on an ongoing basis). See theREADME.md
for more details here.