Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

このコンテンツは選択した言語では利用できません。

Chapter 2. Migration planning

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

Expand
FeatureMinimal downtime migrationMaintenance 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
RequirementDescription

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

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る