MongoDB: バックアップと復旧、セキュリティ、運用監視

最終更新:2026-08-26

運用監視はMongoDB本番デプロイメントの鍵—バックアップ、セキュリティ、監視を習得すれば、本番インシデントの90%を防止できます。

1. 学習内容


100%
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時間以内にサービス復旧必要
BASH
# === データベース全体をバックアップ ===
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 圧縮アーカイブから復旧
BASH
# === バックアップ全体を復旧 ===
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

ポイント解説:

  1. --dropはまずコレクションを削除してから復旧するため、本番環境では慎重に使用(バックアップ後に追加された新規データが消失する可能性)。
  2. mongorestoreへのデータ挿入はインデックス再構築をトリガーし、大規模コレクションの復旧は遅くなります。
  3. 既存データベースへの復旧時、_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対応

バックアップ戦略選択フロー:

100%
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エントリを再生することで、秒単位の時点復旧を実現します。

100%
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ポイントインタイムリカバリのハンズオン

BASH
# 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を使って複数回ハッシュ操作を行い、証明を生成、サーバーは証明が保存されたハッシュと一致するか検証します。パスワードはネットワーク上で平文送信されません。

100%
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認証

JAVASCRIPT
// === 管理者ユーザー作成 ===
db.createUser({
  user: 'admin',
  pwd: 'SecurePass123!',
  roles: [
    { role: 'userAdminAnyDatabase', db: 'admin' },
    { role: 'readWriteAnyDatabase', db: 'admin' }
  ]
});

出力:

TEXT 📖 参照専用
{ ok: 1 }
JAVASCRIPT
// === アプリケーションユーザー作成 ===
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 管理権限、スーパーユーザーではない
JAVASCRIPT
// === カスタムロール作成 ===
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設定

JAVASCRIPT
// 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({}); // ❌ 権限不足

  1. TLS/SSL暗号化

概念説明: TLS/SSL暗号化はMongoDBネットワーク通信を保護—中間者攻撃、データ盗聴、改ざんを防止します。本番環境ではTLSの有効化が必須です。特にクロスデータセンター、クロスクラウド通信では重要です。

動作原理: TLSは証明書でサーバーの身元を検証し、暗号化接続を確立します。MongoDBはX.509証明書認証(SCRAMの代替)をサポートし、相互TLS(mTLS)はクライアントとサーバー双方の身元を検証します。

暗号化レベル:

レベル 暗号化方式 保護範囲
トランスポート層 TLS/SSL ネットワーク通信(クライアント ↔ サーバー、ノード間)
ストレージ層 WiredTiger暗号化 データファイル(静的暗号化)
フィールドレベル アプリケーションレベル暗号化 機密フィールド(パスワード、ID番号など)
BASH
# === 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 無効な証明書を許可 ❌ 本番では無効化

ポイント解説:

  1. 自己署名証明書は自己ホストクラスターで使用可能、AtlasではTLSがデフォルトで有効。
  2. mTLS(相互TLS)は証明書ベース認証を有効化し、パスワードベース認証の代替となる。
  3. 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(頻繁な再起動)
JAVASCRIPT
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) データベース統計

JAVASCRIPT
db.stats();
// {
//   db: 'shopdb',
//   collections: 10,
//   objects: 1000000,
//   dataSize: 524288000,
//   storageSize: 268435456,
//   indexes: 20,
//   indexSize: 52428800
// }

(3) スロークエリ分析

概念説明: スロークエリはMongoDBパフォーマンス問題の主要な指標です。パフォーマンス最適化の標準プロセスは、Profilerを使って閾値を超えるクエリをログに記録し、実行計画とインデックス使用状況を分析することです。

プロファイリングレベル 説明 パフォーマンス影響
0 オフ なし
1 スロークエリのみ 非常に低い
2 全操作をログ 中程度(デバッグのみ)
JAVASCRIPT
// === スロークエリログを有効化(>100ms)===
db.setProfilingLevel(2, { slowms: 100 });

// === スロークエリを確認 ===
db.system.profile.find({ millis: { $gt: 100 } })
  .sort({ ts: -1 })
  .limit(10);

(4) インデックス使用統計

JAVASCRIPT
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') 同期元を指定
JAVASCRIPT
// === 現在の操作確認 ===
db.currentOp({ "op": "query" });

// === プロセスをキル ===
db.killOp(opId);

// === コレクション圧縮 ===
db.runCommand({ compact: 'products' });

// === インデックス再構築 ===
db.products.reIndex();

// === 接続確認 ===
db.serverStatus().connections;

運用ガイドライン:

操作 ロックタイプ ブロックリスク 推奨
compact 排他ロック 高い メンテナンス時間中に実行
reIndex 排他ロック 高い メンテナンス時間中に実行
killOp ロックなし なし いつでも実行可能
currentOp ロックなし なし いつでも実行可能
logRotate ロックなし なし いつでも実行可能

緊急トラブルシューティング手順:

  1. db.currentOp()で長時間操作を発見
  2. db.killOp(opId)で問題操作をキル
  3. db.serverStatus().connectionsで接続数を確認
  4. 接続数が上限に達している場合、アプリケーションの接続プールサイズを一時的に減らすことを検討
  5. 事後にProfilerで根本原因を分析し、インデックス追加またはクエリ最適化

▶ サンプル:完全なバックアップポリシー + RBACセキュリティ設定

BASH
# === 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
JAVASCRIPT
// === 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ユーザーアクセス制御;監視アラートでパフォーマンス問題を早期発見。

❓ よくある質問

Q mongodumpはホットバックアップですか?
A はい、mongodumpはサービス停止を必要としません。ただし、大規模コレクションのバックアップはパフォーマンスに影響するため、オフピーク時間帯の実行を推奨します。
Q RBACはパフォーマンスに影響しますか?
A ほぼ影響ありません。RBACはメモリ内で権限をチェックします。
Q 本番監視はどうすべき?
A MongoDB Atlas(組み込み監視機能)または Prometheus + mongo_exporter(自己ホスト)を使用。

📖 まとめ


📝 練習問題

  1. 基礎問題(⭐): mongodumpshopdbデータベースをバックアップし、mongorestoreで復旧。
  2. 基礎問題(⭐): adminユーザーとapp_userユーザーを作成し、権限を付与。
  3. 応用問題(⭐⭐): 日次バックアップスクリプトを実装(cron + mongodump + 圧縮 + 7日以前のデータ削除)。
  4. 応用問題(⭐⭐): スロークエリ分析を有効化し、Top 10スロークエリを特定。
  5. チャレンジ(⭐⭐⭐): 完全な運用計画作成(バックアップスクリプト + ユーザー権限 + TLS + 監視アラート)。
Web-Tutorial.com

Web-Tutorial 技術チーム

複数の開発者によって共同維持されているプログラミングチュートリアルプラットフォーム。各チュートリアルは専門分野の開発者が執筆・レビューしています。正確で信頼性の高いコンテンツを目指しています — 問題を見つけた場合はお知らせください。

100%