Diagnosticar problemas

Descripción general

Es posible que la transmisión tenga errores durante el tiempo de ejecución.

  • Algunos errores, como una contraseña incorrecta en la base de datos de origen, se pueden recuperar, lo que significa que se pueden corregir y la transmisión se reanuda automáticamente.
  • Los errores pueden afectar a un solo objeto, como un evento que contiene tipos de datos no admitidos. Otros errores pueden afectar a varios objetos o a toda la transmisión, como cuando Datastream no puede conectarse a la base de datos de origen.
  • Según el error, la información se proporciona en las páginas Transmisiones o Detalles de la transmisión de la IU de Datastream. También puedes usar las APIs de Datastream para recuperar información sobre el error.

Para solucionar un error, navega a las novedades para ver el error y sigue los pasos que se indican en el mensaje de error.

Esta página contiene información sobre errores de configuración, conectividad, Oracle y MySQL, junto con pasos para solucionarlos.

Errores de configuración y conectividad

Error Pasos para solucionar problemas
Falló la conexión a la base de datos de origen (genérico).

Esto puede suceder por varios motivos. Para solucionar este error, realiza las siguientes acciones:

  1. Asegúrate de que la base de datos de origen esté activa y sea accesible.
  2. Navega al perfil de conexión de origen desde las páginas Transmisiones o Perfiles de conexión.
  3. Verifica que la información de conectividad del perfil de conexión sea correcta.
  4. Verifica que el nombre de usuario y la contraseña coincidan.
  5. Verifica que el nombre de usuario exista en la base de datos y que tenga la privilegios.
  6. Guarda los cambios que realizaste en la página Perfiles de conexión.

La transmisión se reanudará automáticamente.
Falla en la conexión a la base de datos de origen (lista de IP permitidas). Esto puede suceder si el método de conectividad elegido es lista de IP permitidas, pero una o más de las direcciones IP de salida de Datastream no se agregan de forma correcta a la base de datos de origen. Asegúrate de que las direcciones IP salientes que se muestran en el perfil de conexión de Datastream estén configuradas en el firewall de red para que el servidor de la base de datos de origen pueda aceptar conexiones de estas direcciones IP. Una vez corregido esto, la transmisión se reanuda automáticamente.
Falla en la conexión a la base de datos de origen (túnel SSH de reenvío). Esto puede ocurrir si hay un problema con el túnel SSH de reenvío. Verifica el estado del túnel. Si el túnel está detenido, se debe iniciar. Una vez corregido esto, la transmisión se reanuda automáticamente.
Datastream no puede conectarse a un host de bastión a través de un túnel SSH de reenvío. Verifica que la configuración del túnel SSH de reenvío sea la correcta en el perfil de conexión de origen y que el puerto esté abierto en el servidor de túnel SSH.
No se pudo establecer la conexión con la base de datos de origen debido a certificados incorrectos. Esto puede suceder si hay un problema con los certificados proporcionados cuando definas el perfil de conexión fuente. Navega a la página Perfiles de conexión y, luego, selecciona el perfil de conexión determinado. Verifica que los certificados estén configurados de forma correcta. Después de realizar los cambios, guarda la conexión y la transmisión se reanudará automáticamente.
Falla en el uso de la conectividad privada para conectarse a la base de datos de origen.
  1. Asegúrate de haber completado todos los requisitos previos en Antes de comenzar.

  2. Después de crear la configuración de conectividad privada, verifica que la ruta que contiene la dirección IP interna de la base de datos aparezca en la pestaña Rutas exportadas de la página Intercambio de tráfico entre redes de VPC.

    Para ello, ve a la página Intercambio de tráfico entre redes de VPC y, luego, busca el intercambio de tráfico que se agregó (el nombre es peering-[UUID]). La ruta se puede encontrar en la pestaña Rutas exportadas. Si esta ruta no existe, agrégala de forma manual.

  3. Datastream no verifica si se superponen con rutas de intercambio dinámico. Proporcionar una subred que se superponga con una ruta dinámica puede generar problemas de conectividad. Por lo tanto, no recomendamos usar una subred que forme parte de una ruta dinámica.
  4. Asegúrate de que las rutas personalizadas para los rangos de direcciones IP de Datastream se anuncien correctamente. Si faltan las rutas personalizadas, consulta Rutas anunciadas personalizadas.
  5. Si los problemas persisten, consulta Cómo configurar un proxy inverso.
