galife

MongoDB でシャードクラスタ環境を構築する

今回は「シャードクラスタの構築方法」についてまとめます。「ハッシュシャード」と「レンジシャード」の違いについても触れています。

概要
シャードクラスタの構築
シャードクラスタの動作確認
- mongoシェルコマンド
- Node.js MongoDB Driver

概要

まずは「シャードクラスタ構成」の基本的なイメージを以下に載せます。シャード環境ではデータ保存されている場所に直接アクセスするのではなく、ルーターを経由して操作します。

設定サーバー: レプリカセット。どのシャードにデータが保存されているかといった情報を保存しているサーバー。
シャード: レプリカセット。実際にデータを保存しているサーバー。
ルーター: アプリサーバー上で動作させる。設定サーバーから保存先を取得、シャードへのアクセスを行うサーバー。

「ハッシュシャード」では「シャードキー」の「ハッシュ値」を利用してデータを分散保存します。単調増加するようなデータの場合、ハッシュシャードの分散化は効果を発揮します。

では、そんな「ハッシュシャード」を構築していきましょう！

シャードクラスタの構築

今回作成する環境の概要を以下に載せます。実運用として最低限の構成を想定したものになっています。ただし、物理サーバーは1台としたいのでインスタンスを必要数（10台分）作成するため、ポート番号を振り分けて識別するようにします。

もしテスト環境として最低限の構成とするのであれば、ルーター1台、シャード1台、設定サーバー1セット（レプリカセット）の組み合わせで最低5台必要です。

さて、これから早速構築に入っていきますが、大まかな手順は次のようになっています。

フォルダ準備
設定サーバー構築
シャードサーバー構築
ルーター構築

以下でそれぞれについて詳しく見ていきましょう。

フォルダ準備

必要なフォルダやファイルを準備していきます。今回は以下のようなフォルダやファイルを準備しておきます。サーバーごとにフォルダを切っていますが、ログだけは同じ場所に出すようにします。

C:\work\MongoDB\shard
│  
├─config-1
│  │  mongod.config-1.cfg
│  │  
│  └─data
├─config-2
│  │  mongod.config-2.cfg
│  │  
│  └─data
├─config-3
│  │  mongod.config-3.cfg
│  │  
│  └─data
├─shard1-1
│  │  mongod.shard1-1.cfg
│  │  
│  └─data
├─shard1-2
│  │  mongod.shard1-2.cfg
│  │  
│  └─data
├─shard1-3
│  │  mongod.shard1-3.cfg
│  │  
│  └─data
├─shard2-1
│  │  mongod.shard2-1.cfg
│  │  
│  └─data
├─shard2-2
│  │  mongod.shard2-2.cfg
│  │  
│  └─data
├─shard2-2
│  │  mongod.shard2-3.cfg
│  │  
│  └─data
├─router
│      mongos.cfg
└─log

設定サーバー構築

レプリカセットを構成します。

各サーバーに設定ファイルを作成

以下のサンプルを参考に設定サーバー用のコンフィグファイルを作成していきます。

mongod.config-1.cfg

systemLog:
  destination: file
  logAppend: true
  path: C:\work\MongoDB\shard\log\mongod.config-1.log
storage:
  dbPath: C:\work\MongoDB\shard\config-1\data
  journal:
    enabled: true
replication:
  replSetName: "config-rs"
sharding:
  clusterRole: configsvr
net:
  bindIpAll: true
  port: 8001

引数	説明
systemLog.path	出力ログファイル名を指定します。
storage.dbPath	データファイル保存先フォルダを指定します。
replication.replSetName	任意のレプリカセット名を指定します。今回は `"config-rs"` とします。
sharding.clusterRole	設定サーバーは `configsvr` 固定です。
net.port	今回はポート番号で識別するので個別に設定します。

各サーバーを起動

コマンドプロンプトを必要数（今回だと3つ）立ち上げて設定サーバーを起動していきます。
```
mongod --config "./mongod.config-1.log"
```
任意の設定サーバーへ接続

新しくコマンドプロンプトを立ち上げて任意のサーバーへ接続します。以下のサンプルでは1台目のサーバー（config-1）へ接続します。
```
mongo --host 127.0.0.1:8001
```

レプリカセットを初期化

rs.initiate() で初期化します。

 > rs.initiate({
  _id: "config-rs",
  configsvr: true,
  members: [
    { _id: 0, host: "127.0.0.1:8001" },
    { _id: 1, host: "127.0.0.1:8002" },
    { _id: 2, host: "127.0.0.1:8003" },
  ]
})

必要に応じて状態を確認

rs.status() でレプリカセットが認識していることを確認します。
```
PRIMARY > rs.status()
```

シャードサーバー構築

シャードサーバーは2台用意します。以下の手順は1セット分の手順なので、2セット目もサーバー名を変えて準備します。

各サーバーに設定ファイルを作成

以下のサンプルを参考にシャードサーバー用のコンフィグファイルを作成していきます。

mongod.shard1-1.cfg

systemLog:
  destination: file
  logAppend: true
  path: C:\work\MongoDB\shard\log\mongod.shard1-1.log
storage:
  dbPath: C:\work\MongoDB\shard\shard1-1\data
  journal:
    enabled: true
replication:
  replSetName: "shard1-rs"
sharding:
  clusterRole: shardsvr
net:
  bindIpAll: true
  port: 27011

設定	説明
systemLog.path	出力ログファイル名を指定します。
storage.dbPath	データファイル保存先フォルダを指定します。
replication.replSetName	任意のレプリカセット名を指定します。今回は `"shard1-rs"` とします。
sharding.clusterRole	シャードサーバーは `shardsvr` 固定です。
net.port	今回はポート番号で識別するので個別に設定します。

各サーバーを起動

コマンドプロンプトを必要数（今回だと3つ）立ち上げて設定サーバーを起動していきます。
```
mongod --config "./mongod.shard1-1.log"
```
任意の設定サーバーへ接続

新しくコマンドプロンプトを立ち上げて任意のサーバーへ接続します。以下のサンプルでは1台目のサーバー（shard1-1）へ接続します。
```
mongo --host 127.0.0.1:27011
```

レプリカセットを初期化

rs.initiate() で初期化します。一度 config というオブジェクトに設定を記述してから

 > rs.initiate({
  _id: "shard1-rs",
  members: [
    { _id: 0, host: "127.0.0.1:27011" },
    { _id: 1, host: "127.0.0.1:27012" },
    { _id: 2, host: "127.0.0.1:27013" },
  ]
})

必要に応じて状態を確認

rs.status() でレプリカセットが認識していることを確認します。
```
PRIMARY > rs.status()
```

ルーター構築

ルーター（ mongos ）もサーバーなので設定ファイルを準備して起動します。シャードサーバーは mongos 経由で登録します。

ルーター用設定ファイルを作成

mongos.cfg

systemLog:
  destination: file
  logAppend: true
  path: C:\work\MongoDB\shard\log\mongod.router.log
sharding:
  configDB: config-rs/127.0.0.1:8001,127.0.0.1:8002,127.0.0.1:8003
net:
  bindIpAll: true
  port: 8000

引数	説明
systemLog.path	出力ログファイル名を指定します。
sharding.configDB	設定サーバーのレプリカセットへのパスを指定します。指定方法は以下のような形式で指定します。 `[レプリカセット名]/[サーバー1]:[ポート1],[サーバー2]:[ポート2], ...`
net.port	今回はポート番号で識別するので特定できるポートを設定します。

ルーターを起動

新しくコマンドプロンプトを起動して mongos でルーターを起動します。
```
mongos --config "./mongos.cfg"
```
ルーターへ接続

上記ルーターのコマンドプロンプトとは別のコマンドプロンプトでルーターへ接続します。
```
mongo --host 127.0.0.1:8000
```

シャードサーバーを登録

sh.addShard() でシャードサーバーを登録していきます。今回は "shard1-rs" と "shard2-rs" の2つを登録します。

mongos > sh.addShard("shard1-rs/127.0.0.1:27011,127.0.0.1:27012,127.0.0.1:27013")

sh.addShard() コマンド

シャードレプリカセットをシャードクラスタに追加します。

sh.addShard( url )

引数	型	説明
url	string	設定サーバーのレプリカセットへのURLを指定します。指定は以下のようなURLを指定します。 `[レプリカセット名]/[サーバー1]:[ポート1],[サーバー2]:[ポート2], ...`

データベースを登録

今回は "sample" データベースをシャードクラスタに登録します。

mongos > sh.enableSharding("sample")

sh.enableSharding() コマンド

指定したデータベースのシャーディングを有効化します。自動的にシャード化は行わないので sh.shardCollection() でシャード化するコレクションを指定する必要があります。

sh.enableSharding( database )

引数	型	説明
database	string	シャード化するデータベース名を指定します。データベース名はクォート（ `"` または `'` ）で囲みます。

シャード化するコレクションを登録

今回は "sample.users" コレクションに対して "email" をシャードキーとしてシャードできるように登録します。ハッシュシャードかレンジシャードかはこの設定が異なるだけです。

ハッシュシャードで登録したい場合、以下のようにハッシュキー "email" に対して "hashed" を指定して登録します。

mongos > sh.shardCollection("sample.users", { email: "hashed" })

レンジシャードの場合、以下のようにハッシュキー "email" に対して "1" または "-1" を指定して登録します。以下のサンプルでは昇順になるような指定をしています。

mongos > sh.shardCollection("sample.users", { email: 1 })

sh.shardCollection() コマンド

シャードキーを指定してコレクションをシャード化します。

sh.shardCollection( namespace, key, unique, options )

引数	型	説明
namespace	string	シャード化したいコレクションを以下の形式で指定します。 `[データベース名].[コレクション名]`
key	object	シャードキーをオブジェクト形式指定します。ハッシュシャードの場合は "hashed" 固定です。 `{ [シャードキー]: "hashed" }` レンジシャードの場合は "1"(昇順) または "-1"(降順) を指定します。 `{ [シャードキー]: 1 }` `{ [シャードキー]: -1 }`
unique	boolean	オプション。 `true` を指定すればシャードキーにユニーク制約をつけられます。デフォルトは `false` 。ハッシュシャードの場合は必ず `false` で `true` が指定できないので注意。
options	object	オプション。

ハッシュ設定が有効化されたことを確認

sh.status() を実行してハッシュキーが設定されていることを確認します。
```
mongos > sh.status()
```

シャードクラスタの動作確認

基本は「ルーター (mongos) へ接続して操作」です。

mongoシェルコマンド

接続

接続は mongos サーバーに接続します。
```
mongo --host 127.0.0.1:8000
```
書き込み

通常の書き込み方と同じ方法で書き込めます。シャードキーを含んでいないと書き込みエラーになる点に注意します。
```
mongos > use sample
mongos > db.users.insert({ email: "tanaka@sample.com", name: "tanaka" })
```
読み込み

mongosに接続していれば通常通りの操作で読み取れます。
```
mongos > use sample
mongos > db.users.find()
```
切断

