4.x から 5.0 へのアップグレード

要点：4.1.1 を停止し、同じデータディレクトリ上で 5.0 バイナリを 起動するだけ。 設定変更は不要。5.0 のリリースゲートはタグ発行前に この手順そのもの(双方向切替 + バックアップコピーからのコールド復元) を毎回リプレイしている。

そのまま引き継がれるもの

• データファイル。 5.0 は 4.1.1 のデータディレクトリをそのまま 開く：AOF(v1/v2 レコード形式)、スナップショット、shards.meta、 セグメントディレクトリ。v1 時代の AOF は最初の rewrite までは v1 の まま追記され、rewrite でチェックサム付き v2 へ昇格——4.1 と同じ挙動。
• ダウングレード窓。 5.0 が書いたディレクトリを 4.1.1 バイナリが 再度開ける(アップグレードゲートがこの往復を検証)。切替前は どちらの方向でもクリーンシャットダウンを。
• 設定ファイルとフラグ。 4.x のキーはすべて受理。ゼロコンフィグ 起動(--port + --dir)の挙動は同一。
• ワイヤプロトコルとクライアント契約。 本リリースで RESP 表面の 削除・型変更はない。

挙動が変わる点

AOF 書き込みが reactor スレッドを離れる(io_uring、デフォルト有効)

Linux で io_uring が使える場合、appendfsync everysec(または no) の AOF 追記はシャード自身のリングにキューされ、reactor スレッドでの 同期書き込みは行われない。本リリースのテールレイテンシ改善の中核。 耐久性のセマンティクスは不変(everysec のクラッシュ窓は依然 ≤1 秒、 crash ゲートが両モードで検証)。

• KEVY_AOF_OFFLOAD=0 で 4.x の同期パスに戻せる。
• appendfsync always は定義上同期パスのまま。
• epoll reactor(io_uring 非対応カーネル)は 4.x パスのまま。

継続的な書き込み圧下の rewrite は停止ではなく延期

4.x は成長ルールが発火すれば rewrite を実行し、ディスクが要求する だけの停止を支払っていた——高インジェスト下では数秒級のサーバ停止。 5.0 は rewrite が収束可能か(追記レートと rewrite 自身の進度)を測り、 収束不能と証明されたら延期する：ログは伸び続け、サーバは応答し 続け、次の成長因子後(または明示的 BGREWRITEAOF——こちらは常に 無条件)に再試行。持続的飽和下では AOF が一時的に大きくなる—— それが交換条件であり、誠実な方だ：ディスクは取り返せる、停止は 取り返せない。

AOF の隣に現れる新しいハウスキーピングファイル

rewrite 中・直後に <aof>.rewrite(構築中イメージ)や <aof>.trashN(旧ログの GB 級解放をスレッド外へ移すための ハードリンク)が一時的に見えることがある。どちらも自動清掃され、 クラッシュ残骸は次の rewrite が回収する。これらはバックアップ しないこと；バックアップ = データディレクトリから *.rewrite / *.trash* を除いたもの——あるいは単純に全部コピーして 5.0 の起動に 任せてよい(disk ゲートの復元ドリルがまさにそれ)。

推奨手順

1. バックアップ：クリーンシャットダウン(または BGSAVE + コピー) の後、データディレクトリをコピー。
2. 4.1.1 停止。同じディレクトリ・設定で 5.0 バイナリを起動。
3. 検証：INFO persistence(aof 有効、rewrite 進行)、DBSIZE、 アプリ自身のスモーク。
4. ロールバックが必要なら:5.0 をクリーン停止し、同じディレクトリで 4.1.1 を起動。