No se permite el tipo de conectividad STATIC_SERVICE_IP_CONNECTIVITY mientras esté activada la política de la organización constraints/datastream.disablePublicConnectivity.

Seleccionaste los métodos de conectividad de red de lista de IP públicas permitidas o túnel SSH de reenvío para el perfil de conexión que estás creando. Sin embargo, la política de la organización Bloquear los métodos de conectividad pública para Datastream está habilitada. Por lo tanto, no puedes seleccionar métodos de conectividad pública para tu perfil de conexión.

Para resolver este problema, selecciona el método de conectividad de red privada Intercambio de tráfico entre VPC o inhabilita la política de la organización.

Para inhabilitar la política de la organización, sigue estos pasos:

  1. Ve a la página Políticas de la organización en la consola de Google Cloud.
  2. Selecciona la política de la organización Datastream: Bloquear los métodos de conectividad pública.

  3. Haz clic en EDITAR.

  4. En la sección Se aplica a de la página, selecciona Personalizar.

  5. En la sección Aplicación, selecciona Desactivada.

  6. Haz clic en GUARDAR.
  7. Regresa al perfil de conexión de Oracle que estás creando y, luego, haz clic en CREAR.
Cuando configuro la base de datos de origen para mi transmisión, no encuentro las tablas y los esquemas que quiero transferir en la lista de objetos que se incluyen.

Esto puede suceder si tu base de datos tiene miles de tablas y esquemas. Es posible que algunos no estén incluidos en la lista de objetos que se extraerán cuando configures la fuente de la transmisión en la consola de Google Cloud. En lugar de seleccionar Esquemas y tablas específicos en la sección Selecciona objetos para incluir, elige Personalizado. En el campo Criterios de coincidencia de objetos, ingresa los esquemas y las tablas que quieres que extraiga Datastream.
Agregué varias tablas a mi transmisión con el menú Objetos para incluir. Sin embargo, cuando miro la pestaña Objetos en Detalles del flujo, veo que faltan algunas tablas. Asegúrate de que haya al menos una actualización de CDC en cada una de estas tablas para que Datastream pueda reconocer los cambios y, luego, incluir automáticamente las tablas en la transmisión.
No se pudo cargar la lista de objetos cuando se usa el menú Objetos para incluir en la consola de Google Cloud. Esto puede suceder si tu base de datos tiene más de 5,000 esquemas y tablas. Usa un método diferente para especificar qué objetos incluir o usa la API de Datastream. Para obtener más información, consulta Configura las bases de datos de origen.
Los eventos se descartan durante la transmisión y no se replican en el destino.

Es posible que Datastream deje de lado los eventos no admitidos durante la transmisión. Puedes realizar las siguientes acciones para solucionar el problema:

  • Activa de forma manual el reabastecimiento de toda la tabla. Esto funciona si los eventos descartados son solo eventos UPSERT. Si los eventos eliminados incluyen eventos DELETE, debes truncar la tabla en BigQuery antes de realizar el reabastecimiento.

    Para obtener información sobre cómo realizar un reabastecimiento, consulta Inicia un reabastecimiento.

  • Comunícate con Atención al cliente de Google y pídeles que realicen un reabastecimiento parcial. Esto es posible solo si puedes identificar los eventos descartados con una cláusula WHERE de SQL y si ninguno de ellos es DELETE.
  • Ignora el problema si la cantidad de eventos descartados es baja o si no es significativa.

Errores de Oracle

Error Pasos para solucionar problemas
El registro complementario está configurado de forma incorrecta en la base de datos de origen.

Si la configuración de registro complementaria no es correcta en la base de datos de origen, puede ocurrir un error de recuperación de datos de captura de datos modificados (CDC) en curso. Verifica que el registro complementario esté configurado de forma correcta. Específicamente, confirma que el registro complementario esté activado para las tablas de la base de datos que se transmiten desde el origen hacia el destino. La transmisión se reanuda automáticamente.
No se puede reanudar la replicación porque se perdió la posición del registro. Este error puede ocurrir cuando el proceso de replicación se pausa durante mucho tiempo, lo que hace que se pierda la posición del registro. No se deben pausar las transmisiones por períodos que se acerquen al período de retención de registros. Vuelve a crear la transmisión.
Faltan los archivos de registro, ya sea de forma parcial o total.

