Diagnosticar problemas

Es posible que la emisión genere 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 contenga tipos de datos no admitidos. Otros errores pueden afectar a varios objetos o a todo el flujo, como cuando Datastream no puede conectarse a la base de datos de origen.
  • En función del error, se proporciona información en las páginas Flujos o Detalles del flujo de la interfaz de usuario de Datastream. También puede usar las APIs de Datastream para obtener información sobre el error.

Para solucionar un error, vaya al flujo para verlo y siga 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, así como los pasos para solucionar los errores.

Errores de configuración y conectividad

Error Pasos para solucionar el problema
No se ha podido conectar con la base de datos de origen (genérico).

Esto puede deberse a varios motivos. Para solucionar este error:

  1. Asegúrate de que la base de datos de origen esté activa y accesible.
  2. Ve al perfil de conexión de origen desde las páginas Flujos o Perfiles de conexión.
  3. Verifica que la información de conectividad del perfil de conexión sea correcta.
  4. Comprueba 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 los privilegios necesarios.
  6. Guarda los cambios que hayas hecho en la página Perfiles de conexión.

La emisión se reanudará automáticamente.
No se ha podido conectar a la base de datos de origen (lista de IP permitidas). Esto puede ocurrir si el método de conectividad elegido es Lista de IP permitidas, pero una o varias de las direcciones IP salientes de Datastream no se han añadido correctamente a la base de datos de origen. Asegúrate de que las direcciones IP de salida que se muestran en el perfil de conexión de Datastream estén configuradas en el cortafuegos de red para que el servidor de la base de datos de origen pueda aceptar conexiones de esas direcciones IP. Cuando se haya solucionado, la emisión se reanudará automáticamente.
No se ha podido conectar a la base de datos de origen (túnel directo SSH). Esto puede ocurrir si hay un problema con el túnel directo SSH. Comprueba el estado del túnel. Si el túnel está detenido, debe iniciarse. Cuando se haya solucionado, la emisión se reanudará automáticamente.
Datastream no puede conectarse a un host bastion a través de un túnel directo SSH. Verifica que la configuración del túnel directo SSH esté configurada correctamente en el perfil de conexión de origen y que el puerto esté abierto en el servidor del túnel SSH.
No se ha podido conectar a la base de datos de origen debido a que los certificados no son válidos. Esto puede ocurrir si hay un problema con los certificados proporcionados al definir el perfil de conexión de origen. Ve a la página Perfiles de conexión y selecciona el perfil de conexión correspondiente. Verifica que los certificados se hayan configurado correctamente. Después de hacer los cambios, guarda el perfil de conexión y la emisión se reanudará automáticamente.
No se ha podido usar la conectividad privada para conectarse a la base de datos de origen. Este error se refiere al método de conectividad privada de emparejamiento de VPC.
  1. Comprueba que has completado todos los requisitos previos de la interconexión de VPCs.

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

    Para ello, ve a la página Emparejamiento entre redes de VPC y busca el emparejamiento que se ha añadido (el nombre es peering-[UUID]). La ruta se encuentra en la pestaña Rutas exportadas. Si esta ruta no existe, añádela manualmente.

  3. Datastream no comprueba si hay superposiciones con rutas de peering dinámico. Si proporcionas una subred que se solapa con una ruta dinámica, pueden producirse problemas de conectividad. Por lo tanto, no recomendamos usar una subred que forme parte de una ruta dinámica.
  4. Asegúrese de que las rutas personalizadas de los intervalos de direcciones IP de flujo de datos se anuncian correctamente. Si faltan las rutas personalizadas, consulta Rutas anunciadas personalizadas.
  5. Si sigues teniendo problemas para conectarte a la base de datos de origen, consulta el artículo sobre cómo configurar un proxy inverso.
No se ha podido usar la interfaz de Private Service Connect para conectarse a la base de datos de origen.
  1. Comprueba que has completado todos los requisitos previos.
  2. Asegúrate de que las reglas de tu cortafuegos permitan que la subred del archivo de red proporcionado se conecte a la base de datos de origen.
  3. Asegúrese de que las rutas personalizadas de los intervalos de direcciones IP de flujo de datos se anuncian correctamente. Si faltan las rutas personalizadas, consulta Rutas anunciadas personalizadas.
