# Operations **Operations** allows to manage and troubleshoot the data pipeline, control the synchronization process, and handle the schema changes. To manage the data ingestion pipeline, navigate to the **Operations** tab. Select the following according to your requirements. 1. **On/Off toggle:** Turns the scheduler on or off. When the scheduler is disabled, Ingest stops looking for changes in the source database. If the scheduler state changes either manually or automatically (e.g., after a service restart or user change to the toggle), a message appears next to the it explaining the reason for the state change (e.g., "Manual on", "Restore on startup"). Same as the On/Off toggle in the **Schedule** section of the dashboard. 2. **Full Extract**: Triggers the initial bulk load for all the selected tables, except those marked as **Skip Initial Extract**. Every Ingest pipeline must undergo a full extract at least once to begin with. 3. **Sync New Tables**: Triggers the initial bulk load for tables marked as **Redo Initial Extract** and newly added tables in an ongoing replication. This operation cannot replace a full extract. 4. **Sync Struct**: Compares and synchronizes the table structure in the destination database. Flow does not automatically apply schema changes, Sync Struct must be triggered manually to align the destination schema with the source. After the sync completes, Flow automatically rolls back to the last successful load and resumes the scheduler. In case of persistent load failures, errors are recorded in the logs for the affected tables, and the user must rollback to a point before the failure. Refer to [Schema Evolution with Sync Struct](https://docs.singlestore.com/db/v9.1/load-data/load-data-with-singlestore-flow-on-helios/singlestore-ingest/operations/#section-idm443519626583236.md) for more information. **Note: ** * Sync Struct does not reload all data from the source, only updates the table structure. * For planned upgrades, refer to [Planned Schema Upgrade with Sync Struct](https://docs.singlestore.com/db/v9.1/load-data/load-data-with-singlestore-flow-on-helios/singlestore-ingest/operations/#section-idm4417598132916182.md). * If a load has failed due to a schema change, refer to [Handling Load Failures Due to Schema Changes.](https://docs.singlestore.com/db/v9.1/load-data/load-data-with-singlestore-flow-on-helios/singlestore-ingest/operations/#section-idm44209417781702663.md) 5. **Rollback**: Replay logs from a specific point to reapply changes to the destination. If the primary key columns are correctly selected, there should be no duplicates in the destination table. Rollback affects all tables in the selected list. 6. **Manual Delta** : Triggers a manual delta extract to process incremental changes. ## Rollback In the event of unexpected issues, such as intermittent source database outages or network connectivity problems, you can rollback Ingest to a point in time before the issue occurred and replay the changes. To perform the rollback: 1. Navigate to the **Schedule** tab. 2. Select **Rollback**. 3. The rollback screen appears, displaying a list of available rollback points in descending order, depending on the source database log retention policy. 4. Select the desired date (radio button) and **Select**. 5. Select **Rollback** to initiate the rollback. 6. Ingest automatically catches up from the selected point in time to the current time that replays all log entries and applies them to the destination. ## Schema Evolution with Sync Struct Schema evolution is handled manually through Flow. When the source schema changes, the scheduler is automatically turned off with an error message indicating a schema change. To proceed, the user must invoke the **Sync Struct** operation, which compares and updates the table structure in the destination database by aligning the destination schema with the source, without losing data. **Note**: Basic changes such as adding or removing a column are supported. Renaming a column is not supported. Significant changes (for example, altering a column type or size) may also not be supported. For unsupported changes, the user may need to drop the destination table and reload all data using a **Full Extract** operation before resuming replication. When **Sync Struct** is triggered, Flow performs the following steps: 1. Creates a backup of the existing table (`tablename_bak`). 2. Creates a new table with the updated schema from the source. 3. Copies compatible data from the backup table to the new table (matched by column name). * New columns contain `NULL` values for existing rows. * Removed columns and their data are lost. * If column order changes, the table is recreated and data is preserved correctly as columns are matched by name, not position. 4. Drops the backup table after the data is copied (if an error occurs during migration, the backup is preserved). ## Planned Schema Upgrade with Sync Struct (Recommended) To minimize risk of data loss during schema upgrades, use Sync Struct in a controlled manner. Plan the change when application updates are paused. Follow these steps: 1. Pause updates from your application running on the source database.  2. Turn off the scheduler to prevent load failures while the schema is being modified. 3. Apply the necessary schema changes to the source database. 4. After the changes are complete, go to the **Operations** tab and select **Sync Struct**. 5. This synchronizes schema changes to the destination. 6. Wait for the Sync Struct process to complete successfully, which is indicated by the log message: ``` Delta key for rolled back from . ``` Flow automatically rolls back to the last successful load file number and ensures that all changes are applied correctly, no manual rollback is required. Sync Struct resumes the scheduler when it completes. 7. Optionally, validate that the source and destination schema are in sync by running a `SELECT COUNT (*)` query in both databases, before and after the sync. 8. Resume CDC from your source database. ## Example: Adding a column to a MySQL Table Consider a table named employees being replicated to the destination. 1. Turn off the scheduler. 2. Alter the table on the source: ```sql ALTER TABLE employees ADD COLUMN salary DECIMAL(10,2); ``` 3. On the **Operations** tab, select **Sync Struct**. (This automatically turns the scheduler back on.) ## Destination Schema Comparison The following queries show the destination schema before and after the sync for comparison. **Before Sync Struct** ```sql SHOW CREATE TABLE employees; ``` ```output +---------------------------------+-------+--------+-------------+-----------------+ |CREATE TABLE `employees` ( | | `employeeNumber` int(11) NOT NULL DEFAULT '0', | | `lastName` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL, | | `firstName` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL, | | `extension_` varchar(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL,| | `email` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL, | | `officeCode` varchar(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL, | | `reportsTo` int(11) DEFAULT NULL, | | `jobTitle` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL, | | PRIMARY KEY (`employeeNumber`), | | SHARD KEY `__SHARDKEY` (`employeeNumber`), | | SORT KEY `__UNORDERED` () | | ) | +---------------------------------+-------+--------+-------------+-----------------+ ``` **After Sync Struct** The newly added column salary is present in the following output: ```sql SHOW CREATE TABLE employees; ``` ```output +---------------------------------+-------+--------+-------------+-----------------+ |CREATE TABLE `employees` ( | | `employeeNumber` int(11) NOT NULL DEFAULT '0', | | `lastName` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL, | | `firstName` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL, | | `extension_` varchar(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL,| | `email` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL, | | `officeCode` varchar(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL,| | `reportsTo` int(11) DEFAULT NULL, | | `jobTitle` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL, | | `salary` decimal(10,2) DEFAULT NULL, | | PRIMARY KEY (`employeeNumber`), | | SHARD KEY `__SHARDKEY` (`employeeNumber`), | | SORT KEY `__UNORDERED` () | ) | +---------------------------------+-------+--------+-------------+-----------------+ ``` ## Handling Load Failures Due to Schema Changes If the source schema is changed while CDC is ongoing, the load may fail due to the schema mismatch. Flow retries the load a few times, but if the issue persists, the scheduler is automatically turned off to prevent further failures. If you encounter errors, follow these steps: 1. If the scheduler is not turned off, turn it off and wait for the load to complete. 2. On the **Operations** tab, select **Sync Struct** and wait for the process to complete successfully. Sync Struct automatically rolls back the CDC by one extract file (current - 1). 3. If errors persist, manually roll back CDC two or three files before the failed extract file: 1. Identify the failed extract file number by navigating to the `log` folder in your Ingest installation directory and opening `sirus-YYYY-MM.log`. 2. On the **Operations** tab, select **Rollback**, then select the file number to rollback to (usually `n - 2` or `n - 3` where `n` is the failed extract file). 3. Start the rollback. 4. If a significant amount of time has passed or the log file is unavailable, trigger a **Redo Initial Extract** to sync the table. *** Modified at: February 12, 2026 Source: [/db/v9.1/load-data/load-data-with-singlestore-flow-on-helios/singlestore-ingest/operations/](https://docs.singlestore.com/db/v9.1/load-data/load-data-with-singlestore-flow-on-helios/singlestore-ingest/operations/) (An index of the documentation is available at /llms.txt)