何も考えず exit 。
```
mongos > exit
```

Node.js MongoDB Driver

Node.js MongoDB Driver でも「ルーター (mongos) へサクセスして操作」です。以下のサンプルコードはサーバー接続して、データ書き込み、読み込みをしています。

var MongoClient = require("mongodb").MongoClient;

var URL = "mongodb://127.0.0.1:8000/sample";

MongoClient.connect(URL, (error, client) => {
  var db = client.db("sample");
  db.collection("users").insertOne(
    { email: "suzuki@sample.com", name: "suzuki" }
  ).then(() => {
    db.collection("users").find().toArray((error, docs) => {
      console.log(docs);
    });
  });
});

今回は「シャードクラスタの構築方法」についてまとめました。ポイントは以下の通りです。参考になったでしょうか？

必要な役割は「設定サーバー」「シャード」「ルーター」の３つ
シャードへのアクセスは必ず「ルーター」経由

本記事がお役に立っていると嬉しいです！！

MongoDB でトランザクションを利用する方法

今回は MongoDB 4.0 で追加された「トランザクション」の利用方法についてまとめます。

概要
前提準備
実装例
動作確認

概要

2018年6月27日にリリースされた MongoDB 4.0 には、新機能として「マルチドキュメントトランザクション」が追加されました。基本の設計は非正規化したドキュメント構造ですが、どうしても分割されてしまうドキュメントが出ないとは言い切れません。そんな時に「トランザクション」はデータの整合性を保つうえで重要な機能になります。

では、以下で実際にトランザクションを利用した Node.js からのDB操作のサンプル実装および動作確認をしていきます。

前提準備

利用するモジュールは以下のものになります。サーバーサイドとクライアントサイドは対になっていますので、両方が利用したい機能を含んだバージョン以上でないと使えません。トランザクション機能が使うためには、サーバーは MongoDB 4.0 以上、クライアントは MongoDB Node.js Driver 3.1 以上を利用します。

さて、これでトランザクションが利用できるのかと思いきや…実は「トランザクション」が利用できるのは「レプリカセット構成」か「シャーディング構成」の時だけでした。つまり「スタンドアローン構成」で「トランザクション」は利用できません。なので、以下の記事を参考に「レプリカセット構成」を準備します。

※補足

ちなみに、スタンドアローン構成で実行すると以下のようなエラーが出ます。

"Transaction numbers are only allowed on a replica set member or mongos"

また、公式ドキュメントにも以下のような記述がります。このことから、トランザクションはレプリカセットないしシャーディングのための機能であることが読み取れます。

Starting in version 4.0, MongoDB provides the ability to perform multi-document transactions against replica sets.

MongoDB Manual - Release Notes for MongoDB 4.0

実装例

前述の前提（MongoDB 4.0、MongoDB Node.js Driver 3.1、レプリカセット構成）が準備できている状況で、以下のようなソースを実行するとトランザクションを利用したDB操作が可能になります。

index.js

var MongoClient = require("mongodb").MongoClient;
var url = "mongodb://127.0.0.1:27001,127.0.0.1:27002,127.0.0.1:27003/";
var options = {
  family: 4,
  useNewUrlParser: true,
  replicaSet: "rs0"
};

MongoClient.connect(url, options, (error, client) => {
  var session = client.startSession();
  var db = client.db("sample");

  session.startTransaction();

  db.collection("users")
    .insertOne({ name: "tanaka" }, { session })
    .then((results) => {
      return session.commitTransaction();
    }).catch((error) => {
      return session.abortTransaction();
    }).then(() => {
      client.close();
    });
});

L2, 5, 6: URLの指定方法が MongoDB Node.js Driver 3.1 から変更されています。 useNewUrlParser: true を使う場合、接続URLに ?replicaSet="rs0" のように記述しただけではレプリカセットに接続できないので注意です。オプション replicaSet: "rs0" を加える必要があります。
L10: セッションの開始は client.startSession() です。
L16: トランザクションが利用できるのはドキュメント操作全般（aggregate, find, delete, insert, update など）です。対象となる具体的な操作は MongoDB Manual - Transactions : Transactions and Operations に記述があります。
L18, 20: ドキュメント操作が成功したら session.commitTransaction() を、失敗したら session.abortTransaction() を呼びます。また、このとき return をつけて非同期が完了してから次へ進むようにしてあげます。こうしないとコミットする前に client.close() が呼ばれてセッションが破棄されてしまいます。

動作確認

実行は通常の Node.js アプリケーション実行と同じで以下のようなコマンドでできます。

node "./index.js"

データ登録されているかどうかは実際に MongoDB へ接続して確認します。接続先はレプリカセットのプライマリへ接続します。

mongo 127.0.0.1:27001

接続できれば以下のコマンドでデータ登録できていることを確認します。

PRIMARY > use sample
PRIMARY > db.users.find()

正しいコードだと本当にトランザクションが有効なのかわからないですが、コーディング途中でエラーを含んでいたりすると登録されていないことから有効になっていることが確認できます。いろいろと試してみると良いと思います。

今回は「MongoDBにおけるトランザクションの利用補法」についてまとめました。ポイントは以下の通りです。

使うモジュールは以下のバージョン以上のもの
- MongoDB Enterprise 4.0 +
- MongoDB Node.js Driver 3.1 +
レプリカセット構成またはシャーディング構成で利用可能

参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

MongoDB のシャーディング概要

今回は「MongoDB のシャーディング」についてまとめます。

スケーリング
シャーディングとは
シャードクラスタ
シャードキー
チャンク
シャーディングの制約
シャードコレクションと非シャードコレクション
データ分散方法

スケーリング

いきなりシャーディングの話を始める前にそもそものスケーリングについて触れておきたいと思います。

一般的なスケーリングの話として、システム規模が大きくなるとスケーリング（拡張）が必要になってきます。スケーリング方法は大きく2種類あり、具体的には「垂直スケーリング」と「水平スケーリング」があります。

垂直スケーリング: CPUやRAM、ストレージをより高性能なものに取り換えていく方法です。スケーリングは簡単ですが、そもそものCPUやメモリに限界があるのである程度で性能限界が来てしまいます。
水平スケーリング: データセットでシステム分割を行い、複数サーバーから並列で読み取れるようにする方法です。総合的な性能は垂直スケーリングするよりも良くなりますが、スケールすればするほど複雑さが増すため管理が難しくなります。

シャーディングとは

シャーディングとは「データを複数サーバーに分散展開させる仕組み」で、その特徴から「水平スケーリング」を実現する仕組みです。 …と言われてもいまいちピンとこないですが。。

シャーディングを行うことで大きく３つの利点（「読み書き処理が速くなる & 性能を上げやすい」「ストレージが増設しやすい」「可用性が上がる」）があります。それぞれ詳しくは以下で見ていきますが、MongoDB では標準機能としてシャーディング（水平スケーリング）をサポートします。

読み書き

データをシャードクラスタに分散して保存しておくことで、読み書き処理（ファイルI/O）を分散して処理できるようになります。ファイル読み書き（ファイルI/O）は遅い処理なので、これが分散化することでより高速な読み書きができるようになります。また、読み書きの負荷が上がってきたとしてもサーバーを増やしていくことで水平スケーリングできます。

ストレージ

シャードクラスタには断片データを分散して保存します。データ量が増えた際もサーバーを増やしていくことで水平スケーリングできます。

高可用性

シャードクラスタでは部分読み書きができます。読み書きができなかった場合、操作ができるシャードサーバーから取得してくることもできます。

シャードクラスタ

MongoDB におけるシャーディングは以下の３コンポーネント（シャード、ルーター、設定サーバー）で成り立っています。それぞれの関係性と説明は以下の通りです。

シャード: シャードサーバーにはコレクションを分割した断片データ（チャンク）を保存します。シャードサーバーはレプリカセットで構成することができます。
ルーター: mongos はクエリルーターとしてアプリケーションからシャードクラスタへのインターフェースを提供します。シャードクラスタへアクセスする際は必ず mongos 経由でアクセスします。シャード化していないコレクションだったとしても必ず mongos 経由でアクセスします。
設定サーバー: シャードクラスタ設定に関するメタデータを保存します。どのシャードサーバーにデータがあるかなどもこのサーバーに保存されます。 MongoDB 3.4 以降では設定サーバーをレプリカセットで構成します。

シャードキー

「シャードキー」はデータを分散してシャードサーバーへ保存する際にキーとして利用する情報のことを言います。 MongoDB は「シャードキー」を用いてコレクション内ドキュメント分散化を行います。

以下の図は x をシャードキーとして分散化している簡単な例になります。

「シャードキー」についておさえておきたいポイントは以下の3点です。

すべてのドキュメントに存在する不変なフィールドまたはフィールド群で構成します。
一度シャードキーを決めて分散化を行ってしまうと、再度シャードキーを変更することはできません。
シャーディングするコレクションはシャードキーを含むインデックスが必要です。

もちろんシャードキーの選択によって性能、効率、拡張性に大きな影響が出るのは言うまでもありません。シャードキーの選択が不適切であれば、前述の通りシャードサーバーに偏りが発生して非効率な動作となることもあり得ます。

チャンク

前述の通り、MongoDBは「シャードキー」の値でデータ保存の分散化を行いますが、このとき「チャンク」と呼ばれる塊ごとにグルーピングしてシャードサーバーへ分散保存します。 MongoDB はこの「チャンク」がシャードクラスタ内でバランスよく分散化されるよう、自動的に移動を行います。

チャンクへ分割およびそれを各シャードへ分散保存するイメージは以下のような図になります。

シャードデータに対する操作の制約

シャーディングしたデータ（シャードデータ）に対する操作にはいくつか制約があります。その具体的なものを以下にとりあげます。

groupコマンドが使えない。
代わりに aggregate ないし MapReduce を利用します。
updateOne や deleteOne など単一ドキュメント操作の場合はシャードキーか _id の指定が必要です。
シャードキーか _id が含まれていない場合エラーになります。
シャーディングしたコレクションにはユニークインデックスが必要。

シャードコレクションと非シャードコレクション

MongoDBではシャード化するコレクションとシャード化しないコレクションを混在させることができます。シャード化するコレクションはシャードクラスタに分散して保存されますが、シャード化しないコレクションはプライマリシャードに保存されます。

データ分散方法

シャード化する際の分散方法は「ハッシュシャード」と「レンジシャード」の2通りがあります。

ハッシュシャード

シャードキーのハッシュ値を利用してデータ分散を行います。ハッシュを利用したシャードの場合、シャードキーの値が近かったとしてもチャンクがバラバラになりやすい特徴があります。つまり、シャードキーが単調変化するようなケースで分散化させやすい分散化方法です。逆にデータが分散化しやすいため、データ構造や取得方法によってはブロードキャスト操作が増える懸念もあります。

レンジシャード

シャードキーのレンジによってデータ分散を行います。ハッシュシャードと異なり、シャードキーの値が近ければ同じチャンク上に存在する可能性が高くなる分散化方法です。シャードキーの選定が不適切であればせっかくシャードという分散化技術を利用しようとしているにもかかわらず特定サーバーに負荷が偏ってしまうような懸念があります。

今回は「MongoDB のシャーディング」についてまとめました。

参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

MongoDB の特定レプリカセットメンバーに対して強制再同期を行う方法

今回は「MongoDBのレプリカセットメンバーに対して強制再同期をする方法」についてまとめます。

再同期が必要なケース
再同期する際の注意点
自動再同期を行う手順

再同期が必要なケース

レプリカセットの中でデータ不整合が起こっている状態のとき、再同期が必要になってきます。具体的なケースとしては以下のいずれかの場合にデータ再同期が必要になります。

"stale"な状態（時間当たりの更新処理が多すぎてoplog容量を超えてしまいプライマリと完全な同期ができなくなった状態）になった場合
新規メンバーとして追加する場合

再同期する際の注意点

データ再同期する場合、大量のデータ移動が発生するためネットワーク通信帯域を使います。通信帯域を使うとMongoDB全体のパフォーマンスが下がってしまうので、実行するタイミングは利用率が低い時間帯を選んで実行するように注意します。

自動再同期を行う手順

dbPath に指定されたフォルダ配下にファイルが存在しない状態で mongod を起動すれば自動的に再同期が始まります。具体的には以下のような手順で行えば再同期が始まります。

データ再同期したい稼働中のサーバーを停止

mongoシェルコマンドで以下を実行することで安全に停止させます。
```
> use admin
> db.shutdownServer()
```
dbPath配下のフォルダ・ファイルをすべて削除

コマンドプロンプト上で以下のコマンドを実行し、dbPath配下のファイルやフォルダをすべて削除します。
```
set DBPATH=C:\mongodb\server2\data
del "%DBPATH%" /f /s /q
for /d %a in (%DBPATH%\*) do (rmdir /s /q "%a")
```

mongod を起動

mongo --config "C:\mongodb\server2\mongod.server2.cfg"

今回は「MongoDBのレプリカセットメンバーに対して強制再同期をする方法」についてまとめました。参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

参考記事

MongoDB - Resync a Member of a Replica Set

MongoDB を CentOS にインストールする方法

今回は「MongoDB を CentOS にインストールする方法」についてまとめます。

動作環境
インストール
初期設定
動作確認

動作環境

今回は Linux も CentOS へ MongoDB をインストールする方法についてまとめます。対象とする環境は以下のような環境です。

CentOS 7

MongoDBをインストールする際に関係するフォルダやファイルは以下のような構成になっています。

/usr/bin
  ├mongo
  ├mongod
  ├mongos
    ...
/etc
  └mongod.conf
/var/lib/mongo
  ├ジャーナル、データファイルなど
    ...
/var/log/mongodb
  └mongod.log

インストール

yum を使ってインストールします。

リポジトリを追加

$ sudo vi /etc/yum.repo.d/mongodb-enterprise.repo

mongodb-enterprise.repo

[mongodb-enterprise]
name=MongoDB Enterprise Repository
baseurl=https://repo.mongodb.com/yum/redhat/$releasever/mongodb-enterprise/3.6/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-3.6.asc

MongoDB をインストール

$ sudo yum install -y mongodb-enterprise

再起動
```
$ shutdown -r now
```

初期設定

Windowsと違い、基本的にはデフォルトのままで問題ない設定になっています。以下では一部設定を変更する場合を想定して、その修正方法を取り上げます。

データ保存ディレクトリ

MongoDB はデフォルトだと /data/db にデータを保存します。 yum でインストールした場合、設定ファイル（ mongod.conf ）が生成され、/var/lib/mongo へ保存されるよう設定されてるので、そもそもインストール完了時点でMongoDBのデフォルトとは異なる場所へデータが保存される設定になっています。

もしまったく異なる場所にデータを保存したいのであれば、該当フォルダを作成、権限変更をしたのち、設定ファイルを修正します。フォルダ作成は以下のコマンドで実行します。設定ファイルの修正は以下のように sorage.dbPath を設定します。

フォルダ作成

$ mkdir -p /usr/local/mongo/server/data
$ chown -R mongod /usr/local/mongo 
$ chgrp -R mondog /usr/local/mongo

設定修正

/etc/mongod.conf

storage:
  dbPath: /usr/local/mongo/server/data

再起動
```
$ shutdown -r now
```

ポート開放

デフォルトだと MongoDB インスタンスへ外部からアクセスできないので、ポート開放してアクセスできるようにします。 MongoDB はデフォルトでだれでもアクセス可能な仕組みとなっているので、外部からアクセスできるようにする場合はあわせて MongoDB 自体のアクセス制御も検討してください。

$ firewall-cmd --zone=public --add-port=27017/tcp --permanent

設定ファイル (mongod.conf)

yum でインストールした場合、デフォルトでは /etc/mongod.conf が作成されます。このファイルへ必要な設定を追記することで設定変更が行えます。

デフォルトからあまり変更することもないですが…、ログ(systemLog)、データ保存先(storage)、ネットワーク(net) あたりを見直しておきます。

/etc/mongod.conf

systemLog:
  destination: file
  logAppend: true
  logRotate: "rename"
  path: /var/log/mongodb/mongod.log
storage:
  dbPath: /var/lib/mongo/
net:
  port: 27017
  bindIp: 127.0.0.1
  bindIpAll: true

自動起動設定

yum でインストールした場合、デフォルトでは自動起動が有効化されています。インストール後に再起動すれば自動で mongod が立ち上がっていると思います。

CentOS 7 で mongod サービスの設定確認、有効化、無効化は以下のコマンドで実行できます。 CentOS 7 は CentOS 6 からサービスの実行方法が変わったようで、コマンドも少し変わっているようです。

自動起動の確認

$ /usr/bin/systemctrl is-enabled mongod

自動起動の有効化

$ /usr/bin/systemctrl enable mongod

自動起動の無効化

$ /usr/bin/systemctrl disable mongod

動作確認

MongoDBの起動 (mongod)

基本的には起動時に自動実行されているので起動済みのハズですが、コマンド実行して起動する場合は以下のコマンドで起動します。

$ sudo service mongod start

MongoDBへ接続 (mongo)

MongoDB サーバー (mongod) が起動していれば mongo シェルで接続できます。以下のコマンドで MongoDB へ接続、切断してみます。

接続

$ mongo

切断

MongoDB Enterprise > exit

MongoDBの終了 (mongod)

意図的にサービス終了する場合、以下のコマンドで終了できます。

$ sudo service mongod stop

今回は「MongoDB を CentOS にインストールする方法」についてまとめました。参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

MongoDB のレプリカセットで特定メンバーをプライマリに昇格させる方法

今回は「MongoDBの特定レプリカセットメンバーを強制的にプライマリサーバーにする方法」についてまとめます。

前提状況
優先度の調整で変更する
コマンドで変更する

前提状況

今回は以下のような状況（ _id: 1 がプライマリ、 _id: 0 および _id: 2 はセカンダリ）で、 _id: 0 をプライマリにする方法を見ていきます。

変更する方法は以下の2通りが考えられます。

優先度の調整で変更する
コマンドで変更する

「優先度調整」は設定変更なので、サーバースペックが異なるなど恒久的にあるサーバーを優先的にプライマリサーバーとしたい場合に有効な手段になります。「コマンド」は一時的な変更なので動作確認やテストなどの用途での利用になるかと思います。

優先度の調整で変更する

mongoシェルコマンドの rs.config() および rs.reconfig() を利用して優先度を変更することで特定メンバーをプライマリに昇格させます。設定変更なので一度実行すると基本的に特定サーバーがプライマリサーバーに昇格するようになります。例えば、一度ダウンしてレプリカセットから外れた後、再び復活してレプリカセットへ参加した際にセカンダリとして参加してすぐプライマリへ昇格する動作を行います。

プライマリサーバーへ接続

rs.reconfig() はプライマリサーバー上でしか実行できないので、プライマリサーバーへ接続します。
```
mongo --host 127.0.0.1:8002
```
現在の設定を取得
```
PRIMARY> config = rs.config()
```

設定値を修正

PRIMARY> config.members[0].priority = 2
PRIMARY> config.members[1].priority = 1
PRIMARY> config.members[2].priority = 1

修正した設定値を適用
```
PRIMARY> rs.reconfig(config)
```
一度 mongoシェル接続を切断
```
PRIMARY> exit
```
10秒程度待って(プライマリサーバーの変更処理が終わるのを待って)任意のサーバーへ接続
```
mongo --host 127.0.0.1:8001
```

変更結果を確認

PRIMARY> rs.status()
{
  ...
  "members" : [
    {
      "_id" : 0,
      "name" : "127.0.0.1:8001",
      "health" : 1,
      "state" : 1,
      "stateStr" : "PRIMARY",
      ...
    },
    {
      "_id" : 1,
      "name" : "127.0.0.1:8002",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      ...
    },
    {
      "_id" : 2,
      "name" : "127.0.0.1:8003",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      ...
    }
  ],
  ...
}

コマンドで変更する

mongoシェルコマンドの rs.freeze() および rs.stepDown() を利用して変更することができます。コマンドそれぞれの動作概略は以下の通りです。

rs.freeze()
指定された時間（秒）の間、プライマリに昇格しなくなります。
rs.stepDown()
指定された時間（秒）の間、セカンダリに降格して次のプライマリサーバー選出を行います。

以下では実際に上記コマンドを利用してプライマリサーバーに変更する手順を載せます。

プライマリにしたくないサーバーへ接続
```
mongo --host 127.0.0.1:8003
```
rs.freeze() を実行してプライマリ昇格を抑止
```
SECONDARY> rs.freeze(120)
```
mongoシェル接続を切断
```
SECONDARY> exit
```
現在のプライマリサーバーへ接続
```
mongo --host 127.0.0.1:8002
```
rs.stepDown() を実行してセカンダリに降格
```
PRIMARY> rs.stepDown(120)
```
一度 mongoシェル接続を切断
```
PRIMARY> exit
```
10秒程度待って(プライマリサーバーの変更処理が終わるのを待って)任意のサーバーへ接続
```
mongo --host 127.0.0.1:8001
```

変更結果を確認

PRIMARY> rs.status()
{
  ...
  "members" : [
    {
      "_id" : 0,
      "name" : "127.0.0.1:8001",
      "health" : 1,
      "state" : 1,
      "stateStr" : "PRIMARY",
      ...
    },
    {
      "_id" : 1,
      "name" : "127.0.0.1:8002",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      ...
    },
    {
      "_id" : 2,
      "name" : "127.0.0.1:8003",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      ...
    }
  ],
  ...
}

今回は「MongoDBの特定レプリカセットメンバーを強制的にプライマリサーバーにする方法」についてまとめました。ポイントは以下の通りです。

優先度変更は恒久的な対応
コマンド変更は一時的な対応

参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

MongoDB の oplog ファイルサイズを変更する方法

今回は「MongoDB の oplog ファイルサイズを変更する方法」についてまとめます。

概要
変更手順

概要

oplogファイルサイズの変更は replSetResizeOplog コマンドで変更できます。

基本的には現状確認、検討、変更、データ再同期の手順です。実施する際はセカンダリサーバーから実施するようにします。データ再同期はサイズ縮小する場合だけですが、サーバー停止を伴うので実施には要注意です。

それでは以下で詳しい手順を見ていきます。

変更手順

現在のサイズを確認

現在の設定を確認してどの程度に変更するかを考えます。

レプリカセットのセカンダリサーバーへ接続
```
mongo --host 127.0.0.1:8002
```

rs.printReplicationInfo()コマンドでoplogサイズ確認

レプリケーションに関する情報を取得、oplogサイズを確認します。

SECONDARY> rs.printReplicationInfo()

以下のような応答が返ってきますので、 oplog size を確認します。

configured oplog size:   2244.146240234375MB
log length start to end: 9152215secs (2542.28hrs)
oplog first event time:  Sat Mar 03 2018 23:42:09 GMT+0900
oplog last event time:   Sun Jun 17 2018 21:59:04 GMT+0900
now:                     Sun Jun 17 2018 21:59:11 GMT+0900

oplogサイズ変更

レプリカセットのセカンダリサーバーへ接続
```
mongo --host 127.0.0.1:8002
```
replSetResizeOplogコマンドでoplogサイズ変更

サイズはメガバイトで指定します。以下のサンプルコードでは16G (= 16000MB) に設定しています。
```
SECONDARY> db.adminCommand({ replSetResizeOplog: 1, size: 16000 })
```
上記を繰り返しすべてのサーバーのoplogサイズを変更

データ再同期

oplogサイズを小さくする場合、データ不整合が発生する可能性があるためデータ再同期させる必要があります。

データ再同期したい稼働中のサーバーを停止

mongoシェルコマンドで以下を実行することで安全に停止させます。
```
SECONDARY> use admin
SECONDARY> db.shutdownServer()
```
dbPath配下のフォルダ・ファイルをすべて削除

コマンドプロンプト上で以下のコマンドを実行し、dbPath配下のファイルやフォルダをすべて削除します。
```
set DBPATH=C:\mongodb\server2\data
del "%DBPATH%" /f /s /q
for /d %a in (%DBPATH%\*) do (rmdir /s /q "%a")
```

mongod を起動

mongo --config "C:\mongodb\server2\mongod.server2.cfg"

今回は「MongoDB の oplog ファイルサイズを変更する方法」についてまとめました。ポイントは以下の通りです。

oplogファイルサイズ変更は db.adminCommand({ replSetResizeOplog: 1, size: 16000 }) で実行可能。
セカンダリサーバーから順に変更する。
oplogファイルサイズを小さくする場合はデータ再同期が必要。

参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

参考記事

MongoDB - Change the Size of the Oplog

MongoDB のレプリカセットへ Node.jsドライバーを使ってアクセスする方法

今回は「MongoDB のレプリカセットにNode.jsドライバを使ってアクセスする方法」についてまとめます。

接続する
読み書きする

接続する

MongoDBのレプリカセットも接続さえできてしまえばほぼ終わりです。ここではその基本となる接続文字列、読み込み設定、書き込み設定についてまとめます。

Node.jsドライバーでMongoDBへ接続する場合、 MongoClient.connect() を利用するので、その引数にどのような値を与えるとよいか、が要です。

接続文字列 (url)

ここでは MongoClient.connect() の第1引数に指定する接続文字列の設定方法についてみていきます。

MongoDBの接続文字列は以下のような構成になっています。

mongodb://[username:password@]host1[:port1][,host2[:port2],...[,hostN[:portN]]][/[database][?options]]

基本は host1, host2, ... というように接続先ホスト名を列挙して指定します。また、 options としてレプリカセット ?replicaSet=<レプリカセット名> を指定します。もし、レプリカセットが認証を有効にしているのであれば username 、 password および database を指定します。

例えば、レプリカセットメンバーが 127.0.0.1:8001 、 127.0.0.1:8002 、 127.0.0.1:8003 で、レプリカセット名が rs0 、認証が有効でユーザー名/パスワードが test/test で、認証先データベースが test 出会った場合、以下のようなURLになります。

mongodb://test:test@127.0.0.1:8001,127.0.0.1:8002,127.0.0.1:8003/test?replicaSet=rs0

読み込み設定 (options)

MongoClient.connect() の第2引数 options のうち、レプリカセットの読み込みに関するオプションを見ていきます。関係するのは readPreference の1つのみです。

readPreference

Read Preference 設定では、どのサーバーから優先的にデータ読み込みするかを設定します。設定できる値は以下のような5種類です。

設定値	説明
PRIMARY	デフォルトモード。プライマリサーバーから取得します。
PRIMARY_PREFERRED	ほとんどの場合はプライマリサーバーから取得しますが、プライマリサーバーにアクセスできない場合はセカンダリサーバーから取得します。
SECONDARY	セカンダリサーバーから取得します。
SECONDARY_PREFERRED	ほとんどの場合はセカンダリサーバーから取得しますが、セカンダリサーバーにアクセスできない場合はプライマリサーバーから取得します。
NEAREST	レプリカセットの種類に関わらず、レイテンシーが最小のサーバーから取得します。

書き込み設定

MongoClient.connect() の第2引数 options のうち、レプリカセットの書き込みに関するオプションを見ていきます。関係するのは w 、 j 、 wtimeoutの3つです。

w オプションでは何台目まで書き込みを保証するかを設定します。

設定値	説明
<number>	指定した台数まで書き込まれることを保証します。
"majority"	投票権のあるサーバーの過半数に書き込まれることを保証します。

ジャーナルへの書き込みまで保証するかどうかを設定します。

設定値	説明
true	ディスクへの書き込みまで行います。
false	デフォルト。メモリ上への書き込みのみを保証します。

wtimeout

書き込み応答のタイムアウト設定です。指定した時間内に応答がなければ書き込み失敗と判断して後続の処理を続けられるようにします。

設定値	説明
<number>	書き込みをタイムアウトにする時間（ミリ秒）を指定します。設定する場合は1より大きな値を指定します。 0を指定した場合、タイムアウト処理を行いません。

読み書きする

実際に上記設定を用いてレプリカセットへ書き込みを行うコードを載せます。タイトルは「読み書き」と書いていますが接続できれば関係ないのでここでは「書き込み」のサンプルコードを掲載します。

index.js

var { MongoClient, ReadPreference } = require("mongodb");

var usr = "test";
var pwd = "test";
var authDb = "test";
var hosts = [
  "127.0.0.1:8001",
  "127.0.0.1:8002",
  "127.0.0.1:8003"
];
var URL = `mongodb://${usr}:${pwd}@${hosts.join(",")}/${authDb}?replicaSet=rs0`;

var options = {
  w: "majority",
  wtimeout: 3000,
  j: true,
  readPreference: ReadPreference.NEAREST
};

MongoClient.connect(URL, options, (err, client) => {
  if (err) {
    console.log(err);
    return;
  }
  var db = client.db("test");
  db.collection("orders").insertMany([
    { datetime: "2018-01-12", item: "apple", quantity: 8 },
    { datetime: "2018-01-12", item: "grapefruit", quantity: 3 },
    { datetime: "2018-01-13", item: "strawberry", quantity: 4 },
    { datetime: "2018-01-14", item: "orange", quantity: 8 },
    { datetime: "2018-01-15", item: "apple", quantity: 6 },
    { datetime: "2018-01-15", item: "grapefruit", quantity: 5 },
    { datetime: "2018-01-17", item: "pear", quantity: 2 },
    { datetime: "2018-01-17", item: "apple", quantity: 9 },
    { datetime: "2018-01-20", item: "orange", quantity: 10 },
    { datetime: "2018-01-21", item: "strawberry", quantity: 2 },
    { datetime: "2018-01-21", item: "banana", quantity: 3 },
    { datetime: "2018-01-22", item: "strawberry", quantity: 2 }
  ]).then((docs) => {
    console.log(docs);
  }).catch((err) => {
    console.log(err);
  }).then(() => {
    client.close();
  });
});

今回は「MongoDB のレプリカセットにNode.jsドライバを使ってアクセスする方法」についてまとめました。ポイントは以下の通りです。

接続先ホストは列挙する
MongoClient.connect() で接続設定

参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

参考記事

MongoDB - Connection String URI Format

MongoDB のレプリカセットへ mongoシェルを使ってアクセスする方法

今回は「MongoDB のレプリカセットにmongoシェルを使ってアクセスする方法」についてまとめます。

接続する
読み書きする
- プライマリサーバーで読み書き
- セカンダリサーバーで読取

接続する

何はともあれサーバーへの接続から見ていきます。

サーバーを指定して接続する

もっとも単純な接続は接続先サーバーを指定した接続で、サーバーIPが 127.0.0.1:8001 であれば以下のようなコマンドで接続できます。

C:\work>mongo --host 127.0.0.1:8001

単一ノードの場合と基本的に接続方法は変わりません。接続できれば接続先サーバーが PRIMARY か SECONDARY かなどがわかる表記があります。

MongoDB shell version v3.6.2
connecting to: mongodb://127.0.0.1:8001/
MongoDB server version: 3.6.2
MongoDB Enterprise rs0:PRIMARY>

プライマリサーバーを探す

レプリカセットで書き込みができるのは唯一プライマリサーバーのみなので、書き込みたい場合はプライマリサーバーを探す必要があります。

任意のサーバーへ接続したのち、 rs.status() を実行すると接続中レプリカセットの各メンバーステータスを確認できます。

PRIMARY> rs.status()

上記コマンドを実行すると以下のような応答を取得できます。 stateStr に各サーバーがどの状態で稼働しているかが記載されているので、この中からプライマリを探します。

{
  "set" : "rs0",
  "date" : ISODate("2018-02-27T05:13:26.672Z"),
  "myState" : 1,
  "term" : NumberLong(18),
  "heartbeatIntervalMillis" : NumberLong(2000),
  "optimes" : {
    "lastCommittedOpTime" : {
      "ts" : Timestamp(1519708406, 1),
      "t" : NumberLong(18)
    },
    "readConcernMajorityOpTime" : {
      "ts" : Timestamp(1519708406, 1),
      "t" : NumberLong(18)
    },
    "appliedOpTime" : {
      "ts" : Timestamp(1519708406, 1),
      "t" : NumberLong(18)
    },
    "durableOpTime" : {
      "ts" : Timestamp(1519708406, 1),
      "t" : NumberLong(18)
    }
  },
  "members" : [
    {
      "_id" : 0,
      "name" : "127.0.0.1:8001",
      "health" : 1,
      "state" : 1,
      "stateStr" : "PRIMARY",
      "uptime" : 144787,
      "optime" : {
        "ts" : Timestamp(1519708406, 1),
        "t" : NumberLong(18)
      },
      "optimeDate" : ISODate("2018-02-27T05:13:26Z"),
      "electionTime" : Timestamp(1519563637, 1),
      "electionDate" : ISODate("2018-02-25T13:00:37Z"),
      "configVersion" : 7,
      "self" : true
    },
    {
      "_id" : 1,
      "name" : "127.0.0.1:8002",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      "uptime" : 144759,
      "optime" : {
        "ts" : Timestamp(1519708406, 1),
        "t" : NumberLong(18)
      },
      "optimeDurable" : {
        "ts" : Timestamp(1519708406, 1),
        "t" : NumberLong(18)
      },
      "optimeDate" : ISODate("2018-02-27T05:13:26Z"),
      "optimeDurableDate" : ISODate("2018-02-27T05:13:26Z"),
      "lastHeartbeat" : ISODate("2018-02-27T05:13:26.413Z"),
      "lastHeartbeatRecv" : ISODate("2018-02-27T05:13:25.208Z"),
      "pingMs" : NumberLong(0),
      "syncingTo" : "127.0.0.1:8001",
      "configVersion" : 7
    },
    {
      "_id" : 2,
      "name" : "127.0.0.1:8003",
      "health" : 1,
      "state" : 7,
      "stateStr" : "ARBITER",
      "uptime" : 144780,
      "lastHeartbeat" : ISODate("2018-02-27T05:13:26.431Z"),
      "lastHeartbeatRecv" : ISODate("2018-02-27T05:13:22.188Z"),
      "pingMs" : NumberLong(0),
      "configVersion" : 7
    }
  ],
  "ok" : 1,
  "operationTime" : Timestamp(1519708406, 1),
  "$clusterTime" : {
    "clusterTime" : Timestamp(1519708406, 1),
    "signature" : {
      "hash" : BinData(0,"0vruFBe4bYLFcuHiqSa9gtgUhRo="),
      "keyId" : NumberLong("6518666083560325121")
    }
  }
}

ユーザー名とパスワードを指定して接続する

レプリカセットがアクセス制御を有効化している場合、ユーザー名とパスワードおよび認証先データベースを指定して接続する必要があります。認証の仕方は2通りあり、「接続時にユーザー名とパスワードを指定する方法」と「接続後にユーザー名とパスワードを指定する方法」があります。

例えば、ユーザー名「user」、パスワード「password」、認証先データベース「test」でサーバー「127.0.0.1:8001」へ接続する場合、それぞれどのように接続するか見ていきます。

接続時にユーザー名とパスワードを指定する方法

接続時にユーザー名、パスワード、認証情報を渡して接続

C:\work>mongo --host 127.0.0.1:8001 -u user -p password --authenticationDatabase test

接続後にユーザー名とパスワードを指定する方法

単純に任意のサーバーへ接続します。

C:\work>mongo --host 127.0.0.1:8001
MongoDB shell version v3.6.2
connecting to: mongodb://127.0.0.1:8001/
MongoDB server version: 3.6.2
MongoDB Enterprise rs0:PRIMARY>

接続で来たら認証したいデータベースへスイッチ（use）して認証（db.auth()）を行います。

MongoDB Enterprise rs0:PRIMARY> use test
switched to db admin
MongoDB Enterprise rs0:PRIMARY> db.auth("user", "password")
1
MongoDB Enterprise rs0:PRIMARY>

アクセス制御が有効化されている場合に必要な権限

データベース自身に対する読み書き権限

read
readWrite

レプリカセットに対する操作権限

clusterAdmin
clusterManager
clusterMonitor

読み書きしたいデータベースに対して readWrite があり、レプリカセットの状態確認に clusterMonitor があればとりあえずは事足りるかと思います。

読み書きする

レプリカセットで書き込みができるのは唯一プライマリサーバーのみです。セカンダリサーバーでは読み取りのみになります。

プライマリサーバーで読み書き

プライマリサーバーは単一ノードの場合と同じで通常通りのコマンド実行ができます。

PRIMARY> db.orders.find()

PRIMARY> db.orders.insert({ name: "orange", amount: 4 })

セカンダリサーバーで読取

セカンダリサーバーで読取操作を行う場合、あらかじめセカンダリサーバーへ接続した後、読取設定（rs.slaveOk()）を行う必要があります。

SECONDARY> rs.slaveOk()

上記コマンドを一度実行した後は通常通り読み取り操作が利用できます。

SECONDARY> db.orders.find()

今回は「MongoDB のレプリカセットにmongoシェルを使ってアクセスする方法」についてまとめました。ポイントは以下の通りです。

rs.status() でプライマリサーバーを探す
セカンダリサーバーで読取する場合は rs.slaveOk() を実行する

参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

MongoDB のレプリカセットでアクセス制御（ユーザー認証）を有効化する方法

今回は「MongoDB のレプリカセットに対してアクセス制御（ユーザー認証）を有効化する方法」についてまとめます。

概要
キーファイルを用いたアクセス制御

概要

レプリカセットに対するアクセス制御を有効化するためには内部認証（レプリカセットメンバー間の認証）を有効化する必要があります。内部認証の方法は以下の2通りがあります。

キーファイル (チャレンジレスポンス認証、SCRAM-SHA-1)
x.509（公開鍵認証、TLS/SSL）

今回はお手軽に実現できる「キーファイル」を用いた内部認証の有効化およびアクセス制御の有効化を行います。

キーファイルを用いたアクセス制御

管理ユーザーの追加

アクセス制御を有効化する前に管理ユーザーを作っておきます。

アクセス制御無効化状態でMongoDBのすべてのレプリカセットメンバーを起動
```
mongod --config "C:\mongodb\server1\server1.cfg"
```
プライマリサーバーに接続

mongoシェルでプライマリサーバーに接続します。プライマリサーバーが不明な場合、 rs.status() でプライマリサーバーを確認して接続しなおします。
```
mongo --host 127.0.0.1:8001
```
管理ユーザーを追加

以下のコマンドのように、adminデータベースへスイッチしたのち、管理ユーザーを作成します。

レプリカセットコマンドである rs.xxxx を利用できるのは clusterMonitor というロールのようですが、ここでは clusterAdmin ロールを追加しています。
```
PRIMARY> use admin
PRIMARY> db.createUser({
  user: "admin",
  pwd: "password",
  roles: [
    "userAdminAnyDatabase",
    "dbAdminAnyDatabase",
    "clusterAdmin"
  ]
})
```

MongoDBの設定変更（アクセス制御有効化）

キーファイルの作成

キーファイルは Base64セットの文字列（[a-zA-Z0-9/+] の64種類）を使った 6～1024文字のファイルになります。ランダム文字列生成した後、Base64変換して1024文字までにカットするような方法で良いかと思います。 Linux使えるなら openssl を使った以下のコマンドでランダム文字列を生成できます。
```
$ openssl rand -base64 1024 > keyfile
```
キーファイルは以下のようなBase64文字列で構成される内容になります。以下はサンプルなので、必ず自前で生成してください。ランダム文字列生成するツールを使うとラクかもしれません。

keyfile
```
rMvhlWEIzktbhXN+rcTV43z2YKPGsd8YHNNuOVpZLW9bIPx1MaAeGTVullFVY4A5
B0zRpKLXcB347T/m278LK3BNBynB3mVpoe1pPmSYVjpBmo3LhsDKXywb8dU7UrBl
9bgh4NZfNaBcYykuoQsiloWNP5QtMquBymF2bh+1s+aJpvkq1FzAhsJvwcGeILBc
gnBOwZAsDXlE0M1hr0zvsulkyvFDgE2UcS+2tm4yZPKNDygA2HCcXqJypa9L2f1J
dC83SLNxbN4MkeE+NeY3ZE+LFUqTyvb827VhXfCX+S+TpD5h/otiS1GiQnTcBiSB
fYrMhLsOFPU9UYc705XDw48m
```
ランダム文字列生成ツール
キーファイルをレプリカセットメンバーへ配布

任意の方法で各レプリカセットメンバーに作成したキーファイルを配置します。今回はサンプルとして以下のような場所に配置したものとします。
```
C:\mongodb
  │
  ├ \server1
  │  └ keyfile
  │     
  ├ \server2
  │  └ keyfile
  │     
  └ \server3
      └ keyfile
```

すべてのレプリカセットメンバー設定に認証設定を追加

MongoDB設定ファイル（mongod.config）に対して security.authorization を有効化し、 security.keyFile 設定を追加します。

mongod.config

systemLog:
  destination: file
  path: C:\mongodb\server1\log\mongod.server1.log
  logAppend: true
  logRotate: "rename"
storage:
  dbPath: C:\mongodb\server1\data
security:
  authorization: enabled
  keyFile: C:\mongodb\server1\keyfile
replication:
  replSetName: "rs0"
net:
  bindIpAll: true
  port: 8001

すべてのレプリカセットメンバーを再起動

各サーバーに mongoシェルでログインして以下のコマンドを実行してサーバーを停止させます。サーバーを停止させる際、ロールバックを避けるため、プライマリサーバーが最後になるよう停止していきます。

停止
```
SECONDARY> use admin
SECONDARY> db.shutdownServer()
```
開始
```
mongod --config "C:\mongodb\server1\server1.cfg"
```

通常ユーザーの追加

プライマリサーバーに管理ユーザーで接続

mongoシェルでプライマリサーバーに管理ユーザーで接続します。プライマリサーバーが不明な場合、 rs.status() でプライマリサーバーを確認して接続しなおします。

接続方法は「接続時にユーザー名とパスワードを指定する方法」と「接続語にユーザー名とパスワードを指定する方法」の2通りがあります。
- MongoDB へ接続と同時に認証する
```
mongo --host 127.0.0.1:8001 -u admin -p Passw0rd --authenticationDatabase admin
```
- MongoDB へ接続、接続後に認証する
```
mongo --host 127.0.0.1:8001
```
```
PRIMARY> use admin
PRIMARY> db.auth('admin', 'Passw0rd')
```

通常ユーザーを追加

データベースを指定して通常ユーザーを追加します。

PRIMARY> use test
PRIMARY> db.createUser({
  user: "test",
  pwd: "test",
  roles: [{
    role: "readWrite",
    db: "test"
  }]
})

ユーザー名とパスワードを指定してデータベースへ接続

プライマリサーバーに通常ユーザーで接続

mongoシェルでプライマリサーバーに通常ユーザーで接続します。

接続方法は管理ユーザーで接続するのと同じで、「接続時にユーザー名とパスワードを指定する方法」と「接続語にユーザー名とパスワードを指定する方法」の2通りがあります。
- MongoDB へ接続と同時に認証する
```
mongo --host 127.0.0.1:8001 -u test -p test --authenticationDatabase test
```
- MongoDB へ接続、接続後に認証する
```
mongo --host 127.0.0.1:8001
```
```
PRIMARY> use test
PRIMARY> db.auth(test, test)
```

今回は「MongoDB のレプリカセットに対してキーファイルを用いたアクセス制御（ユーザー認証）を有効化する方法」についてまとめました。ポイントは以下の通りです。

