Realtime Compute for Apache Flink:Flink CDC FAQ

¿Es posible configurar el despliegue para que se cancele en lugar de reiniciarse ante un error?

Establezca una estrategia de reinicio en la configuración del despliegue. A continuación se muestra un ejemplo que limita los reinicios a dos intentos con un intervalo de 10 segundos. Si ambos intentos fallan, el despliegue se cancela.

restart-strategy: fixed-delay
restart-strategy.fixed-delay.attempts: 2
restart-strategy.fixed-delay.delay: 10 s

Las tablas de origen de MySQL CDC y Hologres CDC no admiten funciones de ventana. ¿Cómo implemento agregaciones por minuto?

Utilice DATE_FORMAT para convertir las marcas de tiempo en cadenas con nivel de minuto y aplique GROUP BY sobre esas cadenas. En el siguiente ejemplo se calculan el número de pedidos y los ingresos por tienda cada minuto:

SELECT
    shop_id,
    DATE_FORMAT(order_ts, 'yyyy-MM-dd HH:mm') AS window,
    COUNT(*) AS order_count,
    SUM(price) AS amount
FROM order_mysql_cdc
GROUP BY shop_id, window

¿Se puede usar una tabla de MySQL CDC como tabla de dimensiones o tabla de destino?

No. Una tabla de MySQL CDC solo funciona como tabla de origen, ya que lee datos completos e incrementales de MySQL. Para escenarios de tabla de dimensiones o de destino, utilice una tabla de MySQL estándar (sin CDC).

¿Por qué el conector de MySQL CDC se detiene tras leer los datos completos y no cambia a modo incremental?

Este comportamiento suele deberse a una de cuatro causas:

• Instancias secundarias o de solo lectura de ApsaraDB RDS for MySQL V5.6: Estas instancias no escriben datos en los archivos de registro binario, por lo que el conector no tiene datos incrementales que leer. Utilice una instancia con capacidad de escritura o actualice a una versión posterior a V5.6.

• Compresión de transacciones del registro binario habilitada: Las tablas de origen de MySQL CDC no admiten esta compresión. Deshabilite esta función en los clústeres de MySQL autogestionados.

• Error de falta de memoria (OOM) durante la lectura de datos completos: Si el último shard es demasiado grande, un error OOM suspende el despliegue tras el failover. Aumente el paralelismo para acelerar la lectura de datos completos.

• Intervalo de checkpoint demasiado largo: Cuando todas las subtareas paralelas terminan de leer los datos completos, el conector espera un checkpoint antes de cambiar a modo incremental. Un intervalo de 20 minutos implica un retraso de 20 minutos. Establezca un intervalo de checkpoint más corto según sus necesidades.

¿Cómo compruebo que la sincronización de datos completos finalizó?

Existen dos métodos:

• Métrica currentEmitEventTimeLag: En la pestaña Metrics de la página Deployments, revise esta métrica. Un valor ≤ 0 indica que la sincronización completa continúa en curso; un valor > 0 significa que el conector terminó la sincronización completa y comenzó a leer datos del registro binario.

  

