Understanding OMS Components, Migration Workflow, and Performance Optimization

The article examines the OMS (Open Migration Service) community edition 3.3.1, starting with its overall architecture diagram and the main components such as DBCat, Store, Connector, JDBCWriter, Checker, and Supervisor.

Component processes are described one by one:

1. Ghana-endpoint – provides the OMS backend UI and schedules TaskJob and StructTaskJob. Example command:

[ActionTech ~]# ps uax | grep Ghana-endpoint
root        61  3.1  0.5 20918816 1582384 pts/0 Sl  Feb07 1756:47 java -Dspring.config.location=/home/ds/ghana/config/application-oms.properties -server -Xms1g -Xmx2g -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:/home/admin/logs/ghana/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=10M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/admin/logs/ghana -jar /home/ds/ghana/boot/Ghana-endpoint-1.0.0-executable.jar

2. commons-daemon (CM) – cluster management process that creates tasks for incremental log pulling, full migration, incremental sync, and verification. Example command:

[ActionTech ~]# ps uax | grep commons-daemon
root        50  297  1.7 25997476 4711620 pts/0 Sl  Feb07 163685:09 java -cp /home/ds/cm/package/deployapp/lib/commons-daemon.jar:/home/ds/cm/package/jetty/start.jar -server -Xmx4g -Xms4g -Xmn4g -Dorg.eclipse.jetty.util.URI.charset=utf-8 -Dorg.eclipse.jetty.server.Request.maxFormContentSize=0 -Dorg.eclipse.jetty.server.Request.maxFormKeys=20000 -DSTOP.PORT=8089 -DSTOP.KEY=cm -Djetty.base=/home/ds/cm/package/deployapp org.eclipse.jetty.start.Main

3. oms-supervisor – launches and monitors the execution of migration, sync, and verification tasks. Example command:

[ActionTech ~]# ps uax | grep oms-supervisor
ds          63  1.0  0.3 11780820 985860 pts/0 Sl   Feb07 566:35 java -server -Xms1g -Xmx1g -Xmn512m -verbose:gc -Xloggc:./log/gc.log -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Dserver.port=9000 -DconfigDir=/u01/ds/supervisor/config/ -Dspring.main.allow-circular-references=true -jar ./bin/oms-supervisor.jar

4. store – pulls incremental logs from the source; the main process is ./bin/store with child processes such as /u01/ds/store/store7100/bin/metadata_builder that filter, transform, and write DDL.

5. Full migration and verification share the same start command but are distinguished by the task.type entry in the configuration file (e.g., task.type=migrate for migration, task.type=verify for verification).

6. Incremental sync – reads incremental logs and replays SQL on the target. Example command:

[ActionTech ~]# ps aux | grep "coordinator\.Bootstrap"
... java -server -XX:+DisableExplicitGC -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/u01/ds/bin/../run/10.186.17.104-4000:p_4gmn723gtt28_dest-000-0:0002000001 -Djava.library.path=/u01/ds/bin/../plugins/jdbc_connector/ -Duser.home=/home/ds -Dlogging.path=/u01/ds/bin/../run/10.186.17.104-4000:p_4gmn723gtt28_dest-000-0:0002000001/logs -cp jdbc_connector.jar:jdbc-source-store.jar:jdbc-sink-ob-mysql.jar com.oceanbase.oms.connector.jdbc.coordinator.Bootstrap -c conf -s com.oceanbase.oms.connector.jdbc.source.store.StoreSource -d com.oceanbase.oms.connector.jdbc.sink.obmysql.OBMySQLJdbcSink -t 10.186.17.104-4000:p_4gmn723gtt28_dest-000-0:0002000001 start

The article then illustrates the overall migration workflow using an incremental migration example, showing how source, dispatcher, and sink stages interact.

Monitoring – OMS uses InfluxDB to store metrics such as checker.dest.rps , checker.dest.rt , etc., and also writes detailed JSON logs to metrics.log . Key metrics for each stage are listed:

Source stage: source_record_num , source_rps , source_iops , source_dml_num , source_dml_rps , StoreSource[0]source_status , StoreSource[0]source_delay .

Dispatcher stage: dispatcher_ready_transaction_size , coordinator_dispatch_record_size .

Sink stage: sink_tps , sink_total_transaction , sink_worker_num , sink_worker_num_all , sink_rps , sink_total_record , sink_execute_time , sink_commit_time , sink_iops , sink_total_bytes .

Optimization suggestions focus on the migration chain:

Increase sink_worker_number (threads) to match the CPU core count (up to 4× cores) to relieve dispatch queue back‑pressure.

Adjust the “full migration concurrency speed” option when creating a full‑migration task; higher levels consume more resources but finish faster.

By monitoring the mentioned metrics and tuning the above parameters, operators can identify bottlenecks and improve OMS migration performance.