MongoDB の日常運用と障害シナリオ (replica set と sharded cluster)

インストール手順ではありません。構築済みの MongoDB replica set と sharded cluster を日常的に運用し、障害時に復旧するためのシナリオ別 runbook です。ヘルスチェック、メンバーの追加・削除、priority/hidden/delayed メンバー、arbiter からデータ保持メンバーへの置き換え、遅延したメンバーの再同期、過半数喪失時の force reconfig、計画的な stepDown、oplog サイズ、FCV、shard の追加・削除、balancer、jumbo chunk、reshardCollection を扱います。何をすべきか分からない場合はヘルスチェックから始めてください。バックアップからのリストア、セキュリティ設定、メジャーバージョンアップグレードは別の MongoDB ガイドで扱います。

構成: Replica set (3 メンバー以上) または sharded cluster (config server + shard replica set + mongos)

シナリオ

• ヘルスチェック: メンバー、遅延、oplog ウィンドウ (sharded の場合は shard と balancer) — 読み取り専用: メンバーの状態、レプリケーション遅延、oplog ウィンドウ、構成。sharded cluster では shard 一覧、balancer、chunk の分布も確認します。何をすべきか分からない場合はここから始めてください。
• replica set に新しいメンバーを追加する (initial sync) — 新しいサーバーを構築済み (同じバージョン、keyfile、replSetName) であることが前提です。priority 0 / votes 0 で追加し、initial sync が完了して SECONDARY になった後に投票権と priority を与えます。ダウンタイムはありません。
• replica set からメンバーを削除する — サーバーを廃止する、または恒久的に失われた場合です。メンバーを構成から削除し、残りの投票数で過半数が維持されることを確認します。対象が primary の場合は先に stepDown します。
• メンバーのロールを変更する: priority、hidden、delayed メンバー — メンバーが primary になる優先度を変更する、レポート/バックアップ用の hidden メンバーや誤削除対策の delayed メンバーにする、または通常のメンバーに戻します。
• arbiter をデータ保持メンバーに置き換える (PSA → PSS) — primary + secondary + arbiter 構成の replica set では、データメンバーが 1 台停止すると majority 書き込みと cache 負荷が問題になります。新しいデータメンバーを追加し、arbiter を削除します。
• 遅延または破損したメンバーを再同期する (resync) — メンバーが RECOVERING のまま止まり 'too stale to catch up' と出力している、またはデータファイルが破損している場合です。メンバーのデータディレクトリを空にし、initial sync で一から同期し直します。他のメンバーは稼働を続けます。
• 過半数喪失: 残存メンバーで強制再構成する (force reconfig) — メンバーの大半が恒久的に失われ (サイト/サーバー喪失)、残ったメンバーで primary を選出できない場合です。残存メンバーで rs.reconfig(cfg, {force: true}) を実行します。最後の手段であり、使い方を誤るとデータ損失と split brain の危険があります。
• 計画的な primary 切り替え (rs.stepDown、特定メンバーの primary 化) — primary サーバーでメンテナンス/パッチ適用を行う場合です。primary を降格させ、追いついている secondary が primary になります。アプリケーションでは数秒間書き込みエラーが発生することがあります。
• oplog サイズを変更する (replSetResizeOplog) — oplog ウィンドウが短い場合です。メンテナンス後に secondary が 'too stale' になる、バックアップが oplog を取得しきれない、またはポイントインタイムリカバリに足りない、といった症状が出ます。各メンバーでダウンタイムなしに拡張します。
• Feature Compatibility Version (FCV) を確認して完了させる — アップグレード後に FCV が旧バージョンのまま、またはメンバー間でバージョンが異なる場合です。全メンバーのバイナリバージョンと FCV を確認し、FCV を新バージョンに引き上げます。
• cluster に shard を追加する (sh.addShard) — 容量が不足している場合です。新しい shard replica set (shardsvr) を構築済みで、それを cluster に追加します。balancer が chunk を段階的に移動します。
• shard を削除する (removeShard: drain と movePrimary) — shard を廃止する場合です。chunk を他の shard へ退避 (drain) し、その shard が primary shard になっているデータベースを移動 (movePrimary) した後、cluster から削除します。
• Balancer: 時間ウィンドウ、停止 / 開始、collection 単位の無効化 — ピーク時間帯に chunk の移動が負荷になる、メンテナンス/バックアップのために移動を止める必要がある、または特定の collection だけバランシングさせたくない場合です。
• 分布の偏りまたは jumbo chunk (診断と対処) — 特定の shard だけが他より大きく偏っている、balancer が移動しない、'jumbo' フラグ付きの chunk がある、または moveChunk が失敗する場合です。分布、jumbo chunk、balancer のエラーを調べます。
• shard key を変更する (reshardCollection) — 現在の shard key が hot shard、jumbo chunk、scatter-gather クエリを生んでいる場合です。collection をオンラインのまま新しい shard key で再分散します (5.0+)。最後に書き込みが約 2 秒ブロックされます。