El tipo de conectividad STATIC_SERVICE_IP_CONNECTIVITY no está permitido mientras las restricciones de la política de la organización o datastream.disablePublicConnectivity estén activadas.

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

Para solucionar este problema, selecciona el método de conectividad de red Emparejamiento de VPC o Interfaces de Private Service Connect o inhabilita la política de la organización.

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

  1. Ve a la página Políticas de la organización de la Google Cloud consola.
  2. Selecciona la política de organización Datastream - Block Public Connectivity Methods (Datastream - Bloquear métodos de conectividad públicos).

  3. Haz clic en EDITAR.

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

  5. En la sección Implementación obligatoria, selecciona Desactivada.

  6. Haz clic en GUARDAR.
  7. Vuelve al perfil de conexión de Oracle que estás creando y haz clic en CREAR.
Al configurar la base de datos de origen de mi flujo, no encuentro las tablas y los esquemas que quiero transferir en la lista de objetos que se van a incluir.

Esto puede ocurrir si tu base de datos tiene miles de tablas y esquemas. Es posible que algunos de ellos no se incluyan en la lista de objetos que se van a extraer al configurar la fuente de la secuencia en la Google Cloud consola. En lugar de seleccionar Esquemas y tablas específicos en la sección Seleccionar objetos que incluir, elija Personalizado. En el campo Criterios de coincidencia de objetos, introduce los esquemas y las tablas que quieres que extraiga Datastream.
He añadido varias tablas a mi emisión mediante el menú Objetos que incluir. Sin embargo, cuando consulto la pestaña Objetos de Detalles del flujo, veo que faltan algunas tablas. Asegúrese de que haya al menos una actualización de CDC en cada una de estas tablas para que Datastream pueda reconocer los cambios e incluirlas automáticamente en el flujo.
No se puede cargar la lista de objetos al usar el menú Objetos que incluir en la consola Google Cloud . Esto puede ocurrir si tu base de datos tiene más de 5000 esquemas y tablas. Usa otro método para especificar los objetos que quieres incluir o usa la API Datastream. Para obtener más información, consulta Configurar bases de datos de origen.
Eventos que se han perdido durante la transmisión y no se han replicado en el destino.

Datastream puede descartar eventos no admitidos durante el streaming. Para solucionar el problema, puedes hacer lo siguiente:

  • Activa manualmente un relleno de toda la tabla. Esto funciona si los eventos descartados son solo eventos UPSERT. Si los eventos descartados incluyen eventos DELETE, debe truncar la tabla en BigQuery antes de realizar la reposición.

    Para obtener información sobre cómo realizar un relleno, consulta Iniciar un relleno.

  • Ponte en contacto con el equipo de Asistencia de Google y pídele que realice un relleno parcial. Esto solo es posible si puede identificar los eventos perdidos con una cláusula WHERE de SQL y si ninguno de los eventos es un evento DELETE.
  • No le dé importancia al problema si el número de eventos descartados es bajo o si los eventos descartados no son significativos.
Se ha agotado el tiempo de espera mientras se intentaba conectar con la fuente de datos. Asegúrese de que la configuración del nombre de host y del puerto sea correcta y de que se pueda acceder a la fuente de datos. Como la red de Datastream no se puede emparejar directamente con una red de servicios privados (por ejemplo, una instancia de Cloud SQL) cuando se usa el emparejamiento de VPCs, debes usar una VM de traducción de direcciones de red (NAT) para establecer la conectividad entre Datastream y tu recurso. Para obtener más información sobre cómo configurar una VM de NAT, consulta Configurar el peering de VPC.
El esquema del objeto OBJECT_NAME es demasiado grande para que Datastream lo procese. Datastream no admite la replicación de eventos con esquemas de origen correspondientes que tengan más de 2.621.440 caracteres Unicode. Estos eventos se descartan con el siguiente código de motivo: UNSUPPORTED_LARGE_SCHEMA. Puede que quieras excluir algunas de las columnas o cambiarles el nombre. También puedes excluir el objeto con el esquema grande.
El estado de la emisión ha cambiado. Aunque puede haber más de un motivo por el que se produzca este error, un problema subyacente habitual es que la configuración de la fuente no sea válida. Si tu emisión no se inicia y aparece este mensaje de error, comprueba la configuración de la fuente para detectar claves o nombres de tabla duplicados, incoherencias en los datos o conflictos de esquemas. Muchos de los problemas se pueden resolver editando la configuración de la transmisión fallida directamente en la consola Google Cloud y ajustando las entradas de los objetos incluidos y excluidos. Para obtener más información, consulta Modificar la información de configuración de la base de datos de origen.

