Diagnosticar problemas

Es posible que la transmisió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 contiene tipos de datos no admitidos. Otros errores pueden afectar varios objetos o todo el flujo, por ejemplo, cuando Datastream no puede conectarse a la base de datos de origen.
  • Según el error, se proporciona información en las páginas Flujos o Detalles del flujo 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 la transmisión para verlo 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
Falla en la conexión a la base de datos de origen (genérica).

Esto puede suceder por varios motivos. Para solucionar este error, haz lo siguiente:

  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 tenga los privilegios necesarios.
  6. Guarda los cambios que realizaste en la página Perfiles de conexión.

La transmisión se reanuda 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 (reenvío por túnel SSH). 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, debe iniciarse. 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.
Falla en la conexión a la base de datos de origen debido a certificados incorrectos. Esto puede ocurrir si hay un problema con los certificados proporcionados cuando se define 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 correctamente. Después de realizar los cambios, guarda el perfil de conexión y la transmisión se reanudará automáticamente.
No se pudo usar la conectividad privada para conectarse a la base de datos de origen. Este error se relaciona con el método de conectividad privada de intercambio de tráfico entre VPC.
  1. Asegúrate de haber completado todos los requisitos previos del intercambio de tráfico entre VPCs.

  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 hay superposiciones 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 del flujo de datos se anuncien 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 Cómo configurar un proxy inverso.
No se pudo usar la interfaz de Private Service Connect para conectarse a la base de datos de origen.
  1. Asegúrate de haber completado todos los requisitos previos.
  2. Asegúrate de que tus reglas de firewall permitan que la subred del adjunto de red proporcionado se conecte a la base de datos de origen.
  3. Asegúrate de que las rutas personalizadas para los rangos de direcciones IP del flujo de datos se anuncien correctamente. Si faltan las rutas personalizadas, consulta Rutas anunciadas personalizadas.
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 túnel SSH de reenvío o de lista de IP públicas permitidas para el perfil de conexión que estás creando. Sin embargo, se habilitó la política de la organización Block Public Connectivity Methods para Datastream. 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 interfaces de Private Service Connect, o bien inhabilita la política de la organización.

Para inhabilitar la política de la organización, haz lo siguiente:

  1. Ve a la página Políticas de la organización en la Google Cloud consola.
  2. Selecciona la política de la organización Datastream - Block Public Connectivity Methods.

  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 de ellos no se incluyan en la lista de objetos que se deben extraer cuando se configura la fuente para 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, selecciona Personalizado. En el campo Criterios de coincidencia de objetos, ingresa los esquemas y las tablas que deseas que Datastream extraiga.
Agregué varias tablas a mi transmisión con el menú Objetos para incluir. Sin embargo, cuando miro la pestaña Objects en Stream details, 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, incluirlas automáticamente en el flujo.
No se pudo cargar la lista de objetos cuando se usó el menú Objetos para incluir en la consola de Google Cloud . Esto puede ocurrir si tu base de datos tiene más de 5,000 esquemas y tablas. Usa otro método para especificar qué objetos incluir o usa la API de Datastream. Para obtener más información, consulta Configura bases de datos de origen.
Eventos que se descartaron durante la transmisión y no se replicaron en el destino.

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

  • Activa manualmente un reabastecimiento de toda la tabla. Esto funciona si los eventos descartados son solo eventos UPSERT. Si los eventos descartados incluyen eventos de 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ídele que realice un relleno parcial. Esto solo es posible si puedes identificar los eventos descartados con una cláusula WHERE de SQL y si ninguno de los eventos es un evento DELETE.
  • Ignora el problema si la cantidad de eventos descartados es baja o si los eventos descartados no son significativos.