Es posible que se hayan borrado los archivos de registro. Oracle borra definitivamente los archivos de registro en cuanto que pueden, a menos que especifiques un período de rotación mínimo para mantenerlos. En el servidor de Oracle, establece durante cuánto tiempo se deben conservar los archivos de registro. Por ejemplo, usa CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS; para mantener los archivos de registro durante al menos 4 días.

Para una implementación de RDS, usa exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',96);.
La lista de exclusión incluye la lista de inclusión. Toda la lista de inclusión se encuentra en la lista de exclusión, por lo que la lista de objetos que Datastream extrae de la fuente está vacía. Modifica la selección de objetos y vuelve a intentarlo.
El modo de registro de la base de datos de Oracle no está configurado en ARCHIVELOG. Cambia el modo de registro y, luego, vuelve a intentarlo.
Datastream muestra un mensaje de error ORA-00942: table or view does not exist, pero todo está configurado correctamente. Esto puede deberse a la caché del servidor de Oracle. Volver a crear el usuario de la base de datos debería solucionar el problema de almacenamiento en caché.
Los cambios en una fuente de Oracle no se reflejan en el destino cuando la transmisión ya está en ejecución. Debido a que Datastream lee de los archivos de registro de rehacer archivados, los cambios que realices en la fuente no se reflejarán en el destino hasta que se archive el registro. Para ver los cambios en el destino, cambia la política de archivo de registro o aplica manualmente un cambio de registro. Para obtener más información, consulta Trabaja con archivos de registro de rehacer de la base de datos de Oracle.
Se produjo un error interno inesperado. Para obtener más información, comunícate con Atención al cliente de Google.

Errores de MySQL

Error Pasos para solucionar problemas
El registro binario está configurado de forma incorrecta en la base de datos de origen.

Esto puede suceder con las transmisiones continuas de MySQL si binlog es incorrecta en la base de datos de origen. Para solucionar este error, realiza las siguientes acciones:

  1. Verifica que el registro binario esté configurado de forma correcta.
  2. Confirma que el formato del registro binario de la base de datos MySQL esté configurado como ROW.
  3. Reinicia la transmisión.
No se pudo reanudar la replicación porque se perdió la posición del registro binario. Este error puede ocurrir cuando el proceso de replicación está en pausa durante mucho tiempo, lo que hace que se pierda la posición de binlog. No se deben pausar las transmisiones durante períodos que se acerquen al período de retención de binlog. Vuelve a crear la transmisión.
Falla en la ejecución de la transmisión debido a la incompatibilidad de versiones de la base de datos de origen y el destino.

Esto puede ocurrir cuando la base de datos de origen no cumple con la matriz de compatibilidad de versiones. Para solucionar este error, realiza las siguientes acciones:

  1. Asegúrate de que la base de datos de origen siga la matriz.
  2. Vuelve a crear la transmisión con la base de datos de origen actualizada.
Faltan los registros binarios de la fuente de AWS RDS MySQL, ya sea de forma parcial o total. Es posible que se hayan borrado los registros binarios. El RDS de AWS borra definitivamente los registros binarios en cuanto que pueden, a menos que especifiques un período de rotación mínimo para mantenerlos. En la instancia de origen de AWS RDS MySQL establecer por cuánto tiempo, en horas, se deben conservar los registros binarios. Por ejemplo, usa mysql.rds_set_configuration('binlog retention hours', 168); para mantener los registros binarios durante al menos 7 días.
La lista de exclusión incluye la lista de inclusiones. Toda la lista de inclusión se encuentra en la lista de exclusión, por lo que la lista de objetos que Datastream extrae de la fuente está vacía. Modifica la selección de objetos y vuelve a intentarlo.
Datastream no puede replicar una base de datos de MySQL. Asegúrate de que Datastream tenga permisos para replicar la base de datos.
Cuando se crea un perfil de conexión para una fuente de MySQL, no se aceptan varios certificados SSL codificados con PEM en el menú Tipo de encriptación. Datastream no admite cadenas de certificados SSL en los perfiles de conexión de MySQL. Solo se admiten certificados únicos con codificación PEM x509.
Latencia alta cuando se transmite desde una fuente de MySQL.

