シャーディングは新規デプロイには最適でしょうか？

時には最適なこともあります。しかしながら、データセットが1つのサーバに収まる場合は、シャードのないデプロイを開始した方が良いでしょう。データセットが小さい場合は、シャーディングにはほとんど利点がないからです。

コレクションをシャーディングした後にシャードキーを変更できますか？

いいえ。

MongoDBはコレクションをシャードした後に、自動的にシャードキーを変更するサポートをしておりません。従って、適切なシャードキーを選ぶことが大変重要です。もしシャードした後にシャードキーを変更しなくてはならない際、最善の方法は次の通りです：

MongoDBからのすべてのデータを、外部フォーマットにダンプします
元のシャードされたコレクションをドロップします
より適切なシャードキーを使用してシャーディング設定をします
シャードキー範囲を事前に分割し、最初から均等に分配できるようにします
MongoDBにダンプしたデータを再度格納します

こちらもご参照ください： Shard Keys

ドキュメントがシャード間に分散されていないのはなぜですか？

チャンクの分布が一定のしきい値に達すると、バランサーがシャード間でデータの分散を開始します。こちらをご参照ください: Migration Thresholds

さらに、MongoDBではチャンク内のドキュメントが一定数を超えると、チャンクを移動することはできません。こちらをご参照ください: Maximum Number of Documents Per Chunk to Migrate および Indivisible Chunks

mongosは、シャードされたクラスタ構成の変更をどのように検知しますか？

mongosインスタンスは、シャードされたクラスタのメタデータを持つ設定データベースのキャッシュを保持します。

mongosはシャードにアクセスすることで、自身の設定データベースキャッシュを更新します。ただし、その更新タイミングはシャード構成変更と同期せず、遅延する可能性があります。mongosにキャッシュのリロードを強制するために、各々のmongosに対して直接的にflushRouterConfigcommandを実行することができます。

ログ内の writebacklistenは何を意味しますか？

ライトバックリスナーはmongodあるいはmongosプロセスに対して生存時間の長いポーリングを行い、ライトバックを中継します。これはmongod, mongosが移行後に間違ったサーバに移動していないかどうかを確認しています。ライトバックリスナーは必要に応じて正しいサーバに書き戻します。

これらのメッセージは、シャーディングインフラストラクチャの重要な部分であり、心配することではありません。

mongosは、コネクションをどのように使用しますか？

各mongosインスタンスは、シャードされたクラスタの各メンバーへのコネクションプールを維持しています。クライアントからのリクエストに応じて、プールの中から接続が割り当てられます。すなわち要求は多重化されず、パイプライン化されません。

クライアントの要求が完了すると、mongosは接続をプールに戻します。このようなプールはクライアント数が減少すると小さくなるわけではありません。結果として、mongosが(実際には使用されていない)多数のコネクションをメンバーに対して維持し続けることになります。もしmongosが使用されなくなった場合、既存の接続を閉じるためにプロセスを再起動しても問題ありません。

mongosで使用されるすべての接続プールに関する集計情報を返すには、mongoシェルをmongosに接続して、connPoolStatsコマンドを実行します：

(例)
db.adminCommand("connPoolStats");

こちらをご参照ください: UNIX ulimit Settings ドキュメントにおける、System Resource Utilization セクション