Errores de Oracle

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

Se puede producir un error al obtener datos de captura de datos de cambios (CDC) en curso si la configuración de registro complementario no es correcta en la base de datos de origen. Comprueba que el registro complementario esté configurado correctamente. En concreto, confirma que el registro complementario está activado en las tablas de la base de datos que se están transmitiendo desde el origen al destino. La emisión se reanudará automáticamente.
No se puede reanudar la replicación porque se ha perdido la posición del registro. Este error puede producirse cuando el proceso de replicación se pausa durante mucho tiempo, lo que provoca que se pierda la posición del registro. Los flujos no deben pausarse durante periodos de tiempo que se acerquen al periodo de conservación de los registros. Vuelve a crear el flujo.
Faltan archivos de registro, ya sea parcial o totalmente.

Es posible que se hayan eliminado los archivos de registro. Oracle purga los archivos de registro en cuanto puede, a menos que especifiques un periodo de rotación mínimo para conservarlos. En el servidor Oracle, define cuánto tiempo se deben conservar los archivos de registro. Por ejemplo, usa CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS; para conservar los archivos de registro durante al menos 4 días.

Para un despliegue de RDS, usa exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',96);
La lista de exclusión incluye la lista de inclusión. La lista de inclusión está completamente incluida 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 Oracle no está definido como ARCHIVELOG. Cambia el modo de registro y vuelve a intentarlo.
Datastream devuelve un mensaje de error ORA-00942: table or view does not exist, pero todo está configurado correctamente. Esto puede deberse al almacenamiento en caché en el servidor de Oracle. Si vuelves a crear el usuario de la base de datos, se debería solucionar el problema de almacenamiento en caché.
Los cambios que se hagan en un origen de Oracle no se reflejarán en el destino si el flujo ya está en ejecución. Si usa LogMiner como método de CDC, Datastream lee los archivos de registro de rehacer archivados. En ese caso, los cambios que hagas en el origen no se reflejarán en el destino hasta que se archive el registro. Para ver los cambios en el destino, cambia el método de CDC a lector de registros binarios, cambia la política de archivo de registros o fuerza manualmente un cambio de registro. Para obtener más información, consulta Trabajar con archivos de registro de versiones de base de datos de Oracle.
No se ha podido validar la configuración de CDC de Oracle. Has seleccionado un método de CDC para el que no se ha configurado tu base de datos de origen. Selecciona otro método o completa la configuración del método de CDC. Para obtener más información, consulta Configurar una base de datos de Oracle de origen.
Se ha producido un error interno inesperado. Para obtener más información, ponte en contacto con el equipo de Asistencia de Google.

Errores de MySQL

Error Pasos para solucionar el problema
Binlog está configurado incorrectamente en la base de datos de origen.

Esto puede ocurrir en las secuencias de MySQL continuas si la configuración de binlog es incorrecta en la base de datos de origen. Para solucionar este error, haz lo siguiente:

  1. Comprueba que binlog esté configurado correctamente.
  2. Confirma que el formato del registro binario de la base de datos MySQL sea ROW.
  3. Reinicia la emisión.
No se puede reanudar la replicación porque se ha perdido la posición del archivo de registro binario. Este error puede producirse cuando el proceso de replicación se pausa durante mucho tiempo, lo que provoca que se pierda la posición del registro binario. Las secuencias no deben pausarse durante periodos que se acerquen al periodo de conservación de binlog. Vuelve a crear el flujo.
No se ha podido ejecutar el flujo debido a que las versiones de la base de datos de origen y de destino no son compatibles.