Se agotó el tiempo de espera al intentar conectarse a la fuente de datos. Asegúrate de que la configuración del nombre de host y el puerto sea precisa, y de que se pueda acceder a la fuente de datos. Debido a que la red de Datastream no puede intercambiar tráfico directamente con una red de servicios privados (por ejemplo, una instancia de Cloud SQL) cuando se usa el intercambio de tráfico de VPC, 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 Configura el intercambio de tráfico entre VPCs.
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 superen los 2,621,440 caracteres Unicode. Estos eventos se descartan con el siguiente código de motivo: UNSUPPORTED_LARGE_SCHEMA. Es posible que desees excluir algunas de las columnas o cambiarles el nombre. Como alternativa, puedes excluir el objeto con el esquema grande.
Cambió el estado de la transmisión. Si bien puede haber más de un motivo para que se produzca este error, un problema subyacente común es la configuración de fuente no válida. Si tu transmisión no se inicia con este mensaje de error, verifica la configuración de la fuente para detectar claves o nombres de tablas duplicados, inconsistencias 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 de Google Cloud y ajustando las entradas de los objetos incluidos y excluidos. Para obtener más información, consulta Cómo modificar la información de configuración sobre la base de datos de origen.

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 del registro complementario no es correcta en la base de datos de origen, puede producirse un error al recuperar los datos de captura de datos modificados (CDC) en curso. Verifica que el registro complementario esté configurado correctamente. Específicamente, confirma que el registro complementario esté activado para las tablas de la base de datos que se transmiten desde la fuente al destino. La transmisión se reanuda automáticamente.
No se pudo 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 provoca que se pierda la posición del registro. Las transmisiones no deben pausarse durante 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 los archivos de registro tan pronto como puede, a menos que especifiques un período de rotación mínimo para conservarlos. En el servidor de Oracle, establece el tiempo durante el que 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 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á establecido en ARCHIVELOG. Cambia el modo de registro y, luego, 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. Recrear 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. Si usas LogMiner como método de CDC, Datastream lee los archivos de registro de rehacer archivados. En ese caso, 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 el método de CDC al 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 Trabaja con archivos de registro de rehacer de la base de datos de Oracle.
No se pudo validar la configuración de CDC de Oracle. Seleccionaste un método de CDC para el que no se configuró tu base de datos de origen. Selecciona otro método o completa la configuración del método de CDC. Para obtener más detalles, consulta Configura una base de datos de Oracle de origen.
Se produjo un error interno inesperado. Para obtener más detalles, comunícate con el equipo de 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 ocurrir en transmisiones continuas de MySQL si la configuración del registro binario 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 de registro binario de la base de datos de 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 se pausa durante mucho tiempo, lo que provoca que se pierda la posición del registro binario. No se deben pausar las transmisiones durante períodos que se acerquen al período de retención del registro binario. 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 binlogs. AWS RDS borra los registros binarios tan pronto como puede, a menos que especifiques un período de rotación mínimo para conservarlos. En la instancia de origen de AWS RDS MySQL, establece durante cuántas horas se deben conservar los registros binarios. Por ejemplo, usa mysql.rds_set_configuration('binlog retention hours', 168); para conservar los registros binarios durante al menos 7 días.
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.
Datastream no puede replicar una base de datos de MySQL. Asegúrate de que Datastream tenga permisos para replicar la base de datos.
Cuando creas un perfil de conexión para una fuente de MySQL, no se aceptan varios certificados SSL codificados en 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.
Hay una latencia alta cuando se transmite desde una fuente de MySQL.

Aumenta la capacidad de Datastream para leer desde la base de datos de origen:

  • Reduce el tamaño máximo del archivo de registro binario (binlog) para tu base de datos de origen. Reducir el tamaño aumenta la cantidad de archivos de registro binario.
  • Si hay varios archivos de registro binario, establece la cantidad de tareas de CDC simultáneas máximas para la transmisión según corresponda. Tener varios archivos de registro binario permite que Datastream lea los eventos de la base de datos de origen de forma simultánea, hasta la cantidad establecida en el campo maxConcurrentCdcTasks.
