Important

The SingleStore 9.0 release candidate (RC) gives you the opportunity to preview, evaluate, and provide feedback on new and upcoming features prior to their general availability. In the interim, SingleStore 8.9 is recommended for production workloads, which can later be upgraded to SingleStore 9.0.

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: Trigger 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: Trigger 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: Compare and fix the table structure in the destination database. Load fails if the schema changes. The operator identifies when the load started failing and rolls back to a point just before the initial failure. During this operation, Ingest compares and updates the structure of the destination table without losing data.

  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.

Sync Struct

Sync Struct compares and updates the table structure in the destination database. When schema changes are made to the source database, the replication may fail due to mismatches between the source and destination. Sync Struct resolves this by aligning the destination schema with the source, without losing data. 

Note: Basic changes, such as adding a column, are generally handled successfully. However, significant changes (for example, altering a column type or size) may not be supported. In such cases, you may need to drop the destination table and reload all data using a Full Extract operation before resuming replication.

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 <X> rolled back from <Y>.

    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 updates from your application.

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:

    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

SHOW CREATE TABLE employees;
+---------------------------------+-------+--------+-------------+-----------------+
|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:

SHOW CREATE TABLE employees;
+---------------------------------+-------+--------+-------------+-----------------+
|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 Schema Changes during CDC

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.

Last modified: August 28, 2025

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined
  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined
  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
    cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
    --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
    --bundle undefined \
    --new-bundle-format -
    Verified OK