Aumenta la capacidad de Datastream para leer de la base de datos de origen:
Se produjo un error interno inesperado. Para obtener más información, comunícate con Atención al cliente de Google.

Errores de PostgreSQL

Error Pasos para solucionar problemas
La decodificación lógica está configurada de forma incorrecta en la base de datos de origen.

Verifica que la decodificación lógica esté configurada de forma correcta. Consulta Configura una base de datos PostgreSQL de origen.
El espacio de replicación no existe. Si el espacio de replicación no existe en la base de datos, puede ocurrir un error al recuperar datos de captura de datos modificados (CDC) en curso. Verifica que el espacio de replicación esté configurado correctamente. Consulta Configura una base de datos PostgreSQL de origen.
La ranura de replicación está configurada con un complemento incorrecto. Este error puede ocurrir si la ranura de replicación está configurada con un complemento diferente de pgoutput. Verifica que el espacio de replicación esté configurado correctamente. Consulta Base de datos de PostgreSQL de origen para obtener más información.
La ranura de replicación está activa en un proceso diferente. Este error puede ocurrir cuando otro proceso usa el espacio de replicación. Solo un proceso puede usar los espacios de replicación a la vez. Asegúrate de no usar la misma ranura de replicación en ningún otro proceso, excepto en Datastream.
La publicación no está configurada correctamente. Este error puede ocurrir cuando la publicación no está configurada para exponer las tablas que se incluyen en la configuración del flujo. Verifica que la publicación esté configurada de forma correcta. Consulta Configura la información sobre la base de datos de origen de la transmisión.
La publicación no existe. Este error puede ocurrir si la publicación no existe en la base de datos. Verifica que la publicación esté configurada de forma correcta. Consulta Cómo configurar una base de datos de PostgreSQL de origen.
No se puede reanudar la replicación porque se pierden los archivos del WAL. Este error puede ocurrir cuando el proceso de replicación se pausa durante mucho tiempo, lo que provoca la pérdida de los archivos del WAL. Las transmisiones no deben detenerse durante períodos que se acerquen al período de retención de los archivos WAL. Vuelve a crear la transmisión.
La lista de exclusión incluye la lista de inclusiones. Toda la lista de inclusión se encuentra en la lista de exclusión, por lo que la lista de objetos que Datastream extrae de la fuente está vacía. Modifica la selección de objetos y vuelve a intentarlo.
Datastream no puede replicar un esquema de PostgreSQL. Asegúrate de que Datastream tenga permisos para replicar el esquema.
Las transacciones grandes en la base de datos de origen causan problemas con la replicación y sincronización de datos. Si insertas, actualizas o borras una cantidad significativa de registros en la base de datos de origen, es posible que el espacio de replicación se sobrecargue con los eventos correspondientes. Datastream necesita tiempo para leer y procesar estos eventos. Debido a que los ranuras de replicación de PostgreSQL son de subproceso único, el procesamiento de otros cambios en el ranura de replicación, incluidos los cambios en los datos de otras tablas, se retrasa hasta que Datastream se pone al día con todos los cambios en el ranura de replicación.
Las transacciones grandes en la base de datos de origen causan una baja capacidad de procesamiento del CDC. Datastream no admite la CDC de varios subprocesos en PostgreSQL. Para superar esta limitación y aumentar la capacidad de procesamiento de CDC, puedes dividir el origen en varias transmisiones, cada una con su propia ranura de publicación y replicación. Por ejemplo, puedes crear un flujo para la tabla más grande de tu base de datos y otro para todas las demás, o uno para tus tablas de prioridad alta y otro para las restantes. Los casos de uso pueden variar, por lo que debes considerar qué tiene más sentido en tu situación específica de CDC. Para obtener información sobre cómo crear una publicación, consulta Configura una base de datos de origen de PostgreSQL.
Se descartaron eventos no admitidos con el código de motivo: BIGQUERY_TOO_MANY_PRIMARY_KEYS. Cuando la identidad de réplica de PostgreSQL para una tabla se establece en FULL, Datastream trata todas las columnas de esta tabla como claves primarias. Si hay más de 16 columnas en la tabla, se infringe la limitación de CDC de BigQuery y se produce el error. Para resolver el problema, completa los siguientes pasos:
  1. Cambia la identidad de la réplica a DEFAULT: 
    ALTER TABLE TABLE_NAME REPLICA IDENTITY DEFAULT
     Reemplaza TABLE_NAME por el nombre de la tabla para la que deseas cambiar la identidad de réplica.
  2. Quita la tabla de la lista de objetos que se incluirán en la transmisión. Para obtener más información, consulta Cómo modificar la información de configuración de la base de datos de origen.
  3. Borra la tabla de BigQuery. Para obtener más información, consulta Borra tablas.
  4. En Datastream, edita la configuración de la fuente para volver a agregar la tabla a la transmisión.
