-
Notifications
You must be signed in to change notification settings - Fork 650
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
Bolt and importer changes #14736
Bolt and importer changes #14736
Conversation
da75aa3
to
02a57b9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you planning to add some tests for the new behavior?
Regarding the importer, the idea is to take the lock in order to avoid GTM executions, but allow it to run if it's already locked, right? What happens if it's locked when it starts but then is released? GTM could be called again and run, couldn't it? Why not using it the same way as GTM (with retriable)?
@javitonino 3rd round? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some suggestions for cleaner code
080f246
to
cf01b59
Compare
@javitonino @gonzaloriestra added all the comments and now I'm going to add ghost_table_manager tests in order to test the part |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry to be so nitpicking 🤓
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👌
Looks OK but CI does not agree |
You probably are wondering why is the purpose of this. The main reason to execute a "critical section" without acquiring the mutex (Bolt) is because we only need that the lock has been acquired so we know for sure that Ghost Tables are not going to be executed. In which cases are we going to need this? Mainly in the register part of the importer where we're going to perform DDL operations that are going to trigger ghost tables jobs and that could coincide at the same time with other DDL operations leading into a race condition.
We've added the possibility to retry critical sections of code if Bolt received an attempt to lock and that block of code is marked as retriable. Why are we doing this? Because we don't want to miss changes in the user's schema because Bolt was already acquired. For example, if some user is doing intensive DDL operations we want to sync all the changes so to achieve that we need to inform Bolt that we have other processes trying to execute Ghost tables at the same time and instead of releasing the lock, we mark it asking for retry and at the end we re-execute the same critical section again.
This happens when other process tried to acquire Bolt and was not able to do it.
e489852
to
9bd28aa
Compare
d30c559
to
42edb60
Compare
42edb60
to
a9dda22
Compare
✔️ Acceptance OK Importer and GTM calls from dashboard seem to work as before. Concurrency situations have not been tested (we can check it when we have the trigger). |
Closes #14720 #14725