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
[Mysql] Apply initial setup time to Debezium setup time #32662
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
@@ -55,6 +55,7 @@ public class JdbcUtils { | |||
public static final String TLS_KEY = "tls"; | |||
public static final String USERNAME_KEY = "username"; | |||
public static final String MODE_KEY = "mode"; | |||
public static final String ENGINE_WARMUP_MINUTE_KEY = "engine_warmup_minute"; |
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 we adding this to the spec as a user configured option? IMO maybe we shouldn't present this option to the user as it might be confusing to have 2 timeouts.
We already provide the initial record waiting time option to the user. What we can do is :
- Have logic that defaults the minimum value to 5 min (current time)
- If the user has defined the initial wait time > 5 min, we can set it to that.
What do you think? Also what was the new time that worked for the OC issue?
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.
yeah that sounds good! I was thinking just to add that so in our backend we could adjust this in oncall operations; but I think your proposal makes more sense.
In the OC issue the timeout was 9 minutes 30 seconds; so adjusting initial wait time should work
if (Duration.between(engineStartTime, Instant.now()).compareTo(Duration.ofMinutes(5L)) > 0) { | ||
LOGGER.error("No record is returned even after 5 minutes of waiting, closing the engine"); | ||
final Duration initialWaitingDuration = database.getSourceConfig().has(INITIAL_WAITING_SECONDS) ? Duration | ||
.ofSeconds(database.getSourceConfig().get(INITIAL_WAITING_SECONDS).asLong()) : Duration.ofMinutes(5L); |
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.
I think just to not change the minimum default (since we were seeing some timeouts), we should take the max (5 min, user_configured_first_wait_time)
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.
good call - fixed!
@@ -53,6 +53,7 @@ | |||
public class MySqlDebeziumStateUtil implements DebeziumStateUtil { | |||
|
|||
private static final Logger LOGGER = LoggerFactory.getLogger(MySqlDebeziumStateUtil.class); | |||
private static final String INITIAL_WAITING_SECONDS = "initial_waiting_seconds"; |
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.
nit : can we reuse the method RecordWaitTimeUtil.getFirstRecordWaitSeconds() instead of re-read this?
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.
Approving - one small nit about PR description + changelog comment : I think that you should mention that initial wait time is already configurable - but this is extending the wait time to read schema history from Debezium
/publish-java-cdk
|
Fix https://github.com/airbytehq/oncall/issues/3567
Some DB has large number of tables to sync. In that case, our default 5 minutes wait time is not enough. The change is to make initial setup time defined by user also applies to that default debezium setup time if it's larger.
What
Describe what the change is solving
It helps to add screenshots if it affects the frontend.
How
Describe the solution
Recommended reading order
x.java
y.python
🚨 User Impact 🚨
Are there any breaking changes? What is the end result perceived by the user?
For connector PRs, use this section to explain which type of semantic versioning bump occurs as a result of the changes. Refer to our Semantic Versioning for Connectors guidelines for more information. Breaking changes to connectors must be documented by an Airbyte engineer (PR author, or reviewer for community PRs) by using the Breaking Change Release Playbook.
If there are breaking changes, please merge this PR with the 🚨🚨 emoji so changelog authors can further highlight this if needed.
Pre-merge Actions
Expand the relevant checklist and delete the others.
New Connector
Community member or Airbyter
./gradlew :airbyte-integrations:connectors:<name>:integrationTest
.0.0.1
Dockerfile
has version0.0.1
README.md
bootstrap.md
. See description and examplesdocs/integrations/<source or destination>/<name>.md
including changelog with an entry for the initial version. See changelog exampledocs/integrations/README.md
Airbyter
If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.
Updating a connector
Community member or Airbyter
Airbyter
If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.
Connector Generator
-scaffold
in their name) have been updated with the latest scaffold by running./gradlew :airbyte-integrations:connector-templates:generator:generateScaffolds
then checking in your changesUpdating the Python CDK
Airbyter
Before merging:
--use-local-cdk --name=source-<connector>
as optionsairbyte-ci connectors --use-local-cdk --name=source-<connector> test
After merging: