DataWorks:Preguntas frecuentes sobre la sincronización en tiempo real

¿Qué orígenes de datos admite la sincronización en tiempo real?

Para conocer los orígenes de datos compatibles con la sincronización en tiempo real, consulte Supported data sources.

¿Por qué la latencia de mi tarea de sincronización en tiempo real es alta?

Si al consultar los datos de una tabla generados por una tarea de sincronización en tiempo real nota que no se han sincronizado, es posible que la causa sea una latencia alta en dicha tarea. Vaya a la página Real-time synchronization tasks en Operation Center y compruebe si el valor de Business Latency es demasiado alto. Para obtener más información, consulte Solutions for high latency in real-time synchronization tasks.

Si la latencia del negocio es alta, las posibles causas son las siguientes:

¿Por qué no se recomienda usar la red pública para las tareas de sincronización en tiempo real?

Usar la red pública para las tareas de sincronización en tiempo real implica los siguientes riesgos:

• La red puede ser inestable y pueden producirse pérdidas de paquetes con frecuencia, lo cual afecta el rendimiento de la sincronización.

• La seguridad es baja.

Formato de columnas en la sincronización en tiempo real

Cuando Data Integration sincroniza datos en tiempo real desde MySQL, Oracle, Loghub o PolarDB hacia DataHub o Kafka, agrega cinco columnas adicionales en el destino para gestionar metadatos, ordenar, deduplicar y ejecutar otras operaciones. Para obtener más información, consulte Additional columns in real-time synchronization.

¿Cómo maneja la sincronización en tiempo real las operaciones TRUNCATE?

La sincronización en tiempo real admite operaciones TRUNCATE, las cuales surten efecto durante la fase incremental y la fusión completa. Si elige ignorar TRUNCATE, podrían aparecer datos adicionales durante la sincronización de datos en tiempo real.

¿Cómo puedo mejorar la velocidad y el rendimiento de la sincronización en tiempo real?

Si la velocidad de escritura es lenta, aumente la concurrencia de escritura y ajuste los parámetros de JVM. Los parámetros de JVM no dependen del número de bases de datos sincronizadas, sino de la frecuencia de cambios. Si la máquina del resource group actual lo permite, entre más memoria asigne, menor será la frecuencia de Full GC y mayor el rendimiento de la sincronización en tiempo real. Establezca Concurrency en 3. En el panel Basic Configuration de la tarea, establezca JVM Parameters en -Xms8192m -Xmx8192m.

¿Puedo ejecutar tareas de sincronización en tiempo real en la consola?

Las tareas de sincronización en tiempo real no se pueden ejecutar directamente en la consola de DataWorks. Después de configurar una tarea de sincronización en tiempo real, debe confirmar y desplegar el nodo correspondiente, y luego ejecutarlo en el entorno de producción. Para obtener más información, consulte Deploy a real-time synchronization node.

¿Por qué la sincronización en tiempo real se vuelve más lenta al usar un origen de datos de MySQL?

Una razón es que aumenta el volumen de binlogs por procesar. Dado que los binlogs se generan a nivel de instancia, incluso si la tarea de sincronización está configurada para sincronizar solo la tabla A, los cambios en otras tablas, como la B o la C, también generan binlogs. Estos binlogs adicionales reducen la velocidad de procesamiento de la sincronización.

¿Por qué el uso de memoria difiere entre seleccionar una sola base de datos y varias en la sincronización en tiempo real?

Cuando selecciona dos o más bases de datos, la tarea entra en el modo de sincronización en tiempo real de "instancia completa", el cual consume más recursos que dos tareas independientes que sincronizan una sola base de datos cada una.

¿Qué políticas de DDL admite la sincronización en tiempo real?

Los métodos de procesamiento son los siguientes:

Categorías de tipos de DDL:

Consideraciones sobre las operaciones DDL y DML de origen al escribir en un origen de datos de destino

• Después de agregar una columna en el origen y ejecutar correctamente el DDL en el destino, aplican las siguientes limitaciones:

  • Tras agregar una columna con DEFAULT VALUE, la nueva columna en la tabla de destino no tiene valor y permanece en NULL. Cuando posteriormente se insertan datos nuevos en la columna agregada del origen, la tarea de sincronización en tiempo real los sincroniza hacia esa columna.

  • Tras agregar una columna VIRTUAL, la nueva columna en la tabla de destino no tiene valor y permanece en NULL. Cuando posteriormente se insertan datos nuevos en la columna agregada del origen, la tarea de sincronización en tiempo real los sincroniza hacia esa columna.

• Para la sincronización en tiempo real desde orígenes MySQL o PolarDB MySQL, se recomienda añadir las columnas al final cuando agregue columnas en el origen. No agregue columnas en medio de las existentes. Si resulta inevitable agregar columnas intermedias en el origen, tenga en cuenta las siguientes restricciones:

  • En una solución completa más incremental, no agregue columnas intermedias durante la fase de sincronización completa. De lo contrario, ocurrirán excepciones de datos durante la fase de sincronización incremental.

  • Durante la fase de sincronización incremental, la hora de restablecimiento del punto de control de sincronización debe ubicarse después del evento DDL que agregó las columnas intermedias. De lo contrario, los datos de la sincronización incremental posterior podrían presentar anomalías.

• Si ocurren excepciones de datos, vuelva a ejecutar la inicialización completa de datos. Solo necesita quitar las tablas a las que se les agregaron columnas intermedias y reinicializar esas tablas, en lugar de reinicializar todas las tablas de la tarea, para restaurar los datos correctos.

¿Por qué la latencia es alta después de que una tarea de sincronización en tiempo real que lee de PostgreSQL realiza una conmutación por error?

Esta situación es una característica propia de la base de datos PostgreSQL. Si la latencia resulta inaceptable, detenga la tarea y reiníciela para ejecutar una sincronización de datos completa más incremental.

¿Cómo ejecuto una sincronización completa para una tarea de sincronización existente?

En Data Integration, busque la tarea de sincronización deseada en la lista de tareas y luego haga clic en More > Rerun en la columna Actions.

¿Una tarea de sincronización en tiempo real de DataWorks admite configurar un umbral de datos incorrectos (errorLimit) o ignorar datos incorrectos?

Las tareas de sincronización en tiempo real no admiten configurar un umbral de datos incorrectos (errorLimit) ni ignorarlos. Si se encuentran datos incorrectos durante la sincronización, la tarea se bloquea.

Soluciones alternativas:

• Reemplace la tarea de sincronización en tiempo real por una tarea de sincronización por lotes programada por hora o por minuto. La sincronización por lotes sí admite configurar un umbral de datos incorrectos e ignorarlos.

• Agregue un nodo de procesamiento de datos en la canalización de sincronización en tiempo real para limpiar y filtrar la información, evitando que los datos incorrectos lleguen al destino.

• Localice y corrija los datos de origen con base en el mensaje de error de la tarea para eliminar los datos incorrectos desde el origen.

Al sincronizar datos en tiempo real desde un origen de datos de MySQL, la lectura comienza pero se detiene después de un rato. ¿Cómo lo soluciono?

1. Ejecute el siguiente comando en la base de datos para comprobar en qué archivo binlog está escribiendo la instancia de base de datos actual.

   show master status 

2. Compare el archivo binlog leído en los registros. Busque en los registros journalName=MySQL-bin.000001,position=50 para comprobar si se están escribiendo datos en la base de datos.

3. Si se están escribiendo datos pero el binlog no avanza, contacte a su DBA para recibir asistencia.

Las tareas de sincronización en tiempo real para Oracle, PolarDB y MySQL reportan errores de forma repetida

• Síntoma: la tarea de sincronización en tiempo real reporta errores de forma repetida.

  Cuando el origen de una tarea de sincronización en tiempo real es un origen de datos de Oracle, PolarDB o MySQL, los mensajes DDL del origen no se procesan de forma predeterminada. Si se realizan cambios DDL distintos a la creación de tablas, la tarea en tiempo real reporta un error y finaliza. En un escenario de recuperación basada en puntos de control, la tarea de sincronización podría seguir reportando errores aunque el origen no genere ningún mensaje DDL.

  Nota

  Para evitar la pérdida o desorden de datos durante cierto periodo, no use el comando Rename para intercambiar los nombres de dos columnas. Por ejemplo, no se permite intercambiar los nombres de la columna A y la columna B.

• Causa: la sincronización en tiempo real admite la recuperación basada en puntos de control. Para evitar la pérdida de datos, al reiniciar la sincronización el desplazamiento puede retroceder para reprocesar parte de la información. Este proceso puede provocar que los mensajes DDL encontrados previamente se lean de nuevo y activen otra alerta.

• Solución:

  1. Cuando se hagan cambios DDL en el origen, aplique manualmente los cambios DDL correspondientes en la base de datos de destino.

  2. Inicie la tarea de sincronización en tiempo real y cambie la política de procesamiento de mensajes DDL de Error a Ignore.

     Nota

     Dado que la reanudación basada en puntos de control sigue suscribiéndose a este evento DDL, el evento se configura temporalmente para ignorarse y evitar que la tarea vuelva a fallar.

  3. Detenga la tarea de sincronización en tiempo real, cambie la política de procesamiento de mensajes DDL de Ignore nuevamente a Error y reinicie la tarea de sincronización en tiempo real.

Error de sincronización en tiempo real de Kafka: Startup mode for the consumer set to timestampOffset, but no begin timestamp was specified.

Restablezca el desplazamiento inicial. En el cuadro de diálogo Start de la tarea, busque la opción Reset Offset y seleccione la casilla Reset Offset para habilitar esta función.

La función Reset Offset de Data Integration sirve para restablecer la posición inicial de la sincronización de datos. Úsela cuando necesite reiniciar la sincronización desde un momento específico o desde una posición de datos concreta. Por ejemplo, si ocurre un error durante la sincronización o necesita volver a sincronizar parte de los datos, restablecer el desplazamiento le permite reiniciar la sincronización desde una posición específica para garantizar la consistencia e integridad de los datos.

Error de sincronización en tiempo real de MySQL: Cannot replicate because the master purged required binary logs.

Error de sincronización en tiempo real de MySQL: Cannot replicate because the master purged required binary logs. Replicate the missing transactions from elsewhere, or provision a new slave from backup.. Este error puede ocurrir porque no se encuentra en MySQL el registro binlog correspondiente al desplazamiento de consumo. Compruebe el periodo de retención de binlog de su instancia de MySQL y asegúrese de que el desplazamiento esté configurado dentro de este rango de tiempo al iniciar la tarea de sincronización.

Si no logra suscribirse al binlog, intente restablecer el desplazamiento a la hora actual.

Error de sincronización en tiempo real de MySQL: MySQLBinlogReaderException

Error de sincronización en tiempo real de MySQL: MySQLBinlogReaderException: The database you are currently syncing is the standby database, but the current value of log_slave_updates is OFF, you need to enable the binlog log update of the standby database first. . Este error puede ocurrir porque el binlog no está habilitado para la base de datos en espera. Si desea sincronizar datos desde la base de datos en espera, debe habilitar el binlog en cascada en ella. Contacte a su DBA para recibir asistencia.

Para obtener más información sobre cómo habilitar binlog, consulte Step 3: Enable MySQL binlog.

Error de sincronización en tiempo real de MySQL: show master status' has an error!

Error de sincronización en tiempo real de MySQL: show master status' has an error!. Los detalles del error son Caused by: java.io.IOException: message=Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s) for this operation, with command: show master status. Este error puede ocurrir porque el origen de datos no tiene los permisos de base de datos obligatorios.

La cuenta configurada para el origen de datos debe tener los permisos SELECT, REPLICATION SLAVE y REPLICATION CLIENT en la base de datos. Para obtener más información sobre cómo otorgar los permisos necesarios al origen de datos, consulte Step 2: Create an account and configure permissions.

Error de sincronización en tiempo real de MySQL: parse.exception.PositionNotFoundException: can't find start position forxxx

La sincronización no encuentra el desplazamiento. Restablezca el desplazamiento.

Error de sincronización en tiempo real de MySQL: Can't get position by timestamp

Posible causa: la base de datos de origen purgó el binlog correspondiente a la hora de inicio de sincronización especificada. Una vez purgado el binlog, la tarea de sincronización en tiempo real no puede obtener el desplazamiento con base en ese punto temporal, lo que genera este error.

Solución: en la página Data Source Configuration, habilite la función Support OSS Binlog Reading para el origen de datos de MySQL. Con esta función habilitada, la tarea de sincronización puede leer el binlog purgado desde las copias de seguridad de registros en OSS, lo que evita interrupciones de sincronización causadas por la expiración del binlog local.

Esta función solo es compatible con orígenes de datos de RDS MySQL, y la instancia de RDS debe estar en la misma región que el espacio de trabajo de DataWorks.

Error de sincronización en tiempo real de PolarDB:The mysql server does not enable the binlog write function. Please enable the mysql binlog write function first

• Posible causa: el parámetro loose_polar_log_bin no está habilitado en el origen de datos de PolarDB.

• Solución: habilite el parámetro loose_polar_log_bin. Para obtener más información, consulte Configure a PolarDB data source for real-time synchronization.

Error de sincronización en tiempo real hacia Hologres: permission denied for database xxx

Cuando sincroniza datos hacia Hologres en tiempo real, debe otorgar al usuario operativo actual el permiso admin en la instancia de Hologres (se requiere el permiso para crear esquemas). Para obtener más información, consulte Manage Hologres permissions.

Error de sincronización en tiempo real hacia MaxCompute: ODPS-0410051:invalid credentials-accessKeyid not found

Cuando sincroniza datos hacia un origen de datos de MaxCompute en tiempo real y utiliza un par de AccessKey temporal, dicho par caduca automáticamente después de 7 días, lo que provoca que la tarea falle. La plataforma reinicia automáticamente la tarea cuando detecta que un par de AccessKey temporal causó el fallo. Si configuró reglas de alerta de este tipo para la tarea, recibirá las notificaciones de alerta correspondientes.

Error de sincronización en tiempo real desde Oracle: logminer doesn't init, send HeartbeatRecord

Cuando una tarea de sincronización en tiempo real desde Oracle se inicializa y busca un punto de control de sincronización adecuado, necesita cargar el registro archivado anterior. Si el registro archivado es grande, la fase de inicialización puede tardar de 3 a 5 minutos en completarse.

¿Qué hago si un error de sincronización en tiempo real de PostgreSQL indica que no se admite la dirección de división de lectura/escritura o el modo Replication?

Posible causa: la sincronización en tiempo real de PostgreSQL (CDC) depende del mecanismo de replicación lógica (Replication Mode) de la base de datos y solo admite la conexión al endpoint de la instancia principal. Las direcciones de división de lectura/escritura, las direcciones de proxy y las direcciones de instancias secundarias no admiten este mecanismo. Por lo tanto, la tarea reporta un error que indica que no se admite la dirección de división de lectura/escritura o el modo Replication.

Solución: cambie la dirección de conexión del origen de datos de PostgreSQL en la data source configuration al endpoint de la instancia principal, guarde la configuración, pruebe la conectividad de nuevo y, tras superar la prueba, vuelva a ejecutar la tarea de sincronización en tiempo real.