此内容没有您所选择的语言版本。

Chapter 2. Migration planning

Select the migration approach that best aligns with your architecture, and customize the steps for your infrastructure.

Expand

Feature	Minimal downtime migration	Maintenance window migration
Primary Method	Parallel environments with reverse proxy or load balancer routing	Sequential process
Complexity	High: Requires configuration for dual-routing and traffic management.	Low: Straightforward, linear execution steps.
Read Downtime	10-30 seconds (Switchover latency)	1-2 hours (Full duration of maintenance)
Write Downtime	30-45 minutes (Final sync and import phase)	1-2 hours (Full duration of maintenance)
Infrastructure	Requires Nginx or HAProxy and running dual instances.	Single target environment.
Best For	High-availability production environments.	Development, staging, or systems with flexible SLAs.

Regardless of the migration path you choose, you need to:

Test the data migration in a staging environment before migrating production. A dry run helps you estimate timing for export and import phases. See Migrating Apicurio Registry data.
Verify client applications connect to Apicurio Registry 3.x after the data migration completes. For minimal downtime migrations, verify the load balancer routes to 3.x and update any clients that bypass the load balancer. For maintenance window migrations, update client configurations directly. See Migrating Apicurio Registry client applications.
Update configuration properties for the v3 deployment. Combine this with client updates where possible. See Updating Apicurio Registry configuration.

Minimal downtime migration

The objective is to keep the service reachable. While data is being moved, a reverse proxy (such as nginx) manages the cutover. See Migrating with minimal downtime.

Maintenance window migration

This approach ensures the cleanest data integrity. By stopping all client applications first, you ensure no data is in flight during the move. See Migrating in a maintenance window.

During a minimal downtime migration, you temporarily run both Apicurio Registry 2.6 and Apicurio Registry 3.x simultaneously. Plan for:

Infrastructure:

Separate database instances for v2 and v3 (or different schemas in the same database)
For KafkaSQL deployments: same Kafka cluster with different topic names
Load balancer capacity for routing traffic
Network connectivity between all components

Storage requirements:

v2 database/storage: existing size
v3 database/storage: approximately same size as v2 (plan for 110% of the v2 size)
Export file storage: approximately 10-20% of the database size (compressed)

Timeline:

Keep v2 running for 1-7 days after migration for rollback capability
Total parallel operation period: 1-7 days
Budget for staging environment testing before production migration

Prerequisites

Before beginning migration:

Expand

Requirement	Description
Staging environment	Test complete migration workflow before production
Load balancer	nginx, HAProxy, or similar for traffic management
Administrative access	Admin role credentials for export/import API endpoints and testing admin functionality
Database or storage	Separate database instance or schema (or separate Kafka topic) for Apicurio Registry 3.x
Backup	Current backup of 2.6 data
Rollback plan	Documented procedure to revert to v2 if needed

此内容没有您所选择的语言版本。

Chapter 2. Migration planning

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links