OceanBase Implementation and Migration Practices at vivo

Background

vivo, a technology company serving over 500 million users, faced growing data volumes and database operation challenges, including the need for sharding (分库分表) due to MySQL capacity limits and rising storage cost pressures.

Challenges

Sharding and table partitioning became costly and risky.

Continuous hardware procurement increased operational costs.

After evaluating mature MySQL‑compatible distributed databases, vivo selected OceanBase for its native distributed architecture, partition‑table support, strong data compression, and tenant‑level resource isolation.

OceanBase Technical Features

OceanBase’s native distributed architecture consists of an OBProxy layer for routing and an OBServer layer for storage and computation. It uses Zones for automatic fault‑tolerance and supports transparent horizontal scaling. Partition tables (分区表) distribute data evenly across OBServers, with each partition stored in a Tablet that has multiple replicas synchronized via Log Streams. Tenants provide isolated database instances, reducing deployment and operational costs. The LSM‑Tree storage engine delivers over 60% storage cost reduction.

Operational Platform (OCP) Deployment

The OceanBase Cloud Platform (OCP) manages the full lifecycle of clusters and tenants, offering high‑availability configurations (e.g., three‑zone three‑replica). A three‑node cross‑data‑center deployment was used for metadata, management services, and alert integration with vivo’s existing monitoring system.

Backup and recovery are performed by selecting follower replicas, creating backup tasks on the RS node, and storing backup files on NFS, S3, or compatible object storage.

oblogproxy Deployment

oblogproxy (OceanBase LogProxy) acts as an incremental log agent, converting OceanBase clog to MySQL‑compatible binlog. It runs a bc module to pull clog, writes binlog files, and a bd module to serve binlog dump requests. Multi‑node deployment via shared storage ensures high availability.

OMS (OceanBase Migration Service) Deployment

OMS provides both full‑load and incremental migration capabilities, supporting heterogeneous sources. Core components include DBCat (data collection), Store, Incr‑Sync, Full‑Import, Full‑Verification, and a management console.

Migration Process

The migration from MySQL to OceanBase followed an eight‑step workflow: pre‑migration validation, tenant/account verification, data consistency check, DDL pause, sync‑delay verification, application switch, source connection kill, and finally stopping forward sync and enabling reverse sync for rollback.

Five MySQL clusters (≈20 TB) were migrated, yielding:

Elimination of sharding maintenance costs and >70% storage savings due to compression.

Resolution of high replication lag and data loss risk via strong consistency.

Significant performance improvements for archival workloads and horizontal scalability.

Additional Migration Cases

A separate migration from a proprietary distributed database to OceanBase was performed using a CDC + Kafka + OMS architecture, chosen over a simpler CloudCanal solution because it offered bidirectional sync and better performance.

During large‑scale sync (≈500 billion rows), initial RPS was low (6‑8 k). Tuning involved increasing source.sliceBatchSize to 12 000, adjusting memory, and disabling partition bucket processing ( sink.enablePartitionBucket=false ) while increasing worker threads, raising RPS to 500‑600 k.

Issues & Solutions

Three major issues were encountered:

OMS task failure due to insufficient JVM memory – resolved by editing /home/admin/conf/command/start_oms_cm.sh and setting -server -Xmx16g -Xms16g -Xmn8g .

Low incremental sync RPS caused by duplicate primary key writes from CDC – mitigated by increasing write concurrency.

Index space explosion during index creation – identified as a pre‑4.2.3 bug; upgraded to 4.2.3+ where index space growth is limited to ~1.5×.

Conclusion

vivo’s adoption of OceanBase successfully addressed MySQL‑related pain points, delivering superior performance, strong data compression, and a comprehensive operational ecosystem. Future work will continue to explore OceanBase capabilities and request further enhancements to operational tools.