Has anyone ever run into an issue with the tap-mys...
# singer-tap-development
j
Has anyone ever run into an issue with the tap-mysql (pipelinewise variant) where it will time out when trying to access the database? Normally, in the past this is caused by a networking disconnect between my ECS container and the database I’m trying to replicate. In this case I know it’s not a networking problem because: 1. our engineers didn’t change any of that config nor did I 2. I can exec into one of my containers and access the mysql instance from the CLI. 3. My pipelines can successfully access RDS instances in an EU region (only instances in us-east-1 time out) To add to the strangeness, when I run a pipeline with a unique
--state-id-suffix
everything runs fine, only on the second run does it timeout. I’ve checked the connection parameters I’m using and they are all properly formatted (again I didn’t change any of that). This just started happening on a weekend so it happened out of the blue even though no one had changed anything … so confusing.
t
How are you replicating table (log_based, incremental, etc.)? Is it starting to pull some data and then timing out? Or is it timing out before it retrieves any data? If it's the former you may need to increase @@session.wait_timeout. If it's the latter you may be running into a problem with catalog discovery... maybe something like this.
j
LOG_BASED
is how I’m running it. It’s timing out on the very first call to the database, probably part of discovery though I think it’s prior to the query you reference in your bug report. I need to go find the exact line/query again …
t
Yeah the discovery happens really early on, pretty much before anything else (so it can detect column changes and such) so that's a good candidate. If you have lots of tables and/or large tables in the database that would definitely explain it.