Troubleshooting zero-ETL integrations
Use the following information to troubleshoot common issues with zero-ETL integrations with Aurora MySQL.
Topics
- Creation of the integration failed
- Tables don't have primary keys
- Unsupported data types in tables
- Data manipulation language commands failed
- Tracked changes between data sources don't match
- Authorization failed
- Number of tables is more than 100K or the number of schemas is more than 4950
- Amazon Redshift can't load data
- Workgroup parameter settings are incorrect
- Database isn't created to activate a zero-ETL integration
- Table is in the Resync Required or Resync Initiated state
Creation of the integration failed
If the creation of the zero-ETL integration failed, the status of the integration is
Inactive. Make sure that the following are correct for your source Aurora
DB cluster:
-
You created your cluster in the Amazon RDS console.
-
Your source Aurora DB cluster is running MySQL version 3.05 or higher. To validate this, go to the Configuration tab for the cluster and check the Engine version.
-
You correctly configured binlog parameter settings for your cluster. If your Aurora MySQL binlog parameters are set incorrectly or not associated with the source Aurora DB cluster, creation fails. See Configure DB cluster parameters.
In addition, make sure the following are correct for your Amazon Redshift data warehouse:
-
Case sensitivity is turned on. See Turn on case sensitivity for your data warehouse.
-
You added the correct authorized principal and integration source for your namespace. See Configure authorization for your Amazon Redshift data warehouse.
Tables don't have primary keys
In the destination database, one or more of the tables don't have a primary key and can't be synchronized.
To resolve this issue, go to the Table statistics tab on the integration details page or use SVV_INTEGRATION_TABLE_STATE to view the failed tables. You can add primary keys to the tables and Amazon Redshift will resynchronize the tables. Alternatively, although not recommended, you can drop these tables on Aurora and create tables with a primary key. For more information, see Amazon Redshift best practices for designing tables.
Unsupported data types in tables
In the database that you created from the integration in Amazon Redshift and in which data is replicated from the Aurora DB cluster, one or more of the tables have unsupported data types and can't be synchronized.
To resolve this issue, go to the Table statistics tab on the integration details page or use SVV_INTEGRATION_TABLE_STATE to view the failed tables. Then, remove these tables and recreate new tables on Amazon RDS. For more information on unsupported data types, see Data type differences between Aurora and Amazon Redshift databases in the Amazon Aurora User Guide.
Data manipulation language commands failed
Amazon Redshift could not run DML commands on the Redshift tables. To resolve this issue, use SVV_INTEGRATION_TABLE_STATE to view the failed tables. Amazon Redshift automatically resynchronizes the tables to resolve this error.
Tracked changes between data sources don't match
This error occurs when changes between Amazon Aurora and Amazon Redshift don't match,
leading to the integration entering a Failed state.
To resolve this, delete the zero-ETL integration and create it again in Amazon RDS. For more information, see Creating zero-ETL integrations and Deleting zero-ETL integrations.
Authorization failed
Authorization failed because the source Aurora DB cluster was removed as an authorized integration source for the Amazon Redshift data warehouse.
To resolve this issue, delete the zero-ETL integration and create it again on Amazon RDS. For more information, see Creating zero-ETL integrations and Deleting zero-ETL integrations.
Number of tables is more than 100K or the number of schemas is more than 4950
For a destination data warehouse, the number of tables is more than 100K or the number of schemas is more than 4950. Amazon Aurora can't send data to Amazon Redshift. The number of tables and schemas exceeds the set limit. To resolve this issue, remove any unnecessary schemas or tables from the source database.
Amazon Redshift can't load data
Amazon Redshift can't load data to the zero-ETL integration.
To resolve this issue, delete the zero-ETL integration on Amazon RDS and create it again. For more information, see Creating zero-ETL integrations and Deleting zero-ETL integrations.
Workgroup parameter settings are incorrect
Your workgroup doesn't have case sensitivity turned on.
To resolve this issue, go to the Properties tab on the integration details page, choose the parameter group, and turn on the case-sensitive identifier from the Properties tab. If you don't have an existing parameter group, create one with the case-sensitive identifier turned on. Then, create a new zero-ETL integration on Amazon RDS. For more information, see Creating zero-ETL integrations.
Database isn't created to activate a zero-ETL integration
There isn't a database created for the zero-ETL integration to activate it.
To resolve this issue, create a database for the integration. For more information, see Creating a destination database in Amazon Redshift.
Table is in the Resync Required or Resync Initiated state
Your table is in the Resync Required or Resync Initiated state.
To gather more detailed error information about why your table is in that state, use the SYS_LOAD_ERROR_DETAIL system view.
Use the following information to troubleshoot common issues with zero-ETL integrations with Aurora PostgreSQL.
Topics
- Creation of the integration failed
- Tables don't have primary keys
- Unsupported data types in tables
- Data manipulation language commands failed
- Tracked changes between data sources don't match
- Authorization failed
- Number of tables is more than 100K or the number of schemas is more than 4950
- Amazon Redshift can't load data
- Workgroup parameter settings are incorrect
- Database isn't created to activate a zero-ETL integration
- Table is in the Resync Required or Resync Initiated state
Creation of the integration failed
If the creation of the zero-ETL integration failed, the status of the integration is
Inactive. Make sure that the following are correct for your source Aurora
DB cluster:
-
You created your cluster in the Amazon RDS console.
-
Your source Aurora DB cluster is running Aurora PostgreSQL version 15.4.99 or higher. To validate this, go to the Configuration tab for the cluster and check the Engine version.
-
You correctly configured binlog parameter settings for your cluster. If your Aurora PostgreSQL binlog parameters are set incorrectly or not associated with the source Aurora DB cluster, creation fails. See Configure DB cluster parameters.
In addition, make sure the following are correct for your Amazon Redshift data warehouse:
-
Case sensitivity is turned on. See Turn on case sensitivity for your data warehouse.
-
You added the correct authorized principal and integration source for your endterm="zero-etl-using.redshift-iam.title"/>.
Tables don't have primary keys
In the destination database, one or more of the tables don't have a primary key and can't be synchronized.
To resolve this issue, go to the Table statistics tab on the integration details page or use SVV_INTEGRATION_TABLE_STATE to view the failed tables. You can add primary keys to the tables and Amazon Redshift will resynchronize the tables. Alternatively, although not recommended, you can drop these tables on Aurora and create tables with a primary key. For more information, see Amazon Redshift best practices for designing tables.
Unsupported data types in tables
In the database that you created from the integration in Amazon Redshift and in which data is replicated from the Aurora DB cluster, one or more of the tables have unsupported data types and can't be synchronized.
To resolve this issue, go to the Table statistics tab on the integration details page or use SVV_INTEGRATION_TABLE_STATE to view the failed tables. Then, remove these tables and recreate new tables on Amazon RDS. For more information on unsupported data types, see Data type differences between Aurora and Amazon Redshift databases in the Amazon Aurora User Guide.
Data manipulation language commands failed
Amazon Redshift could not run DML commands on the Redshift tables. To resolve this issue, use SVV_INTEGRATION_TABLE_STATE to view the failed tables. Amazon Redshift automatically resynchronizes the tables to resolve this error.
Tracked changes between data sources don't match
This error occurs when changes between Amazon Aurora and Amazon Redshift don't match,
leading to the integration entering a Failed state.
To resolve this, delete the zero-ETL integration and create it again in Amazon RDS. For more information, see Creating zero-ETL integrations and Deleting zero-ETL integrations.
Authorization failed
Authorization failed because the source Aurora DB cluster was removed as an authorized integration source for the Amazon Redshift data warehouse.
To resolve this issue, delete the zero-ETL integration and create it again on Amazon RDS. For more information, see Creating zero-ETL integrations and Deleting zero-ETL integrations.
Number of tables is more than 100K or the number of schemas is more than 4950
For a destination data warehouse, the number of tables is more than 100K or the number of schemas is more than 4950. Amazon Aurora can't send data to Amazon Redshift. The number of tables and schemas exceeds the set limit. To resolve this issue, remove any unnecessary schemas or tables from the source database.
Amazon Redshift can't load data
Amazon Redshift can't load data to the zero-ETL integration.
To resolve this issue, delete the zero-ETL integration on Amazon RDS and create it again. For more information, see Creating zero-ETL integrations and Deleting zero-ETL integrations.
Workgroup parameter settings are incorrect
Your workgroup doesn't have case sensitivity turned on.
To resolve this issue, go to the Properties tab on the integration details page, choose the parameter group, and turn on the case-sensitive identifier from the Properties tab. If you don't have an existing parameter group, create one with the case-sensitive identifier turned on. Then, create a new zero-ETL integration on Amazon RDS. For more information, see Creating zero-ETL integrations.
Database isn't created to activate a zero-ETL integration
There isn't a database created for the zero-ETL integration to activate it.
To resolve this issue, create a database for the integration. For more information, see Creating a destination database in Amazon Redshift.
Table is in the Resync Required or Resync Initiated state
Your table is in the Resync Required or Resync Initiated state.
To gather more detailed error information about why your table is in that state, use the SYS_LOAD_ERROR_DETAIL system view.
Use the following information to troubleshoot common issues with zero-ETL integrations with RDS for MySQL.
Topics
- Creation of the integration failed
- Tables don't have primary keys
- Unsupported data types in tables
- Data manipulation language commands failed
- Tracked changes between data sources don't match
- Authorization failed
- Number of tables is more than 100K or the number of schemas is more than 4950
- Amazon Redshift can't load data
- Workgroup parameter settings are incorrect
- Database isn't created to activate a zero-ETL integration
- Table is in the Resync Required or Resync Initiated state
Creation of the integration failed
If the creation of the zero-ETL integration failed, the status of the integration is
Inactive. Make sure that the following are correct for your source RDS DB
instance:
-
You created your instance in the Amazon RDS console.
-
Your source RDS DB instance is running RDS for MySQL version 8.0.32 or higher. To validate this, go to the Configuration tab for the instance and check the Engine version.
-
You correctly configured binlog parameter settings for your instance. If your RDS for MySQL binlog parameters are set incorrectly or not associated with the source RDS DB instance, creation fails. See Configure DB instance parameters.
In addition, make sure the following are correct for your Amazon Redshift data warehouse:
-
Case sensitivity is turned on. See Turn on case sensitivity for your data warehouse.
-
You added the correct authorized principal and integration source for your namespace. See Configure authorization for your Amazon Redshift data warehouse.
Tables don't have primary keys
In the destination database, one or more of the tables don't have a primary key and can't be synchronized.
To resolve this issue, go to the Table statistics tab on the integration details page or use SVV_INTEGRATION_TABLE_STATE to view the failed tables. You can add primary keys to the tables and Amazon Redshift will resynchronize the tables. Alternatively, although not recommended, you can drop these tables on RDS and create tables with a primary key. For more information, see Amazon Redshift best practices for designing tables.
Unsupported data types in tables
In the database that you created from the integration in Amazon Redshift and in which data is replicated from the RDS DB instance, one or more of the tables have unsupported data types and can't be synchronized.
To resolve this issue, go to the Table statistics tab on the integration details page or use SVV_INTEGRATION_TABLE_STATE to view the failed tables. Then, remove these tables and recreate new tables on Amazon RDS. For more information on unsupported data types, see Data type differences between RDS and Amazon Redshift databases in the Amazon RDS User Guide.
Data manipulation language commands failed
Amazon Redshift could not run DML commands on the Redshift tables. To resolve this issue, use SVV_INTEGRATION_TABLE_STATE to view the failed tables. Amazon Redshift automatically resynchronizes the tables to resolve this error.
Tracked changes between data sources don't match
This error occurs when changes between Amazon Aurora and Amazon Redshift don't match,
leading to the integration entering a Failed state.
To resolve this, delete the zero-ETL integration and create it again in Amazon RDS. For more information, see Creating zero-ETL integrations and Deleting zero-ETL integrations.
Authorization failed
Authorization failed because the source RDS DB instance was removed as an authorized integration source for the Amazon Redshift data warehouse.
To resolve this issue, delete the zero-ETL integration and create it again on Amazon RDS. For more information, see Creating zero-ETL integrations and Deleting zero-ETL integrations.
Number of tables is more than 100K or the number of schemas is more than 4950
For a destination data warehouse, the number of tables is more than 100K or the number of schemas is more than 4950. Amazon Aurora can't send data to Amazon Redshift. The number of tables and schemas exceeds the set limit. To resolve this issue, remove any unnecessary schemas or tables from the source database.
Amazon Redshift can't load data
Amazon Redshift can't load data to the zero-ETL integration.
To resolve this issue, delete the zero-ETL integration on Amazon RDS and create it again. For more information, see Creating zero-ETL integrations and Deleting zero-ETL integrations.
Workgroup parameter settings are incorrect
Your workgroup doesn't have case sensitivity turned on.
To resolve this issue, go to the Properties tab on the integration details page, choose the parameter group, and turn on the case-sensitive identifier from the Properties tab. If you don't have an existing parameter group, create one with the case-sensitive identifier turned on. Then, create a new zero-ETL integration on Amazon RDS. For more information, see Creating zero-ETL integrations.
Database isn't created to activate a zero-ETL integration
There isn't a database created for the zero-ETL integration to activate it.
To resolve this issue, create a database for the integration. For more information, see Creating a destination database in Amazon Redshift.
Table is in the Resync Required or Resync Initiated state
Your table is in the Resync Required or Resync Initiated state.
To gather more detailed error information about why your table is in that state, use the SYS_LOAD_ERROR_DETAIL system view.