No se pudo validar la configuración de los CDC de MySQL. Tu base de datos de origen no se configuró para el método de CDC que seleccionaste. Selecciona otro método o completa la configuración del método de CDC. Para obtener más detalles, consulta Configura una base de datos MySQL de origen.
Se produjo un error interno inesperado. Para obtener más detalles, comunícate con el equipo de 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 correctamente. Consulta Cómo configurar una base de datos de PostgreSQL de origen.
No existe la ranura de replicación. Se puede producir un error al recuperar datos de captura de datos modificados (CDC) en curso si la ranura de replicación no existe en la base de datos. Verifica que la ranura de replicación esté configurada correctamente. Consulta Cómo configurar una base de datos de 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 la ranura de replicación esté configurada correctamente. Consulta Base de datos de PostgreSQL de origen para obtener más información.
La ranura de replicación está activa en otro proceso. Este error puede ocurrir cuando otro proceso usa la ranura de replicación. Las ranuras de replicación solo pueden ser utilizadas por un solo proceso 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 de la transmisión. Verifica que la publicación esté configurada correctamente. 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 correctamente. Consulta Cómo configurar una base de datos de PostgreSQL de origen.
No se pudo reanudar la replicación porque se perdieron los archivos WAL. Este error puede ocurrir cuando el proceso de replicación se pausa durante un período prolongado, lo que provoca la pérdida de los archivos WAL. Las transmisiones no deben pausarse durante períodos que se acerquen al período de retención de los archivos del WAL. Vuelve a crear la transmisión.
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.
Datastream no puede replicar un esquema de PostgreSQL. Asegúrate de que Datastream tenga permiso para replicar el esquema.
Las transacciones grandes en la base de datos de origen causan problemas con la replicación y la sincronización de datos. Si insertas, actualizas o borras una cantidad significativa de registros en la base de datos de origen, es posible que la ranura de replicación se sobrecargue con los eventos correspondientes. Datastream necesita tiempo para leer y procesar estos eventos. Dado que las ranuras de replicación de PostgreSQL son de un solo subproceso, el procesamiento de otros cambios en la ranura de replicación, incluidos los cambios en los datos de otras tablas, se retrasa hasta que Datastream se ponga al día con todos los cambios en la ranura de replicación.
Las transacciones grandes en la base de datos de origen provocan un bajo rendimiento de CDC. Datastream no admite la CDC de subprocesos múltiples en PostgreSQL. Para superar esta limitación y aumentar la capacidad de procesamiento de CDC, puedes dividir la fuente en múltiples transmisiones, cada una con su propia ranura de publicación y replicación. Por ejemplo, puedes crear una transmisión para la tabla más grande de tu base de datos y otra para todas las demás, o una transmisión para las tablas de mayor prioridad y otra 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 PostgreSQL de origen.
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 principales. Si hay más de 16 columnas en la tabla, se incumple la limitación de CDC de BigQuery y se genera 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 sobre la base de datos de origen.
  3. Borra la tabla de BigQuery. Para obtener más información, consulta Borra tablas.
  4. En Datastream, vuelve a agregar la tabla al flujo editando la configuración de la fuente.
Se produjo un error interno inesperado. Para obtener más detalles, comunícate con el equipo de 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.

La captura de datos modificados (CDC) debe estar habilitada para la base de datos. Datastream necesita acceso directo de lectura a los registros de transacciones para replicar los cambios en tiempo real en la base de datos de origen y obtener información completa del registro. Habilita los 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 Configurar una base de datos de SQL Server de origen.
Tablas con CDC inhabilitadas.

La captura de datos modificados (CDC) debe estar habilitada para todas las tablas incluidas en la transmisión. Datastream necesita acceso directo de lectura a los registros de transacciones para replicar los cambios en tiempo real en las tablas de origen y obtener información completa del registro. Habilita la CDC para las tablas incluidas en la transmisión 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 admite 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 Standard 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.
La transmisión no puede leer el evento en LSN "YOUR_LSN", ya que el registro de la transacción parece estar truncado.

Este problema puede ocurrir cuando los registros de transacciones ya no existen en la base de datos de origen. Cuando replicas datos desde una fuente de SQL Server con el método CDC de registros de transacción, es posible que los registros se trunquen antes de que Datastream los lea. Cuando esto sucede, Datastream no puede replicar de manera confiable la base de datos de origen en el destino.

Para resolver el problema, recupera tu transmisión o considera 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 fuente.
Error en la configuración de los CDC de SQL Server. 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 Salesforce

Error Pasos para solucionar problemas
No tienes permisos suficientes.

El usuario de la app conectada o la app cliente externa que configuraste para autenticar la conexión entre tu organización de Salesforce y Datastream no tiene permisos suficientes para acceder a los datos que deseas replicar. Asegúrate de haber configurado correctamente tu fuente de Salesforce. Para obtener más información, consulta Configura una fuente de Salesforce.
Se inhabilitó la API masiva 2.0.

La API masiva 2.0 está habilitada de forma predeterminada para 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úrate de que el perfil de usuario que uses tenga el permiso API Enabled otorgado.
Se superó el límite.

Superaste el límite de consultas de la API de Salesforce. Verás este mensaje cuando alcances el 90% de la cuota límite de la 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 superó el límite de eliminación.

