Migration and recovery
Adopting Realfuture can involve catalogs, development resources, AI configuration, CDC pipelines and jobs across several runtime clusters. Start by identifying what will move and what will stay in place. Registering an existing environment, changing a job’s runtime and moving stored data are separate operations.
Define the migration scope
| Area | What to carry forward and verify |
|---|---|
| Catalogs | Connection settings, database and table names, views, functions and schema overrides |
| Development | SQL, CDC YAML, ETL definitions, application artifacts, Git references and resource dependencies |
| AI | Provider endpoints, model selection, access and the data context allowed for each workflow |
| Runtime targets | YARN or Kubernetes environments, identities, queues or namespaces, storage paths and network routes |
| CDC and lakehouse | Source positions, target tables, keys, schema evolution policy and source log retention |
| Platform operations | Workspace permissions, monitoring, alerts, platform backups and operational ownership |
For teams coming from Apache StreamPark, identify reusable Flink applications and environment settings first, then add the catalog, AI and lakehouse workflows needed by the team. Realfuture builds on Apache StreamPark, but a shared foundation does not establish database, configuration or state compatibility between arbitrary releases.
Inventory the current job
Record Flink and CDC versions, connector artifacts, JAR dependencies, SQL and UDFs, state backend, checkpoint storage, source offsets and target write behavior. Preserve the existing configuration and a known recovery procedure.
A Flink checkpoint or savepoint stores job state. It does not replace backups of the platform database, external catalog metadata or lakehouse data. Plan recovery for each of those systems separately.
Validate the change
- Check API, SQL, dependency and connector compatibility for the target release.
- Validate Checkpoint or Savepoint compatibility for the actual source and target versions. Do not assume a state snapshot is portable across arbitrary versions.
- Test restoration with representative state and data.
- Check output correctness, including duplicates, updates, deletes and catch-up after recovery.
- Measure any interruption and recovery time under the intended operating procedure.
- Recheck catalog references, schema evolution and target table behavior after changing connectors or storage versions.
- When moving between clusters, verify access to state, artifacts, sources and sinks from the destination environment.
Agree on rollout and rollback
Decide who performs each step, what permits the rollout to continue, when to stop and how to return to the previous deployment. Some upgrades change state or metadata in ways that constrain rollback; validate the return path explicitly.
Define the recovery path using the actual releases, state and data involved. Restoring a draft version alone does not restore running state or reverse changes already written to downstream systems.
For deployment or migration assistance, review the support scope and contact the team.