MongoDB: バックアップと復旧、セキュリティ、運用監視
最終更新:2026-08-26
運用監視はMongoDB本番デプロイメントの鍵—バックアップ、セキュリティ、監視を習得すれば、本番インシデントの90%を防止できます。
1. 学習内容
- mongodump / mongorestore論理バックアップ
- Ops Manager / Atlasバックアップポリシー
- SCRAM認証とRBAC
- TLS/SSL暗号化
- 運用監視(serverStatus / dbStats / スロークエリ)
graph TB
subgraph "バックアップ戦略"
A1[日次フルバックアップ<br/>mongodump] --> S3[(S3/OSS<br/>オブジェクトストレージ)]
A2[oplog継続<br/>増分] --> S3
A3[Atlas PITR<br/>ポイントインタイムリカバリ] --> S3
end
subgraph "復旧シーン"
R1[誤削除データ] --> R2[mongorestore]
R3[データベース全損] --> R2
R4[特定時点への復旧] --> R5[oplogReplay]
R2 --> R6[✅ データ復旧]
R5 --> R6
end
style R6 fill:#d4edda
2. mongodump論理バックアップ
概念説明: mongodumpはMongoDB公式の論理バックアップツール—コレクションデータを読み出してBSON/JSONファイルにエクスポートします。論理バックアップは「データをエクスポート」するもので「ファイルをコピー」するわけではないため、バージョンやプラットフォームをまたいで復旧できますが、大規模DBのバックアップは比較的遅いです。
動作原理: mongodumpはMongoDBに接続し、データをコレクション単位、ドキュメント単位で読み出し、BSON形式にシリアライズしてディスクに書き込みます。gzip圧縮、条件フィルタリング、oplog包含(PITR用)をサポートします。バックアップ中、コレクションはロックされません(ホットバックアップ)が、大規模コレクションのバックアップはパフォーマンスに影響する可能性があります。
論理バックアップ vs 物理バックアップ:
| 項目 | 論理バックアップ(mongodump) | 物理バックアップ(ファイルコピー) |
|---|---|---|
| 実装 | データ読み出し → シリアライズ → ファイル書き込み | データファイルを直接コピー |
| 速度 | 遅い(読み出し + シリアライズ必要) | 速い(ファイルレベルコピー) |
| クロスバージョン | ✅ 対応 | ❌ 特定エンジンバージョンに依存 |
| 選択性 | ✅ データベース/コレクション/条件指定可 | ❌ 全量のみ |
| サイズ | 小さい(圧縮済み) | 大きい(元ファイル) |
| 整合性 | 単一コレクション整合性 | ロックまたはレプリカセットスナップショット必要 |
| 復旧粒度 | 柔軟(DB/コレクション/ドキュメント) | データベース全体 |
RPO/RTO概念:
| 概念 | 意味 | 例 |
|---|---|---|
| RPO(Recovery Point Objective) | 許容される最大データ損失 | RPO=1h = 最大1時間のデータ損失 |
| RTO(Recovery Time Objective) | 許容される最大復旧時間 | RTO=4h = 4時間以内にサービス復旧必要 |
# === データベース全体をバックアップ ===
mongodump --uri="mongodb://localhost:27017/shopdb" --out=/backup/2026-07-01
# === 特定コレクションをバックアップ ===
mongodump --uri="mongodb://localhost:27017/shopdb" --collection=users --out=/backup/users
# === 圧縮バックアップ ===
mongodump --uri="mongodb://localhost:27017" --gzip --archive=/backup/shopdb.gz
# === メタデータのみバックアップ ===
mongodump --uri="mongodb://localhost:27017" --db=shopdb --collection=users --query='{"role":"admin"}'
主要なmongodumpパラメータ:
| パラメータ | 説明 | 例 |
|---|---|---|
--uri |
接続文字列 | mongodb://user:pass@host:port/db |
--out |
出力ディレクトリ | /backup/2026-07-01 |
--gzip |
gzip圧縮 | ファイルサイズを60–80%削減 |
--archive |
単一ファイルアーカイブ | --archive=backup.gz |
--oplog |
oplogを含める(PITR用) | --oplog |
--collection |
特定コレクション | --collection=users |
--query |
条件フィルタ | --query='{"role":"admin"}' |
3. mongorestore復旧
概念概要: mongorestoreはmongodumpの対となるツール—BSON/JSONバックアップファイルをMongoDBにインポートします。全量復旧、部分復旧、PITR(ポイントインタイムリストア)などのモードをサポートします。
動作原理: mongorestoreはバックアップディレクトリまたはアーカイブファイルから読み出し、コレクション単位でドキュメントをインポートします。--dropオプションはまず既存コレクションを削除してから復旧(上書きモード)。--oplogReplayと組み合わせると、oplogを再生してポイントインタイムリカバリを実行します。
復旧モードの比較:
| モード | コマンドオプション | 使用シーン |
|---|---|---|
| 全量復旧 | mongorestore /backup/db |
データベース全体をバックアップ時点に復旧 |
| 上書き復旧 | --drop |
クリア後に復旧(テスト環境) |
| 部分復旧 | --nsInclude |
特定コレクションのみ復旧 |
| PITR復旧 | --oplogReplay |
特定時点に復旧 |
| 圧縮アーカイブから復旧 | --gzip --archive=file.gz |
圧縮アーカイブから復旧 |
# === バックアップ全体を復旧 ===
mongorestore --uri="mongodb://localhost:27017" /backup/2026-07-01
# === 特定データベースを復旧 ===
mongorestore --uri="mongodb://localhost:27017" /backup/2026-07-01/shopdb
# === gzip圧縮バックアップを復旧 ===
mongorestore --uri="mongodb://localhost:27017" --gzip --archive=/backup/shopdb.gz
# === 既存データを上書きして復旧 ===
mongorestore --uri="mongodb://localhost:27017" --drop /backup/2026-07-01
ポイント解説:
--dropはまずコレクションを削除してから復旧するため、本番環境では慎重に使用(バックアップ後に追加された新規データが消失する可能性)。- mongorestoreへのデータ挿入はインデックス再構築をトリガーし、大規模コレクションの復旧は遅くなります。
- 既存データベースへの復旧時、
_id競合により重複ドキュメントはスキップされます。--dropで競合を回避可能。
4. バックアップ戦略
概念説明: バックアップ戦略は運用保守の中核—RPO(最大データ損失)とRTO(最大復旧時間)を決定します。ビジネスシーンにより、異なるバックアップ頻度、保持期間、復旧計画が必要です。
バックアップ戦略の比較:
| 戦略 | 頻度 | 保持期間 | RPO | RTO | 適用 | コスト |
|---|---|---|---|---|---|---|
| 日次フルバックアップ | 毎朝 | 7–30日 | 24時間 | 数時間 | 小規模DB | 低 |
| 時間単位増分 | 毎時 | 24–48時間 | 1時間 | 数時間 | 中規模DB | 中 |
| oplog永続化 | リアルタイム | 7日 | < 1秒 | 分単位 | 大規模DB | 高 |
| Atlas PITR | 自動 | 35日 | 秒単位 | 分単位 | Atlasクラウドサービス | 従量課金 |
| ファイルスナップショット | オンデマンド | 7–30日 | スナップショット頻度 | 分単位 | LVM/EBS対応 | 低 |
バックアップ戦略選択フロー:
graph TB
A{ビジネスタイプ?} -->|非重要<br/>ログ/キャッシュ| B[日次フル<br/>RPO=24h]
A -->|一般ビジネス<br/>ユーザー/注文| C{データ量?}
A -->|コアビジネス<br/>金融/決済| D[oplog継続<br/>RPO<1s]
C -->|< 100GB| E[日次フル+<br/>oplog PITR]
C -->|> 100GB| F[ファイルスナップショット+<br/>oplog継続]
style D fill:#d4edda
style B fill:#fff3cd
PITR(Point-In-Time Recovery)の原理: まずフルバックアップを復旧し、その後バックアップ時点からターゲット時点までのoplogエントリを再生することで、秒単位の時点復旧を実現します。
sequenceDiagram
participant Full as フルバックアップ
participant Oplog as oplog増分
participant Target as ターゲット時点
Note over Full: バックアップ時点T0
Full->>Oplog: T0時点のフルデータセットを復旧
Note over Oplog: T0 → T1間のoplog
loop oplog再生
Oplog->>Target: 書き込み操作を順次再生
end
Note over Target: 特定時点T1に復旧
| 戦略 | 頻度 | 保持期間 | 適用 |
|---|---|---|---|
| 日次フルバックアップ | 毎朝 | 7–30日 | 小規模DB |
| 時間単位増分 | 毎時 | 24–48時間 | 中規模DB |
| Oplog永続化 | リアルタイム | 7日 | 大規模DB(レプリカセットoplogベース) |
| Atlas PITR | 自動 | 35日 | Atlasクラウドサービス |
▶ サンプル 1:PITRポイントインタイムリカバリのハンズオン
# ShopHubで2026-07-01 10:00-10:30の注文データを誤削除、10:00の状態に戻す必要あり
# 1. 前日のフルバックアップを復旧
mongorestore --uri="mongodb://localhost:27017/shopdb_recovery" --drop /backup/2026-06-30/shopdb
# 2. ターゲット時点までoplogを再生
mongorestore --uri="mongodb://localhost:27017/shopdb_recovery" --oplogReplay --oplogLimit=1750604400 /backup/2026-06-30/oplog.bson
# 3. 復旧データを確認
mongosh --port 27017 shopdb_recovery --eval 'db.orders.count()'
# 4. 復旧データをエクスポートして本番環境にインポート
mongodump --uri="mongodb://localhost:27017/shopdb_recovery" --collection=orders --query='{"createdAt":{"$gte":{"$date":"2026-07-01T10:00:00Z"},"$lt":{"$date":"2026-07-01T10:30:00Z"}}}' --out=/recovery/orders
mongorestore --uri="mongodb://localhost:27017/shopdb" /recovery/orders
5. ユーザーと認証
概念概要: セキュリティはMongoDB本番デプロイメントの第一防衛線です。SCRAM(Salted Challenge Response Authentication Mechanism)はMongoDBのデフォルト認証メカニズム、RBAC(Role-Based Access Control)はロールベースで権限を制御します。最小権限の原則がセキュリティの中核—各ユーザーにはタスク遂行に必要な最小限の権限のみを付与します。
SCRAM認証の動作原理: クライアントがユーザー名を送信、サーバーはランダムなsaltとイテレーション回数を返します。クライアントはパスワードとsaltを使って複数回ハッシュ操作を行い、証明を生成、サーバーは証明が保存されたハッシュと一致するか検証します。パスワードはネットワーク上で平文送信されません。
sequenceDiagram
participant C as クライアント
participant S as MongoDBサーバー
C->>S: 1. ユーザー名
S-->>C: 2. salt + iterationCount + storedKey
C->>C: 3. パスワード + salt → PBKDF2 → clientKey → storedKey
C->>S: 4. clientProof(デジタル署名)
S->>S: 5. clientProofを検証
S-->>C: 6. 認証成功 ✅ / 失敗 ❌
Note over C,S: パスワードはネットワーク上で送信されない
RBAC権限モデル:
| レベル | 説明 |
|---|---|
| ユーザー | 認証されるエンティティ、1つ以上のロールを持つ |
| ロール | 権限の集合、他のロールから継承可能 |
| 権限 | リソースとアクションの組み合わせ |
| リソース | データベース/コレクション/クラスターレベル |
(1) SCRAM認証
// === 管理者ユーザー作成 ===
db.createUser({
user: 'admin',
pwd: 'SecurePass123!',
roles: [
{ role: 'userAdminAnyDatabase', db: 'admin' },
{ role: 'readWriteAnyDatabase', db: 'admin' }
]
});
出力:
TEXT 📖 参照専用{ ok: 1 }
// === アプリケーションユーザー作成 ===
db.createUser({
user: 'app_user',
pwd: 'AppPass456!',
roles: [{ role: 'readWrite', db: 'shopdb' }]
});
出力:
TEXT 📖 参照専用{ ok: 1 }
(2) RBACロール
| 組み込みロール | 権限 | 適用ユーザー |
|---|---|---|
read |
全コレクション読み取り | アナリスト |
readWrite |
全コレクション読み書き | アプリケーション |
dbAdmin |
データベース管理 | DBA |
userAdmin |
ユーザー管理 | DBA |
dbOwner |
上記全権限 | 責任者 |
readAnyDatabase |
全データベース読み取り | クロスDBアナリスト |
readWriteAnyDatabase |
全データベース読み書き | クロスDBアプリケーション |
userAdminAnyDatabase |
全データベースユーザー管理 | スーパーDBA |
dbAdminAnyDatabase |
全データベース管理 | スーパーDBA |
backup |
バックアップ権限 | バックアップスクリプト |
restore |
復旧権限 | 復旧スクリプト |
root |
スーパーユーザー | 緊急メンテナンス |
最小権限の原則:
| ユーザー | 推奨ロール | 説明 |
|---|---|---|
| アプリケーションユーザー | readWrite(単一DB) |
ビジネスDBへの読み書きのみ |
| バックアップユーザー | backup + readAnyDatabase |
バックアップに必要な最小権限 |
| 分析ユーザー | read(単一DB) |
読み取り専用権限 |
| DBA | userAdmin + dbAdmin |
管理権限、スーパーユーザーではない |
// === カスタムロール作成 ===
db.createRole({
role: 'orderManager',
privileges: [
{ resource: { db: 'shopdb', collection: 'orders' }, actions: ['find', 'insert', 'update'] },
{ resource: { db: 'shopdb', collection: 'products' }, actions: ['find'] }
],
roles: []
});
// === 権限付与 ===
db.grantRolesToUser('app_user', [{ role: 'orderManager', db: 'shopdb' }]);
▶ サンプル 2:最小権限RBAC設定
// TechCorp:各チームに必要最小限の権限を付与
// 1. アプリケーションサービスアカウント(shopdbのみ読み書き)
db.createUser({
user: 'app_service',
pwd: 'AppSecurePass!',
roles: [{ role: 'readWrite', db: 'shopdb' }]
});
// 2. バックアップサービスアカウント(バックアップ権限のみ)
db.createUser({
user: 'backup_service',
pwd: 'BackupSecurePass!',
roles: [
{ role: 'backup', db: 'admin' },
{ role: 'readAnyDatabase', db: 'admin' }
]
});
// 3. データ分析チーム(読み取り専用 + 特定コレクション)
db.createRole({
role: 'analyticsReader',
privileges: [
{ resource: { db: 'shopdb', collection: 'orders' }, actions: ['find'] },
{ resource: { db: 'shopdb', collection: 'products' }, actions: ['find'] }
],
roles: []
});
db.createUser({
user: 'analyst',
pwd: 'AnalystPass!',
roles: [{ role: 'analyticsReader', db: 'shopdb' }]
});
// 4. 権限確認
db.auth('analyst', 'AnalystPass!');
db.orders.find({}); // ✅ 読み取り可能
db.orders.insertOne({}); // ❌ 権限不足
- TLS/SSL暗号化
概念説明: TLS/SSL暗号化はMongoDBネットワーク通信を保護—中間者攻撃、データ盗聴、改ざんを防止します。本番環境ではTLSの有効化が必須です。特にクロスデータセンター、クロスクラウド通信では重要です。
動作原理: TLSは証明書でサーバーの身元を検証し、暗号化接続を確立します。MongoDBはX.509証明書認証(SCRAMの代替)をサポートし、相互TLS(mTLS)はクライアントとサーバー双方の身元を検証します。
暗号化レベル:
| レベル | 暗号化方式 | 保護範囲 |
|---|---|---|
| トランスポート層 | TLS/SSL | ネットワーク通信(クライアント ↔ サーバー、ノード間) |
| ストレージ層 | WiredTiger暗号化 | データファイル(静的暗号化) |
| フィールドレベル | アプリケーションレベル暗号化 | 機密フィールド(パスワード、ID番号など) |
# === SSL有効でmongod起動 ===
mongod --tlsMode requireTLS --tlsCertificateKeyFile /etc/ssl/mongodb.pem
# === クライアント接続 ===
mongosh "mongodb://localhost:27017/shopdb?ssl=true&sslCertificateKeyFile=/etc/ssl/client.pem"
TLS設定パラメータ:
| パラメータ | 説明 | 推奨値 |
|---|---|---|
--tlsMode |
TLSモード | requireTLS(本番) |
--tlsCertificateKeyFile |
サーバー証明書 + 秘密鍵 | PEM形式 |
--tlsCAFile |
CA証明書 | クライアント証明書検証用 |
--tlsAllowInvalidCertificates |
無効な証明書を許可 | ❌ 本番では無効化 |
ポイント解説:
- 自己署名証明書は自己ホストクラスターで使用可能、AtlasではTLSがデフォルトで有効。
- mTLS(相互TLS)は証明書ベース認証を有効化し、パスワードベース認証の代替となる。
- TLSは接続遅延を約5–10%増加させるが、データセキュリティには不可欠。
6. 運用監視
概念説明: 運用監視はMongoDB本番デプロイメントの「健康ダッシュボード」—serverStatus、dbStats、スロークエリ分析などのツールでデータベース健全性をリアルタイム監視し、問題を早期に発見・防止します。
監視システム:
| 監視レベル | ツール | 主要メトリクス |
|---|---|---|
| インスタンスレベル | serverStatus() |
接続数、操作数、メモリ |
| データベースレベル | db.stats() |
データ量、インデックス数、コレクション数 |
| コレクションレベル | collStats() |
ドキュメント数、サイズ、インデックス効率 |
| クエリレベル | Profiler / Explain | スロークエリ、実行計画 |
| インデックスレベル | $indexStats |
インデックス使用状況 |
(1) serverStatus
主要メトリクス:
| メトリクス | 説明 | 健全範囲 | アラート閾値 |
|---|---|---|---|
connections.current |
現在の接続数 | < 1000 | > 8000 |
connections.available |
利用可能接続数 | > 50,000 | < 1,000 |
opcounters.query |
秒間クエリ数 | ベースライン | 10倍急増 |
opcounters.insert |
秒間操作数 | ベースライン | 10倍増加 |
mem.resident |
使用メモリ(MB) | < 総メモリの80% | > 総メモリの95% |
uptime |
稼働時間(秒) | > 86,400 | < 3,600(頻繁な再起動) |
db.serverStatus();
// {
// host: 'mongo1',
// version: '7.0.5',
// process: 'mongod',
// uptime: 864000,
// connections: { current: 150, available: 83860 },
// opcounters: {
// insert: 1234567,
// query: 9876543,
// update: 234567,
// delete: 12345
// },
// mem: { resident: 1024, virtual: 4096 },
// ...
// }
(2) データベース統計
db.stats();
// {
// db: 'shopdb',
// collections: 10,
// objects: 1000000,
// dataSize: 524288000,
// storageSize: 268435456,
// indexes: 20,
// indexSize: 52428800
// }
(3) スロークエリ分析
概念説明: スロークエリはMongoDBパフォーマンス問題の主要な指標です。パフォーマンス最適化の標準プロセスは、Profilerを使って閾値を超えるクエリをログに記録し、実行計画とインデックス使用状況を分析することです。
| プロファイリングレベル | 説明 | パフォーマンス影響 |
|---|---|---|
| 0 | オフ | なし |
| 1 | スロークエリのみ | 非常に低い |
| 2 | 全操作をログ | 中程度(デバッグのみ) |
// === スロークエリログを有効化(>100ms)===
db.setProfilingLevel(2, { slowms: 100 });
// === スロークエリを確認 ===
db.system.profile.find({ millis: { $gt: 100 } })
.sort({ ts: -1 })
.limit(10);
(4) インデックス使用統計
db.products.aggregate([{ $indexStats: {} }]);
// 未使用インデックスを特定
監視アラート設定推奨:
| アラート項目 | 閾値 | 通知方法 |
|---|---|---|
| 接続数 > 最大の80% | current > 64,000 | メール + SMS |
| スロークエリ > 10回/分 | 5分継続 | Slack |
| メモリ > 90% | resident > 総メモリの90% | メール |
| ディスク > 85% | storageSize > ディスクの85% | メール + SMS |
| レプリケーション遅延 > 10s | optimeDate偏差 | メール |
7. よくある運用コマンド
概念概要: 日々の運用では、現在の操作、長時間トランザクション、インデックスメンテナンス、コレクション圧縮などの問題に対応します。MongoDBはDBAが本番問題を迅速に診断・解決するための運用コマンドセットを提供します。
運用コマンドクイックリファレンス:
| シーン | コマンド | 説明 |
|---|---|---|
| 現在の操作確認 | db.currentOp() |
長時間クエリ/デッドロックを発見 |
| 操作をキル | db.killOp(opId) |
問題操作を終了 |
| コレクション圧縮 | db.runCommand({compact:'col'}) |
断片化スペースを回収 |
| インデックス再構築 | db.col.reIndex() |
インデックス断片化を修復 |
| 接続確認 | db.serverStatus().connections |
接続数 |
| ログローテーション | db.adminCommand({logRotate:1}) |
ログローテーション |
| 強制同期 | rs.syncFrom('host:port') |
同期元を指定 |
// === 現在の操作確認 ===
db.currentOp({ "op": "query" });
// === プロセスをキル ===
db.killOp(opId);
// === コレクション圧縮 ===
db.runCommand({ compact: 'products' });
// === インデックス再構築 ===
db.products.reIndex();
// === 接続確認 ===
db.serverStatus().connections;
運用ガイドライン:
| 操作 | ロックタイプ | ブロックリスク | 推奨 |
|---|---|---|---|
compact |
排他ロック | 高い | メンテナンス時間中に実行 |
reIndex |
排他ロック | 高い | メンテナンス時間中に実行 |
killOp |
ロックなし | なし | いつでも実行可能 |
currentOp |
ロックなし | なし | いつでも実行可能 |
logRotate |
ロックなし | なし | いつでも実行可能 |
緊急トラブルシューティング手順:
db.currentOp()で長時間操作を発見db.killOp(opId)で問題操作をキルdb.serverStatus().connectionsで接続数を確認- 接続数が上限に達している場合、アプリケーションの接続プールサイズを一時的に減らすことを検討
- 事後にProfilerで根本原因を分析し、インデックス追加またはクエリ最適化
▶ サンプル:完全なバックアップポリシー + RBACセキュリティ設定
# === 1. 日次自動バックアップスクリプト(backup-daily.sh)===
#!/bin/bash
set -e
DATE=$(date +%Y%m%d)
BACKUP_DIR=/backup/mongodb/$DATE
RETENTION_DAYS=7
# 1.1 フルバックアップ(gzip圧縮)
mongodump --uri="mongodb://backup_user:SecurePass@mongo1:27017,mongo2:27017,mongo3:27017/shopdb?replicaSet=rs0" --gzip --archive=$BACKUP_DIR.gz --oplog # oplogを含める、PITR対応
# 1.2 S3にアップロード
aws s3 cp $BACKUP_DIR.gz s3://my-bucket/mongodb-backups/$DATE/
# 1.3 7日前のローカルバックアップを削除
find /backup/mongodb/ -name "*.gz" -mtime +$RETENTION_DAYS -delete
# 1.4 バックアップログを記録
echo "[$(date)] バックアップ完了: $BACKUP_DIR.gz ($(du -h $BACKUP_DIR.gz | cut -f1))" >> /var/log/mongodb-backup.log
# 1.5 crontabに追加(毎日午前2時)
# 0 2 * * * /usr/local/bin/backup-daily.sh
# === 2. 復旧訓練 ===
# 2.1 利用可能なバックアップを確認
ls -lh /backup/mongodb/
# 2.2 テスト環境に復旧
mongorestore --uri="mongodb://localhost:27017/shopdb_test" --gzip --archive=/backup/mongodb/20260701.gz --drop # 既存データを上書き
# 2.3 PITRで特定時点に復旧
mongorestore --uri="mongodb://localhost:27017" --gzip --archive=/backup/mongodb/20260701.gz --oplogReplay --pointInTime=2026-07-01T10:30:00
// === 3. 認証有効化 + RBACユーザー作成 ===
// 3.1 管理者ユーザー作成(最初に必須)
db.createUser({
user: 'root',
pwd: 'RootSecurePass!',
roles: [{ role: 'root', db: 'admin' }]
});
// 3.2 バックアップ専用ユーザー作成(最小権限)
db.createUser({
user: 'backup_user',
pwd: 'BackupPass!',
roles: [
{ role: 'backup', db: 'admin' },
{ role: 'readAnyDatabase', db: 'admin' }
]
});
// 3.3 アプリケーションユーザー作成(shopdb読み書き)
db.createUser({
user: 'app_user',
pwd: 'AppPass!',
roles: [{ role: 'readWrite', db: 'shopdb' }]
});
// 3.4 読み取り専用分析ユーザー作成
db.createUser({
user: 'analytics_user',
pwd: 'AnalyticsPass!',
roles: [{ role: 'read', db: 'shopdb' }]
});
// 3.5 TLS/SSL有効化(mongod起動パラメータ)
// mongod --tlsMode requireTLS --tlsCertificateKeyFile /etc/ssl/mongodb.pem --auth
// === 4. 監視アラート ===
// スロークエリログを有効化
db.setProfilingLevel(2, { slowms: 100 });
// スロークエリTop 10を確認
db.system.profile.find({ millis: { $gt: 100 } })
.sort({ ts: -1 })
.limit(10)
.forEach(p => print(`[${p.ts}] ${p.command.find}: ${p.millis}ms`));
// 接続数を監視
const stats = db.serverStatus();
print(`アクティブ接続: ${stats.connections.current}/${stats.connections.available}`);
// アラート閾値:current > 1000 → メールアラート
// === 5. 自動点検スクリプト ===
function dailyHealthCheck() {
print('=== MongoDB 日次健康チェック ===');
// 5.1 レプリカセットステータス
const rsStatus = rs.status();
const primary = rsStatus.members.find(m => m.stateStr === 'PRIMARY');
print(`Primary: ${primary.name}`);
// 5.2 oplogウィンドウ(上書き回避)
const oplogWindow = primary.optimeDate ? (Date.now() - primary.optimeDate.getTime()) / 1000 : 0;
print(`Oplogウィンドウ: ${Math.floor(oplogWindow / 3600)}時間`);
if (oplogWindow > 24 * 3600) print('⚠️ 警告: oplogウィンドウ > 24h');
// 5.3 インデックス使用率
const indexes = db.products.aggregate([{ $indexStats: {} }]).toArray();
const unused = indexes.filter(i => i.accesses.ops === 0);
print(`未使用インデックス: ${unused.length}`);
if (unused.length > 0) {
unused.forEach(i => print(` - ${i.name}`));
}
}
dailyHealthCheck();
出力:
TEXT 📖 参照専用日次自動バックアップ、7日保持;3層RBACユーザーアクセス制御;監視アラートでパフォーマンス問題を早期発見。
❓ よくある質問
📖 まとめ
- mongodump/mongorestore論理バックアップ
- バックアップ戦略:日次フルバックアップ + oplog継続バックアップ + Atlas PITR
- SCRAM認証 + RBACロールベース権限
- TLS/SSL暗号化
- 監視:serverStatus / dbStats / スロークエリ / $indexStats
- 運用コマンド:currentOp / killOp / compact / reIndex
📝 練習問題
- 基礎問題(⭐):
mongodumpでshopdbデータベースをバックアップし、mongorestoreで復旧。 - 基礎問題(⭐): adminユーザーとapp_userユーザーを作成し、権限を付与。
- 応用問題(⭐⭐): 日次バックアップスクリプトを実装(cron + mongodump + 圧縮 + 7日以前のデータ削除)。
- 応用問題(⭐⭐): スロークエリ分析を有効化し、Top 10スロークエリを特定。
- チャレンジ(⭐⭐⭐): 完全な運用計画作成(バックアップスクリプト + ユーザー権限 + TLS + 監視アラート)。