MongoDBレプリカセット構築

MongoDB
MongoDBは現在最も流行しているNoSQLデータベースの一つです.ビッグデータ時代には、従来のリレーショナル・データベースでは、高同時読み書き、大量のデータの効率的なストレージ、高拡張性、高可用性という難題に直面しています.MySQLを例にとると、データ量が多くて分表分庫が必要な場合、それ自体は分片能力を提供せず、自分で別のサービスを構築する必要があります.これらの問題を解決するためにNoSQLが誕生したのです.注意:NoSQL(NoSQL=Not Only SQL)は、「SQLだけではない」という意味です.NoSQLには次のようなメリットがあります.

ビッグデータ量は、安価なサーバで大量のデータを格納することで、従来のmysql単一テーブルストレージレベルの制限から簡単に抜け出すことができます.

高性能で、NoSQLは簡単なkey-value方式でデータを取得し、非常に高速です.また、NoSQLのCacheは記録級で、細粒度のCacheなので、NoSQLはこのレベルでは性能が高いです.

柔軟なデータモデルで、NoSQLは事前に保存するデータのフィールドを確立する必要がなく、いつでもカスタムデータフォーマットを保存することができます.リレーショナル・データベースでは、フィールドを削除するのは非常に面倒なことです.非常に大きなデータ量のテーブルであれば、フィールドを増やすのは悪夢です.

は高可用性で、NoSQLはパフォーマンスにあまり影響を及ぼさず、高可用性のアーキテクチャを容易に実現できます.例えばmongodbはmongos,mongoスライスにより高可用性構成を迅速に構成できる.

スタンドアロン版MongoDB
この構成は簡易開発時にのみ適用され、高可用性ではないため、生産では使用できません.ここではdockerを使用してMongoDBサービスを迅速に起動し、MongoDBバージョンは3.6です.
docker-compose.yml

version: '3'
services:
  mongo1:
    image: mongo:3.6
    environment:
        - MONGO_INITDB_ROOT_USERNAME=test
        - MONGO_INITDB_ROOT_PASSWORD=IIm7A5C5GqRWqnLg
    network_mode: "host"
    volumes:
      - ./mongo_data:/data/db
      - ./mongod.conf:/etc/mongo/mongod.conf
      - ./log:/var/log/mongodb
    command: ["--config", "/etc/mongo/mongod.conf"]

mongod.conf

systemLog:
  destination: file
  path: /var/log/mongodb/mongo.log
  logAppend: false
storage:
  dbPath: /data/db
  indexBuildRetry: true
  journal:
    enabled: true
net:
  port: 40031
  bindIp: 0.0.0.0
  maxIncomingConnections: 65536

docker-compose.ymlでnetwork_mode:「host」はコンテナにホストネットワークを直接使用させ、プロファイル内のnet下portはMongoDBサービスのリスニングを指定するポート、storage下のdbPathはデータストレージディレクトリを指定し、journalを開くのはjournalファイルがデータベースの異常終了時にデータを復元するためである(デフォルトはオン).WindowsでMongoDBが起動できないという問題(WiredTigerプロンプトOperation not permitted)が発生し、トップクラスのデータボリュームを自分で作成することが解決します

version: '3'
services:
  mongo1:
    image: mongo:3.6
    environment:
        - MONGO_INITDB_ROOT_USERNAME=test
        - MONGO_INITDB_ROOT_PASSWORD=IIm7A5C5GqRWqnLg
    network_mode: "host"
    volumes:
      - mongo_data:/data/db
      - ./mongod.conf:/etc/mongo/mongod.conf
      - ./log:/var/log/mongodb
    command: ["--config", "/etc/mongo/mongod.conf"]
volumes:
  mongo_data:

コピーセット
高可用性の1つの方法は主従であり、MongoDBが与えたスキームは である(分散ストレージには があり、後で書く).MongoDBレプリカセットのプライマリ・サーバは、レプリカセット全体の読み書きを担当し、レプリカセットは定期的にデータ・バックアップを同期します.プライマリ・ノードが停止すると、レプリカ・ノードは新しいプライマリ・サーバを選択します.これはアプリケーション・サーバには関心がありません.このようなメカニズムは、データの可用性を向上させ、データの安全性を保証することができる.
注意すべき点は、MongoDB公式では主従モードの使用は推奨されていません.代替案は、レプリカセットのモードを採用することです(4.0はmaster-slave機能、リンクを削除します).
REMOVED
MongoDB 4.0 removes support for master-slave replication. Before youcan upgrade to MongoDB 4.0, if your deployment uses master-slavereplication, you must upgrade to a replica set.
To convert your master-slave replication, see Convert a Master-SlaveDeployment to a Replica Set.
構築前にmongod.confでreplication構成項目を追加する必要があります

systemLog:
  destination: file
  path: /var/log/mongodb/mongo.log
  logAppend: false
storage:
  dbPath: /data/db
  indexBuildRetry: true
  journal: 
    enabled: true
net:
  port: 40031
  bindIp: 0.0.0.0
  maxIncomingConnections: 65536
replication:
   replSetName: myset

スライスクラスタの構築
レプリカセットの初期化
3台のホストでそれぞれMongoDBサービスを起動し、起動に成功した後、あるホストにMongoDBを登録し、rs.initiate()初期化コピーセットを実行すると、次のような出力があります.

{
    "info2" : "no configuration specified. Using a default configuration for the set",
    "me" : "mongo1:40031",
    "ok" : 1
}

現在のレプリカセットの構成情報はrs.conf()で表示できます.
メンテナンス操作rs.add("ip:port")でノードを追加します.ノードを削除するには、rs.remove("ip:port")を使用してレプリカセットのステータスを表示できます.rs.status()を使用します.レプリケーションの遅延を表示するには、 db.printSlaveReplicationInfo()を使用します.