Cuando se consultan registros borrados, Salesforce limita la respuesta a 600,000 identificadores de registros. La granularidad de consulta más baja en Salesforce es de un minuto. Si borras más de 600,000 registros en un minuto, Salesforce mostrará este error.
Error de autenticación

Datastream no puede autenticarse con Salesforce. Es probable que hayas usado credenciales o un nombre de dominio incorrectos.

Errores de MongoDB

Error Pasos para solucionar problemas
No se pudo realizar la 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 privilegiada y permite que los usuarios ejecuten ciertos comandos administrativos.
No se pudo acceder a la base de datos. Revisa tu nombre de usuario y contraseña, y vuelve a intentarlo. 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 se haya borrado tu cuenta de usuario o que se haya creado de forma incorrecta.
La lista de objetos excluidos no es válida: {exclude_list}. Especifica los objetos excluidos en el siguiente formato: DATABASE_NAME.COLLECTION_NAME.FIELD_NAME.NESTED_FIELD_NAME con comodines opcionales. Ejemplos válidos: db.*, database.collection.*, database.*.field.*.
No tenemos los permisos necesarios para leer datos desde 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 pudo 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 Cómo configurar una base de datos de MongoDB.
Se agotó el tiempo de espera de la conexión al clúster de MongoDB. Asegúrate de haber proporcionado el nombre de host y las credenciales correctos, y vuelve a intentarlo.
No podemos leer los datos necesarios porque no tienes los permisos requeridos. 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 tu clúster de MongoDB no existe. Crea la cuenta de usuario y vuelve a intentarlo.
No pudimos establecer la conexión con la información proporcionada. Verifica que se use el formato de conexión correcto (SRV o estándar) y que se incluya toda la información necesaria (como los nombres de conjuntos de réplicas para la cadena de conexión del conjunto de réplicas). Para obtener más información, consulta Crea un perfil de conexión para una base de datos de MongoDB.
Se produjo una excepción de MongoDB. Mensaje de error de la fuente: {source_error}. Si el mensaje de error de la fuente no es claro, comunícate con el equipo de Atención al cliente de Google.

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 correcta combinación de eventos nuevos con filas existentes si la clave primaria es diferente. Para obtener más información, consulta Cómo configurar 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 un reabastecimiento en el modo de escritura Solo agregar.

Cuando seleccionas el modo de escritura Solo agregar para tu transmisión, tus datos se agregan en 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 reabastecimiento o cuando ocurra un problema y el escritor de BigQuery vuelva a intentar las operaciones de escritura. Para solucionar el problema, te recomendamos que ejecutes 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 para el modo de escritura de combinación, pero los cambios no se combinan en BigQuery.

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

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

  1. Pausa la transmisión
  2. Trunca la tabla en BigQuery.
  3. Agrega la clave primaria a la definición de la tabla.
  4. Reanuda la transmisión.
  5. Activa el reabastecimiento de la tabla.
No se puede agregar ni quitar una clave primaria, ni cambiar la definición de la clave primaria de una tabla que ya se replicó 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 la clave primaria de una tabla de origen replicada en BigQuery que ya tenga una clave primaria:

  1. Verifica la métrica de latencia total de la transmisión y espera al menos el tiempo de 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 primaria original se transmitan correctamente.
  2. Pausa la transmisión.
  3. Copia el comando del lenguaje de definición de datos (DDL) de CREATE TABLE para la tabla en BigQuery: 
        SELECT ddl FROM PROJECT_ID.DATASET.INFORMATION_SCHEMA.TABLES
      WHERE table_name='TABLE_NAME';

    Reemplaza lo siguiente:

    • PROJECT_ID: Es 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 para la que deseas copiar el comando DDL.
  4. Borra la tabla en BigQuery.
  5. Ajusta el comando DDL CREATE TABLE con las nuevas claves primarias. Incluye las claves de partición y clúster, y el 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
    );
    ;

    Reemplaza lo siguiente:

    • PROJECT_ID: Es 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 para la que copiaste el comando 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 Soluciona problemas de una transmisión.
  • Para obtener información sobre cómo configurar tu base de datos de origen, consulta Fuentes.
  • Para obtener información sobre cómo configurar tu destino de BigQuery o Cloud Storage, consulta Destinos.