Lindorm Tunnel Service (LTS) lets you migrate full data and synchronize incremental data between ApsaraDB for HBase clusters without service downtime. Use LTS for version upgrades, cross-region moves, cross-account transfers, cluster rescaling, and workload decoupling.
How it works
LTS reads data directly from the Hadoop Distributed File System (HDFS) of the source cluster — it never interacts with the source cluster's HBase layer. This file-level approach reduces data transfer volume by more than 50% compared to API-layer migration and minimizes the impact on your online workloads.
Each LTS node migrates data at up to 150 MB/s. Add nodes horizontally to handle terabyte- or petabyte-scale datasets. LTS monitors task speed and progress in real time, retries on errors automatically, and sends alerts when tasks fail. LTS automatically synchronizes schemas to ensure consistent partitions.
A migration task supports the following three operations, which you can select based on your requirements:
Schema migration (migration table schema): LTS creates tables in the destination cluster with the same schema and partition layout as the source. You do not need to create tables manually.
Full data migration (history data migration): LTS physically copies files at the HDFS layer.
Real-time incremental sync (real time data replication): LTS tails write-ahead logging (WAL) to capture changes written after the full migration starts, keeping the destination current until you switch over.
Use cases
| Scenario | Example |
|---|---|
| Major version upgrade | Upgrade an ApsaraDB for HBase cluster from V1.x to V2.x |
| Cross-region migration | Move data from China (Qingdao) to China (Beijing) |
| Cross-account migration | Migrate data across different accounts |
| Cluster specification upgrade | Scale up from 4 cores and 8 GB to 8 cores and 16 GB |
| Workload decoupling | Offload part of a cluster's workload to a new cluster |
Supported versions
LTS supports migration between any combination of the following versions with no service downtime:
HBase 094
HBase 098
HBase V1.x
HBase V2.x
Lindorm
Features
Migrate table schemas, synchronize data in real time, and migrate full data
Migrate data based on databases, namespaces, and tables
Rename a table when you migrate the data in the table
Specify the time range, the row key range, and the columns when you migrate data
Call API operations to create migration tasks
Limitations
| Constraint | Detail |
|---|---|
| Kerberos clusters | Not supported |
| Single-node clusters | Not supported |
| Classic network clusters | Not supported |
| BulkLoad data | Not synchronized — incremental sync captures only WAL-written data |
| Data not written to WAL | Not synchronized |
Prerequisites
Before you begin, make sure you have:
Verified network connectivity among the source cluster, the destination cluster, and LTS
Added the HBase and Lindorm data sources in LTS
Verified that the destination cluster has enough HDFS capacity to accommodate the migrated data
Logged on to the LTS web UI
Create a migration task
In the left navigation pane, go to Migration > Quick Migration.
Configure the following parameters, then click create.
NoteLTS creates destination tables automatically with the same partition layout as the source. If you create tables manually before migration, the partition layout may differ, which can cause frequent splits and compactions after migration — especially for large tables.
Parameter Description job name A name for the task. Letters and digits only. If left blank, the task ID is used. Source Cluster The source ApsaraDB for HBase or Lindorm cluster. Target Cluster The destination cluster. migration table schema Creates tables in the destination with the same schema and partition layout as the source. If a table already exists in the destination cluster, the data in this table is not migrated. real time data replication Synchronizes incremental changes from the source in real time using WAL. history data migration Physically migrates all files at the HDFS layer. table mapping Table names to migrate, one per line. advance configuration Optional. Leave blank to use defaults. If the source table has a coprocessor, ensure that the destination cluster contains the corresponding JAR package of the coprocessor when you create a destination table.
Configure incremental synchronization
Set the log retention period
Before starting an incremental sync task, extend the log retention period on the source cluster. This gives LTS time to recover from transient errors without losing WAL data.
Set hbase.master.logcleaner.ttl in hbase-site.xml to a value greater than 12 hours, then restart the HBase Master.
Understand the default retention window
If LTS cannot consume log data — for example, because the LTS cluster was released, the synchronization task was suspended, or the task was abnormally blocked — unconsumed logs are retained for 48 hours by default. After 48 hours, the subscription is cancelled and the retained data is deleted.
Monitor a task
To view the task list, go to Migration > Quick Migration in the left navigation pane.
To view task details and execution status, click the task name.
Perform a switchover
Wait until the full migration is complete and the latency of incremental synchronization becomes as low as several seconds or hundreds of milliseconds.
Enable LTS data sampling and verification. For large tables, use an appropriate sampling ratio to avoid affecting online traffic.
Validate your application against the destination cluster.
Switch application traffic to the destination cluster.