Se produjo un error interno inesperado. Para obtener más información, comunícate con Atención al cliente de Google.

Errores de SQL Server

Error Pasos para solucionar problemas
Las CDC están inhabilitadas para la base de datos DATABASE_NAME.

Se debe habilitar la captura de datos modificados (CDC) para la base de datos. Datastream necesita acceso de lectura directo a los registros de transacciones para replicar cambios en tiempo real en la base de datos de origen y obtener información de registro completa. Habilita la CDC para la base de datos y vuelve a intentarlo.

Para obtener información sobre cómo habilitar la CDC para una base de datos, consulta Configura una base de datos de origen de SQL Server.
Tablas con las CDC inhabilitadas.

La captura de datos modificados (CDC) debe estar habilitada para todas las tablas incluidas en el flujo. Datastream necesita acceso de lectura directo a los registros de transacciones para replicar los cambios en tiempo real en las tablas de origen y obtener información de registro completa. Habilita la CDC para las tablas incluidas en el flujo y vuelve a intentarlo.

Para obtener información sobre cómo habilitar la CDC para las tablas de origen, consulta Configura una base de datos de SQL Server de origen.
Faltan permisos. A Datastream le faltan los permisos necesarios para leer desde la fuente. Otorga los privilegios adecuados a la cuenta de usuario que se usa para conectarse a tu base de datos y vuelve a intentarlo.
No se admite la edición EDITION_NAME de SQL Server. Datastream no es compatible con esta edición de SQL Server. Para obtener más información sobre las ediciones compatibles de SQL Server, consulta Descripción general de SQL Server como fuente.
No se admite la versión VERSION_NAME de SQL Server de la edición Standard. Datastream no admite esta versión de la edición estándar de SQL Server. Para obtener más información sobre las versiones compatibles de SQL Server, consulta Descripción general de SQL Server como fuente.
Configuración de los CDC de SQL Server: con errores. El método de CDC que seleccionaste no cumple con la configuración de tu base de datos. Cambia el método de CDC y vuelve a intentarlo.

Errores de BigQuery

Error Pasos para solucionar problemas
BIGQUERY_UNSUPPORTED_PRIMARY_KEY_CHANGE, details: Failed to write to BigQuery due to an unsupported primary key change: adding primary keys to existing tables is not supported. Si la clave primaria cambia en la fuente, debes descartar la tabla en BigQuery y volver a iniciar el reabastecimiento. Esta es una limitación de BigQuery, ya que no hay forma de garantizar la combinación correcta de eventos nuevos con filas existentes si la clave primaria es diferente. Para obtener más información, consulta Configura un destino de BigQuery.
La tabla de BigQuery de destino tiene muchos más registros que la tabla de origen. Esto puede suceder cuando la tabla de origen no tiene una clave primaria. En ese caso, Datastream procesa la tabla en el modo de escritura de solo anexar, y cada evento de una fila determinada aparece como una fila separada en BigQuery.
Los datos se duplican cuando se realiza el reabastecimiento en el modo de escritura Solo agregar.

