< kapa ai> I have the following error on source mysql check Airbyte #replication-ask-ai

<@U04S8PLJWMT> I have the following error on sourc...

Fabrizio Spini

12/16/2025, 7:55 AM

@kapa.ai I have the following error on source-mysql-check pod

Copy code

2025-12-16 07:52:18,199 [main]	INFO	i.a.c.ConnectorWatcher(saveConnectorOutput):186 - Writing output of 435bb9a5-7887-4809-aa58-28c27df0d7ad_138badd9-c058-4b44-9f21-a2b86a18699a_0_check to the doc store
2025-12-16 07:52:21,092 [main]	WARN	i.a.a.c.c.ClientConfigurationSupport(generateDefaultRetryPolicy$lambda$5):79 - Retry attempt 1 of 5. Last response: null
2025-12-16 07:52:23,663 [main]	WARN	i.a.a.c.c.ClientConfigurationSupport(generateDefaultRetryPolicy$lambda$5):79 - Retry attempt 2 of 5. Last response: null
2025-12-16 07:52:26,543 [main]	WARN	i.a.a.c.c.ClientConfigurationSupport(generateDefaultRetryPolicy$lambda$5):79 - Retry attempt 3 of 5. Last response: null
2025-12-16 07:52:28,802 [main]	WARN	i.a.a.c.c.ClientConfigurationSupport(generateDefaultRetryPolicy$lambda$5):79 - Retry attempt 4 of 5. Last response: null
2025-12-16 07:52:31,253 [main]	WARN	i.a.a.c.c.ClientConfigurationSupport(generateDefaultRetryPolicy$lambda$5):79 - Retry attempt 5 of 5. Last response: null
2025-12-16 07:52:31,512 [main]	ERROR	i.a.a.c.c.ClientConfigurationSupport(generateDefaultRetryPolicy$lambda$7):95 - Retry attempts exceeded.
java.io.IOException: HTTP error: 500 Internal Server Error
	at io.airbyte.api.client.interceptor.ThrowOn5xxInterceptor.intercept(ThrowOn5xxInterceptor.kt:16)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
	at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
	at dev.failsafe.okhttp.FailsafeCall.lambda$execute$0(FailsafeCall.java:117)
	at dev.failsafe.Functions.lambda$get$0(Functions.java:46)
	at dev.failsafe.internal.RetryPolicyExecutor.lambda$apply$0(RetryPolicyExecutor.java:74)
	at dev.failsafe.SyncExecutionImpl.executeSync(SyncExecutionImpl.java:187)
	at dev.failsafe.CallImpl.execute(CallImpl.java:33)
	at dev.failsafe.okhttp.FailsafeCall.execute(FailsafeCall.java:121)
	at io.airbyte.api.client.generated.WorkloadOutputApi.writeWorkloadOutputWithHttpInfo(WorkloadOutputApi.kt:376)
	at io.airbyte.api.client.generated.WorkloadOutputApi.writeWorkloadOutput(WorkloadOutputApi.kt:62)
	at io.airbyte.workers.workload.WorkloadOutputWriter.writeOutputThroughServer(WorkloadOutputWriter.kt:82)
	at io.airbyte.workers.workload.WorkloadOutputWriter.write(WorkloadOutputWriter.kt:65)
	at io.airbyte.connectorSidecar.ConnectorWatcher.saveConnectorOutput(ConnectorWatcher.kt:187)
	at io.airbyte.connectorSidecar.ConnectorWatcher.run(ConnectorWatcher.kt:80)
	at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt:22)
	at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt)

2025-12-16 07:52:31,515 [main]	ERROR	i.a.a.c.c.ClientConfigurationSupport(generateDefaultRetryPolicy$lambda$3):63 - Failed to call unknown.  Last response: null
java.io.IOException: HTTP error: 500 Internal Server Error
	at io.airbyte.api.client.interceptor.ThrowOn5xxInterceptor.intercept(ThrowOn5xxInterceptor.kt:16)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
	at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
	at dev.failsafe.okhttp.FailsafeCall.lambda$execute$0(FailsafeCall.java:117)
	at dev.failsafe.Functions.lambda$get$0(Functions.java:46)
	at dev.failsafe.internal.RetryPolicyExecutor.lambda$apply$0(RetryPolicyExecutor.java:74)
	at dev.failsafe.SyncExecutionImpl.executeSync(SyncExecutionImpl.java:187)
	at dev.failsafe.CallImpl.execute(CallImpl.java:33)
	at dev.failsafe.okhttp.FailsafeCall.execute(FailsafeCall.java:121)
	at io.airbyte.api.client.generated.WorkloadOutputApi.writeWorkloadOutputWithHttpInfo(WorkloadOutputApi.kt:376)
	at io.airbyte.api.client.generated.WorkloadOutputApi.writeWorkloadOutput(WorkloadOutputApi.kt:62)
	at io.airbyte.workers.workload.WorkloadOutputWriter.writeOutputThroughServer(WorkloadOutputWriter.kt:82)
	at io.airbyte.workers.workload.WorkloadOutputWriter.write(WorkloadOutputWriter.kt:65)
	at io.airbyte.connectorSidecar.ConnectorWatcher.saveConnectorOutput(ConnectorWatcher.kt:187)
	at io.airbyte.connectorSidecar.ConnectorWatcher.run(ConnectorWatcher.kt:80)
	at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt:22)
	at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt)

