Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"attempt-instant-ddl" should support lock_wait_timeout #1386

Open
Hexcles opened this issue Mar 7, 2024 · 1 comment
Open

"attempt-instant-ddl" should support lock_wait_timeout #1386

Hexcles opened this issue Mar 7, 2024 · 1 comment

Comments

@Hexcles
Copy link

Hexcles commented Mar 7, 2024

Currently gh-ost only sets lock_wait_timeout when doing normal cutover: https://github.com/search?q=repo%3Agithub%2Fgh-ost%20lock_wait_timeout&type=code

When Instant DDL is used, there doesn't seem to be a way to set the lock timeout. We can either reuse the same cut-over-lock-timeout-seconds flag or introduce a new one specifically for Instant DDL.

@hakusaro
Copy link

hakusaro commented Apr 3, 2024

Peering into #1201, I found it perplexing that it says this in the docs:

This is not a problem for most scenarios, but it could be a problem for users that start the DDL during a period with long running transactions.

This is really critical information, in my opinion, because if gh-ost is supposed to be inherently safe, it seems to jeopardize this safety by potentially creating table outages with no controllable timeout here. We primarily introduced gh-ost because of long-running transactions that were hard to pin down and a lack of safety with LHM in these scenarios. While we've mostly cleaned these up, I still think anything that could remotely incur a table outage should have defined characteristics for how long the table will be out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants