データベース運用管理は、監視システムの80％の読み取りと解釈で構成されています。何百ものメトリックをさまざまな方法で解釈および組み合わせて、データベースシステムとそれらを最適化する方法についての深い洞察を得ることができます。複数のデータベースシステムを実行している場合、これらのシステムの監視は非常に面倒になる可能性があります。指標の解釈と組み合わせに時間がかかる場合、これを何らかの方法で自動化できれば素晴らしいと思いませんか？
これが、ClusterControlでデータベースアドバイザーを作成した理由です。これは、メトリックを解釈および結合し、該当する場合にアドバイスを提供できる小さなスクリプトです。 MySQLについては、最も一般的に使用されるMySQLモニタリングチェックの広範なライブラリを作成しました。しかし、MongoDBについても、自由に使える幅広いアドバイザーのライブラリがあります。このブログ投稿では、あなたにとって最も重要な9つを選びました。それぞれについて詳しく説明します。
このブログ投稿で取り上げる9つのMongoDBアドバイザーは次のとおりです。
- ディスクマウントオプションの確認
- ヌマチェック
- コレクションロック率（MMAP）
- レプリケーションの遅れ
- レプリケーションウィンドウ
- シャーディングされていないデータベースとコレクション（シャーディングされたクラスターのみ）
- 認証が有効なチェック
- 認証/承認の健全性チェック
- エラー検出（新しいアドバイザー）
ディスクマウントオプションアドバイザー
ディスクを最適な方法でマウントすることが非常に重要です。 ClusterControlディスクマウントオプションアドバイザを使用すると、データディスクを日常的に詳しく調べることができます。このアドバイザでは、使用されているファイルシステム、マウントオプション、およびオペレーティングシステムのioスケジューラ設定を調査します。
ディスクがnoatimeおよびnodiratimeでマウントされているかどうかを確認します。これらを設定すると、ファイルまたはディレクトリにアクセスするたびにアクセス時間をディスクに書き込む必要があるため、ディスクのパフォーマンスが低下します。これはデータベースで継続的に発生するため、これは優れたパフォーマンス設定であり、SSDの耐久性も向上します。
ファイルシステムの場合、 xfs、などの最新のファイルシステムを使用することをお勧めします。 zfs、 ext4 またはbtrfs。 これらのファイルシステムは、パフォーマンスを念頭に置いて作成されています。 ioスケジューラーは、 noopのいずれかにすることをお勧めします または締め切り。 締め切り 何年もの間データベースのデフォルトでしたが、SSDのようなより高速なストレージのおかげで noop 最近、スケジューラーの方が理にかなっています。
ヌマチェックアドバイザー
MongoDBの場合、 NUMAを有効にします アドバイザーを確認してください。このアドバイザーは、 NUMAかどうかを確認します （Non-Uniform Access Memory）がシステムで有効になっています。この場合は、オフにします。
Non-Uniform Access Memoryが有効になっている場合、サーバーのCPUは、マシン内の他のCPUではなく、自身のメモリを直接アドレス指定することしかできません。このように、CPUは自身のメモリスペースからのみメモリを割り当てることができ、過剰に割り当てるとスワップが使用されます。このアーキテクチャは、すべてのCPUを割り当てるマルチプロセッサアプリケーションで強力なパフォーマンス上の利点がありますが、MongoDBはマルチプロセッサアプリケーションではないため、パフォーマンスが大幅に低下し、スワップの使用量が大幅に増える可能性があります。
コレクションロック率（MMAP）
MMAPとして はファイルベースのストレージシステムであり、 WiredTigerに見られるようなドキュメントレベルのロックをサポートしていません およびRocksDB。 代わりに、 MMAPの最低レベルのロック コレクションロックです。これは、コレクションへの書き込み（挿入、更新、または削除）がコレクション全体をロックすることを意味します。ロックの割合が高くなりすぎている場合は、コレクションで競合の問題があることを示しています。適切に対処しないと、書き込みスループットが大幅に停止する可能性があります。したがって、事前にアドバイザーに警告してもらうと非常に役立ちます。
MongoDB Replication Lag Advisor
セカンダリを介した読み取りのためにMongoDBをスケールアウトする場合、レプリケーションの遅延は監視するために非常に重要です。 MongoDBクライアントドライバーは、それほど遅れていないセカンダリのみを使用します。そうしないと、古いデータを提供するリスクが生じる可能性があります。
MongoDB内では、プライマリはセカンダリのレプリケーションステータスを追跡します。アドバイザはレプリケーション情報をフェッチし、レプリケーションラグを保護します。ラグが大きくなりすぎると、警告またはクリティカルステータスメッセージが送信されます。
MongoDBレプリケーションウィンドウアドバイザー
レプリケーションラグの次に、レプリケーションウィンドウは注意すべき重要なメトリックです。 MongoDB oplogは単一のコレクションであり、（プリセット）サイズが制限されています。 oplogが最後に到達し、新しいトランザクションを保存する必要がある場合、最も古いトランザクションを削除して、新しいトランザクション用のスペースを確保します。レプリケーションウィンドウは、oplog内の最も古いトランザクションと最も新しいトランザクションの間の秒数を反映します。
レプリケーションが大幅に遅れているためにマスターに追いつくことができなくなる前に、replicaSetからセカンダリを取得できる期間を知る必要があるため、このメトリックは非常に重要です。また、セカンダリが遅れを取り始めた場合、セカンダリが追いつくことができなくなるまでに、これにどれだけ耐えられるかを知っておくとよいでしょう。
MongoDBシェルでは、レプリケーションウィンドウを計算するための関数を使用できます。 ClusterControlのこのアドバイザーは、この関数を使用して同じ計算を行います。利点は、複製ウィンドウが短すぎる場合にアラートを受け取ることができることです。
SomeninesがMongoDBDBAになる-MongoDBを本番環境に導入MongoDBDownloadを無料でデプロイ、監視、管理、スケーリングするために知っておくべきことを学びましょうMongoDB Un-Sharded Databases and Collections Advisor
シャーディングされたMongoDBクラスターでは、シャーディングされていないすべてのデータベースとコレクションが、MongoDBシャードルーターによってデフォルトのプライマリシャードに割り当てられます。このプライマリシャードはデータベースとコレクションによって異なる場合がありますが、通常、これは使用可能なディスク容量が最も多いシャードになります。
シャーディングされていないデータベースまたはコレクションがあっても、クラスターにすぐにリスクが生じることはありません。ただし、アプリケーションまたはユーザーがこれらのいずれかに大量のデータを書き込み始めると、プライマリシャードがすぐにいっぱいになり、このシャードが停止する可能性があります。データベースまたはコレクションはシャーディングされていないため、他のシャードを利用することはできません。
このため、これを防ぐためのアドバイザーを作成しました。アドバイザはすべてのデータベースとコレクションをスキャンし、シャーディングされていない場合は警告します。
認証が有効なチェック
MongoDBで認証を有効にしないと、ログインしているユーザーはすべて管理者として扱われます。ユーザーの作成やバックアップの作成などの通常の管理タスクが誰でも利用できるようになったため、これは重大なリスクです。これを公開されたMongoDBサーバーと組み合わせると、最近のMongoDB身代金ハックが発生しましたが、認証を有効にするだけで、これらのケースのほとんどを防ぐことができました。
MongoDBサーバーで認証が有効になっているかどうかを確認するアドバイザーを実装しました。これは、構成でこれを設定することによって明示的に行うことも、レプリケーションキーファイルを有効にすることによって暗黙的に行うこともできます。このアドバイザが認証が有効になっていることを検出できない場合は、サーバーが危険にさらされやすいため、すぐに対処する必要があります。
認証/承認の健全性チェック
認証対応アドバイザの隣に、MongoDBでの認証と承認の両方の健全性チェックを実行するアドバイザも構築しました。
MongoDBでは、認証と承認は中央の場所に配置されませんが、データベースレベルで実行および保存されます。通常、ユーザーはデータベースに接続し、使用する予定のデータベースに対して認証を行います。ただし、適切な許可があれば、他の（無関係の）データベースに対して認証を行い、別のデータベースを利用することもできます。通常、ユーザーが別のデータベースに対して過度の権限（管理者ロールなど）を持っていない限り、これはまったく問題ありません。
このアドバイザーでは、これらの過剰な役割が存在するかどうか、およびそれらが脅威をもたらす可能性があるかどうかを確認します。同時に、パスワードが弱くて推測しやすいかどうかもチェックします。
エラー検出（新しいアドバイザ）
MongoDBでは、発生したエラーはすべてカウントまたはログに記録されます。 MongoDB内には、ユーザーのアサート、通常のアサート、警告、さらには内部サーバーの例外など、さまざまなエラーが発生する可能性があります。これらのエラーに傾向がある場合は、構成の誤りまたはアプリケーションの問題がある可能性があります。
このアドバイザーは、MongoDBエラー（アサート）の統計を調べて、これを理解します。見つかった傾向を解釈し、MongoDB環境でエラーを減らす方法についてアドバイスします！