2025-12-16 07:52:31,516 [main]	ERROR	i.a.c.ConnectorWatcher(handleException):200 - Error performing operation: io.airbyte.workers.workload.exception.DocStoreAccessException
io.airbyte.workers.workload.exception.DocStoreAccessException: Unable to write output for 435bb9a5-7887-4809-aa58-28c27df0d7ad_138badd9-c058-4b44-9f21-a2b86a18699a_0_check
	at io.airbyte.workers.workload.WorkloadOutputWriter.writeOutputThroughServer(WorkloadOutputWriter.kt:86)
	at io.airbyte.workers.workload.WorkloadOutputWriter.write(WorkloadOutputWriter.kt:65)
	at io.airbyte.connectorSidecar.ConnectorWatcher.saveConnectorOutput(ConnectorWatcher.kt:187)
	at io.airbyte.connectorSidecar.ConnectorWatcher.run(ConnectorWatcher.kt:80)
	at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt:22)
	at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt)
Caused by: java.io.IOException: HTTP error: 500 Internal Server Error
	at io.airbyte.api.client.interceptor.ThrowOn5xxInterceptor.intercept(ThrowOn5xxInterceptor.kt:16)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
	at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
	at dev.failsafe.okhttp.FailsafeCall.lambda$execute$0(FailsafeCall.java:117)
	at dev.failsafe.Functions.lambda$get$0(Functions.java:46)
	at dev.failsafe.internal.RetryPolicyExecutor.lambda$apply$0(RetryPolicyExecutor.java:74)
	at dev.failsafe.SyncExecutionImpl.executeSync(SyncExecutionImpl.java:187)
	at dev.failsafe.CallImpl.execute(CallImpl.java:33)
	at dev.failsafe.okhttp.FailsafeCall.execute(FailsafeCall.java:121)
	at io.airbyte.api.client.generated.WorkloadOutputApi.writeWorkloadOutputWithHttpInfo(WorkloadOutputApi.kt:376)
	at io.airbyte.api.client.generated.WorkloadOutputApi.writeWorkloadOutput(WorkloadOutputApi.kt:62)
	at io.airbyte.workers.workload.WorkloadOutputWriter.writeOutputThroughServer(WorkloadOutputWriter.kt:82)
	... 5 common frames omitted

2025-12-16 07:52:33,484 [main]	WARN	i.a.a.c.c.ClientConfigurationSupport(generateDefaultRetryPolicy$lambda$5):79 - Retry attempt 1 of 5. Last response: null
2025-12-16 07:52:36,030 [main]	WARN	i.a.a.c.c.ClientConfigurationSupport(generateDefaultRetryPolicy$lambda$5):79 - Retry attempt 2 of 5. Last response: null
2025-12-16 07:52:38,146 [main]	WARN	i.a.a.c.c.ClientConfigurationSupport(generateDefaultRetryPolicy$lambda$5):79 - Retry attempt 3 of 5. Last response: null
2025-12-16 07:52:40,634 [main]	WARN	i.a.a.c.c.ClientConfigurationSupport(generateDefaultRetryPolicy$lambda$5):79 - Retry attempt 4 of 5. Last response: null
2025-12-16 07:52:43,302 [main]	WARN	i.a.a.c.c.ClientConfigurationSupport(generateDefaultRetryPolicy$lambda$5):79 - Retry attempt 5 of 5. Last response: null
2025-12-16 07:52:43,663 [main]	ERROR	i.a.a.c.c.ClientConfigurationSupport(generateDefaultRetryPolicy$lambda$7):95 - Retry attempts exceeded.
java.io.IOException: HTTP error: 500 Internal Server Error
	at io.airbyte.api.client.interceptor.ThrowOn5xxInterceptor.intercept(ThrowOn5xxInterceptor.kt:16)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
	at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
	at dev.failsafe.okhttp.FailsafeCall.lambda$execute$0(FailsafeCall.java:117)
	at dev.failsafe.Functions.lambda$get$0(Functions.java:46)
	at dev.failsafe.internal.RetryPolicyExecutor.lambda$apply$0(RetryPolicyExecutor.java:74)
	at dev.failsafe.SyncExecutionImpl.executeSync(SyncExecutionImpl.java:187)
	at dev.failsafe.CallImpl.execute(CallImpl.java:33)
	at dev.failsafe.okhttp.FailsafeCall.execute(FailsafeCall.java:121)
	at io.airbyte.api.client.generated.WorkloadOutputApi.writeWorkloadOutputWithHttpInfo(WorkloadOutputApi.kt:376)
	at io.airbyte.api.client.generated.WorkloadOutputApi.writeWorkloadOutput(WorkloadOutputApi.kt:62)
	at io.airbyte.workers.workload.WorkloadOutputWriter.writeOutputThroughServer(WorkloadOutputWriter.kt:82)
	at io.airbyte.workers.workload.WorkloadOutputWriter.write(WorkloadOutputWriter.kt:65)
	at io.airbyte.connectorSidecar.ConnectorWatcher.handleException(ConnectorWatcher.kt:207)
	at io.airbyte.connectorSidecar.ConnectorWatcher.run(ConnectorWatcher.kt:83)
	at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt:22)
	at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt)

