RedisのNOREPLICASエラーを修正：書き込みアクセスを迅速に復旧する方法

背景本番環境の Redis マスターが突然読み取り専用モードになりました。キーを更新しようとするすべてのアプリケーションリクエストが、次のエラーに直面しています：NOREPLICAS Not enough good replicas to write.

これは安全装置のようなものだと考えてください。このエラーは、min-replicas-to-write ディレクティブを使用して Redis を高い整合性（Consistency）に設定している場合に発生します。Redis は、更新内容が十分な数の正常なレプリカにミラーリングされることを保証できないため、データの受け入れを拒否しています。フェイルオーバー中にデータが失われるリスクを冒すよりも、動作を停止することを選択しているのです。

デバッグプロセスまず、マスターノードで直接レプリケーションの健全性を確認します。ターミナルで次のコマンドを実行してください。

redis-cli -h <master-ip> -p 6379
> INFO replication

出力を詳しく確認してください。次のような内容が表示されるはずです。

# レプリケーション
role:master
connected_slaves:1
slave0:ip=10.0.1.5,port=6379,state=online,offset=12345,lag=15
min_slaves_good_slaves:0

ここでの決定的な証拠は min_slaves_good_slaves:0 です。1つのレプリカが "online" と表示されていても、その lag（遅延） が15秒に急増しています。Redis は、ハートビートの遅延が min-replicas-max-lag のしきい値より低い場合にのみ、そのレプリカを「正常（good）」とカウントします。 現在の制限値を確認します：

> CONFIG GET min-replicas-to-write
1) "min-replicas-to-write"
2) "2"

> CONFIG GET min-replicas-max-lag
1) "min-replicas-max-lag"
2) "10"

この例では、Redis は遅延が10秒未満の正常なレプリカが2つ揃うのを待っています。レプリカは1つしかなく、しかも15秒遅れているため、マスターはデータの整合性を守るためにロックされています。

解決策### 1. 緊急の「止血」対応アプリケーションがダウンしており、すぐにサービスを復旧させる必要がある場合は、一時的に健全性チェックを無効にできます。これはトレードオフです。サイトは復旧しますが、マスターがレプリカと同期する前にクラッシュした場合、データが失われるリスクがあります。

> CONFIG SET min-replicas-to-write 0

このコマンドは再起動なしで即座に反映されます。根本的なインフラの問題を調査する間の、一時的な回避策として使用してください。

2. 根本的なレプリカの健全性の修正これを適切に解決するには、レプリカが苦戦している理由を突き止める必要があります。レプリカノードに SSH でログインし、ログを確認してください。

tail -n 100 /var/log/redis/redis-server.log

私は通常、次の4つの原因を疑います。

• ネットワークの混雑: AWS のアベイラビリティゾーン間やデータセンター間の高レイテンシにより、ハートビート（replconf acks）の到着が遅れることがあります。- メモリ圧迫: レプリカの RAM 使用率が 95% に達し、ディスクへのスワップが発生している場合、マスターへの応答が間に合わなくなります。- CPU のスパイク: 重い KEYS * コマンドや負荷の高い Lua スクリプトは、Redis のイベントループをブロックする可能性があります。- 大規模な永続化タスク: 巨大な RDB スナップショットや AOF 書き換えにより、レプリカが数秒間応答不能になることがあります。### 3. ネットワークの実情に合わせた調整ノードが異なるクラウドリージョン（例：us-east-1 と us-west-2）に分散している場合、10秒の遅延制限は厳しすぎるかもしれません。マイナーなネットワークの瞬断に対して耐性を持たせるよう、redis.conf を調整できます。

# redis.conf 内
min-replicas-to-write 1
min-replicas-max-lag 20

忘れないでください。CONFIG SET は実行中のインスタンスのみを変更します。設定を再起動後も維持するには、必ず物理的な設定ファイルを更新してください。

確認レプリカを修正するか設定を緩和した後、再度 INFO replication を実行します。min_slaves_good_slaves が要件を満たしているか、それを上回っていることを確認してください。簡単な書き込みテストを行います。

> SET health_check "ok"
OK

OK と表示されれば、書き込みブロックは正式に解除されています。

学んだ教訓- 早期アラート: 完全にシャットダウンするまで待たないでください。監視スタックで connected_slaves や master_link_down_since_seconds のアラートを設定しましょう。- CAP定理を意識する: min-replicas-to-write を使用することは、可用性（Availability）よりも一貫性（Consistency）を選択していることを意味します。アプリケーションが軽微なデータ損失を許容できる場合は、この設定を 0（デフォルト）のままにしてください。- N+1 ルール: 書き込みに 1 つの正常なレプリカが必要な場合は、少なくとも 2 つのレプリカを稼働させるべきです。これにより「メンテナンスの余裕」が生まれ、書き込み能力を維持したまま 1 つのノードを再起動できます。