Database Integration Extraction Error Reference

All database integrations

Discovery job limits

Stitch discovered more than the maximum limit of 10,000 tables for the integration.

Decrease the number of discoverable tables by limiting the Stitch database user’s access only to tables you want to replicate. You can accomplish this by altering the Stitch database user’s privileges in the database.

Refer to the documentation for your database for instructions.

All integrations

Extraction job limits

The extraction exceeded the maximum six hour limit set for individual extraction jobs.

Stitch sets a maximum limit of six hours for individual extraction jobs. This is done to balance resource usage across Stitch, and to help prevent unexpected or unintended continuations of connections against integrations.

To help decrease the runtime of extraction, we recommend de-selecting unneeded tables and columns. This will reduce the amount of data being replicated.

Stitch will automatically retry extraction based on the integration’s schedule.

All integrations

Extraction job limits

A single record exceeded the maximum size limit of 20MB. This limit is imposed by the Import API, which Stitch uses as part of the replication process.

Locate the record in the source and, if possible, modify it to be less than Stitch’s limit. You can also try de-selecting columns in the table containing the record.

Amazon DynamoDB v1 database integrations

A projection expression entered in Stitch contains double quotes.

Remove double quotes from any projection expression and ensure they adhere to Stitch’s other requirements for projection expressions.

Microsoft SQL Server v1-backed database integrations

Change Tracking is not enabled for the named database, which contains tables that are set to replicate and use Log-based Incremental Replication in Stitch.

Enable Change Tracking for the database referenced in the error message. To use Change Tracking, you must enabled it both at the database and table level.

To enable Change Tracking for the database, log into your database and run the following statement, replacing <database_name> with the name of the database:

ALTER DATABASE <database_name>  
SET CHANGE_TRACKING = ON  
(CHANGE_RETENTION = 3 DAYS, AUTO_CLEANUP = ON)

Microsoft SQL Server v1-backed database integrations

Change tracking is not enabled for the named table, which is set to replicate and use Log-based Incremental Replication.

Enable change tracking for the table referenced in the error message. To use Change Tracking, you must enabled it both at the database and table level. Microsoft SQL Server requires that Change Tracking be enabled for every table you want to use Log-based Incremental for.

To enable Change Tracking for the table, log into your database and run the following statement, replacing <schema_name>.<table_name> with the names of the schema and table:

ALTER TABLE <schema_name>.<table_name>  
ENABLE CHANGE_TRACKING  
WITH (TRACK_COLUMNS_UPDATED = ON)

Run the statement for every table you want to replicate using Log-based Incremental Replication.

Microsoft SQL Server v1-backed database integrations

The log retention settings for the database are insufficient, causing log files to age out before Stitch can replicate them. When this occurs, Stitch will clear the saved log position ID for any affection table(s) and re-replicate them in full.

Increase the database’s CHANGE_RETENTION setting. Stitch recommends a minimum of 3 days, but 7 days is preferred. This ensures that you have time to resolve any issues that arise before logs age out and are purged. Refer to Microsoft’s documentation for more info about this setting.

In addition, make sure you resolve any connection or replication issues quickly. This will reduce the likelihood that binary log files will age out and cause this error.

MongoDB v1+-backed database integrations

The OpLog’s maximum size is insufficient, causing log files to age out before Stitch can replicate them. When this occurs, Stitch will clear the saved log position ID for any affection collection(s) and re-replicate them in full.

Increase the maximum size of the OpLog using the replSetResizeOplog command.

Note: As the maximum size you need depends on your database, it may take some experimentation to identify the best setting. Mongo doesn’t currently recommend an OpLog size.

MongoDB v1+-backed database integrations

Database user privileges

The Stitch MongoDB database user isn’t authorized to execute commands on the local database. This is required to successfully replicate data.

Grant the Stitch MongoDB database user read access to the local database. Refer to the guide for your MongoDB type for instructions:

• MongoDB

• MongoDB Atlas

MongoDB v1+-backed database integrations

A projection query for a collection set to replicate is excluding the collection’s _id field.