開始前の確認

• 管理サーバーに mongosh がインストールされ、…mongos (…)…全メンバー (…)… への名前解決とポート疎通があること。接続に使う名前は rs.conf() のメンバー名と一致している必要があります。
• … ユーザーのパスワードを用意していること。ロールは root、または少なくとも clusterAdmin + readAnyDatabase。… shard または config server replica set に直接接続する場合は、shard-local の管理ユーザー (mongo-sharded ガイドで作成) が必要です。…
• 変更記録 / メンテナンスウィンドウを起票し、アプリケーションチームに連絡済みであること。reconfig、stepDown、shard 操作では数秒間の選出 (election) やルーティングの遅延が発生することがあります。
• 新メンバー … が replica set インストールガイド の OS、インストール、keyfile、構成の各フェーズで準備されていること: 同じ MongoDB バージョン (…)、同じ keyfile、replication.replSetName: …、mongod は稼働中だが rs.initiate は実行していない。他のメンバーとの間で双方向の名前解決とポート疎通があり、データディスクの空き容量が現在のデータ量以上あること。
• initial sync の間、メンバーのディスクには全データが書き直されます…。古いディレクトリを退避するため、データサイズの 2 倍 の空き容量が必要です…。残りのメンバーで過半数が維持され、同期元メンバーの oplog ウィンドウが initial sync の所要時間より長いこと。

ガイドのフェーズ

• 状態: メンバー、遅延、oplog (読み取り専用) — メンバーの状態と遅延を表示する · 構成を表示する (priority、votes、hidden、delay) · 結果を解釈して適切なシナリオを選ぶ
• 状態: shard、balancer、chunk の分布 (読み取り専用) — cluster の概要を表示する · chunk の分布と jumbo chunk · shard replica set の状態を確認する
• 1. 診断: 新メンバーの準備はできているか — 新メンバーのサービスとバージョンを確認する · 現在の set の状態とデータサイズを確認する · 新メンバーへの疎通を確認する
• 2. セーフティネット — 現在の replica set 構成を保存する
• 3. 適用: メンバーを追加して同期を待つ — メンバーを priority 0 / votes 0 で追加する · initial sync の完了を待つ · メンバーに投票権と priority を与える
• 4. 検証と事後作業 — 状態を検証する · アプリケーションの接続文字列と監視を更新する
• 1. 診断: 削除するメンバーは primary か、過半数は維持されるか — メンバーのロールと残りの投票数を確認する
• 2. セーフティネット — 現在の replica set 構成を保存する
• 3. 適用: メンバーを削除する — メンバーを構成から削除する (rs.remove) · 削除したサーバーの mongod を停止する
• 4. 検証と事後作業 — 状態を検証する · 接続文字列、監視、ファイアウォールを更新する
• 1. 診断 — メンバーの現在の設定と oplog ウィンドウを確認する
• 2. セーフティネット — 現在の replica set 構成を保存する
• 3. 適用 — メンバーの設定を変更する (rs.reconfig)
• 4. 検証 — 結果を検証する
• 1. 診断: arbiter と新メンバー — arbiter と write concern を確認する · 新メンバーの準備ができていることを確認する
• 2. セーフティネット — 現在の replica set 構成を保存する
• 3. 適用: データメンバーを追加し、arbiter を削除する — 新メンバーを priority 0 / votes 0 で追加する · initial sync の完了を待つ · 新メンバーに投票権と priority を与える · arbiter を削除する · arbiter サーバーの mongod を停止する
• 4. 検証と事後作業 — 状態と write concern を検証する
• 1. 診断: メンバーの再同期は本当に必要か — メンバーの状態と最後のメッセージを確認する · メンバーのログでエラーを確認する
• 2. セーフティネット — 現在の replica set 構成を保存する
• 3. 適用: データディレクトリを空にして initial sync を行う — mongod を停止する · データディレクトリを…退避する…空にする… · mongod を起動する (initial sync が始まる) · initial sync の完了を待つ
• 4. 検証と事後作業 — 状態を検証する · 古いデータディレクトリを削除する
• 1. 診断: 過半数は本当に恒久的に失われているか — 残存メンバーから状態と optime を確認する · 失われたメンバーが停止していることを確認する
• 2. セーフティネット — 残存メンバーの構成を保存する
• 3. 適用: force reconfig — 残存メンバーだけで強制的に再構成する · primary が選出されたことを確認する
• 4. 検証と事後作業 — majority 書き込みを試す · 失われたメンバーを再追加し、根本原因を解消する
• 1. 診断: secondary は追いついているか — primary と遅延を確認する
• 2. 適用 — 他の secondary を凍結する (対象メンバーを選出させる) · primary を降格させる (rs.stepDown)
• 3. 検証 — 新しい状態を検証する
• 1. 診断: 現在の oplog サイズとウィンドウ — 各メンバーの oplog サイズとウィンドウ