MongoDBのレプリカセットでアクセス制御は「キーファイル」と「x.509」の2種類が選べる
アクセス制御有効化前に管理ユーザーを作成しておく

参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

参考記事

MongoDB の既存レプリカセットからメンバーを削除する方法

MongoDB の既存レプリカセットにメンバーを追加する方法

今回は「MongoDBの既存レプリカセットに新しいメンバーを追加する方法」についてまとめます。

前提・制約
レプリカセットへの追加手順

前提・制約

MongoDBのレプリカセットにおけるそもそもの制約も含めて追加しようとしている新しいMongoDBサーバーが以下の前提や制約を満たしていることを確認しておきます。

有効なレプリカセットが既に存在している
追加したい新しいMongoDBは有効なレプリカセットにアクセス可能な状態
追加するメンバーを含めて投票権は7台以下になっている
追加するメンバー含めてレプリカセット全体が50台以下になっている

レプリカセットへの追加手順

レプリカセットに追加

MongoDBを起動

mongod --config "C:\mongodb\server4\mongod4.cfg"

プライマリサーバーに接続

プライマリサーバーが不明な場合、任意のサーバーに接続して rs.status() を実行することでプライマリサーバーがどれか確認できます。
```
mongo --host 127.0.0.1:8001
```
レプリカセットに追加する新しいメンバー情報を作成

優先度(priority）、隠し（hidden）、遅延（slaveDelay）など必要な設定があれば合わせて準備しておきます。
```
PRIMARY> member = { host: "127.0.0.1:8004" }
```
アービターの場合、以下のように arbiterOnly を設定しておきます。
```
PRIMARY> member = { host: "127.0.0.1:8004", arbiterOnly: true }
```
レプリカセットに新規メンバーを追加
```
PRIMARY> rs.add(member)
```

追加したメンバーのデータ確認

レプリカセットメンバーに追加されると自動的にデータ同期が始まります。データ同期されていることを以下の手順で確認します。

追加したメンバーへ接続
```
mongo --host 127.0.0.1:8004
```
参照設定変更

セカンダリ接続しただけだとデータ参照できないので、以下の mongoシェルを実行して参照できるようにします。
```
SECONDARY> rs.slaveOk()
```
データ確認

以下はサンプルとして test データベースの users コレクションを参照するようなコードです。存在する任意のコレクションを確認してみてください。
```
SECONDARY> use test
SECONDARY> db.users.find()
```

新規メンバーのデータを同期

基本的にはデータは自動的に同期されますが、何かしらの理由でうまくいかなかった場合、以下の手順で強制的に再同期させます。

追加した新規メンバーを停止

追加した新規メンバーに mongoシェルでログインし、以下のコマンドを実行します。
```
> use admin
> db.shutdownServer()
```
追加したMongoDBサーバーの dbPath 配下のファイル・フォルダを削除

追加した後に再同期を自動的におこなえるようにするため、 dbPath 配下のファイル・フォルダは削除しておきます。
追加した新規メンバーを起動

コマンドプロンプト上で以下のコマンドを実行します。
```
mongo --config "C:\mongo\server4\server4.cfg"
```

今回は「MongoDBの既存レプリカセットに新しいメンバーを追加する方法」についてまとめました。参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

MongoDB のレプリカセットメンバー設定の初期化および変更する

今回は「MongoDB のレプリカセットメンバー設定」について「設定を初期化/変更する方法」と「変更できる内容」まとめます。

レプリカセット設定を初期化する
レプリカセット設定を変更する
主なレプリカセット設定例

レプリカセット設定を初期化する

レプリカセット構築時に行う初期化処理は mongo シェルで任意のメンバーに接続したのち、 rs.initiate() で初期化を行います。

任意のMongoDBレプリカセットメンバーへ接続
```
mongo --host 127.0.0.1:8001
```

初期設定オブジェクトを作成

> config = {
   _id : "rs0",
   members: [
      { _id: 0, host: "172.0.0.1:27001" },
      { _id: 1, host: "172.0.0.1:27002" },
      { _id: 2, host: "172.0.0.1:27003", arbiterOnly; true },
   ]
}

レプリカセットを初期化
```
> rs.initiate(config)
```

レプリカセット設定を変更する

設定変更の手順は基本的に以下の4ステップで行います。以下では「優先度」を変更する方法をサンプルに手順を載せています。いずれも mongoシェル上で実施します。

設定変更を行うと、プライマリサーバーは降格して、クライアントからの接続が切断されます。この処理に10～20秒かかるので、設定変更はメンテナンス期間に実施するようにします。

任意のMongoDBレプリカセットメンバーへ接続
```
mongo --host 127.0.0.1:8001
```
現在の設定を取得
```
> config = rs.config()
```

設定を変更

> config.members[0].priority = 1
> config.members[1].priority = 2
> config.members[2].priority = 2

変更した設定を適用
```
> rs.reconfig(config)
```

主なレプリカセット設定例

レプリカセットメンバーの設定には以下のような項目があります。

config = {
  ...
  members: [
    {
      _id: <int>,
      host: <string>,
      arbiterOnly: <boolean>,
      buildIndexes: <boolean>,
      hidden: <boolean>,
      priority: <number>,
      tags: <document>,
      slaveDelay: <int>,
      votes: <number>
    },
    ...
  ]
  ...
}

以下ではよくある設定パターンを例に取り上げます。

プライマリにならないようにする
隠しメンバーにする
遅延メンバーにする
投票権のないメンバーにする
アービターにする

プライマリにならないようにする

優先度（Priority）を 0 に設定することで、フェイルオーバー時にプライマリサーバーにならなくなります。設定例は以下のようになります。

> config = rs.config()
> config.members[2].priority = 0
> rs.reconfig(config)

隠しメンバーにする

優先度（Priority）を 0 、隠し（hidden）を true に設定します。

> config = rs.config()
> config.members[2].priority = 0
> config.members[2].hidden = true
> rs.reconfig(config)

遅延メンバーにする

優先度（Priority）を 0 、隠し（hidden）を true 、遅延時間（slaveDelay）に遅延させたい時間（秒）を設定します。以下のサンプルでは1時間遅延させて反映するような遅延メンバー設定になっています。

遅延メンバーを利用する場合、遅延時間が長くなればなるほど oplog サイズが大きくなるので、oplog サイズが十分大きなサイズに設定されるよう注意が必要です。

> config = rs.config()
> config.members[2].priority = 0
> config.members[2].hidden = true
> config.members[2].slaveDelay = 3600
> rs.reconfig(config)

投票権のないメンバーにする

投票権（votes）のないメンバーは読み取り専用サーバーで、プライマリになれないサーバーです。

そのため、投票権（votes）が 0 のメンバーは必ず優先度（priority）も 0 にします。逆に、優先度（priority）が 1以上のメンバーは必ず投票権（votes）に 1 を設定します。投票権は1つのレプリカセットで7つまでで奇数表となるよう設定する必要があるので投票権の設定時には制約が満たされていることを確認するよう注意します。

> config = rs.config()
> config.members[2].priority = 0
> config.members[2].votes = 0
> rs.reconfig(config)

アービターにする

アービターサーバーは投票権だけあるサーバーです。優先度（Priority）は 1 、アービター（arbiterOnly）を true に設定します。以下は通常のセカンダリ（優先度が1以上で投票権がある状態）に対する設定を前提に記載しています。

> config = rs.config()
> config.members[2].arbiterOnly = true
> rs.reconfig(config)

今回は「MongoDB のレプリカセットメンバー設定」についてまとめました。参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

MongoDB で 2台構成のレプリカセットを構築する方法

今回は「MongoDB で 2台構成のレプリカセットを作成する方法」についてまとめます。

…いきなりですが、MongoDB で 2台構成のレプリカセットを作ることはできません。低スペックで構いませんので必ず3台構成にする必要があります。

概要
レプリカセットの構築
- レプリカセットメンバーの準備
- レプリカセットの初期化
レプリカセットの動作確認

概要

今回は物理2台サーバーでレプリカセットを構築する方法について実際のコードを交えながら見ていきます。 …が、先に述べた通りMongoDBにおけるレプリカセットは最小構成が3台なので、物理2台の場合もう1台追加する必要があります。追加するサーバーはデータを持たないインスタンスのみが稼働するサーバーで良いので、スペックの低いサーバー（アプリケーションサーバーや管理サーバーなど）でも問題ありません。このデータを保持せず投票権だけを持つサーバーをアービターサーバーと呼びます。 アービターをプライマリやセカンダリに同居させるのも、冗長性の観点で意味がないので行わないでください。

今回は以下の図のようなサーバー3台構成（プライマリ1台、セカンダリ1台、アービター1台）のMongoDBレプリカセットを構築していきます。

今回は動作確認をお試しで行いたいので、以下の制約をつけた環境でのサンプルになります。

1台の物理マシンの中に上記3インスタンスを構築
認証制御は行わない

どちらかというと本番向けというよりは開発環境向けのデータベースサーバー構築になります。

レプリカセットの構築

今回はテスト用として物理1台の中に3台分のMongoDBインスタンスを作成するサンプルです。実運用だと先述の通り「冗長性を持たせたい高スペック2サーバーそれぞれに1インスタンス（プライマリ、セカンダリ）、低スペックな1サーバーに1インスタンス（アービター）」になるはずなので、一部設定は読み替えていただければと思います。

レプリカセットメンバーの準備

各インスタンス用にフォルダ・ファイルを作成

C:\mongodb
  │
  ├ \server1
  │  ├ \data
  │  ├ \log
  │  └ mongod.srver1.cfg
  │     
  ├ \server2
  │  ├ \data
  │  ├ \log
  │  └ mongod.server2.cfg
  │     
  └ \server3
      ├ \data
      ├ \log
      └ mongod.server3.cfg

各インスタンスの設定ファイル（mongod.serverN.cfg）を修正

1サーバー中に複数インスタンス生成しているため、ポート番号を分けています。 1サーバー1インスタンスであればポートはすべて同じ（27017 など) でも問題ないです。

レプリカセット名（replSetName）はすべて共通（今回は rs0 ）で設定しておきます。また、開発環境向けであれば bindIpAll 設定を入れておくとバインドIPを列挙しなくてよいので設定が簡単です。プロダクション向けは bindIp を面倒でも設定しておくほうが良いと思いますが…。 アービターサーバーにはファイル保存しないので storage.journal.enabled: false を設定しておきます。

mongod.srver1.cfg
```
systemLog:
  destination: file
  path: C:\mongodb\server1\log\mongod.srver1.log
  logAppend: true
  logRotate: "rename"
storage:
  dbPath: C:\mongodb\server1\data
replication:
  replSetName: "rs0"
net:
  bindIpAll: true
  port: 8001
```
mongod.server2.cfg
```
systemLog:
  destination: file
  path: C:\mongodb\server2\log\mongod.server2.log
  logAppend: true
  logRotate: "rename"
storage:
  dbPath: C:\mongodb\server2\data
replication:
  replSetName: "rs0"
net:
  bindIpAll: true
  port: 8002
```
mongod.server3.cfg
```
systemLog:
  destination: file
  path: C:\mongodb\server3\log\mongod.server3.log
  logAppend: true
  logRotate: "rename"
storage:
  dbPath: C:\mongodb\server3\data
  journal:
    enabled: false
replication:
  replSetName: "rs0"
net:
  bindIpAll: true
  port: 8003
```

