octoleo/gh-ost
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Document true maximum cutover timeout length

Browse Source 
When attempting a gh-ost migration, I was observed that gh-ost sets the
lock timeout to 6 seconds, not 3 seconds, when attempting to lock
tables. This is potentially dangerous, because a user may set this flag
to 10 seconds and expect that the max table unavailability is a total of
10 seconds, when it's really 20 seconds. I observed this happening quite
clearly, as gh-ost was unable to obtain the first stage lock several
times. I didn't realize the docs didn't account for this total lock time.

(Now, they do!)
This commit is contained in:
Lucas Nicodemus 2020-12-10 17:05:33 -08:00
parent e99b915cf5
commit 44e99167ba
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/command-line-flags.md
View File

@ -71,7 +71,7 @@ Optional. Default is `safe`. See more discussion in [`cut-over`](cut-over.md)
### cut-over-lock-timeout-seconds ### cut-over-lock-timeout-seconds
Default `3`. Max number of seconds to hold locks on tables while attempting to cut-over (retry attempted when lock exceeds timeout). Default `3`. Max number of seconds to hold locks on tables while attempting to issue the atomic rename during cut-over (retry attempted when lock exceeds timeout). The theoretical max lock time is `2x` this timeout, as gh-ost sets the timeout to acquire the initial table locks to twice this value. Therefore, the true maximum time a table may be blocked by default is `6` seconds.
### discard-foreign-keys ### discard-foreign-keys