You can resynchronize source and target objects for a subtask that is part of a running application ingestion and replication job of combined initial and incremental load type. The subtask must be in a state other than Queued or Starting.
For example, you might want to resynchronize the target with the source if initial load or incremental load processing failed or if you want to start the job over again from a specific restart point.
1Drill down on the application ingestion and replication job that you want to resynchronize from one of the following monitoring interfaces:
- My Jobs page that's accessed from the navigation bar of the Home page
- All Jobs page in Monitor
- All Jobs tab on the Data Ingestion and Replication page in Operational Insights
The job must be in the Up and Running state and be for a combined initial and incremental load operation.
2Click the Object Detail tab.
3In the subtask row for the source and target objects that you want to resynchronize, click the Actions menu and select Resync. The resync operation resynchronizes the target table with the latest source table definition, including any DDL changes.
Note: For the Actions menu and Resync option to be available, the subtask must be in a state other than Queued or Starting.
If you resynchronize a subtask for an application ingestion and replication combined load job that has a Salesforce source, use one of the following resync options instead of the Resync option:
- Resync (refresh). Use this option to resynchronize the target table with the latest source object definition, including any DDL change that schema drift ignored. After the target table is refreshed, the target table structure matches the current source object structure. This option mimics the behavior of the Resync option.
- Resync (retain). Use this option to resynchronize the same fields that have been processed for CDC, retaining the current structure of the source and target tables. No checks for changes in the source or target table definitions are performed. If source DDL changes affected the source object structure, those changes are not processed.
Notes:
•If the source table contains many rows, the resynchronization might take a long time to perform.
•If the source table schema does not match the target table schema, the ingestion subtask drops the target table and creates a new table that matches the source schema. Regardless of whether the target tables are re-created, the subtask truncates the target tables and then reloads source data to the tables.
•When you resync an application ingestion and replication subtask with a Snowflake target and use Audit apply mode, you can retain the audit information. Data Ingestion and Replication re-creates the target table and renames the existing table that contains the audit information using an appended timestamp in the format <target_table_name>_<current_UTC_timestamp>. If you want the audit information in the actual target table, you need to load it, for example, with a join operation. If adding the timestamp to the existing table name causes the name to exceed the maximum number of characters, the subtask fails with an error. If you enable schema drift and a schema drift change, such as Add Column, occurs, the new column will be in the re-created target table but not in the renamed table. To enable this behavior, set the backupTargetTableBeforeResync custom property to true on the Target page of the task wizard.
Consider the following limitations when you resync a combined load job that has an existing audit table:
- Storing the existing audit table on the target consumes extra database storage.
- To obtain a unified view of audit information, you need to join the multiple versions of the audit tables.