各インスタンスを起動

分かりやすいようコマンドプロンプトを3つ立ち上げてそれぞれのインスタンスを起動します。

mongod --config "C:\mongodb\server1\mongod.srver1.cfg"

mongod --config "C:\mongodb\server2\mongod.server2.cfg"

mongod --config "C:\mongodb\server3\mongod.server3.cfg"

レプリカセットの初期化

いずれかのインスタンスにログイン

今回は以下のコマンドを実行して server1 へログインします。
```
mongo --host 127.0.0.1:27001
```
レプリカセット初期化処理の実行

mongoコマンドの rs.initiate() を実行することでレプリカセットを初期化します。渡したい引数はあらかじめ config オブジェクトへ代入してから渡します（そのほうが誤りを訂正できるので）。 アービターサーバーには arbiterOnly: true を付与します。
```
> config = {
   _id : "rs0",
   members: [
      { _id: 0, host: "127.0.0.1:8001" },
      { _id: 1, host: "127.0.0.1:8002" },
      { _id: 2, host: "127.0.0.1:8003", arbiterOnly: true },
   ]
}
> rs.initiate(config)
```

以上で設定は完了してレプリカセットが利用できる状態になりました。次の章で簡単な動作確認をしてみます。

レプリカセットの動作確認

今回は動作確認として以下の以下の3つを行ってみます。

レプリカセットの設定確認
レプリカセットのステータス確認
フェールオーバーの動作確認

レプリカセットの設定確認

コマンドプロンプトで rs.config() を実行
```
> rs.config()
```

コマンド実行結果としてレプリカセット設定が表示されることを確認

{
  "_id" : "rs0",
  "version" : 1,
  "protocolVersion" : NumberLong(1),
  "members" : [
    {
      "_id" : 0,
      "host" : "127.0.0.1:8001",
      "arbiterOnly" : false,
      "buildIndexes" : true,
      "hidden" : false,
      "priority" : 1,
      "tags" : {

      },
      "slaveDelay" : NumberLong(0),
      "votes" : 1
    },
    {
      "_id" : 1,
      "host" : "127.0.0.1:8002",
      "arbiterOnly" : false,
      "buildIndexes" : true,
      "hidden" : false,
      "priority" : 1,
      "tags" : {

      },
      "slaveDelay" : NumberLong(0),
      "votes" : 1
    },
    {
      "_id" : 2,
      "host" : "127.0.0.1:8003",
      "arbiterOnly" : true,
      "buildIndexes" : true,
      "hidden" : false,
      "priority" : 0,
      "tags" : {

      },
      "slaveDelay" : NumberLong(0),
      "votes" : 1
    }
  ],
  "settings" : {
    "chainingAllowed" : true,
    "heartbeatIntervalMillis" : 2000,
    "heartbeatTimeoutSecs" : 10,
    "electionTimeoutMillis" : 10000,
    "catchUpTimeoutMillis" : -1,
    "catchUpTakeoverDelayMillis" : 30000,
    "getLastErrorModes" : {

    },
    "getLastErrorDefaults" : {
      "w" : 1,
      "wtimeout" : 0
    },
    "replicaSetId" : ObjectId("5a76f437386f5b1a0a9f8f01")
  }
}

サーバーのステータス確認

コマンドで rs.status() を実行
```
> rs.status()
```

コマンド実行結果として現在のサーバーステータスが表示されることを確認

{
  "set" : "rs0",
  "date" : ISODate("2018-02-04T11:53:38.972Z"),
  "myState" : 1,
  "term" : NumberLong(1),
  "heartbeatIntervalMillis" : NumberLong(2000),
  "optimes" : {
    "lastCommittedOpTime" : {
      "ts" : Timestamp(0, 0),
      "t" : NumberLong(-1)
    },
    "appliedOpTime" : {
      "ts" : Timestamp(1517745207, 1),
      "t" : NumberLong(-1)
    },
    "durableOpTime" : {
      "ts" : Timestamp(1517745207, 1),
      "t" : NumberLong(-1)
    }
  },
  "members" : [
    {
      "_id" : 0,
      "name" : "127.0.0.1:8001",
      "health" : 1,
      "state" : 1,
      "stateStr" : "PRIMARY",
      "uptime" : 117,
      "optime" : {
        "ts" : Timestamp(1517745207, 1),
        "t" : NumberLong(-1)
      },
      "optimeDate" : ISODate("2018-02-04T11:53:27Z"),
      "infoMessage" : "could not find member to sync from",
      "electionTime" : Timestamp(1517745218, 1),
      "electionDate" : ISODate("2018-02-04T11:53:38Z"),
      "configVersion" : 1,
      "self" : true
    },
    {
      "_id" : 1,
      "name" : "127.0.0.1:8002",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      "uptime" : 11,
      "optime" : {
        "ts" : Timestamp(1517745207, 1),
        "t" : NumberLong(-1)
      },
      "optimeDurable" : {
        "ts" : Timestamp(1517745207, 1),
        "t" : NumberLong(-1)
      },
      "optimeDate" : ISODate("2018-02-04T11:53:27Z"),
      "optimeDurableDate" : ISODate("2018-02-04T11:53:27Z"),
      "lastHeartbeat" : ISODate("2018-02-04T11:53:38.520Z"),
      "lastHeartbeatRecv" : ISODate("2018-02-04T11:53:34.281Z"),
      "pingMs" : NumberLong(0),
      "configVersion" : 1
    },
    {
      "_id" : 2,
      "name" : "127.0.0.1:8003",
      "health" : 1,
      "state" : 7,
      "stateStr" : "ARBITER",
      "uptime" : 11,
      "lastHeartbeat" : ISODate("2018-02-04T11:53:38.524Z"),
      "lastHeartbeatRecv" : ISODate("2018-02-04T11:53:34.205Z"),
      "pingMs" : NumberLong(0),
      "configVersion" : 1
    }
  ],
  "ok" : 1,
  "operationTime" : Timestamp(1517745207, 1),
  "$clusterTime" : {
    "clusterTime" : Timestamp(1517745218, 1),
    "signature" : {
      "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
      "keyId" : NumberLong(0)
    }
  }
}

フェールオーバーの動作確認

MongoDBではプライマリサーバーがダウンしたとき（通信不能になったとき）、自動でセカンダリサーバーがプライマリサーバーに昇格するようになっています。今回はプライマリサーバーを強制的に落としてセカンダリサーバーがプライマリサーバーに昇格することを確認します。

現在のステータスを確認

先述の rs.status() で状況を確認します。結果出力内容は一部省略しています。

PRIMARY> rs.status()
{
  ...
  "members" : [
    {
      "_id" : 0,
      "name" : "127.0.0.1:8001",
      "health" : 1,
      "state" : 1,
      "stateStr" : "PRIMARY",
      ...
    },
    {
      "_id" : 1,
      "name" : "127.0.0.1:8002",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      ...
    },
    {
      "_id" : 2,
      "name" : "127.0.0.1:8003",
      "health" : 1,
      "state" : 7,
      "stateStr" : "ARBITER",
      ...
    }
  ],
  ...
}

プライマリサーバーのコマンドプロンプトを停止

先ほどの rs.status() の結果から _id: 0 のサーバーがプライマリサーバーだとわかりましたので、 _id: 0 のサーバーを起動しているコマンドプロンプト上で Ctrl + C を実行し、停止させます。

ステータスの確認

ハートビート（生死確認）は2秒間隔なので、3秒程度待ってから rs.status() を実行します。セカンダリサーバーのどちらかがプライマリサーバーに昇格していることが確認できます。

PRIMARY> rs.status()
{
  ...
  "members" : [
    {
      "_id" : 0,
      "name" : "127.0.0.1:8001",
      "health" : 0,
      "state" : 8,
      "stateStr" : "(not reachable/healthy)",
      ...
    },
    {
      "_id" : 1,
      "name" : "127.0.0.1:8002",
      "health" : 1,
      "state" : 1,
      "stateStr" : "PRIMARY",
      ...
    },
    {
      "_id" : 2,
      "name" : "127.0.0.1:8003",
      "health" : 1,
      "state" : 7,
      "stateStr" : "ARBITER",
      ...
    }
  ],
  ...
}

今回は「MongoDBの2台構成レプリカセットの構築」についてまとめました。ポイントは以下の通りです。

物理2台構成のレプリカセットは作成できない。
高スペック2台構成（プライマリ、セカンダリ）＋低スペック1台（アービター）の3台構成にする。
1台サーバーに3インスタンスの場合、ポートを分ける。
アービターサーバーには以下の設定を入れる
- storage.journal.enabled: false
- arbiterOnly: true

参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

参考記事

MongoDB で 3台構成のレプリカセットを構築する方法

今回は「MongoDB で 3台構成のレプリカセットを作成する方法」についてまとめます。

概要
レプリカセットの構築
- レプリカセットメンバーの準備
- レプリカセットの初期化
レプリカセットの動作確認

概要

今回は以下の図のようなサーバー3台構成（プライマリ1台、セカンダリ2台）のMongoDBサーバーを構築していきます。

今回は動作確認をお試しで行いたいので、以下の制約をつけた環境でのサンプルになります。

1台の物理マシンの中に上記3インスタンスを構築
認証制御は行わない

どちらかというと本番向けというよりは開発環境向けのデータベースサーバー構築になります。

レプリカセットの構築

今回はテスト用として物理1台の中に3台分のMongoDBインスタンスを作成するサンプルです。実運用だと1サーバー1インスタンスになるはずなので、一部設定は読み替えていただければと思います。

レプリカセットメンバーの準備

各インスタンス用にフォルダ・ファイルを作成

C:\mongodb
  │
  ├ \server1
  │  ├ \data
  │  ├ \log
  │  └ mongod.srver1.cfg
  │     
  ├ \server2
  │  ├ \data
  │  ├ \log
  │  └ mongod.server2.cfg
  │     
  └ \server3
      ├ \data
      ├ \log
      └ mongod.server3.cfg

各インスタンスの設定ファイル（mongod.serverN.cfg）を修正

1サーバー中に複数インスタンス生成しているため、ポート番号を分けています。 1サーバー1インスタンスであればポートはすべて同じ（27017 など) でも問題ないです。

レプリカセット名（replSetName）はすべて共通（今回は rs0 ）で設定しておきます。また、開発環境向けであれば bindIpAll 設定を入れておくとバインドIPを列挙しなくてよいので設定が簡単です。プロダクション向けは bindIp を面倒でも設定しておくほうが良いと思いますが…。

