When Stitch replicates data from a database integration, it will check for the required user permissions and database server settings. If permissions or server settings aren’t properly defined, you may receive an error during the Extraction phase of the replication process.

These errors will surface in the integration’s Extraction Logs.

In this reference:


Common extraction errors

The following errors are applicable to all database integrations that support Extraction Logs:

Maximum discoverable table limit exceeded

Stitch has discovered more than the maximum supported limit of 10,000 tables in your integration.
Applicable to

All integrations

Level Critical
Category

Discovery job limits

Potential cause(s)

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

Suggested action(s)

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.

Back to Common error list
Back to top

Extraction job time limit exceeded

The process was terminated.  Most often this occurs because the job has exceeded its allotted runtime. The next job will run based on the integration's schedule.
Applicable to

All integrations

Level Info
Category

Extraction job limits

Potential cause(s)

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.

Suggested action(s)

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.

Back to Common error list
Back to top


Microsoft SQL Server extraction errors

Change tracking isn't enabled for a database

Cannot sync stream: [TABLE_NAME] using log-based replication. Change Tracking is not enabled for database: [DATABASE_NAME]
Applicable to

Microsoft SQL Server v1-backed database integrations

Level Critical
Category

Log-based Incremental Replication

Potential cause(s)

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.

Suggested action(s)

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)

Back to Microsoft SQL Server error list
Back to top

Change tracking isn't enabled for a table

Cannot sync stream: [TABLE_NAME] using log-based replication. Change Tracking is not enabled for table: [TABLE_NAME]
Applicable to

Microsoft SQL Server v1-backed database integrations

Level Critical
Category

Log-based Incremental Replication

Potential cause(s)

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

Suggested action(s)

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.

Back to Microsoft SQL Server error list
Back to top


MongoDB extraction errors

Insufficient privileges on local database

not authorized on local to execute command { [COMMAND] }
Applicable to

MongoDB v1+-backed database integrations

Level Critical
Category

Database user privileges

Potential cause(s)

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

Suggested action(s)

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

Back to MongoDB error list
Back to top

Projection query excludes the collection's _id field

Projection blacklists key property id
Applicable to

MongoDB v1+-backed database integrations

Level Critical
Category

Projection queries

Potential cause(s)

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

For example:

{ "_id": 0 }
Suggested action(s)

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.

Back to MongoDB error list
Back to top

Projection query contains inclusion and exclusion statements

Projection cannot have a mix of inclusion and exclusion.
Applicable to

MongoDB v1+-backed database integrations

Level Critical
Category

Projection queries

Potential cause(s)

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 }
Suggested action(s)

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.

Back to MongoDB error list
Back to top

Projection query contains invalid JSON

The projection: [PROJECTION_QUERY] for stream [COLLECTION_NAME] is not valid json
Applicable to

MongoDB v1+-backed database integrations

Level Critical
Category

Projection queries

Potential cause(s)

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
Suggested action(s)

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.

Back to MongoDB error list
Back to top

Incompatible data type for Replication Key

[DATA_TYPE] is not a supported replication key type
Applicable to

MongoDB v1+-backed database integrations

Level Critical
Category

Replication Keys

Potential cause(s)

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

Suggested action(s)
  • Select a different Replication Key for the collection, or
  • Convert the data to a supported Replication Key data type, if possible

Back to MongoDB error list
Back to top


MySQL extraction errors

MySQL server ID isn't unique

A slave with the same server_uuid/server_id as this slave has connected to the master
Applicable to

MySQL v1-backed database integrations

Level Critical
Category

Log-based Incremental Replication

Potential cause(s)

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.

Suggested action(s)

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:

Back to MySQL error list
Back to top

Unsupported value for binlog_format server parameter

binlog_format is not set to 'ROW': [MIXED or STATEMENT].
Applicable to

MySQL v1-backed database integrations

Level Critical
Category

Log-based Incremental Replication

Potential cause(s)

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

Suggested action(s)

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.

Back to MySQL error list
Back to top