Cuando seleccionas el modo de escritura Solo agregar para tu transmisión, tus datos se agregan a BigQuery como un flujo de eventos INSERT, UPDATE-INSERT, UPDATE-DELETE y DELETE, sin ninguna consolidación. Esto puede provocar que se escriban filas duplicadas en BigQuery cuando realices el reabastecimiento o cuando se produzca un problema y el escritor de BigQuery vuelva a intentar las operaciones de escritura. Para solucionar este problema, te recomendamos que ejecutes con frecuencia una consulta de deduplicación similar a la siguiente:

SELECT * FROM (SELECT *, row_number() OVER (PARTITION BY datastream_metadata.uuid) AS num FROM TABLE_NAME) WHERE num=1
Datastream está configurado para el modo de escritura de combinación, pero los cambios no se combinan en BigQuery.

Verifica que haya una clave primaria en tu tabla de origen. BigQuery lo necesita para combinar los cambios en la tabla de destino.

Si no hay una clave primaria, considera agregar una a la tabla de origen o de destino. Para agregar una clave principal a tu tabla de BigQuery de destino, sigue estos pasos:

  1. Pausa la transmisión
  2. Truncar la tabla en BigQuery
  3. Agrega la clave primaria a la definición de la tabla.
  4. Reanuda la transmisión.
  5. Activar el reabastecimiento para la tabla
No se puede agregar una clave primaria, quitar una clave primaria ni cambiar la definición de la clave primaria de una tabla que ya está replicada en BigQuery.

De forma predeterminada, Datastream no admite agregar una clave primaria a una tabla que ya se replicó en BigQuery sin una clave primaria ni quitar una clave primaria de una tabla que se replicó en BigQuery con una clave primaria. Sin embargo, puedes cambiar la definición de clave primaria de una tabla de origen replicada en BigQuery que ya tiene una clave primaria:

  1. Verifica la métrica de latencia total de la transmisión y espera al menos el mayor tiempo posible para la latencia actual para asegurarte de que los eventos en tránsito se escriban en el destino. Esto permite que todos los eventos con la clave principal original se transmitan correctamente.
  2. Pausa la transmisión.
  3. Copia el comando CREATE TABLE del lenguaje de definición de datos (DDL) para la tabla en BigQuery: 
        SELECT ddl FROM PROJECT_ID.DATASET.INFORMATION_SCHEMA.TABLES
      WHERE table_name='TABLE_NAME';

    Reemplaza lo siguiente:

    • PROJECT_ID: El identificador de tu proyecto de Google Cloud.
    • DATASET_ID: Es el identificador del conjunto de datos en BigQuery.
    • TABLE_NAME: Es el nombre de la tabla de la que deseas copiar el comando de DDL.
  4. Suelta la tabla en BigQuery.
  5. Ajusta el comando CREATE TABLE del DDL con las claves primarias nuevas. Incluye las claves de partición y clúster, y el OPTION max_staleness: 
        CREATE TABLE `[PROJECT_ID].[DATASET_ID].[TABLE_NAME]`
    (
      product_id INT64 NOT NULL,
      product_name STRING,
      datastream_metadata STRUCT,
      PRIMARY KEY (product_id) NOT ENFORCED
    )
    CLUSTER BY dept_no
    OPTIONS(
      max_staleness=INTERVAL '0-0 0 0:MINS:0' YEAR TO SECOND
    );
    ;

    Reemplaza lo siguiente:

    • PROJECT_ID: El identificador de tu proyecto de Google Cloud.
    • DATASET_ID: Es el identificador del conjunto de datos en BigQuery.
    • TABLE_NAME: Es el nombre de la tabla de la que copiaste el comando de DDL.
    • MINS: Es la cantidad de minutos que deseas establecer para la opción max_staleness, por ejemplo, 15.
  6. Ejecuta la consulta ajustada para volver a crear la tabla en BigQuery.
  7. Reanuda la transmisión.
  8. Inicia el reabastecimiento de la tabla.

¿Qué sigue?

  • Para obtener información sobre cómo buscar posibles problemas con tu transmisión, consulta Cómo solucionar problemas de una transmisión.
  • Para obtener información sobre cómo configurar tu base de datos de origen, consulta Fuentes.
  • Para aprender a configurar tu destino de BigQuery o Cloud Storage, consulta Destinos.