エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント1件
- 注目コメント
- 新着コメント
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
Microsoft Azure - クラウドにおけるフォールト トレランスの問題点と解決策
レプリカ セットでの実行が必要なデータベース ノード数が同数の場合 (たとえば、1 つのレプリカ セット... レプリカ セットでの実行が必要なデータベース ノード数が同数の場合 (たとえば、1 つのレプリカ セットに対して 2 つのデータベース ノード)、MongoDB では決定者の考え方が採用されます。決定者はマスター選出時に投票サーバーとしての役割を果たします。ただし、(コストとリソースを節約するために) データベース スタック全体を実行することはありません。そこで、MongoDB レプリカ セットのデータベース ノードは 2 つで十分という形に落ち着いた場合、第 3 のノード、つまり決定者が必要になります。この決定者は、障害が発生した際に過半数ベースのマスター選出で票数を増やすためだけに配置されます。 SQL Server AlwaysOn 可用性グループでも同様の状況が発生します。この場合、新しいプライマリ ノードを選出するために過半数のノードが必要になります。投票しか実行しないメンバーの
2015/10/09 リンク