2025-12-16 07:52:43,664 [main]	ERROR	i.a.a.c.c.ClientConfigurationSupport(generateDefaultRetryPolicy$lambda$3):63 - Failed to call unknown.  Last response: null
java.io.IOException: HTTP error: 500 Internal Server Error
	at io.airbyte.api.client.interceptor.ThrowOn5xxInterceptor.intercept(ThrowOn5xxInterceptor.kt:16)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
	at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
	at dev.failsafe.okhttp.FailsafeCall.lambda$execute$0(FailsafeCall.java:117)
	at dev.failsafe.Functions.lambda$get$0(Functions.java:46)
	at dev.failsafe.internal.RetryPolicyExecutor.lambda$apply$0(RetryPolicyExecutor.java:74)
	at dev.failsafe.SyncExecutionImpl.executeSync(SyncExecutionImpl.java:187)
	at dev.failsafe.CallImpl.execute(CallImpl.java:33)
	at dev.failsafe.okhttp.FailsafeCall.execute(FailsafeCall.java:121)
	at io.airbyte.api.client.generated.WorkloadOutputApi.writeWorkloadOutputWithHttpInfo(WorkloadOutputApi.kt:376)
	at io.airbyte.api.client.generated.WorkloadOutputApi.writeWorkloadOutput(WorkloadOutputApi.kt:62)
	at io.airbyte.workers.workload.WorkloadOutputWriter.writeOutputThroughServer(WorkloadOutputWriter.kt:82)
	at io.airbyte.workers.workload.WorkloadOutputWriter.write(WorkloadOutputWriter.kt:65)
	at io.airbyte.connectorSidecar.ConnectorWatcher.handleException(ConnectorWatcher.kt:207)
	at io.airbyte.connectorSidecar.ConnectorWatcher.run(ConnectorWatcher.kt:83)
	at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt:22)
	at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt)

2025-12-16 07:52:43,666 [main]	INFO	i.a.c.ConnectorWatcher(failWorkload):342 - Failing workload 435bb9a5-7887-4809-aa58-28c27df0d7ad_138badd9-c058-4b44-9f21-a2b86a18699a_0_check.
2025-12-16 07:52:43,729 [main]	INFO	i.a.c.ConnectorWatcher(exitInternalError):254 - Deliberately exiting process with code 1.

kapa.ai

12/16/2025, 7:55 AM

The knowledge sources you provided don’t contain any examples of this specific error pattern (HTTP 500 from

WorkloadOutputApi.writeWorkloadOutput

DocStoreAccessException

when the sidecar tries to save connector output), so I can’t give a confirmed root cause or fix based on them. From the logs, the failure is happening after the connector has run, when the sidecar (

ConnectorWatcher

) tries to write the check output to the “doc store” via the control plane API and repeatedly gets

500 Internal Server Error

, eventually throwing

DocStoreAccessException

and failing the workload. Because there’s no direct documentation or issue in the provided sources about this

WorkloadOutputApi

/ doc store 500 error, I can only suggest next steps rather than a documented solution: 1. Check control-plane / server logs at the same timestamps Look at the Airbyte server / control-plane logs around

2025-12-16 07:52:18–07:52:44

to see why the

writeWorkloadOutput

endpoint is returning HTTP 500. That’s where the real error should be. 2. Verify doc store / persistence configuration Since the exception is

DocStoreAccessException: Unable to write output

, confirm that whatever backing store Airbyte is using for workload output (database / object storage, depending on your deployment) is reachable and correctly configured. 3. Confirm platform version vs. connectors Some recent issues show that newer connectors can require a minimum platform version and fail in non-obvious ways when the platform is older, though the examples in the sources are about BigQuery and MySQL behaving oddly rather than this exact 500 error.[\[destination-bigquery issue\]](https://github.com/airbytehq/airbyte/issues/59702) If you recently upgraded the MySQL connector or the platform, check that: - Your Airbyte platform version meets the connector’s minimum requirement. - There isn’t a partial/failed upgrade of the control plane. 4. Try another simple check job Run a connection check for a different connector (e.g., a simple destination or source) and see if it also fails at the “Writing output … to the doc store” step. If it does, the problem is likely global (control plane / doc store), not specific to

source-mysql

. Because the knowledge sources don’t describe this exact failure mode, I can’t point you to a known bug or configuration flag that resolves it. If you can share the corresponding server logs (the 500 error details) or your deployment type and Airbyte version, that would be the next thing to inspect.

Fabrizio Spini

12/16/2025, 10:49 AM

@kapa.ai if I want to put on test airbyte values.yaml external postgres user/password where do I have to place it?

kapa.ai

12/16/2025, 10:49 AM

A message from kapa.ai

kapa.ai

12/16/2025, 10:49 AM

To test Airbyte with an external Postgres when using the Helm chart, you configure it in two places: --- ### 1. Create the secret with user/password Create a Kubernetes secret (e.g.

airbyte-config-secrets

) that holds the DB credentials:

