Documentation Index
Fetch the complete documentation index at: https://docs.wirekite.io/llms.txt
Use this file to discover all available pages before exploring further.
Orchestrator
Wirekite has a main binary called the orchestrator. The actual binary is called wirekite. This is a top level binary which calls all the other binaries to execute the task of data movement. Note that other binaries can be called independently also for testing purposes.Orchestrator Configuration File
Orchestrator takes a configuration file to understand what needs to be done. The configuration file has the following rules.- The configuration variables can be represented using the format
variable=value. - Empty lines are allowed.
- Comments are allowed. To comment just start the line with #.
- Multilevel variables are allowed using the format
parent.child=value.
Variables
The configuration file has the following main variables and allowed values.home is the Wirekite installation directory.
source is the database type from which we are extracting. The possible values are
- mysql
- oracle
- postgres
- sqlserver
- spanner (CDC only)
target is the database type to which we are loading. The possible values are
- snowflake
- firebolt
- databricks
- bigquery
- spanner
- singlestore
- mysql
- postgres
- oracle
- sqlserver
- mongodb
log is the path to the orchestrator log file.
When set to
true, the orchestrator preserves the existing position.pkt file and resumes from the last saved position. When false (or absent), the orchestrator truncates the position file before starting. The Web Interface sets this automatically when resuming a migration.Modes
The mode of operation is declared explicitly using themode variable in the configuration file.
The operation mode. Must be one of the values listed below.
Schema Modes
| Mode | Description |
|---|---|
schema-extract | Extract the schema from the source database. Produces a .skt schema file and optionally an .okt objects file. |
schema-apply-tables | Apply CREATE TABLE statements to the target database using the generated SQL file. |
schema-apply-objects | Apply non-table objects (indexes, constraints, foreign keys) to the target database. Errors on individual statements are logged but do not stop execution. |
Data and Change Modes
| Mode | Description |
|---|---|
data | One-time bulk data extraction and loading. The orchestrator runs the extractor, mover, and loader in parallel. |
change | Continuous CDC replication. Extracts ongoing changes (inserts, updates, deletes) from the source and applies them to the target. |
data+change | Combined data migration followed by CDC replication. The orchestrator first completes the bulk data load, captures the source position automatically, and then starts continuous change replication from that position. Do not specify a starting position for the change source — the orchestrator captures this during the data phase. |
wirekite_progress for tracking migration state and crash recovery, and wirekite_action for pause/stop/resume control. See Operations for details on monitoring and controlling running migrations.
Reset Modes
| Mode | Description |
|---|---|
reset-drop | Drop tables from the target database using the specified drop file. |
reset-trunc | Truncate tables on the target database. |
reset-metadata | Reset Wirekite’s internal metadata (progress and action tables) without modifying target data. |
Validation Mode
| Mode | Description |
|---|---|
validate | Compare data between source and target databases to verify migration accuracy. See Data Validation for details. |
Source and Target Child Variables
Bothsource and target variables have child variables that include the mode as part of the hierarchy. The format is source.<mode>.<variable>=value and target.<mode>.<variable>=value.
For example, source.data.dsnFile is the connection string file for the data extractor and target.schema.schemaFile is the input schema file for the schema loader.
The specific variables available depend on the source and target database types. For example if the source is mysql then the child variables can be any of the variables listed in mysql variables. If the target is snowflake then the child variables can be any of the variables listed in snowflake variables.
Mover Variables
The mover is an optional component that transfers files between the source and target. It is configured separately using themover.<variable>=value format. The mover does not have a mode prefix since the same mover handles both data and change files.
Bringing It All Together
Below are example orchestrator configuration files for each mode.Schema Mode Example
Schema mode extracts the database schema from the source and generates SQL files for the target. Schema extraction and application are separate modes.mode=schema-apply-tables with the generated SQL file. Then use mode=schema-apply-objects to apply indexes, constraints, and foreign keys.
Data Mode Example
Data mode performs a one-time bulk data transfer from source to target.Change Mode Example
Change mode captures ongoing changes (CDC) and applies them to the target. When running change mode independently you must specify the starting position for your source database type.Data + Change Mode Example
Data and change modes can be combined usingmode=data+change. The orchestrator will first complete the bulk data load, capture the source position automatically, and then start continuous change replication. Do not specify a starting position for the change source — the orchestrator captures this automatically during the data phase.