mongod.srver1.cfg
```
systemLog:
  destination: file
  path: C:\mongodb\server1\log\mongod.srver1.log
storage:
  dbPath: C:\mongodb\server1\data
replication:
  replSetName: "rs0"
net:
  bindIpAll: true
  port: 27001
```
mongod.server2.cfg
```
systemLog:
  destination: file
  path: C:\mongodb\server2\log\mongod.server2.log
storage:
  dbPath: C:\mongodb\server2\data
replication:
  replSetName: "rs0"
net:
  bindIpAll: true
  port: 27002
```
mongod.server3.cfg
```
systemLog:
  destination: file
  path: C:\mongodb\server3\log\mongod.server3.log
storage:
  dbPath: C:\mongodb\server3\data
replication:
  replSetName: "rs0"
net:
  bindIpAll: true
  port: 27003
```

各インスタンスを起動

分かりやすいようコマンドプロンプトを3つ立ち上げてそれぞれのインスタンスを起動します。

mongod --config "C:\mongodb\server1\mongod.srver1.cfg"

mongod --config "C:\mongodb\server2\mongod.server2.cfg"

mongod --config "C:\mongodb\server3\mongod.server3.cfg"

レプリカセットの初期化

いずれかのインスタンスにログイン

今回は以下のコマンドを実行して server1 へログインします。
```
mongo --host 127.0.0.1:27001
```
レプリカセット初期化処理の実行

mongoコマンドの rs.initiate() を実行することでレプリカセットを初期化します。渡したい引数はあらかじめ config オブジェクトへ代入してから渡します（そのほうが誤りを訂正できるので）。
```
> config = {
   _id : "rs0",
   members: [
      { _id: 0, host: "127.0.0.1:27001" },
      { _id: 1, host: "127.0.0.1:27002" },
      { _id: 2, host: "127.0.0.1:27003" },
   ]
}
> rs.initiate(config)
```

以上で設定は完了してレプリカセットが利用できる状態になりました。次の章で簡単な動作確認をしてみます。

レプリカセットの動作確認

今回は動作確認として以下の以下の3つを行ってみます。

レプリカセットの設定確認
レプリカセットのステータス確認
フェールオーバーの動作確認

レプリカセットの設定確認

コマンドプロンプトで rs.config() を実行
```
> rs.config()
```

コマンド実行結果としてレプリカセット設定が表示されることを確認

{
  "_id" : "rs0",
  "version" : 1,
  "protocolVersion" : NumberLong(1),
  "members" : [
    {
      "_id" : 0,
      "host" : "127.0.0.1:8001",
      "arbiterOnly" : false,
      "buildIndexes" : true,
      "hidden" : false,
      "priority" : 1,
      "tags" : {

      },
      "slaveDelay" : NumberLong(0),
      "votes" : 1
    },
    {
      "_id" : 1,
      "host" : "127.0.0.1:8002",
      "arbiterOnly" : false,
      "buildIndexes" : true,
      "hidden" : false,
      "priority" : 1,
      "tags" : {

      },
      "slaveDelay" : NumberLong(0),
      "votes" : 1
    },
    {
      "_id" : 2,
      "host" : "127.0.0.1:8003",
      "arbiterOnly" : false,
      "buildIndexes" : true,
      "hidden" : false,
      "priority" : 1,
      "tags" : {

      },
      "slaveDelay" : NumberLong(0),
      "votes" : 1
    }
  ],
  "settings" : {
    "chainingAllowed" : true,
    "heartbeatIntervalMillis" : 2000,
    "heartbeatTimeoutSecs" : 10,
    "electionTimeoutMillis" : 10000,
    "catchUpTimeoutMillis" : -1,
    "catchUpTakeoverDelayMillis" : 30000,
    "getLastErrorModes" : {

    },
    "getLastErrorDefaults" : {
      "w" : 1,
      "wtimeout" : 0
    },
    "replicaSetId" : ObjectId("5a75b603abca086c328afd4f")
  }
}

サーバーのステータス確認

コマンドで rs.status() を実行
```
> rs.status()
```

コマンド実行結果として現在のサーバーステータスが表示されることを確認

{
  "set" : "rs0",
  "date" : ISODate("2018-02-03T13:21:42.450Z"),
  "myState" : 1,
  "term" : NumberLong(1),
  "heartbeatIntervalMillis" : NumberLong(2000),
  "optimes" : {
    "lastCommittedOpTime" : {
      "ts" : Timestamp(1517664101, 1),
      "t" : NumberLong(1)
    },
    "readConcernMajorityOpTime" : {
      "ts" : Timestamp(1517664101, 1),
      "t" : NumberLong(1)
    },
    "appliedOpTime" : {
      "ts" : Timestamp(1517664101, 1),
      "t" : NumberLong(1)
    },
    "durableOpTime" : {
      "ts" : Timestamp(1517664101, 1),
      "t" : NumberLong(1)
    }
  },
  "members" : [
    {
      "_id" : 0,
      "name" : "127.0.0.1:8001",
      "health" : 1,
      "state" : 1,
      "stateStr" : "PRIMARY",
      "uptime" : 602,
      "optime" : {
        "ts" : Timestamp(1517664101, 1),
        "t" : NumberLong(1)
      },
      "optimeDate" : ISODate("2018-02-03T13:21:41Z"),
      "electionTime" : Timestamp(1517663759, 1),
      "electionDate" : ISODate("2018-02-03T13:15:59Z"),
      "configVersion" : 1,
      "self" : true
    },
    {
      "_id" : 1,
      "name" : "127.0.0.1:8002",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      "uptime" : 354,
      "optime" : {
        "ts" : Timestamp(1517664101, 1),
        "t" : NumberLong(1)
      },
      "optimeDurable" : {
        "ts" : Timestamp(1517664101, 1),
        "t" : NumberLong(1)
      },
      "optimeDate" : ISODate("2018-02-03T13:21:41Z"),
      "optimeDurableDate" : ISODate("2018-02-03T13:21:41Z"),
      "lastHeartbeat" : ISODate("2018-02-03T13:21:41.665Z"),
      "lastHeartbeatRecv" : ISODate("2018-02-03T13:21:40.647Z"),
      "pingMs" : NumberLong(0),
      "syncingTo" : "127.0.0.1:8001",
      "configVersion" : 1
    },
    {
      "_id" : 2,
      "name" : "127.0.0.1:8003",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      "uptime" : 354,
      "optime" : {
        "ts" : Timestamp(1517664101, 1),
        "t" : NumberLong(1)
      },
      "optimeDurable" : {
        "ts" : Timestamp(1517664101, 1),
        "t" : NumberLong(1)
      },
      "optimeDate" : ISODate("2018-02-03T13:21:41Z"),
      "optimeDurableDate" : ISODate("2018-02-03T13:21:41Z"),
      "lastHeartbeat" : ISODate("2018-02-03T13:21:41.662Z"),
      "lastHeartbeatRecv" : ISODate("2018-02-03T13:21:40.652Z"),
      "pingMs" : NumberLong(0),
      "syncingTo" : "127.0.0.1:8001",
      "configVersion" : 1
    }
  ],
  "ok" : 1,
  "operationTime" : Timestamp(1517664101, 1),
  "$clusterTime" : {
    "clusterTime" : Timestamp(1517664101, 1),
    "signature" : {
      "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
      "keyId" : NumberLong(0)
    }
  }
}

フェールオーバーの動作確認

MongoDBではプライマリサーバーがダウンしたとき（通信不能になったとき）、自動でセカンダリサーバーがプライマリサーバーに昇格するようになっています。今回はプライマリサーバーを強制的に落としてセカンダリサーバーのどちらかがプライマリサーバーに昇格することを確認します。

現在のステータスを確認

先述の rs.status() で状況を確認します。結果出力内容は一部省略しています。

> rs.status()
{
  ...
  "members" : [
    {
      "_id" : 0,
      "name" : "127.0.0.1:8001",
      "health" : 1,
      "state" : 1,
      "stateStr" : "PRIMARY",
      ...
    },
    {
      "_id" : 1,
      "name" : "127.0.0.1:8002",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      ...
    },
    {
      "_id" : 2,
      "name" : "127.0.0.1:8003",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      ...
    }
  ],
  ...
}

プライマリサーバーのコマンドプロンプトを停止

先ほどの rs.status() の結果から _id: 0 のサーバーがプライマリサーバーだとわかりましたので、 _id: 0 のサーバーを起動しているコマンドプロンプト上で Ctrl + C を実行し、停止させます。

ステータスの確認

> rs.status()
{
  ...
  "members" : [
    {
      "_id" : 0,
      "name" : "127.0.0.1:8001",
      "health" : 0,
      "state" : 8,
      "stateStr" : "(not reachable/healthy)",
      ...
    },
    {
      "_id" : 1,
      "name" : "127.0.0.1:8002",
      "health" : 1,
      "state" : 1,
      "stateStr" : "PRIMARY",
      ...
    },
    {
      "_id" : 2,
      "name" : "127.0.0.1:8003",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      ...
    }
  ],
  ...
}

今回は「MongoDBの3台構成レプリカセットの構築」についてまとめました。ポイントは以下の通りです。

3台構成の場合、プライマリ1台＋セカンダリ2台
1台サーバーに3インスタンスの場合、ポートを分ける

参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

参考記事

C# & JavaScript

概要

シャードクラスタの構築

フォルダ準備

設定サーバー構築

シャードサーバー構築

ルーター構築

シャードクラスタの動作確認

mongoシェルコマンド

Node.js MongoDB Driver

概要

前提準備

実装例

動作確認

スケーリング

シャーディングとは

読み書き

ストレージ

高可用性

シャードクラスタ

シャードキー

チャンク

シャードデータに対する操作の制約

シャードコレクションと非シャードコレクション

データ分散方法

ハッシュシャード

レンジシャード

再同期が必要なケース

再同期する際の注意点

自動再同期を行う手順

動作環境

インストール

初期設定

データ保存ディレクトリ

ポート開放

設定ファイル (mongod.conf)

自動起動設定

動作確認

MongoDBの起動 (mongod)

MongoDBへ接続 (mongo)

MongoDBの終了 (mongod)

前提状況

優先度の調整で変更する

コマンドで変更する

概要

変更手順

現在のサイズを確認

oplogサイズ変更

データ再同期

接続する

接続文字列 (url)

読み込み設定 (options)

書き込み設定

読み書きする

接続する

サーバーを指定して接続する

プライマリサーバーを探す

ユーザー名とパスワードを指定して接続する

アクセス制御が有効化されている場合に必要な権限

読み書きする

プライマリサーバーで読み書き

セカンダリサーバーで読取

概要

キーファイルを用いたアクセス制御

管理ユーザーの追加

MongoDBの設定変更（アクセス制御有効化）

通常ユーザーの追加

ユーザー名とパスワードを指定してデータベースへ接続

前提・制約

レプリカセットからメンバーを削除する手順

前提・制約

レプリカセットへの追加手順

レプリカセットに追加

追加したメンバーのデータ確認

新規メンバーのデータを同期

レプリカセット設定を初期化する

レプリカセット設定を変更する

主なレプリカセット設定例

プライマリにならないようにする

隠しメンバーにする