Copy code

yaml apiVersion: v1 kind: Secret metadata:   name: airbyte-config-secrets type: Opaque stringData:   # Database Secrets   database-user: airbyte        # your DB user   database-password: password   # your DB password

Apply it with

kubectl apply -f secret.yaml

.[[External DB 1.6](https://docs.airbyte.com/platform/1.6/deploying-airbyte/integrations/database#secrets); [External DB latest](https://docs.airbyte.com/platform/deploying-airbyte/integrations/database#secrets)] --- ### 2. Configure

values.yaml

to use the external DB In your

values.yaml

, disable the internal Postgres and point Airbyte to the external one, referencing the secret above. For Helm chart v1 style:

Copy code

yaml postgresql:   enabled: false  global:   database:     type: external      # Secret with credentials     secretName: "airbyte-config-secrets"      # Connection details     host: "your-postgres-host"     port: "5432"     database: "airbyte"      # Keys inside the secret     userSecretKey: "database-user"     passwordSecretKey: "database-password"

[[External DB 1.7](https://docs.airbyte.com/platform/1.7/deploying-airbyte/integrations/database#values); [External DB latest](https://docs.airbyte.com/platform/deploying-airbyte/integrations/database#values)] For Helm chart v2 style (note

name

instead of

database

Copy code

yaml postgresql:   enabled: false  global:   database:     type: external     secretName: "airbyte-config-secrets"      host: "your-postgres-host"     port: "5432"     name: "airbyte"      userSecretKey: "database-user"     passwordSecretKey: "database-password"

[[External DB 1.8](https://docs.airbyte.com/platform/1.8/deploying-airbyte/integrations/database#values)] --- So in summary: - User/password values go into the Kubernetes secret (

database-user

database-password

). - values.yaml
references that secret under

global.database.secretName

and the

userSecretKey

passwordSecretKey

fields, with

postgresql.enabled: false

and

global.database.type: external

Fabrizio Spini

12/16/2025, 11:22 AM

@kapa.ai ho tutti i pod attivi su gke. Adesso come faccio a connettermi alla UI?

kapa.ai

12/16/2025, 11:22 AM

A message from kapa.ai

kapa.ai

12/16/2025, 11:22 AM

Se hai già tutti i pod Airbyte attivi su GKE, ci sono due modi principali per accedere alla UI: --- ### 1. Accesso veloce con port‑forward (consigliato per test) Esegui dal tuo terminale (dove hai

kubectl

configurato):

Copy code

bash kubectl -n airbyte port-forward deployment/airbyte-server 8080:8001

oppure, se usi il namespace `airbyte-v2`:

Copy code

bash kubectl -n airbyte-v2 port-forward deployment/airbyte-server 8080:8001

Poi apri il browser su:

Copy code

text <http://127.0.0.1:8080>

[[Deploying Airbyte](https://docs.airbyte.com/platform/deploying-airbyte#6-set-up-port-forward-for-ui-access)] (Il comando esatto ti viene anche stampato alla fine dell’`helm install`.)[[Deploying 1.8](https://docs.airbyte.com/platform/1.8/deploying-airbyte#6-set-up-port-forward-for-ui-access)] --- ### 2. Accesso “permanente” con Ingress / Load Balancer Se vuoi evitare il port‑forward e avere un URL stabile: 1. Installa un Ingress Controller (es. NGINX o AWS ALB, se sei su EKS; su GKE puoi usare l’ingress di GKE). 2. Crea una risorsa

Ingress

che punti al servizio Airbyte (per le versioni recenti, al servizio

airbyte-server-svc

): Esempio NGINX:

Copy code

yaml    apiVersion: <http://networking.k8s.io/v1|networking.k8s.io/v1>    kind: Ingress    metadata:      name: airbyte-ingress      annotations:        <http://nginx.ingress.kubernetes.io/ssl-redirect|nginx.ingress.kubernetes.io/ssl-redirect>: "false"    spec:      ingressClassName: nginx      rules:        - host: <http://airbyte.example.com|airbyte.example.com>   # sostituisci con il tuo host          http:            paths:              - backend:                  service:                    name: airbyte-airbyte-server-svc                    port:                      number: 8001                path: /                pathType: Prefix

[[Ingress 1.7](https://docs.airbyte.com/platform/1.7/deploying-airbyte/integrations/ingress); [Ingress 1.8](https://docs.airbyte.com/platform/1.8/deploying-airbyte/integrations/ingress)] 3. Punta il DNS (o usa l’IP dell’Ingress/Load Balancer) e apri

http://<tuo-host>

nel browser. --- Se mi dici che namespace stai usando (

airbyte

airbyte-v2

) e se vuoi solo test locale o un URL pubblico su GKE, posso indicarti il comando / manifest più preciso.

Fabrizio Spini

12/16/2025, 11:39 AM

@kapa.ai I'm trying to create a source mysql on airbyte 2.0.1 deployed on gke but on source-mysql-check sidecar I have

Copy code

2025-12-16 11:36:01,075 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.AirbyteConnectorRunnable(run):35 Executing class io.airbyte.cdk.check.CheckOperation operation.
2025-12-16 11:36:01,076 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.c.CheckOperation(execute):33 Parsing connector configuration JSON object.
2025-12-16 11:36:01,076 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.c.CheckOperation(execute):35 Building internal connector configuration object.
2025-12-16 11:36:01,077 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.i.s.m.MySqlSourceConfigurationFactory(makeWithoutExceptionHandling):140 SSL mode: required
2025-12-16 11:36:01,077 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.i.s.m.MySqlSourceConfigurationFactory(makeWithoutExceptionHandling):180 maxConcurrencyLegacy: 1. maxDBConnections: null. socket paths: 0
2025-12-16 11:36:01,078 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.i.s.m.MySqlSourceConfigurationFactory(makeWithoutExceptionHandling):199 Effective concurrency: 1
2025-12-16 11:36:01,078 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.c.CheckOperation(execute):37 Connecting for config check.
2025-12-16 11:36:01,079 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.j.JdbcConnectionFactory(get):44 Creating new connection for 'jdbc:<mysql://rds-bifrost.service-management.prd.aws.lmn:3306>'.
2025-12-16 11:36:01,082 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.c.CheckOperation(execute):48 Config check failed.
2025-12-16 11:36:01,082 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.AirbyteConnectorRunnable(run):47 Flushing output consumer prior to shutdown.
2025-12-16 11:36:01,083 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.AirbyteConnectorRunnable(run):49 Completed integration: airbyte/source-mysql.
2025-12-16 11:36:01,085 [main]	INFO	i.a.c.ConnectorMessageProcessor(updateConfigFromControlMessage):281 - Checking for optional control message...
2025-12-16 11:36:01,085 [main]	INFO	i.a.c.ConnectorMessageProcessor(updateConfigFromControlMessage):303 - Optional control message not found. Skipping...
2025-12-16 11:36:01,089 [main]	INFO	i.a.c.ConnectorWatcher(saveConnectorOutput):186 - Writing output of 435bb9a5-7887-4809-aa58-28c27df0d7ad_c1ff28ec-dec4-4302-90e6-ef0e276f9480_0_check to the doc store
2025-12-16 11:36:01,368 [main]	INFO	i.a.c.ConnectorWatcher(markWorkloadSuccess):191 - Marking workload 435bb9a5-7887-4809-aa58-28c27df0d7ad_c1ff28ec-dec4-4302-90e6-ef0e276f9480_0_check as successful
2025-12-16 11:36:01,417 [pool-6-thread-1]	INFO	i.a.c.i.LineGobbler$Companion(gobble$lambda$2):108 -
2025-12-16 11:36:01,417 [main]	INFO	i.a.c.ConnectorWatcher(exitProperly):248 - Deliberately exiting process with code 0.
2025-12-16 11:36:01,418 [pool-6-thread-1]	INFO	i.a.c.i.LineGobbler$Companion(gobble$lambda$2):108 - ----- END CHECK -----
2025-12-16 11:36:01,418 [pool-6-thread-1]	INFO	i.a.c.i.LineGobbler$Companion(gobble$lambda$2):108 -

kapa.ai

12/16/2025, 11:39 AM

A message from kapa.ai

kapa.ai

12/16/2025, 11:39 AM

Dai log che hai incollato si vede solo che: - Il connettore MySQL parte e legge la config - Prova a connettersi (

Creating new connection for 'jdbc:<mysql://...:3306>'

) - Subito dopo logga

Config check failed.

- Il sidecar salva correttamente l’output nel doc store e marca il workload come

successful

- Il processo esce con codice 0 Quindi: - Il job “check” lato piattaforma è considerato riuscito (exit code 0, workload marked successful). - Ma il check della connessione MySQL è fallito internamente (

Config check failed.

), solo che nei log che hai riportato manca il dettaglio dell’errore (stack trace / messaggio MySQL). Nelle sorgenti che ho a disposizione non c’è un esempio di questo identico pattern di log con

Config check failed

per MySQL su Airbyte 2.0.1, quindi non posso dirti con certezza quale sia la causa specifica (credenziali, rete, SSL, ecc.). Le pagine di troubleshooting MySQL parlano di problemi comuni (timeout, SSL/TLS, parametri JDBC) ma non di questo log esatto.[\[MySQL troubleshooting\]](https://docs.airbyte.com/integrations/sources/mysql/mysql-troubleshooting#troubleshooting) Per capire cosa non va devi: 1. Guardare i log completi del container
source-mysql
(non solo il sidecar) Il messaggio di errore vero (es.

Access denied

Communications link failure

, problemi SSL, ecc.) dovrebbe comparire subito dopo la riga:

Copy code

text    Creating new connection for 'jdbc:<mysql://...>'

ma prima di

Config check failed.

2. Verificare SSL / rete in base alla tua config Dai log:

SSL mode: required

. Se il tuo RDS non è configurato per SSL o il certificato non è accettato, il check può fallire. La documentazione MySQL suggerisce di aggiungere parametri JDBC specifici per alcuni casi (es. RDS/TLS), ma non entra nel dettaglio di questo errore.[\[MySQL troubleshooting\]](https://docs.airbyte.com/integrations/sources/mysql/mysql-troubleshooting#troubleshooting) 3. Controllare cosa mostra la UI di Airbyte per quel check Nella pagina della sorgente, il risultato del test connessione dovrebbe mostrare il messaggio di errore restituito dal connettore (lo stesso che vedi nei log completi del container

source-mysql

). Con le informazioni presenti nelle knowledge sources non c’è una soluzione “nota” per questo caso specifico; il passo successivo è recuperare e condividere il messaggio di errore dettagliato dal container

source-mysql

(non solo dal sidecar) per capire se è un problema di credenziali, rete (GKE → RDS), o SSL.

Fabrizio Spini

12/16/2025, 11:41 AM

@kapa.ai

Copy code

(base) ➜  ~ kubectl -n airbyte-v2 logs source-mysql-check-c1ff28ec-dec4-4302-90e6-ef0e276f9480-0-wohlv --follow
Defaulted container "connector-sidecar" out of: connector-sidecar, main, init (init)
Unsetting empty environment variable 'DATA_PLANE_SERVICE_ACCOUNT_CREDENTIALS_PATH'
Unsetting empty environment variable 'DATA_PLANE_SERVICE_ACCOUNT_EMAIL'
Unsetting empty environment variable 'AIRBYTE_ROLE'
2025-12-16 11:33:43,924 [main]	INFO	i.a.c.ApplicationKt(main):14 - Sidecar start

    ___    _      __          __
   /   |  (_)____/ /_  __  __/ /____
  / /| | / / ___/ __ \/ / / / __/ _ \
 / ___ |/ / /  / /_/ / /_/ / /_/  __/
/_/  |_/_/_/  /_.___/\__, /\__/\___/
                    /____/
 : airbyte-connector-sidecar :

2025-12-16 11:33:45,406 [main]	INFO	i.m.c.e.DefaultEnvironment(<init>):170 - Established active environments: [worker-v2, k8s, control-plane, edition-community, local-secrets]
2025-12-16 11:33:46,264 [main]	INFO	i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'INFO' for logger: 'io.netty'
2025-12-16 11:33:46,266 [main]	INFO	i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'ERROR' for logger: 'com.zaxxer.hikari'
2025-12-16 11:33:46,267 [main]	INFO	i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'INFO' for logger: 'io.grpc'
2025-12-16 11:33:46,267 [main]	INFO	i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'INFO' for logger: 'io.temporal'
2025-12-16 11:33:46,268 [main]	INFO	i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'ERROR' for logger: 'com.zaxxer.hikari.pool'
2025-12-16 11:33:46,268 [main]	INFO	i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'INFO' for logger: 'io.fabric8.kubernetes.client'
2025-12-16 11:33:46,294 [main]	INFO	i.m.r.Micronaut(start):183 - No embedded container found. Running as CLI application
2025-12-16 11:33:48,651 [pool-3-thread-1]	INFO	i.a.c.i.LineGobbler$Companion(gobble$lambda$2):108 -
2025-12-16 11:33:48,653 [pool-2-thread-1]	INFO	i.a.c.HeartbeatMonitor$HeartbeatTask(run):92 - Transitioning workload to running state
2025-12-16 11:33:48,678 [pool-3-thread-1]	INFO	i.a.c.i.LineGobbler$Companion(gobble$lambda$2):108 - ----- START CHECK -----
2025-12-16 11:33:48,678 [pool-3-thread-1]	INFO	i.a.c.i.LineGobbler$Companion(gobble$lambda$2):108 -
2025-12-16 11:33:48,823 [pool-2-thread-1]	INFO	i.a.c.HeartbeatMonitor$HeartbeatTask(run):94 - Workload successfully transitioned to running state
2025-12-16 11:36:00,949 [main]	INFO	i.a.c.ConnectorWatcher(processConnectorOutput):138 - Connector exited, processing output
2025-12-16 11:36:00,949 [main]	INFO	i.a.c.ConnectorWatcher(getConnectorOutputStream):175 - Output file jobOutput.json found
2025-12-16 11:36:00,951 [main]	INFO	i.a.c.ConnectorWatcher(processConnectorOutput):141 - Connector exited with exit code 0
2025-12-16 11:36:00,956 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(create):122 - Reading messages from protocol version 0.2.0
2025-12-16 11:36:01,073 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.m.c.e.DefaultEnvironment(<init>):168 Established active environments: [k8s, cloud, cli, source, connector]
2025-12-16 11:36:01,075 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.AirbyteConnectorRunnable(run):35 Executing class io.airbyte.cdk.check.CheckOperation operation.
2025-12-16 11:36:01,076 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.c.CheckOperation(execute):33 Parsing connector configuration JSON object.
2025-12-16 11:36:01,076 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.c.CheckOperation(execute):35 Building internal connector configuration object.
2025-12-16 11:36:01,077 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.i.s.m.MySqlSourceConfigurationFactory(makeWithoutExceptionHandling):140 SSL mode: required
2025-12-16 11:36:01,077 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.i.s.m.MySqlSourceConfigurationFactory(makeWithoutExceptionHandling):180 maxConcurrencyLegacy: 1. maxDBConnections: null. socket paths: 0
2025-12-16 11:36:01,078 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.i.s.m.MySqlSourceConfigurationFactory(makeWithoutExceptionHandling):199 Effective concurrency: 1
2025-12-16 11:36:01,078 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.c.CheckOperation(execute):37 Connecting for config check.
2025-12-16 11:36:01,079 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.j.JdbcConnectionFactory(get):44 Creating new connection for 'jdbc:<mysql://rds-bifrost.service-management.prd.aws.lmn:3306>'.
2025-12-16 11:36:01,082 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.c.CheckOperation(execute):48 Config check failed.
2025-12-16 11:36:01,082 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.AirbyteConnectorRunnable(run):47 Flushing output consumer prior to shutdown.
2025-12-16 11:36:01,083 [main]	INFO	i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.AirbyteConnectorRunnable(run):49 Completed integration: airbyte/source-mysql.
2025-12-16 11:36:01,085 [main]	INFO	i.a.c.ConnectorMessageProcessor(updateConfigFromControlMessage):281 - Checking for optional control message...
2025-12-16 11:36:01,085 [main]	INFO	i.a.c.ConnectorMessageProcessor(updateConfigFromControlMessage):303 - Optional control message not found. Skipping...
2025-12-16 11:36:01,089 [main]	INFO	i.a.c.ConnectorWatcher(saveConnectorOutput):186 - Writing output of 435bb9a5-7887-4809-aa58-28c27df0d7ad_c1ff28ec-dec4-4302-90e6-ef0e276f9480_0_check to the doc store
2025-12-16 11:36:01,368 [main]	INFO	i.a.c.ConnectorWatcher(markWorkloadSuccess):191 - Marking workload 435bb9a5-7887-4809-aa58-28c27df0d7ad_c1ff28ec-dec4-4302-90e6-ef0e276f9480_0_check as successful
2025-12-16 11:36:01,417 [pool-6-thread-1]	INFO	i.a.c.i.LineGobbler$Companion(gobble$lambda$2):108 -
2025-12-16 11:36:01,417 [main]	INFO	i.a.c.ConnectorWatcher(exitProperly):248 - Deliberately exiting process with code 0.
2025-12-16 11:36:01,418 [pool-6-thread-1]	INFO	i.a.c.i.LineGobbler$Companion(gobble$lambda$2):108 - ----- END CHECK -----
2025-12-16 11:36:01,418 [pool-6-thread-1]	INFO	i.a.c.i.LineGobbler$Companion(gobble$lambda$2):108 -

kapa.ai

12/16/2025, 11:41 AM

A message from kapa.ai

kapa.ai

12/16/2025, 11:42 AM

The knowledge sources you provided don’t contain this exact log pattern for Airbyte 2.x (Micronaut sidecar,

CheckOperation

Config check failed

with no error details), so I can’t point to a documented root cause or fix. They only show older MySQL issues (timeouts, RDS TLS params, CDC/SSL, etc.), not this specific behavior.[\[MySQL troubleshooting\]](https://docs.airbyte.com/integrations/sources/mysql/mysql-troubleshooting#troubleshooting) From your logs: - The connector process exits with code 0 and the sidecar marks the workload as successful: -

Connector exited with exit code 0

Marking workload ..._check as successful

- But inside the connector logs you see: -

Config check failed.

right after

Creating new connection for 'jdbc:<mysql://...:3306>'

So the MySQL check is failing internally, but the sidecar still treats the workload as technically “successful” (it only cares that the connector ran and produced output). The real error message is not visible in the sidecar logs you posted. Given what’s in the docs and issues, the only grounded guidance I can give is: 1. Look at the connector container logs (
main
), not only the sidecar Your

kubectl logs

defaulted to

connector-sidecar

. You need the logs from the

main

container in the same pod, which should include the actual JDBC / MySQL error (e.g. access denied, SSL handshake, network timeout, etc.). For example:

Copy code

bash    kubectl -n airbyte-v2 logs source-mysql-check-c1ff28ec-dec4-4302-90e6-ef0e276f9480-0-wohlv -c main

That output is what the UI uses to show the “reason” for the failed check. 2. Check SSL vs. RDS configuration The log shows

SSL mode: required

. If your RDS instance is not configured as the connector expects (or needs extra JDBC params), the connection can fail. The MySQL troubleshooting page mentions that for some RDS setups you must add specific JDBC parameters (e.g. TLS protocol) to avoid connection issues, though it doesn’t give an example for this exact error.[\[MySQL troubleshooting\]](https://docs.airbyte.com/integrations/sources/mysql/mysql-troubleshooting#troubleshooting) 3. Check what the UI shows for this check In the Airbyte UI, on the MySQL source page, the connection test result should display the error message that comes from the connector (the same one you’ll see in the

main

container logs). That will tell you whether it’s: - credentials (

Access denied

), - network (

Communications link failure

), - SSL (

connection is insecure

, certificate issues), - or something else. Because the knowledge sources don’t document this exact “Config check failed but workload marked successful” pattern for MySQL on 2.0.1, I can’t give a specific fix beyond: retrieve the

main

container logs for that pod and use the detailed JDBC/MySQL error to decide next steps (credentials, network from GKE to RDS, or SSL/JDBC parameters).

Fabrizio Spini

12/16/2025, 1:17 PM

@kapa.ai nella ui di airbyte 2.0.1 creando una source mysql ho

Copy code

Failed to save MySQL - vg_stats due to the following error: Could not connect with provided configuration. Error: State code: 08S01; Message: Communications link failure The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.

kapa.ai

12/16/2025, 1:17 PM

A message from kapa.ai

kapa.ai

12/16/2025, 1:17 PM

L’errore che vedi in UI: >

State code: 08S01; Message: Communications link failure ... The driver has not received any packets from the server.

è esattamente il tipo di problema di connettività MySQL che Airbyte documenta per MySQL/RDS: il driver non riesce proprio ad aprire la connessione verso il server (nessun pacchetto ricevuto).[[MySQL troubleshooting](https://docs.airbyte.com/integrations/sources/mysql/mysql-troubleshooting#troubleshooting)] Dalle knowledge sources, le cause più comuni sono: 1. Problema di rete / VPC / firewall (molto probabile su GKE → RDS) - Per RDS MySQL o MariaDB, Airbyte segnala che errori di connessione (inclusi quelli che poi portano a timeout o “communications link failure”) spesso dipendono dal fatto che il database non è raggiungibile dalla rete dove gira Airbyte (VPC, security group, firewall, ecc.).[[MySQL troubleshooting](https://docs.airbyte.com/integrations/sources/mysql/mysql-troubleshooting#troubleshooting)] - Verifica che: - Il Security Group / firewall di RDS permetta traffico in ingresso sulla porta 3306 dall’IP o dal range IP dei nodi GKE. - L’endpoint che usi in Airbyte (host/porta) sia lo stesso che usi da altri client, ma soprattutto che sia raggiungibile dal cluster GKE, non solo dal tuo PC. 2. Parametri TLS / JDBC per RDS MySQL / MariaDB - La documentazione MySQL di Airbyte riporta che, per alcuni RDS MySQL/MariaDB, se vedi errori di connessione tipo

Cannot create a PoolableConnectionFactory

, devi aggiungere il parametro JDBC:

enabledTLSProtocols=TLSv1.2

.[[MySQL destination docs](https://docs.airbyte.com/integrations/destinations/mysql#troubleshooting); [PoolableConnectionFactory forum](https://discuss.airbyte.io/t/244)] - Anche se il tuo messaggio è “communications link failure” e non “PoolableConnectionFactory”, su RDS può comunque essere utile provare ad aggiungere in Airbyte, nel campo JDBC parameters della sorgente MySQL, qualcosa come: -

enabledTLSProtocols=TLSv1.2

- Assicurati anche che la modalità SSL che hai scelto in UI sia compatibile con la configurazione di RDS (se RDS richiede SSL e in Airbyte è disabilitato, o viceversa, la connessione può fallire subito). 3. Uso di MariaDB con il connettore MySQL - Le fonti segnalano che l’uso del connettore MySQL contro MariaDB è “fragile” e può dare errori di connessione.[[MariaDB forum](https://discuss.airbyte.io/t/2863)] - Se il tuo endpoint è MariaDB (non MySQL), tieni presente che non è ufficialmente supportato e può fallire anche se altri client si connettono. 4. Verifica di base da dentro il cluster - Anche se non è descritto passo‑passo nelle fonti, l’errore “The driver has not received any packets from the server” è coerente con un problema di reachability: Airbyte prova a connettersi, ma non riceve risposta. - Per confermare che è rete/VPC e non credenziali, puoi: - Lanciare un pod di debug nello stesso namespace (

airbyte-v2

) e provare un

telnet <host> 3306

mysql -h <host> -P 3306

da lì. Se non risponde, è sicuramente un problema di rete / firewall. Riassumendo, sulla base delle knowledge sources: - L’errore 08S01 / communications link failure indica che Airbyte non riesce a raggiungere il server MySQL.[[MySQL troubleshooting](https://docs.airbyte.com/integrations/sources/mysql/mysql-troubleshooting#troubleshooting)] - Su RDS/MariaDB, controlla attentamente: - Security group / VPC / firewall (GKE deve poter uscire verso RDS sulla porta 3306). - Eventuali parametri JDBC per TLS, in particolare

enabledTLSProtocols=TLSv1.2

se usi TLS su RDS.[[MySQL destination docs](https://docs.airbyte.com/integrations/destinations/mysql#troubleshooting)] - Se dopo aver aperto la rete e aggiunto il parametro TLS l’errore persiste, le fonti non forniscono ulteriori indicazioni specifiche per Airbyte 2.0.1, quindi il passo successivo sarebbe raccogliere i log completi del container

main

del pod

source-mysql-check

e aprire un ticket con quei dettagli.

5 Views

Open in Slack

Previous Next