MongoDBの操作と開発のチェックリストは、データベース管理者がMongoDBの本番環境で問題が発生するのを防ぐのに役立つことを目的としています。開発チェックリストは、次のような問題に対処する必要があります...
一方、操作チェックリストはアドレス...
- ジャーナル（WiredTigerストレージエンジン）
プロジェクトを開始する前に、運用と開発のチェックリストに取り組み、本番環境でMongoDBをスムーズに運用できるようにすることをお勧めします。この記事では、MongoDBをデプロイする前の運用と開発のチェックリストについて説明します。
MongoDB操作チェックリスト
非表示になっていないすべてのレプリカメンバーセットは、ディスク、RAM、ネットワークセットアップ、CPUに関して同じようにプロビジョニングする必要があります。
Oplogサイズは、次のような運用上のニーズに対応するように適切に構成する必要があります。
- 完全な再同期の必要性を回避するために、レプリカoplogアプリケーションウィンドウは、通常のダウンタイムとメンテナンスウィンドウをカバーする必要があります。
- レプリケーションセットメンバーを復元するには、レプリカoplogウィンドウが常に必要な時間をカバーする必要があります。
本番環境には、少なくとも、ジャーナリングを有効にして実行される3つのデータ保持ノードを組み込む必要があります。さらに、書き込みは、データの可用性と耐久性を確保するために、w：「大多数」の書き込みの懸念事項を使用して発行する必要があります。
クラスター内のプライマリノードに障害が発生した場合に投票プロセスを容易にするために、デプロイメントには奇数の投票メンバーを含める必要があります。
IPの変更により構成の変更が必要になる可能性のあるIPアドレスを使用するのではなく、論理DNSホスト名を使用することをお勧めします。
すべてのMongodインスタンスは、関係するノード間でデータの通信が容易になるように、完全かつ双方向に接続する必要があります。
これは、障害が発生した場合にデータの耐久性を確保するために採用されている、ログ先行書き込みのディスクジャーナルファイル戦略です。この理由から、特に書き込みの多いワークロードを処理する場合は、すべてのインスタンスでジャーナル処理を有効にする必要があります。
ただし、データベースの状態を構成するレコードはパーティション化されたボリュームに存在するため、これはスナップショットスタイルの拡張に影響することを考慮してください。
dbPathにニュースファイルシステム（NFS）ドライブを使用しないでください。 NFSドライブは、パフォーマンスを不安定にする可能性があります。 VMwareユーザーはVMware仮想ドライブを使用することをお勧めします。
Linux / Unixユーザーの場合、XFSの使用をお勧めします。 XFSはMongoDBでより良いパフォーマンスを発揮することが知られています。
Windowsオペレーティングシステムのユーザーには、NTFSファイルシステムをお勧めします。 FATファイルシステムの使用は避けてください。
Windows Azure：TCPキープアライブ（tcp_keepalive_time）を100〜120に変更します。 AzureスタックバランサーでのTCPのギアタイムアウトは、MongoDBのアソシエーションプーリング動作に対しても中程度です
Windows Azureなどの高レイテンシストレージを備えたフレームワークでは、MongoDB 2.6.4以降のバージョンを使用します。これらのバージョンには、これらのフレームワークの実行機能拡張が組み込まれているためです。
構成サーバーを専用ハードウェアに配置して、拡張クラスターでの理想的な実行を実現します。
ハードウェアに、情報レコードを完全にメモリに保持するのに十分なRAMがあり、専用のストレージがあることを確認してください。
NTPを使用して、シャードクラスターのすべてのコンポーネントのクロックを同期します。
mongos、mongod、およびconfigサーバー間の完全な双方向ネットワークを確保します。
CNAMEを使用して、クラスターに対する構成サーバーを認識し、ダウンタイムなしで構成サーバーの名前を変更したり、番号を付け直したりできるようにします。
MongoDB Cloud Manager、ClusterControl、または別の監視フレームワークなどのツールを利用して、主要なデータベースメトリックをスクリーニングし、アラームを設定できます。指標のアラートを組み込む：
RAID10およびSSDドライブを利用して理想的なパフォーマンスを実現します。
SANと仮想化：
各mongodインスタンスがdbPathにIOPSをプロビジョニングしているか、物理ドライブまたはLUNを要求していることを確認してください。
仮想環境で実行している場合は、メモリの膨張など、動的なメモリのハイライトを回避してください。
SANは単一の失望点になる可能性があるため、すべてのコピーセットの個人を同じSANに設定することは避けてください。
MongoDBクラスターまたはレプリカセットコンポーネント間にロードバランサーを配置することは避けてください。
バックアップおよび復元プロセスの断続的なテストを計画して、タイムゲージを手元に用意し、その有用性を確認します。
NTFSの「最終アクセス時間」アップグレードを非アクティブ化することを検討してください。
Linux
RHEL / CentOSで調整されたものを利用する場合は、調整されたプロファイルをカスタマイズする必要があります。 RHEL / CentOSに付属する多数の調整済みプロファイルは、デフォルト設定での実行に悪影響を与える可能性があります。選択した調整済みプロファイルを次のようにカスタマイズします：
容量メディアの並べ替えの場合は、先読みを8〜32に設定します。
SSDドライブのnoopまたはdeadlineディスクスケジューラを利用します。
NUMAを無効にするか、vm.zone_reclaim_modeを0に設定して、ノードインターリーブを使用してmongodオカレンスを実行します。
適切なレコードハンドル（fs.file-max）、パーツpid制約（kernel.pid_max）、プロセスあたりの最大スレッド（kernel.threads-max）、およびプロセスあたりのメモリアウトライン領域の最大数を設計します（vm.max_map_count）送信用。拡張フレームワークの場合、次の値が優れた出発点になります。
fs.file-max value of 98000,
kernel.pid_max value of 64000,
kernel.threads-max value of 64000, and vm.max_map_count value of 128000正しいサイズ設定に関する重要なポイントについては、オペレーティングシステムのドキュメントを参照してください。
システムのデフォルトのTCPキープアライブが正確に設定されていることを確認します。多くの場合、値が300の場合、レプリカセットとシャードクラスターのパフォーマンスが向上します。
MongoDB開発チェックリスト
選挙が効果的に継続することを保証するために、奇数の投票者を利用します。最大7人の投票者がいます。投票する個人の数が偶数で、コストなどの制約により、別のセカンダリーを投票メンバーにすることが許可されていない場合は、奇数の投票を保証するためにアービターを含めることができます。
監視ツールを利用し、適切な書き込みの懸念を示すことで、セカンダリが最新の状態に保たれることを保証します。
MongoDBのデータには動的パターンが含まれています。コレクションはレポート構造を支持しません。これにより、反復的な改善とポリモーフィズムが促進されます。いずれにせよ、コレクションは非常に均質な構造のレコードを保持することがよくあります。
スキーマ計画がデプロイメントの並べ替えをサポートすることを保証します。水平スケーリングにシャードクラスターを利用することを計画している場合は、強力なシャードキーを組み込むようにスキーマを計画します。シャードキーは、MongoDBがデータをセグメント化する方法を決定することにより、読み取りと書き込みの実行に影響を与えます。一度設定したシャードキーは変更できません。
スキーマ計画が、無制限に長さが増加するインデックス付きクラスターに依存しないようにしてください。通常、このようなインデックス付きクラスターのコンポーネントが1000未満の場合に、最適な実行を実現できます。
スキーマを設計するときは、ドキュメントの見積もり制限を考慮してください。 BSONDocumentEstimateの制限はドキュメントあたり16MBです。より大きなレポートが必要な場合は、GridFSを使用してください。
アプリケーションが失敗したリクエストを処理することを保証し、必要に応じて再試行します。ドライバーはしません
データベース操作の実行期間を制限したい場合は、読み取りにcursor.maxTimeMS（）を使用し、書き込みにwtimeoutを使用します。
レプリカセットに、w：majoritycomposeの懸念がある少なくとも3つのデータベアリングハブが組み込まれていることを確認してください。レプリカセット全体のデータの堅牢性には、3つのデータベアリングハブが必要です。
MongoDB 3.6以降では、読み取りの懸念が「利用可能」（因果的に信頼できるセッションに関連していない場合のセカンダリに対する読み取りのデフォルトの読み取りの懸念）を利用しない限り、セカンダリは孤立したデータを返さなくなります。
>MongoDB 3.6以降、シャードレプリカセットのすべてのメンバーはチャンクメタデータを保持し、「使用可能」を利用していないときに孤立したものを除外できるようにします。そのため、「利用可能」を利用していない非ターゲットまたはブロードキャストの問い合わせは、どのメンバーでも安全に実行でき、孤立した情報を返すことはありません。
「アクセス可能な」読み取りの懸念事項は、オーバーホールされたチャンクメタデータをチェックしないため、補助メンバーから孤立したドキュメントを返す可能性があります。いずれにせよ、孤立したドキュメントの返送がアプリケーションにとって重要でない場合、「利用可能な」読み取りの懸念は、さまざまな読み取りの懸念の中で可能な限り非アクティブな読み取りを最小限に抑えます。
拡張データセットをハッシュされていない新しいシャードコレクションに埋め込むときに、チャンクを事前に分割して手動で調整します。事前分割と物理的な調整により、埋め込みスタックがシャード間で分散され、開始ロードの実行が拡張されます。
運用と開発のチェックリスト管理は、MongoDBを本番環境で使用するときに開発者が組み込む必要のある重要なステップです。これらは、実稼働中のプロジェクトのタスクのフローを強化するため、重要な考慮事項です。 MongoDBの本番環境では、本番環境のデータベースに実際のデータが保存されるため、安定した信頼性の高いデータベース機能が必要です。データの整合性は、データベースの安定性に依存します。データベースの安定性は、運用および開発チェックリストのすべての項目が本番環境の前に確実に処理されるようにすることで可能になります。