Unsupported value for binlog_row_image server parameter

binlog_row_image is not set to 'FULL': [MINIMAL or NOBLOB].
Applicable to

MySQL v1-backed database integrations

Level Critical
Category

Log-based Incremental Replication

Potential cause(s)

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

Suggested action(s)

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.

Back to MySQL error list
Back to top

MySQL version is insufficient for Log-based Incremental Replication

binlog_row_image system variable does not exist. MySQL version must be at least 5.6.2 to use binlog replication.
Applicable to

MySQL v1-backed database integrations

Level Critical
Category

Log-based Incremental Replication

Potential cause(s)

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.

Suggested action(s)

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.

Back to MySQL error list
Back to top

Schema violation

Error persisting data for table "[table_name]": Record 0 did not conform to schema
Applicable to

MySQL v1-backed database integrations

Level Critical
Category

Log-based Incremental Replication

Potential cause(s)

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
Suggested action(s)

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.

Back to MySQL error list
Back to top

A view is using an unsupported Replication Method

It is a view.
Applicable to

MySQL v1-backed database integrations

Level Critical
Category

Log-based Incremental Replication

Potential cause(s)

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.

Suggested action(s)

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

Back to MySQL error list
Back to top

MySQL server ID not set

Misconfigured master - server id was not set
Applicable to

MySQL v1-backed database integrations

Level Critical
Category

Log-based Incremental Replication

Potential cause(s)

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.

Suggested action(s)

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

Back to MySQL error list
Back to top

Binary logging isn't enabled

MySQL binary logging is not enabled.
Applicable to

MySQL v1-backed database integrations

Level Critical
Category

Log-based Incremental Replication

Potential cause(s)

Binary logging isn’t enabled for the MySQL server.

Suggested action(s)

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.

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.

Back to MySQL error list
Back to top

Unavailable log file position

Requested position ([log_file_position_from_state]) for log file [binary_log_file_name] is greater than current position ([current_log_file_position_on_server]).
Applicable to

MySQL v1-backed database integrations

Level Critical
Category

Log-based Incremental Replication

Potential cause(s)

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.

Suggested action(s)

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).

Back to MySQL error list
Back to top

Insufficient log retention settings

Unable to replicate binlog stream because the following binary log(s) no longer exist: [binary_log_file_name]
Applicable to

MySQL v1-backed database integrations

Level Critical
Category

Log-based Incremental Replication

Potential cause(s)

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.

Suggested action(s)

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.

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.

Back to MySQL error list
Back to top


Oracle extraction errors

A database view is using Log-based Incremental Replication

LogMiner is NOT supported for views. Please change the replication method for [table_name]
Applicable to

All Oracle-backed database integrations

Level Critical
Category

Log-based Incremental Replication

Potential cause(s)

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.

Suggested action(s)

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

Back to Oracle error list
Back to top

Missing log files and insufficient RMAN retention policy settings

ORA-01291: missing logfile
Applicable to

All Oracle-backed database integrations

Level Critical
Category

Log-based Incremental Replication

Potential cause(s)

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.

Suggested action(s)

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.

Back to Oracle error list
Back to top

Unavailable SCNs and RMAN retention window settings

ORA-01292: no log file has been specified for the current LogMiner session
Applicable to

All Oracle-backed database integrations

Level Critical
Category

Log-based Incremental Replication

Potential cause(s)

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.

Suggested action(s)
  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.

Back to Oracle error list
Back to top

Supplemental logging is incorrectly defined

Unable to replicate with logminer for stream([table_name]) because supplmental_log_data is not set to 'ALL' for either the table or the database.
Please run: ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
Applicable to

All Oracle-backed database integrations

Level Critical
Category

Log-based Incremental Replication

Potential cause(s)

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.

Suggested action(s)

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.

Back to Oracle error list
Back to top


Questions? Feedback?

Did this article help? If you have questions or feedback, feel free to submit a pull request with your suggestions, open an issue on GitHub, or reach out to us.