Esto puede ocurrir cuando la base de datos de origen no cumple la matriz de compatibilidad de versiones. Para solucionar este error, haz lo siguiente:

  1. Asegúrate de que la base de datos de origen cumple los requisitos de la matriz.
  2. Vuelve a crear el flujo con la base de datos de origen actualizada.
Faltan los archivos de registro binario de origen de MySQL de AWS RDS, ya sea parcial o totalmente. Es posible que se hayan eliminado los archivos de registro binario. AWS RDS purga los archivos de registro binarios en cuanto puede, a menos que especifiques un periodo de rotación mínimo para conservarlos. En la instancia de origen de AWS RDS MySQL, define durante cuántas horas se deben conservar los registros binarios. Por ejemplo, usa mysql.rds_set_configuration('binlog retention hours', 168); para conservar los binlogs durante al menos 7 días.
La lista de exclusión incluye la lista de inclusión. La lista de inclusión está completamente incluida 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 MySQL. Asegúrate de que Datastream tenga permisos para replicar la base de datos.
Al crear un perfil de conexión para una fuente de MySQL, no se aceptan varios certificados SSL codificados en PEM en el menú Tipo de cifrado. Datastream no admite cadenas de certificados SSL en los perfiles de conexión de MySQL. Solo se admiten certificados únicos x509 codificados en PEM.
Latencia alta al transmitir datos desde una fuente MySQL.

Aumenta la capacidad de Datastream para leer de la base de datos de origen:
No se ha podido validar la configuración de CDC de MySQL. La base de datos de origen no se ha configurado para el método de CDC que ha seleccionado. Selecciona otro método o completa la configuración del método de CDC. Para obtener más información, consulta Configurar una base de datos MySQL de origen.
Se ha producido un error interno inesperado. Para obtener más información, ponte en contacto con el equipo de Asistencia de Google.

Errores de PostgreSQL

Error Pasos para solucionar el problema
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 correctamente. Consulta Configurar una base de datos PostgreSQL de origen.
El espacio de replicación no existe. Se puede producir un error al obtener datos de captura de datos de cambios (CDC) en curso si la ranura de replicación no existe en la base de datos. Verifica que el espacio de réplica esté configurado correctamente. Consulta Configurar una base de datos PostgreSQL de origen.
La ranura de replicación se ha configurado con un complemento incorrecto. Este error puede producirse si la ranura de replicación se configura con un complemento distinto de pgoutput. Verifica que el espacio de réplica esté configurado correctamente. Consulta Base de datos PostgreSQL de origen para obtener más información.
La ranura de replicación está activa en otro proceso. Este error puede producirse cuando otro proceso está usando la ranura de replicación. Solo un proceso puede usar las ranuras de replicación a la vez. Asegúrate de no usar la misma ranura de replicación en ningún otro proceso que no sea Datastream.
La publicación no está configurada correctamente. Este error puede producirse cuando la publicación no está configurada para exponer las tablas que se incluyen en la configuración de la secuencia. Comprueba que la publicación esté configurada correctamente. Consulta Configurar la información sobre la base de datos de origen del flujo.
La publicación no existe. Este error puede producirse si la publicación no existe en la base de datos. Comprueba que la publicación esté configurada correctamente. Consulta Configurar una base de datos PostgreSQL de origen.
No se puede reanudar la replicación porque se han perdido archivos WAL. Este error puede producirse cuando el proceso de replicación se pausa durante mucho tiempo, lo que provoca que se pierdan los archivos WAL. Las secuencias no deben pausarse durante periodos de tiempo que se acerquen al periodo de conservación de los archivos WAL. Vuelve a crear el flujo.
La lista de exclusión incluye la lista de inclusión. La lista de inclusión está completamente incluida 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 de gran tamaño en la base de datos de origen provocan problemas con la replicación y la sincronización de datos. Si inserta, actualiza o elimina un número significativo de registros en la base de datos de origen, la ranura de replicación puede sobrecargarse con los eventos correspondientes. El flujo de datos necesita tiempo para leer y procesar estos eventos. Como los slots de replicación de PostgreSQL son de un solo hilo, el procesamiento de otros cambios en el slot 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 del slot de replicación.
Las transacciones de gran tamaño en la base de datos de origen provocan un bajo rendimiento de CDC. Datastream no admite la captura de datos de cambios (CDC) multihilo en PostgreSQL. Para superar esta limitación y aumentar el rendimiento de CDC, puede dividir la fuente en varias secuencias, cada una con su propia publicación y ranura de replicación. Por ejemplo, puede crear un flujo para la tabla más grande de su base de datos y otro para el resto de las tablas, o bien un flujo para las tablas de máxima prioridad y otro para las demás. Los casos prácticos pueden variar, por lo que debe tener en cuenta qué es lo más adecuado en su caso específico. Para obtener información sobre cómo crear una publicación, consulta Configurar una base de datos PostgreSQL de origen.
Se han descartado eventos no admitidos con el código de motivo BIGQUERY_TOO_MANY_PRIMARY_KEYS. Si la réplica de identidad de PostgreSQL de una tabla se define como FULL, Datastream trata todas las columnas de esa tabla como claves principales. Si la tabla tiene más de 16 columnas, se infringe la limitación de CDC de BigQuery y se produce el error. Para solucionar el problema, sigue estos pasos:
  1. Cambia la identidad de la réplica a DEFAULT: 
    ALTER TABLE TABLE_NAME REPLICA IDENTITY DEFAULT
     Sustituye TABLE_NAME por el nombre de la tabla cuya identidad de réplica quieras cambiar.
  2. Quita la tabla de la lista de objetos que se van a incluir en el flujo. Para obtener más información, consulta Modificar la información de configuración de la base de datos de origen.
  3. Elimina la tabla de BigQuery. Para obtener más información, consulta Eliminar tablas.
  4. En Datastream, vuelva a añadir la tabla al flujo editando la configuración de la fuente.
Se ha producido un error interno inesperado. Para obtener más información, ponte en contacto con el equipo de Asistencia de Google.

Errores de SQL Server

Error Pasos para solucionar el problema
La CDC está inhabilitada en la base de datos DATABASE_NAME.

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

Para obtener información sobre cómo habilitar CDC en una base de datos, consulta Configurar una base de datos SQL Server de origen.
Tablas con CDC inhabilitado.

La captura de datos de cambios (CDC) debe estar habilitada en 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 completa de los registros. Habilita CDC en las tablas incluidas en el flujo y vuelve a intentarlo.

Para obtener información sobre cómo habilitar CDC en las tablas de origen, consulta Configurar una base de datos SQL Server de origen.
Faltan permisos. A la secuencia de datos le faltan los permisos necesarios para leer de la fuente. Concede los permisos adecuados a la cuenta de usuario que se utiliza para conectarse a tu base de datos y vuelve a intentarlo.
No se admite la edición EDITION_NAME de SQL Server. Datastream no admite esta edición de SQL Server. Para obtener más información sobre las ediciones compatibles de SQL Server, consulta el artículo Información general sobre SQL Server como fuente.
No se admite la versión VERSION_NAME de la edición Standard de SQL Server. Datastream no admite esta versión de la edición Standard de SQL Server. Para obtener más información sobre las versiones compatibles de SQL Server, consulta el artículo Información general sobre SQL Server como fuente.
La secuencia no puede leer el evento en LSN "YOUR_LSN" porque el registro de transacciones parece estar truncado.

Este problema puede producirse cuando los registros de transacciones ya no están en la base de datos de origen. Cuando replicas datos de una fuente de SQL Server mediante el método de CDC de los registros de transacciones, es posible que los registros se trunquen antes de que Datastream los lea. Cuando esto ocurre, Datastream no puede replicar de forma fiable la base de datos de origen en el destino.

Para resolver el problema, recupera tu flujo o considera la posibilidad de usar el método de CDC de tablas de cambios. Para obtener más información sobre las diferencias entre los dos métodos, consulta Descripción general de SQL Server como origen.
Configuración de CDC de SQL Server: error. El método de CDC que ha seleccionado no cumple los requisitos de configuración de su base de datos. Cambia el método de CDC y vuelve a intentarlo.

