このガイドでは、WiredTigerエンジンに基づいて3つのmongoDBノードのレプリカをインストールおよび構成する方法について説明します。 MongoDBに最初に出会った人にとっては、ちょっとした便利なこともあります。
重要な説明：
- インストールする前に、最終的なアーキテクチャの理解が必要です。
- 一部のアメニティにはエンタープライズライセンスが必要です。
WiredTigerエンジンについて少し
エンジンWiredTigerは、バージョン3.4以降、MMAPの代わりにデフォルトで使用される新しいmongoDBエンジンです。 良いことは、完全にデータベースではなく、コレクションおよび個々のドキュメントのレベルでデータを処理することです。 また、上記の理由でグローバルロックの問題を修正します。これが実稼働環境で選択された理由です。
WiredTigerがデータを保存する方法の物語：
OSとコンポーネントをインストールする
私たちはあなたに都合の良いあらゆるバージョンのDebianをインストールします。私は8.6.0を使用しました。
ノードとデータベースのスケーリングを簡素化するには、lvmを使用することをお勧めします。
コンポーネントのうち、サーバーへのアクセスを容易にするために必要なのはsshのみです。
MongoDBをインストールします。
私は無料のCommunity Editionを使用しています。ガイドはそれに基づいています。
必要に応じて、Enterpiseバージョンを追加します。 彼女も回転して理解しました。
このマニュアルは、3つのサーバー（マスター、スレーブ、アービター）のオプションについて説明されています。
それでは、行きましょう：
- 最初に、公開GPGキーをインポートする必要があります。
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 0C49F3730359A14518585931BC711F9BA15703C6
- 次に、MongoDBリポジトリを追加します。
リポジトリのリストでファイルを開きます
nano /etc/apt/sources.list
リポジトリをコピーして、変更を保存します。
deb http://repo.mongodb.org/apt/debian jessie/mongodb-org/3.4 main
利用可能なパッケージのリストを更新する
sudo apt-get update
- MongoDBおよび依存パッケージをインストールします。
sudo apt-get install -y mongodb-org
3（3）サーバーについて手順を繰り返します。
これで初期設定は完了です。
それでは、mongoDBの構成に移りましょう。
サーバーの構成とレプリカセットへの追加
まず、レプリカセットとは何かを理解することから始めましょう。
レプリカセットは、マスタースレーブレプリケーションメカニズムを実装し、それらを自動的に切り替えるMongoDBサーバーのクラスターです。 これは、MongoDB開発者が推奨するレプリケーションメカニズムです。 オフへのリンク。 ドキュメント。
写真：
図に示す複製メカニズムを使用します。
マスター、2つのセカンダリおよびアービター。
順番に：
プライマリはメインのmongoDBサーバーです。
セカンダリ-リアルタイム同期を使用したデータのデータベースの正確なコピー。
アービター-最も優先度の高いセカンダリレプリカを選択するためのサーバー。サーバークラッシュの場合にメインレプリカになります。
非常に重要：
アービターは後継者の選出のみを担当し、後継者になることはできないため、アービターに最小限のリソースを提供することをお勧めします。
より重要：
技術的には、アービターなしでも生きることは可能ですが、アービターがいると、選挙が何倍も速く行われ、それに応じてダウンタイムが最小限に抑えられます。 さらに、ReplicaSet全体が失われる可能性はゼロではありません。
一次
/etc/mongod.confファイルに設定を書き込むと、私のファイルは次のようになります。
storage: engine: wiredTiger dbPath: /var/lib/mongodb journal: enabled: true systemLog: destination: file logAppend: true path: /var/log/mongodb/mongod.log replSetName: replicaname net: port: 27017 bindIp:0.0.0.0
示された変数値：
dbPathはデータベースパスです。 空の場所を指すと、そこにベースが作成されます。 バックアップを展開すると、既存のバックアップが取得されます。
ジャーナル -ジャーナリングを有効にします。
replSetNameはレプリカの名前です。 レプリカ内のすべてのノードで同一でなければなりません。
bindIp-ポート27017で接続を許可できるアドレスのリスト。
次に、構成のために、mongoDB自体を使用しました。
mongo
内部に入り、まずステータスを確認します。
rs.status()
初期ステータスは0-スタートアップでなければなりません。 ノードがレプリカのメンバーではないことを示します。
レプリカを初期化します。
プライマリノードのMongoShellで実行する
rs.initiate( { _id: "rs0", version: 1 members: [ { _id : 0, host : "<Primary server ip>:27017" } ] })
構成の確認：
rs.conf()
レプリカに追加した直後、ノードのステータスは5-Startup2になります。これは、ノードがレプリカに参加し、現在同期していることを意味します。 時間がかかる場合があります。
次のノードを追加します。
rs.add("<Secondary server ip>:27017")
アービターを追加：
rs.addArb(“<arbiter server ip>:27017”)
どちらか
rs.add(“<arbiter server ip>:27017”, true)
rs.status（）のステータスは次のようになります。
1-プライマリ
2-セカンダリ
7-アービター
優先順位
実行オプション
最初のもの：
優先度を設定する必要があります（ステータスからメンバーIDの数を取得します）：
cfg = rs.conf() cfg.members[0].priority = 2 cfg.members[1].priority = 3 cfg.members[2].priority = 1 rs.reconfig(cfg, {force : true})
優先順位番号が高いほど、プライマリノードを選択する際の優先順位自体が低くなります。
第二：
定義済みの優先度でノードを追加します。
rs.add({host: “<secondary server ip:27017”, priority: 1})
すべてのノードがアクセス可能であり、正しい優先度で設定されていることを確認します。
rs.status()
私の場合、設定とステータスは次の形式を取りました。
rs.status()
{ "set" : "< >", "date" : ISODate("2017-05-05T13:57:01.538Z"), "myState" : 2, "term" : NumberLong(1021), "syncingTo" : "<secondary server ip>:27017", "heartbeatIntervalMillis" : NumberLong(2000), "members" : [ { "_id" : 0, "name" : "<Secondary server ip>:27017", "health" : 1, "state" : 2, "stateStr" : "SECONDARY", "uptime" : 1908285, "optime" : { "ts" : Timestamp(1493992502, 1), "t" : NumberLong(1021) }, "optimeDate" : ISODate("2017-05-05T13:55:02Z"), "syncingTo" : ":27017", "configVersion" : 373058, "self" : true }, { "_id" : 1, "name" : "<Primary server ip>:27017", "health" : 1, "state" : 1, "stateStr" : "PRIMARY", "uptime" : 1688032, "optime" : { "ts" : Timestamp(1493992502, 1), "t" : NumberLong(1021) }, "optimeDate" : ISODate("2017-05-05T13:55:02Z"), "lastHeartbeat" : ISODate("2017-05-05T13:57:00.108Z"), "lastHeartbeatRecv" : ISODate("2017-05-05T13:57:00.895Z"), "pingMs" : NumberLong(0), "electionTime" : Timestamp(1492304555, 1), "electionDate" : ISODate("2017-04-16T01:02:35Z"), "configVersion" : 373058 }, { "_id" : 2, "name" : "<Arbiter server ip>:27017", "health" : 1, "state" : 7, "stateStr" : "ARBITER", "uptime" : 1680982, "lastHeartbeat" : ISODate("2017-05-05T13:56:59.812Z"), "lastHeartbeatRecv" : ISODate("2017-05-05T13:56:59.062Z"), "pingMs" : NumberLong(0), "configVersion" : 373058 } ], "ok" : 1 }
既存のレプリカにノードを追加すると、同期のためしばらくの間使用できなくなります。
これで、ReplicaSetモードでのMongoDBのインストールと構成が完了し、データベースを明確な良心で満たすことができます。
その他の便利なコマンド
チーム
プライマリをダンプしています。 プライマリノードの変更と優先度の再割り当て
/ var / lib / mongodb / -データベースファイルは次のとおりです。
ダンプからの回復：
データベースをデフォルトのディレクトリに復元します。 同じ名前のファイルがある場合、上書きされます。
指定されたディレクトリからのすべてのデータベースの回復：
単一のテーブル（コレクション）を復元します。
ダンプ作成
バックアップフォルダ内のすべてのデータベースのバックアップを作成します。
別のデータベースのバックアップを作成します。
別のテーブルのバックアップを作成します。
ルートとして実行し、指定されたディレクトリ+現在の日付に指定されたデータベースのバックアップを作成します。
rs.stepDown(60,40)
60秒-コマンドが起動されたサーバーがプライマリになることができない時間。 40秒は、新しいプライマリの再選時間です。
db.adminCommand({replSetStepDown: 30, force: 1})
30秒-プライマリシャットダウン時間と再選択。 すべてのmongoDBサーバーからのコマンド実行が許可されています。
rs.stepDown(60)
コマンドが起動されるノードは、60秒間プライマリになることはできません。
/ var / lib / mongodb / -データベースファイルは次のとおりです。
ダンプからの回復：
データベースをデフォルトのディレクトリに復元します。 同じ名前のファイルがある場合、上書きされます。
mongorestore < >
指定されたディレクトリからのすべてのデータベースの回復：
mongorestore ./Backup
単一のテーブル（コレクション）を復元します。
mongorestore --collection <> --db < > dump/
ダンプ作成
バックアップフォルダ内のすべてのデータベースのバックアップを作成します。
mongodump --out /Backup
別のデータベースのバックアップを作成します。
mongodump --db < > --out /Backup
別のテーブルのバックアップを作成します。
mongodump --db < > --collection < >--out /Backup
ルートとして実行し、指定されたディレクトリ+現在の日付に指定されたデータベースのバックアップを作成します。
sudo mongodump --db newdb --out /var/backups/mongobackups/'date +"%m-%d-%y"'
これは、基本的に、前例のないシステムを運用環境に展開した私の経験に関する全体の話です。 批判や追加があれば喜んでいます。