For example:

{ "_id": 0 }

Modify the collection’s projection query to remove the exclusion of the _id field. Stitch requires the _id field for replication; excluding it in projection queries is not supported.

Refer to the Selecting MongoDB Fields Using Projection Queries guide for more info.

MongoDB v1+-backed database integrations

A projection query for a collection set to replicate includes both inclusion and exclusion statements. MongoDB doesn’t currently support inclusion and exclusion statements in the same projection query.

The following projection query is an example of including both types of statements:

{ "name": 1, "type": 0 }

Modify the collection’s projection query to use only inclusion or only exclusion statements. For example:

{ "name": 1, "type": 1 }

{ "name": 0, "type": 0 }

Refer to the Selecting MongoDB Fields Using Projection Queries guide for more info and examples of projection queries.

MongoDB v1+-backed database integrations

A projection query for a collection set to replicate isn’t valid JSON. A projection query is a JSON object; keys within the object must be enclosed in double quotes (").

For example: The following projection queries are invalid JSON:

{ 'name': 1, 'type': 1 }

"name: 1, "type": 1

Modify the collection’s projection query to be valid JSON. For example:

{ "name": 1, "type": 1 }

You can use JSONFormatter to validate the projection query before entering it into Stitch.

MongoDB v1+-backed database integrations

A Replication Key field contains an incompatible data type.

Stitch requires MongoDB Replication Key fields to be one of the following data types:

• DATETIME

• FLOAT

• INT64

• INTEGER

• OBJECTID

• TIMESTAMP

• UUID

• Select a different Replication Key for the collection, or
• Convert the data to a supported Replication Key data type, if possible

MySQL v1-backed database integrations

The server ID of the instance Stitch is connected to is not unique.

When using Log-based Replication, the ID of the server Stitch connects to must be unique. This is because MySQL doesn’t allow replication to occur using the same server ID simultaneously across multiple connections.

If you’re using Log-based Replication and any of the following are true, you’ll need to define a unique server ID in the integration’s Settings page in Stitch:

1. You connected one or more read replicas
2. You connected multiple databases that are all on the same server
3. You added a new MySQL-based Stitch integration, and the database is on the same server as other previously-connected databases

To do this, refer to the instructions for the database you’re connecting:

• MySQL
• Amazon Aurora RDS
• Amazon MySQL RDS
• Google CloudSQL MySQL
• MariaDB

MySQL v1-backed database integrations

The binlog_format server parameter is not set to ROW, which Stitch requires for MySQL Log-based Replication.

Change the binlog_format parameter to ROW. This ensures that binary replication is “row-based”, meaning that events affecting individual rows are captured.

The steps for changing this parameter will vary depending on the type of MySQL database you’re using. Click the links below to view instructions for that database.

• MySQL
• Amazon Aurora RDS
• Amazon MySQL RDS
• Google CloudSQL MySQL
• MariaDB

MySQL v1-backed database integrations

The binlog_row_image parameter is not set to FULL, which Stitch requires for MySQL Log-based Replication.

Changing the binlog_row_image parameter to FULL. This ensures that when a row is updated in the source database, the entire row is captured versus only the updated values.

The steps for changing this parameter will vary depending on the type of MySQL database you’re using. Click the links below to view instructions for that database.

• MySQL
• Amazon Aurora RDS
• Amazon MySQL RDS
• Google CloudSQL MySQL
• MariaDB

MySQL v1-backed database integrations

The binlog_row_image parameter doesn’t exist in the version that the source MySQL database is running.

The version of the MySQL database is less than 5.6.2, which is the minimum version that supports binlog replication. Versions prior to 5.6.2 don’t support the binlog replication feature, which is required to use Log-based Incremental Replication in Stitch.

The source MySQL database must be running MySQL version 5.6.2 or greater to use binlog replication. If you can upgrade your database version, you may be able to use binlog replication.

MySQL v1-backed database integrations

The data replicated for a table does not match the expected schema. This occurs when the structure of a table changes in the source and Stitch is unable to verify its schema.

This occurs due to how Log-based Incremental Replication works, and how log messages are structured in database binary files. Refer to the Log-based Incremental Replication documentation for more info and examples.

This can occur when:

• The table’s schema is altered by removing a column, adding a new column to the middle of the table, or changing the order of columns
• The data type of a column is changed
• The Stitch database user doesn’t have access to all the columns in the table

To resolve the error, you’ll need to perform a table-level reset. To do this, open the Table Settings page for the table and click the Reset Table button. This will clear the table’s Replication Key value and queue a full re-replication of the table.

To prevent this error in the future:

• When adding or removing columns, or changing data types, perform the table-level reset in Stitch immediately after the modification

• Ensure the Stitch user has access to all the columns in the table. Although Stitch will be limited to the columns you specify while using SELECT during the initial replication job, values for restricted columns will still appear in binary log files.

  Because these values are in the binary log files but not in the initial SELECT replication, Stitch will interpret this as columns being reordered. Ensuring that the Stitch database user has access to all columns at the start can avoid this error.

MySQL v1-backed database integrations

The source object is a database view. Binary logging doesn’t track events that occur in database views, so Stitch is unable to use Log-based Replication for views.

Update the view’s Replication Method to either Key-based Incremental or Full Table.

MySQL v1-backed database integrations

The server ID for the MySQL server hasn’t been set.

The likely cause of this error is setting server parameters on the master server without rebooting the master, which is required for server parameter changes to take effect.

Reboot the master instance to ensure the server parameters for enabling binlog are applied.

MySQL v1-backed database integrations

Binary logging isn’t enabled for the MySQL server.

Enable binary logging on your MySQL server. This is done by defining the log_bin parameter.

The steps for enabling binary logging will vary depending on the type of MySQL database you’re using. Click the links below to view instructions for that database.

• MySQL
• Google CloudSQL MySQL
• MariaDB

Note: Amazon MySQL RDS and Amazon Aurora RDS databases should have binary logging enabled by default. If you receive this error for either of these databases, verify that the rest of the required server settings are defined correctly.

MySQL v1-backed database integrations

The table is empty. For Log-based Incremental Replication there must be Primary Keys in the table, as it’s the only way to identify unique records. If the table is empty, there are no Primary Key values, resulting in this error. Note: Remaining tables will not be replicated if this error occurs, even if they contain valid data.

Use Key-based Incremental Replication to continue replication, or add Primary Keys to the table so that Log-based Incremental Replication can be used.

MySQL v1-backed database integrations

When Stitch replicates data using Log-based Replication, it will “bookmark” its place by saving a position in the log file. When the next replication job begins, Stitch will use this value to identify the place in the log where it should begin reading data.

This error means that the log position Stitch has is “ahead” of the server. To summarize, the log position Stitch is attempting to use is greater than the log position that the MySQL database has available.

Typically this will be an issue only if the server uses a very small max_binlog_size value.

Perform an integration-level reset. To do this, open the Integration Settings page and click the Reset This Integration button. This will clear the integration’s Replication Keys and queue a full re-replication of the integration.

We also recommend checking the value of the max_binlog_size server parameter and increasing it if it’s too small. By default, this is set to MySQL’s maximum of 1 GB (1073741824 bytes).

MySQL v1-backed database integrations

The requested binary log file has been removed from the server. When a binary log file is removed before Stitch can read from it, replication will be unable to proceed.

This can be caused by:

• Insufficient log retention settings, which define how long log files remain on a server before they’re automatically purged.

• Binary log files being purged before historical replication completes or critical errors that prevent Stitch from replicating data. When this occurs, it means Stitch was unable to proceed to the binary log file before the retention period passed and the log was purged.

To resolve the error, you’ll need to perform an integration-level reset. To do this, open the Integration Settings page and click the Reset This Integration button. This will clear the integration’s Replication Keys and queue a full re-replication of the integration.

To prevent this error in the future, verify your server’s log retention settings and update them if needed. Stitch recommends a minimum of 3 days, but 7 days is preferred. This ensures that you have time to resolve any issues that arise before logs age out and are purged.

The steps for changing this parameter will vary depending on the type of MySQL database you’re using. Click the links below to view instructions for that database.

• MySQL
• Amazon Aurora RDS
• Amazon MySQL RDS
• Google CloudSQL MySQL
• MariaDB

In addition, make sure you resolve any connection or replication issues quickly. This will reduce the likelihood that binary log files will age out and cause this error.

All Oracle-backed database integrations

The database is using a version that doesn’t include support for Oracle’s LogMiner package, which Stitch uses to perform Log-based Incremental Replication.

The database must be using a version from 8.0 through 18c.

To resolve this error, you have two options:

1. Modify the database to use a version that supports LogMiner
2. Use either Full Table or Key-based Incremental Replication instead

All Oracle-backed database integrations

The source object is a database view. Binary logging doesn’t track events that occur in database views, so Stitch is unable to use Log-based Replication for views.

Change the view’s Replication Method to Key-based Incremental or Full Table.

All Oracle-backed database integrations

The requested log file has been removed from the server. When a log file is removed before Stitch can read from it, replicaiton will be unable to proceed.

This error typically arises due to insufficient RMAN retention policy settings, which define how long log files remain on a server before they’re automatically purged.

It can also be caused by log files being purged before historical replication completes or critical errors that prevent Stitch from replicating data. When this occurs, it means Stitch was unable to proceed to the log file before the retention period passed and the log was purged.

To resolve the error, you’ll need to perform an integration-level reset. To do this, open the Integration Settings page and click the Reset Table button. This will clear the integration’s Replication Keys and queue a full re-replication of the integration.

To prevent this error in the future, verify your RMAN retention policy settings and update them if needed. Stitch recommends a minimum of 3 days, but 7 days is preferred. This ensures that you have time to resolve any issues that arise before logs age out and are purged. Refer to the Oracle documentation for more info.

In addition, make sure you resolve any connection or replication issues quickly. This will reduce the likelihood that log files will age out and cause this error.

All Oracle-backed database integrations

LogMiner is unable to locate the System Change Number (SCN) value Stitch has saved. SCNs are used to identify data in log files for Log-based Incremental Replication.

• No new data is logged for the length of the RMAN retention window. For example: If the RMAN retention window is set to 2 days and no new data is created for two consecutive days, this error may occur.

• The integration is paused for longer than the RMAN retention window. For example: If the RMAN retention window is set to 2 days and the integration is paused in Stitch for longer than two days, this error may occur.

1. Verify the current RMAN retention window length.
2. Increase the RMAN retention window. For example: Increase the window from 2 days to 7.
3. Perform an integration level reset. To do this, open the Integration Settings page and click the Reset This Integration button. This will clear the integration’s Replication Keys and queue a full re-replication of the integration.

All Oracle-backed database integrations

Supplemental logging is incorrectly defined either for the database or the table. Supplemental logging is required by Oracle to use LogMiner, which Stitch uses to perform Log-based Incremental Replication.

Stitch supports supplemental logging at the database and table level:

• If enabled at the database level, tables do not need to be individually configured:

   ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS
  

• If enabled at the table level, tables need to be individually configured. Run the following for every table you want to replicate through Stitch:

   ALTER TABLE <SCHEMA_NAME>.<TABLE_NAME> ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS
  

Refer to the Oracle documentation for more info.

Google CloudSQL PostgreSQL v2 database integrations

SSL configuration

The Google CloudSQL PostgreSQL instance is configured to require SSL to connect. This configuration isn’t currently supported, as it requires the database to expect client certifications.

Verify that the instance isn’t set to require SSL in Google Cloud. If it is, disable the setting and re-try the connection in Stitch.

PostgreSQL v2 database integrations

Stitch is unable to find a replication slot that adheres to Stitch’s naming requirements.

Verify that a replication slot exists for the database you’re trying to connect, and that it adheres to Stitch’s naming requirements.