• Registro de TaskManager: Busque BinlogSplitReader is created en los registros de TaskManager. Este mensaje confirma que la lectura de datos completos finalizó.

  4123  2022-01-12 05:12:52,157 [pool-6757-thread-1] INFO  io.debezium.jdbc.JdbcConnection                    [] - Connection gracefully close...
  4124  2022-01-12 05:12:52,158 [Source: TableSourceScan(table=[[vvp, default, ods_ex_trade_detail_spot_mysql_cdc ... with job vertex id
           6698b6cdb93164bb0e3bb97f2a17fcd7 (1/4)#0] INFO  org.apache.flink.connector.base.source.reader.SourceReaderBase [] - Adding split(s) to reader:
           [MySqlBinlogSplit{splitId='binlog-split', offset={ts_sec=0, file=mysql-bin.008066, pos=459422339,
           gtids=c32c3579-5c0d-11ec-889a-00163e368abf:1-311125098, row=0, event=0}, endOffset={ts_sec=0, file=, pos=-9223372036854775808, row=0, event=0}}]
  4125  2022-01-12 05:12:52,158 [Source Data Fetcher for Source: TableSourceScan(table=[[vvp, default, ods_ex_trade_detail_spot_mysql_cdc ... with job
           vertex id 6698b6cdb93164bb0e3bb97f2a17fcd7 (1/4)#0] INFO  org.apache.flink.connector.base.source.reader.fetcher.SplitFetcher [] - Starting split
           fetcher_138?
  4126  2022-01-12 05:12:52,159 [Source Data Fetcher for Source: TableSourceScan(table=[[vvp, default, ods_ex_trade_detail_spot_mysql_cdc ... with job
           vertex id 6698b6cdb93164bb0e3bb97f2a17fcd7 (1/4)#0] INFO  com.ververica.cdc.connectors.mysql.source.reader.MySqlSplitReader [] - BinlogSplitReader
           is created.
  4127  2022-01-12 05:12:56,853 [Source Data Fetcher for Source: TableSourceScan(table=[[vvp, default, ods_ex_trade_detail_spot_mysql_cdc ... with job
           vertex id 6698b6cdb93164bb0e3bb97f2a17fcd7 (1/4)#0] WARN  io.debezium.relational.history.DatabaseHistoryMetrics          [] - Unable to register the
           MBean 'debezium.mysql:type=connector-metrics,context=schema-history,server=mysql_binlog_source': debezium.mysql:type=connector-metrics,
           context=schema-history,server=mysql_binlog_source
  4128  2022-01-12 05:12:56,860 [Source Data Fetcher for Source: TableSourceScan(table=[[vvp, default, ods_ex_trade_detail_spot_mysql_cdc ... with job

  La línea 4126 muestra BinlogSplitReader is created, lo cual indica que la lectura de datos completos finalizó y el despliegue pasó a la lectura incremental del registro binario. El registro WARN de la línea 4127 (Unable to register the MBean) es normal y no afecta la sincronización de datos.

¿Cambia la posición inicial cuando reinicio un despliegue?

Depende de la opción Starting Strategy que seleccione en el cuadro de diálogo Deployment Starting Configuration:

• NONE: El conector vuelve a leer desde la posición inicial configurada.

• Latest State: El conector reanuda la lectura desde la posición del registro binario donde se canceló el despliegue por última vez.

Por ejemplo, si el despliegue se configuró para iniciar en {file=mysql-bin.01, position=40} pero se canceló en la posición 210, Latest State reanuda en 210 y NONE reinicia desde 40.

¿Cómo funciona el conector de MySQL CDC y cómo afecta a la base de datos?

Cuando scan.startup.mode se establece en initial (valor predeterminado), el conector realiza lo siguiente:

1. Se conecta mediante JDBC y ejecuta una instrucción SELECT para leer los datos completos. Además, registra la posición actual del registro binario.

2. Tras leer los datos completos, cambia al cliente de binlog para leer los cambios incrementales desde la posición registrada.

La lectura de datos completos aumenta la carga de consultas debido a la instrucción SELECT. Durante la lectura incremental, cada tabla de origen mantiene una conexión de binlog. Si tiene muchas tablas de origen, verifique el límite de conexiones:

show variables like '%max_connections%';

¿Cómo omito la fase de instantánea y leo únicamente los datos de cambio?

Establezca scan.startup.mode en la cláusula WITH con uno de estos valores: earliest-offset, latest-offset, specific-offset o timestamp. Para obtener más información, consulte la sección "Parameters in the WITH clause" en Create a MySQL CDC source table.

¿Cómo localiza MySQL CDC la posición del binlog cuando scan.startup.mode = timestamp?

Con el modo de inicio timestamp, MySQL CDC determina la posición inicial de consumo de la siguiente manera:

1. Analiza todos los archivos de binlog y busca el primer archivo cuya fecha de última modificación sea mayor o igual que la marca de tiempo especificada.

2. Lee los eventos de binlog desde el inicio de ese archivo.

3. Omite los eventos cuya marca de tiempo sea anterior a la marca de tiempo especificada.

4. Comienza a consumir desde el primer evento cuya marca de tiempo sea mayor o igual que la marca de tiempo especificada.

Casos límite:

• Si la marca de tiempo especificada está en el futuro, el consumo comienza desde la última posición disponible. Esto equivale a latest-offset.

• Si el binlog correspondiente a la marca de tiempo especificada ya se purgó, el consumo comienza desde la primera posición disponible. Esto equivale a earliest-offset.

¿Cómo gestiona el conector las tablas fragmentadas de MySQL?

Utilice el parámetro table-name con una expresión regular para coincidir con todos los shards. Por ejemplo, para supervisar todas las tablas con el prefijo user_:

'table-name' = 'user_.*'

Si todas las tablas de los distintos shards tienen el mismo esquema, utilice database-name con una expresión regular.

¿Qué hago si las comas en la expresión regular de table-name provocan errores de análisis sintáctico?

Debezium usa comas como delimitadores, por lo que un patrón como t_process_wi_history_\d{1,2} genera un error.

13-vvr-4.0.13-1-SNAPSHOT.jar:1.13-vvr-4.0.13-1-SNAPSHOT]
Caused by: java.util.regex.PatternSyntaxException: Unclosed counted closure near index 35
zhangtest.t_process_wi_history_\d{1
	at java.util.regex.Pattern.error(Pattern.java:1969) ~[?:1.8.0_302]
	at java.util.regex.Pattern.closure(Pattern.java:3155) ~[?:1.8.0_302]

Utilice alternancia en su lugar:

'table-name' = '(t_process_wi_history_\d{1}|t_process_wi_history_\d{2})'

Varios despliegues de MySQL CDC generan una carga alta en la base de datos. ¿Qué puedo hacer?

Tiene dos alternativas:

• Descargar la carga hacia Kafka: Sincronice la tabla de origen de MySQL CDC con una tabla de destino de ApsaraMQ for Kafka. Luego, los demás despliegues consumen desde Kafka en lugar de leer los registros binarios directamente. Consulte Synchronize data from all tables in a MySQL database to Kafka.

• Fusionar despliegues con un server ID compartido: Si varios despliegues CREATE TABLE AS comparten la misma configuración, asigne el mismo server ID para reutilizar el origen de datos. Consulte Example 4: execution of multiple CREATE TABLE AS statements.

Una actualización pequeña provoca un uso de ancho de banda inusualmente alto. ¿Por qué?

Los archivos de registro binario contienen los cambios de todas las bases de datos y tablas de la instancia de MySQL, no solo de las que supervisa su despliegue. Si su instancia tiene tres tablas, el registro binario transporta los cambios de las tres, incluso si su despliegue rastrea solo una.

Para solucionarlo, reutilice la tabla de origen de MySQL CDC de modo que varios despliegues compartan una única conexión de binlog. Consulte la sección "Enabling of the reuse of a MySQL CDC source table" en MySQL connector.

Los campos de marca de tiempo muestran un desfase de 8 horas respecto a la zona horaria del servidor MySQL. ¿Por qué?

Existen dos causas posibles:

• El parámetro server-time-zone del despliegue CDC no coincide con la zona horaria real del servidor MySQL. Actualice server-time-zone para que coincida.

• Un deserializador personalizado (MyDeserializer implements DebeziumDeserializationSchema) no establece serverTimeZone. Configure serverTimeZone según la forma en que RowDataDebeziumDeserializeSchema analiza los datos TIMESTAMP:

  private TimestampData convertToTimestamp(Object dbzObj, Schema schema) {
      if (dbzObj instanceof Long) {
          switch (schema.name()) {
              case Timestamp.SCHEMA_NAME:
                 return TimestampData.fromEpochMillis((Long) dbzObj);
              case MicroTimestamp.SCHEMA_NAME:
                 long micro = (long) dbzObj;
                 return TimestampData.fromEpochMillis(micro / 1000, (int) (micro % 1000 * 1000));
              case NanoTimestamp.SCHEMA_NAME:
                 long nano = (long) dbzObj;
                 return TimestampData.fromEpochMillis(nano / 1000_000, (int) (nano % 1000_000));
          }
      }
      LocalDateTime localDateTime = TemporalConversions.toLocalDateTime(dbzObj, serverTimeZone);
      return TimestampData.fromLocalDateTime(localDateTime);
  }

¿El conector de MySQL CDC admite escuchar bases de datos secundarias?

Sí. Agregue lo siguiente a la configuración de la base de datos secundaria para que los datos sincronizados desde la primaria se escriban en el registro binario de la secundaria:

log-slave-updates = 1

Si el modo Global Transaction Identifier (GTID) está habilitado en la base de datos primaria, habilítelo también en la secundaria:

gtid_mode = on
enforce_gtid_consistency = on

¿Cómo capturo eventos DDL?

Utilice la API DataStream con MySqlSource y establezca includeSchemaChanges(true):

MySqlSource<xxx> mySqlSource =
    MySqlSource.<xxx>builder()
        .hostname(...)
        .port(...)
        .databaseList("<databaseName>")
        .tableList("<databaseName>.<tableName>")
        .username(...)
        .password(...)
        .serverId(...)
        .deserializer(...)
        .includeSchemaChanges(true) // Capture DDL events
        .build();
// Add downstream processing logic

¿MySQL CDC permite sincronizar todas las tablas de una base de datos a la vez?

Sí. Utilice la instrucción CREATE TABLE AS o CREATE DATABASE AS. Consulte CREATE TABLE AS statement o CREATE DATABASE AS statement.

Las instancias de ApsaraDB RDS for MySQL V5.6 no escriben cambios incrementales en los archivos de registro binario, por lo que el conector no puede leer datos incrementales de ellas.

Los datos incrementales de una tabla específica no se sincronizan. ¿Por qué?

Es posible que un filtro de registro binario en el servidor MySQL esté excluyendo esa base de datos. Ejecute el siguiente comando para comprobarlo:

show master status;

Revise las columnas Binlog_Ignore_DB y Binlog_Do_DB en el resultado:

+------------------+----------+--------------+------------------+----------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |  Executed_Gtid_Set   |
+------------------+----------+--------------+------------------+----------------------+
| mysql-bin.000006 |     4594 |              |                  | xxx:1-15             |
+------------------+----------+--------------+------------------+----------------------+

¿Cómo configuro tableList al usar la API DataStream para MySQL CDC?

El valor de tableList debe incluir tanto el nombre de la base de datos como el de la tabla, con el formato yourDatabaseName.yourTableName.

¿El conector reanuda desde un checkpoint si el despliegue falla durante la lectura de datos completos?

Sí. Establezca 'scan.incremental.snapshot.enabled' = 'true' en la cláusula WITH para habilitar la recuperación basada en checkpoints durante la lectura de datos completos.

¿MongoDB CDC admite leer únicamente datos incrementales?

De forma predeterminada, el conector lee datos completos e incrementales. Para omitir los datos completos y leer solo los cambios incrementales, establezca 'scan.startup.mode' = 'latest-offset' en la cláusula WITH.

¿Es posible suscribirse únicamente a colecciones específicas?

No. El conector se suscribe a nivel de base de datos. Establezca 'database' = 'mgdb' y 'collection' = '' en la cláusula WITH para suscribirse a todas las colecciones de la base de datos.

¿MongoDB CDC admite lectura concurrente?

Sí, durante la fase de instantánea inicial. Establezca scan.incremental.snapshot.enabled en true para habilitar la lectura concurrente.

¿Qué versiones de MongoDB son compatibles?

MongoDB 3.6 y posteriores (los change streams se introdujeron en la versión 3.6). Se recomienda MongoDB 4.0 o superior. En versiones anteriores a 3.6, el conector devuelve el error "Unrecognized pipeline stage name: '$changeStream'".

¿Qué arquitecturas de MongoDB son compatibles?

El conector requiere un replica set o un clúster fragmentado, ya que los change streams solo funcionan en estos modos. Para pruebas locales, convierta MongoDB en un replica set de un solo nodo mediante rs.initiate(). Sin este paso, el conector devuelve "The $changestage is only supported on replica sets".

¿MongoDB CDC admite parámetros de Debezium?

No. El conector de MongoDB CDC se desarrolló de forma independiente en Flink CDC y no depende de Debezium.

La autenticación falla aunque las credenciales sean correctas. ¿Por qué?

Las credenciales del usuario están limitadas a una base de datos específica. Agregue 'connection.options' = 'authSource=<database_the_user_belongs_to>' a la cláusula WITH.

¿El conector reanuda desde un checkpoint después de reiniciar el despliegue?

Sí. Los checkpoints almacenan tokens de reanudación para los change streams. Cuando el despliegue se reinicia, el conector lee el token de reanudación y continúa desde la posición correspondiente en la colección oplog.rs.

Si el token de reanudación ya no existe en oplog.rs (una colección de capacidad fija que rota al llenarse), aumente el tamaño del oplog para evitar rotaciones prematuras. Consulte Change the Oplog Size of Self-Managed Replica Set Members.

¿MongoDB CDC admite mensajes UPDATE_BEFORE (imágenes previas a la actualización)?

Depende de la versión de MongoDB:

• MongoDB 6.0 y posteriores con pre-image/post-image habilitado: Establezca 'scan.full-changelog' = 'true'. MongoDBSource genera mensajes UPDATE_BEFORE directamente.

• Versiones de MongoDB anteriores a 6.0: La colección oplog.rs incluye los tipos INSERT, UPDATE, REPLACE y DELETE, pero no UPDATE_BEFORE. Al usar MongoDBTableSource en modo SQL, el planificador de Flink aplica automáticamente el operador ChangelogNormalize para generar mensajes UPDATE_BEFORE. Sin embargo, este operador almacena todos los estados de clave y añade sobrecarga. Si utiliza la API DataStream con MongoDBSource (sin la optimización del planificador de Flink), ChangelogNormalize no se aplica automáticamente. Gestione el estado usted mismo o utilice MongoDBTableSource y conviértalo a un flujo de changelog:

  tEnv.executeSql("CREATE TABLE orders ( ... ) WITH ( 'connector'='mongodb-cdc', ... )");
  
  Table table = tEnv.from("orders").select($("*"));
  
  tEnv.toChangelogStream(table)
      .print()
      .setParallelism(1);
  
  env.execute();

¿Cómo filtro los valores de fecha no válidos?

Agregue una de las siguientes opciones a la cláusula WITH:

• 'debezium.event.deserialization.failure.handling.mode' = 'warn': Omite los registros no válidos y los registra como advertencias.

• 'debezium.event.deserialization.failure.handling.mode' = 'ignore': Omite los registros no válidos sin generar notificaciones.

Faltan datos TOAST en las actualizaciones. ¿Por qué?

El comportamiento depende de la configuración REPLICA IDENTITY de la tabla:

• REPLICA IDENTITY FULL: Los valores de las columnas TOAST aparecen en los campos before y after de los eventos de cambio, igual que cualquier otra columna.

• REPLICA IDENTITY DEFAULT (valor predeterminado): Las columnas TOAST sin cambios se omiten en los eventos UPDATE. Cuando se usa 'debezium.schema.refresh.mode' = 'columns_diff_exclude_unchanged_toast', el plugin wal2json omite los datos TOAST sin cambios. Por lo tanto, esas columnas solo aparecen en los registros WAL cuando la identidad de réplica es FULL.

Para corregir la ausencia de datos TOAST, establezca la identidad de réplica en FULL:

ALTER TABLE your_table_name REPLICA IDENTITY FULL;

Los registros WAL no se liberan y el uso de disco es alto. ¿Por qué?

El conector de PostgreSQL CDC actualiza el log sequence number (LSN) en los replication slots únicamente cuando finaliza un checkpoint de Flink. Si el uso de disco es alto, compruebe lo siguiente:

• Si los checkpoints están habilitados para el despliegue.

• Si algún replication slot no se utiliza o presenta un retraso de sincronización grande.

¿Qué ocurre cuando la precisión DECIMAL supera la precisión declarada de la columna?

El valor se devuelve como null. Para conservar el valor original, establezca 'debezium.decimal.handling.mode' = 'string' y lea los datos DECIMAL como cadenas.

¿Cómo configuro tableList al usar la API DataStream para PostgreSQL CDC?

El valor de tableList debe incluir tanto el nombre del esquema como el de la tabla, con el formato my_schema.my_table.

¿Por qué no puedo descargar flink-sql-connector-mysql-cdc-2.2-SNAPSHOT.jar?

Las versiones SNAPSHOT corresponden a ramas de desarrollo y no se publican en el repositorio central de Maven. Compile desde el código fuente para usar una versión SNAPSHOT o utilice una versión estable como flink-sql-connector-mysql-cdc-2.1.0.jar, disponible en el repositorio central de Maven.

¿Cuál es la diferencia entre flink-sql-connector-xxx.jar y flink-connector-xxx.jar?

• flink-sql-connector-xxx: Es un JAR completo que incluye el código del conector y todas las dependencias sombreadas (shaded). Agréguelo al directorio lib para los despliegues SQL.

• flink-connector-xxx: Contiene únicamente el código del conector, sin dependencias. Úselo para despliegues DataStream y gestione usted mismo las dependencias de terceros, incluida la resolución de conflictos con operaciones exclude y shade.

¿Por qué no encuentro un paquete de conector de Flink CDC 2.x en el repositorio de Maven?

A partir de Flink CDC 2.0.0, el group ID cambió de com.alibaba.ververica a com.ververica. La ruta de Maven para los paquetes 2.x es /com/ververica/.

Los campos numéricos se devuelven como cadenas al usar JsonDebeziumDeserializationSchema. ¿Cómo lo soluciono?

Configure las propiedades de manejo numérico de Debezium al construir el origen:

Properties properties = new Properties();
properties.setProperty("bigint.unsigned.handling.mode", "long");
properties.setProperty("decimal.handling.mode", "double");

MySqlSource.<String>builder()
    .hostname(config.getHostname())
    // ...
    .debeziumProperties(properties);

Para obtener detalles sobre cómo Debezium convierte los tipos numéricos, consulte Debezium connector for MySQL.

"Replication slot 'xxxx' is active"

Cuando un despliegue de PostgreSQL CDC finaliza, es posible que su replication slot no se libere automáticamente. Libérelo manualmente:

select pg_drop_replication_slot('rep_slot');

Si un proceso activo retiene el slot, finalice primero el proceso:

select pg_terminate_backend(162564);
select pg_drop_replication_slot('rep_slot');

Como alternativa, agregue 'debezium.slot.drop.on.stop' = 'true' a la configuración del origen de PostgreSQL para eliminar el slot automáticamente cuando se cancele el despliegue.

"binlog probably contains events generated with statement or mixed based replication format"

Las tablas de origen de MySQL CDC solo admiten registros binarios en formato ROW. Si el formato es STATEMENT o MIXED, el conector falla.

1. Compruebe el formato actual:

   show variables like "binlog_format";
   -- To check the global setting:
   show global variables like "binlog_format";

2. Cambie el formato a ROW. Consulte Setting the binary log format.

3. Reinicie el despliegue.

"Encountered change event for table xxx.xxx whose schema isn't known to this connector"

Existen tres causas comunes:

• Falta de permisos: La cuenta no tiene acceso a todas las bases de datos utilizadas en el despliegue. Otorgue los permisos necesarios. Consulte Configure a MySQL database.

• debezium.snapshot.mode establecido en never: Leer desde el inicio de los registros binarios implica que el esquema de la tabla registrado allí podría no coincidir con el esquema actual. Evite esta configuración. Para tolerar discrepancias de esquema, agregue 'debezium.inconsistent.schema.handling.mode' = 'warn'.

• Sintaxis DDL no compatible: Debezium no interpreta ciertas expresiones como DEFAULT (now()). Revise el registro WARN de io.debezium.connector.mysql.MySqlSchema para identificar la instrucción problemática.

"The connector is trying to read binlog starting at GTIDs ..., but this is no longer available on the server"

El archivo de registro binario que necesita el conector se eliminó. A continuación se muestran las causas comunes y sus soluciones:

<table> <thead> <tr> <th><b>Causa</b></th> <th><b>Solución</b></th> </tr> </thead> <tbody> <tr> <td>Periodo de retención del registro binario demasiado corto</td> <td>Aumente el periodo de retención, por ejemplo, a 7 días: <code>set global expire_logs_days=7;</code></td> </tr> <tr> <td>El despliegue consume los binlogs demasiado lento (contrapresión en un operador descendente)</td> <td>Optimice la configuración de recursos para reducir la contrapresión</td> </tr> <tr> <td>ApsaraDB RDS for MySQL: los registros se conservan un máximo de 18 horas y hasta el 30 % del almacenamiento</td> <td>Ajuste la directiva de expiración del registro binario para RDS</td> </tr> <tr> <td>Instancia de solo lectura de ApsaraDB RDS for MySQL: el binlog local se conserva un mínimo de 10 segundos antes de cargarse a Object Storage Service (OSS)</td> <td>Evite usar instancias de solo lectura (el nombre de host comienza con <code>rr</code>) para CDC; utilice instancias estándar (el nombre de host comienza con <code>rm</code>)</td> </tr> <tr> <td>Migración interna de datos en la instancia RDS</td> <td>Reinicie el despliegue para volver a leer los datos</td> </tr> </tbody> </table>

"EventDataDeserializationException: Failed to deserialize data of EventHeaderV4"

El servidor MySQL cerró una conexión de binlog inactiva. El parámetro net_write_timeout controla este tiempo de espera (valor predeterminado: 60 segundos). Las conexiones inactivas por contrapresión o problemas de red se desconectan.

• Agregue 'debezium.connect.keep.alive.interval.ms' = '40000' a la configuración de la tabla de origen de MySQL CDC o aumente net_write_timeout en la base de datos. Consulte Optimize instance parameters.

• Si el error se debe a contrapresión, ajuste la configuración de recursos del despliegue.

• Ververica Runtime (VVR) 8.0.7 y versiones posteriores reintenta automáticamente los errores causados por contrapresión.

"The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs"

La lectura de datos completos tardó tanto que la posición GTID registrada al inicio de la sincronización completa se eliminó del servidor antes de que el conector cambiara a lectura incremental.

Aumente el periodo de retención del registro binario o el tamaño máximo del archivo:

mysql> show variables like 'expire_logs_days';
mysql> set global expire_logs_days=7;

"The 'before' field of UPDATE/DELETE message is null"

El valor REPLICA IDENTITY de la tabla de PostgreSQL no está establecido en FULL. Ejecute lo siguiente:

ALTER TABLE yourTableName REPLICA IDENTITY FULL;

Si el error persiste tras reiniciar el despliegue, agregue la instrucción al código del despliegue.

"Can't find any matched tables, please check your configured database-name and table-name"

Existen dos causas posibles:

• El nombre de la tabla no existe en la base de datos. Compruebe el nombre de tabla configurado.

• La cuenta carece de permisos sobre bases de datos específicas del despliegue. Otorgue los permisos necesarios en todas las bases de datos.

"The primary key is necessary when enable 'scan.incremental.snapshot.enabled'"

Este error ocurre en VVR 4.0.x cuando se crea una tabla de origen de MySQL CDC sin clave primaria en la cláusula DDL WITH. Agregue la definición de la clave primaria a la instrucción DDL.

"java.io.EOFException: SSL peer shut down incorrectly" {#javaioeofe-xception-ssl-peer-shut-down-incorrectly}

MySQL 8.0.27 habilita conexiones SSL de forma predeterminada, pero el controlador JDBC no se conecta mediante SSL con la configuración predeterminada.

• Si utiliza VVR 6.0.2 o posterior, agregue 'jdbc.properties.useSSL' = 'false' a la cláusula WITH.

• Si la tabla se usa únicamente como tabla de dimensiones, establezca el conector en rds y agregue characterEncoding=utf-8&useSSL=false a la URL:

  'url' = 'jdbc:mysql://***.***.***.***:3306/test?characterEncoding=utf-8&useSSL=false'

"A slave with the same server_uuid/server_id as this slave has connected to the master"

Cada subtarea paralela de una tabla de origen de MySQL CDC debe tener un server ID único. Si las subtareas paralelas del mismo despliegue, o de varios despliegues, comparten el mismo server ID, se produce este error.

Especifique un server ID globalmente único para cada subtarea paralela. Para obtener más información, consulte la sección "Precautions" en Create a MySQL CDC source table.

"NullPointerException" tras agregar una columna durante la lectura de datos completos

El despliegue registra el esquema de la tabla al iniciarse y lo almacena en los checkpoints. Agregar una columna mientras la lectura de datos completos está en curso provoca una discrepancia de esquema, lo cual desencadena un NullPointerException.

Cancele el despliegue, elimine la tabla descendente y reinicie el despliegue sin estados.

"Mysql8.0 Public Key Retrieval is not allowed"

El usuario de MySQL está configurado con autenticación de contraseña SHA256, que requiere TLS. Cambie el usuario a autenticación de contraseña nativa:

ALTER USER 'username'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';
FLUSH PRIVILEGES;

"sub account not auth permission"

Al usar ApsaraDB RDS for MySQL como origen CDC, el usuario RAM no tiene permiso para descargar archivos de registro binario desde Object Storage Service (OSS). Otorgue los permisos necesarios. Consulte Authorize a RAM user with read-only permissions to download backup files.

"DELETE command denied to user 'userName'@'\.\.\.\' for table 'table_name'"

Cuando una cláusula WHERE filtra flujos de datos de CDC, Realtime Compute for Apache Flink emite un registro BEFORE UPDATE y otro AFTER UPDATE por cada operación UPDATE. El sink descendente trata el registro BEFORE UPDATE como un DELETE. Otorgue el permiso DELETE al usuario de la base de datos que ejecuta las operaciones en la tabla de resultados.