Errores de Salesforce

Error Pasos para solucionar el problema
No tienes permisos suficientes.

El usuario de la aplicación conectada o de la aplicación cliente externa que has configurado para autenticar la conexión entre tu organización de Salesforce y Datastream no tiene permisos suficientes para acceder a los datos que quieres replicar. Asegúrate de que has configurado correctamente tu fuente de Salesforce. Para obtener más información, consulta Configurar una fuente de Salesforce.
Bulk API 2.0 inhabilitada.

La API Bulk 2.0 está habilitada de forma predeterminada en las ediciones Performance, Unlimited, Enterprise y Developer. Este mensaje de error indica que la API está inhabilitada en tu edición o que las credenciales que usas no tienen permisos suficientes. Asegúrese de que el perfil de usuario que utiliza tiene concedido el permiso API Enabled.
Se ha superado el límite.

Has superado el límite de consultas de la API de Salesforce. Este mensaje se muestra cuando alcanzas el 90% de tu cuota de límite de API. En ese caso, Datastream vuelve a intentar la operación más adelante. Te recomendamos que aumentes tu cuota de la API de Salesforce.
Se ha superado el límite de eliminaciones.

Cuando se consultan registros eliminados, Salesforce limita la respuesta a 600.000 identificadores de registros. La granularidad de consulta más baja en Salesforce es de un minuto. Si eliminas más de 600.000 registros en un minuto, Salesforce devuelve este error.
No se ha podido autenticar.

Datastream no puede autenticarse en Salesforce. Es probable que hayas usado las credenciales o el nombre de dominio incorrectos.

Errores de MongoDB

Error Pasos para solucionar el problema
Error de autenticación. Comprueba si el authSource del usuario de Datastream es admin. El usuario de Datastream debe crearse en la base de datos admin. Esta base de datos es una base de datos con privilegios que permite a los usuarios ejecutar determinados comandos administrativos.
No se ha podido iniciar sesión en la base de datos. Comprueba tu nombre de usuario y tu contraseña e inténtalo de nuevo. Además, asegúrate de que tu cuenta de usuario se haya creado en la base de datos admin. Si el problema persiste, es posible que tu cuenta de usuario se haya eliminado o se haya creado de forma incorrecta.
La lista de objetos excluidos no es válida: {exclude_list}. Especifique los objetos excluidos con el siguiente formato: DATABASE_NAME.COLLECTION_NAME.FIELD_NAME.NESTED_FIELD_NAME con comodines opcionales. Ejemplos válidos: db.*, database.collection.* y database.*.field.*.
No tenemos los permisos necesarios para leer la fuente. Asigna el rol readAnyDatabase a tu usuario y vuelve a intentarlo.
La versión VERSION_NAME de MongoDB no es compatible. Usa la versión 5.0 o una posterior.
Datastream no ha podido ejecutar el comando buildinfo para determinar la versión de MongoDB. Asegúrate de que el usuario tenga los permisos necesarios para ejecutar el comando buildinfo y vuelve a intentarlo. Para obtener más información sobre los permisos necesarios, consulta Configurar una base de datos MongoDB.
Se ha agotado el tiempo de espera de conexión con el clúster de MongoDB. Asegúrate de que has proporcionado el nombre de host y las credenciales correctos, y vuelve a intentarlo.
No podemos leer los datos necesarios por falta de permisos. Asigna el rol readAnyDatabase a la cuenta que se usa para conectarse a tu clúster de MongoDB y vuelve a intentarlo.
La cuenta de usuario que se usa para conectarse a su clúster de MongoDB no existe. Crea la cuenta de usuario y vuelve a intentarlo.
No hemos podido conectarnos con la información proporcionada. Verifica que se haya usado el formato de conexión correcto (SRV o estándar) y que se haya incluido toda la información necesaria (como los nombres de los conjuntos de réplicas en el caso de las cadenas de conexión de conjuntos de réplicas). Para obtener más información, consulta Crear un perfil de conexión para una base de datos MongoDB.
Se ha detectado una excepción de MongoDB. Mensaje de error de la fuente: {source_error}. Si el mensaje de error de la fuente no está claro, ponte en contacto con el equipo de Asistencia de Google.

Errores de BigQuery

Error Pasos para solucionar el problema
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 principal cambia en la fuente, debe eliminar la tabla de BigQuery y volver a iniciar el relleno. Esta es una limitación de BigQuery, ya que no hay forma de asegurar que los eventos nuevos se combinen correctamente con las filas existentes si la clave principal es diferente. Para obtener más información, consulta Configurar un destino de BigQuery.
La tabla de BigQuery de destino tiene muchos más registros que la tabla de origen. Esto puede ocurrir cuando la tabla de origen no tiene una clave principal. En ese caso, Datastream procesa la tabla en el modo de escritura solo de anexión y cada evento de una fila determinada aparece como una fila independiente en BigQuery.
Los datos se duplican al realizar un relleno en el modo de escritura Solo añadir.

Si seleccionas el modo de escritura Solo añadir para tu flujo, tus datos se añadirán a BigQuery como un flujo de eventos INSERT, UPDATE-INSERT, UPDATE-DELETE y DELETE, sin consolidación. Esto puede provocar que se escriban filas duplicadas en BigQuery cuando realices un relleno retroactivo o cuando se produzca un problema y el escritor de BigQuery vuelva a intentar las operaciones de escritura. Para solucionar el problema, le recomendamos que ejecute una consulta de eliminación de duplicados similar a la siguiente de forma periódica:

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

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

Si no hay ninguna clave principal, plantéate añadir una en la tabla de origen o en la de destino. Para añadir una clave principal a la tabla de BigQuery de destino, siga estos pasos:

  1. Pausar la emisión.
  2. Truncar la tabla en BigQuery.
  3. Añade la clave principal a la definición de la tabla.
  4. Reanuda la emisión.
  5. Activa el relleno retroactivo de la tabla.
No se puede añadir ni eliminar una clave principal, ni cambiar la definición de la clave principal de una tabla que ya se ha replicado en BigQuery.

De forma predeterminada, Datastream no admite la adición de una clave principal a una tabla que ya se ha replicado en BigQuery sin una clave principal, ni la eliminación de una clave principal de una tabla que se ha replicado en BigQuery con una clave principal. Sin embargo, puedes cambiar la definición de la clave principal de una tabla de origen replicada en BigQuery que ya tenga una clave principal:

  1. Comprueba la métrica de latencia total de la emisión y espera al menos el tiempo que indique la latencia actual para asegurarte de que los eventos en curso se escriben en el destino. De esta forma, todos los eventos con la clave principal original se pueden transmitir correctamente.
  2. Pausa la emisión.
  3. Copia el comando del CREATE TABLElenguaje de definición de datos (DDL) de la tabla en BigQuery: 
        SELECT ddl FROM PROJECT_ID.DATASET.INFORMATION_SCHEMA.TABLES
      WHERE table_name='TABLE_NAME';

    Haz los cambios siguientes:

    • PROJECT_ID: el identificador de tu proyecto de Google Cloud .
    • DATASET_ID: el identificador del conjunto de datos en BigQuery.
    • TABLE_NAME: el nombre de la tabla de la que quieras copiar el comando DDL.
  4. Elimina la tabla en BigQuery.
  5. Ajusta el comando CREATE TABLE DDL con las nuevas claves principales. Incluya las claves de partición y de clúster, así como max_staleness OPTION: 
        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
    );
    ;

    Haz los cambios siguientes:

    • PROJECT_ID: el identificador de tu proyecto de Google Cloud .
    • DATASET_ID: el identificador del conjunto de datos en BigQuery.
    • TABLE_NAME: el nombre de la tabla de la que has copiado el comando DDL.
    • MINS: el número de minutos que quieras definir 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 emisión.
  8. Inicia el backfill de la tabla.

Siguientes pasos

  • Para saber cómo buscar posibles problemas con tu emisión, consulta el artículo Solucionar problemas con una emisión.
  • Para saber cómo configurar la base de datos de origen, consulta Orígenes.
  • Para saber cómo configurar tu destino de BigQuery o Cloud Storage, consulta Destinos.