Directing a cluster article

MongoDB clustering and security

6. Replica Sets (*)

6.1 introduction

Replica Set in MongoDB is a Set of Mongod services that maintain the same data Set. Replica sets provide redundancy and high

Availability is the foundation of all production deployments

You can also say that a replica set is similar to a master/slave cluster with automatic failover. Popular is to use multiple machines for the same data difference

Step synchronization, so that multiple machines have multiple copies of the same data, and automatically when the master library goes down without user intervention

Switch to another backup server as the primary library. Moreover, the replica server can also be used as a read-only server to achieve read and write separation and improve the load
- Redundancy and data availability
  
  Replication provides redundancy and improves data availability. Replication provides a level by providing multiple copies of data on different database servers
  
  To prevent the loss of a single database server
  
  In some cases, replication can provide increased read performance because clients can send read operations to different services, where no
  
  Maintaining copies of data with the data center increases the location and availability of data for distributed applications. You can also maintain others for dedicated purposes
  
  Copies, such as disaster recovery, reports, or backups
- Replication in MongoDB
  
  A replica set is a set of Mongod instances that maintain the same data set. The replica set contains multiple data bearer nodes and an optional quorum node.
  
  In a node hosting data, one and only one member is treated as the primary node, while the other nodes are treated as secondary (slave) nodes
  
  The primary node receives all write operations. The replica set can have only one write that is primarily recognized as having {w: “most”} write concerns; Although in some
  
  In some cases, another Mongod instance may temporarily consider itself primary as well. Records all of the data sets in their operation logs
  
  Change, that is, the Oplog secondary (replica) node copies the oplog of the primary node and applies the operation to its dataset so that the data set of the secondary node mirrors the data set of the primary node. If the principal is absent, the eligible secondary school will hold an election to select a new principal
- Master/slave replication and replica set differences
  
  The biggest difference between master and slave cluster and replica set is that the replica set has no fixed “master node”. The entire cluster will select a “master node” when it hangs
  
  After the drop, select other nodes from the remaining from the node as “primary node”, the replica set always has one active point (primary, primary) and one or more
  
  2 backup nodes (secondary, secondary)

6.2 Three roles in the replica set

There are two types of replica sets and three roles
Two types of
- Primary node type: the main connection point of data operation. It can be read or written
- Secondary (secondary, secondary) nodes: data redundancy backup nodes, which can be read or elected
Three roles
- Primary node: the Primary node that receives all write operations
- Replicate member (Replicate) : A slave node maintains the same data set through replication operations. That is, backup data. It cannot be written, but it can be read (with additional configuration)
- Arbiter: does not retain any copy of data, only voting. It is also possible to maintain the blanking server as part of a replica set, in which the replica members can also be arbitrators, a slave node type
Additional notes on arbitrators:

You can add additional Mongod instances to the replica set as arbitrators. Arbitrators do not maintain datasets. The purpose of the arbiter is to pass

Maintains quorum in the replica set in response to heartbeat and election requests from other replica set members. Because they do not store data sets, mediators do

It is a good way to provide replica set arbitration capability, with a lower resource cost than full-featured replica set members with data sets.

If your replica set has an even number of members, add arbitrators to get a “majority” vote in the main election. Arbitrators need not be dedicated

The hardware.

The arbiter will always be the arbiter, and the primary person may drop out and become the secondary person, and the secondary person may become the primary person during an election

personnel

If your number of replicas + hosts is even, it is recommended to add an arbiter to form an odd number that will easily satisfy the majority of votes

If you have an odd number of replicas + hosts, you can omit the arbiter

6.3 Replica set architecture objectives

One master, one copy, one arbitration

6.4 Creating replica Sets

6.4.1 Step 1: Create an active node

Create a directory for storing data and logs

#-----------myrs 
#The master node
mkdir -p /mongodb/replica_sets/myrs_27017/log \ & 
mkdir -p /mongodb/replica_sets/myrs_27017/data/db
Copy the code

Create or modify a configuration file

vim /mongodb/replica_sets/myrs_27017/mongod.conf
Copy the code

Myrs_27017 mongod.conf (note the space)

SystemLog: #MongoDB sends all logs to destination: file# The path to the log file to which mongod or Mongos should send all diagnostic logging information
   path: "/mongodb/replica_sets/myrs_27017/log/mongod.log"# When the Mongos or Mongod instance is restarted, Mongos or Mongod appends the new entry to the end of the existing log file. logAppend:true
storage:
   The directory in which the mongod instance stores its data. The storage.dbpath setting applies only to Mongod.
   dbPath: "/mongodb/replica_sets/myrs_27017/data/db"Journal: # Enable or disable persistent logging to ensure that data files remain valid and recoverable. enabled:trueProcessManagement: # Enable daemon mode to run mongos or Mongod processes in the background. fork:true# specify the file location used to hold the process ID of mongos or Mongod, where Mongos or Mongod will write its PID pidFilePath:"/mongodb/replica_sets/myrs_27017/log/mongod.pid"When the replica is initialized, the node name is automatically set to the local domain name instead of IP #bindIpAll:trueBindIp: localhost,192.16883.133.#bindIp #bind port:27017Replication: # Name of replica set replSetName: myrsCopy the code

6.4.2 Step 2: Create a replica node

Create a directory for storing data and logs

#A copy of the node 
mkdir -p /mongodb/replica_sets/myrs_27018/log \ & 
mkdir -p /mongodb/replica_sets/myrs_27018/data/db
Copy the code

Create or modify a configuration file

vim /mongodb/replica_sets/myrs_27018/mongod.conf
Copy the code

Myrs_27018 mongod.conf (note the space)

SystemLog: #MongoDB sends all logs to destination: file# The path to the log file to which mongod or Mongos should send all diagnostic logging information
   path: "/mongodb/replica_sets/myrs_27018/log/mongod.log"# When the Mongos or Mongod instance is restarted, Mongos or Mongod appends the new entry to the end of the existing log file. logAppend:true
storage:
   The directory in which the mongod instance stores its data. The storage.dbpath setting applies only to Mongod.
   dbPath: "/mongodb/replica_sets/myrs_27018/data/db"Journal: # Enable or disable persistent logging to ensure that data files remain valid and recoverable. enabled:trueProcessManagement: # Enable daemon mode to run mongos or Mongod processes in the background. fork:true# specify the file location used to hold the process ID of mongos or Mongod, where Mongos or Mongod will write its PID pidFilePath:"/mongodb/replica_sets/myrs_27018/log/mongod.pid"When the replica is initialized, the node name is automatically set to the local domain name instead of IP #bindIpAll:trueBindIp: localhost,192.16883.133.#bindIp #bind port:27018Replication: # Name of replica set replSetName: myrsCopy the code

6.4.3 Step 3: Create blanking node

Create a directory for storing data and logs

#-----------myrs 
#Arbitration node 
mkdir -p /mongodb/replica_sets/myrs_27019/log \ & 
mkdir -p /mongodb/replica_sets/myrs_27019/data/db
Copy the code

Quorum node: Creates or modifies a configuration file

vim /mongodb/replica_sets/myrs_27019/mongod.conf
Copy the code

myrs_27019 mongod.conf

SystemLog: #MongoDB sends all logs to destination: file# The path to the log file to which mongod or Mongos should send all diagnostic logging information
   path: "/mongodb/replica_sets/myrs_27019/log/mongod.log"# When the Mongos or Mongod instance is restarted, Mongos or Mongod appends the new entry to the end of the existing log file. logAppend:true
storage:
   The directory in which the mongod instance stores its data. The storage.dbpath setting applies only to Mongod.
   dbPath: "/mongodb/replica_sets/myrs_27019/data/db"Journal: # Enable or disable persistent logging to ensure that data files remain valid and recoverable. enabled:trueProcessManagement: # Enable daemon mode to run mongos or Mongod processes in the background. fork:true# specify the file location used to hold the process ID of mongos or Mongod, where Mongos or Mongod will write its PID pidFilePath:"/mongodb/replica_sets/myrs_27019/log/mongod.pid"When the replica is initialized, the node name is automatically set to the local domain name instead of IP #bindIpAll:trueBindIp: localhost,192.16883.133.#bindIp #bind port:27019Replication: # Name of replica set replSetName: myrsCopy the code

6.4.4 Step 4: Initialize the replica set and primary node

Start three nodes

./mongod -f /mongodb/replica_sets/myrs_27017/mongod.conf
./mongod -f /mongodb/replica_sets/myrs_27018/mongod.conf
./mongod -f /mongodb/replica_sets/myrs_27019/mongod.conf
ps -ef|grep mongod
Copy the code

Use client commands to connect to any node, but try to connect to the primary node (27017 node)
```
./mongo --port 27017
Copy the code
```
Once connected, many commands, such as show DBS, cannot be used and must be initialized
Ready to initialize a new replica set

Grammar: rs. Initiate (configuration)

Initialize replica sets with default configuration: Rs.Initiate ()

6.4.5 Viewing the Replica Set Configuration

Returns the document containing the current replica set configuration
Grammar: rs. Conf (configuration)
Using the default, view the master node configuration: rs.conf()
instructions
- “_id” : “myRS” : primary key of the configuration data store of the replica set. Default is the name of the replica set
- “Members” : an array of members in a replica set. “host” : “192.168.83.133:27017” does not
  
  Yes Arbitration node: “arbiterOnly” : false, priority (weight) : “priority” : 1
- “Settings” : parameter Settings for the replica set
rs.status()View the running status of the node

6.4.6 Adding a Secondary Replica Node

Add slave nodes to the master node to add other members to the replica set
Grammar:
```
rs.add(host,arbiterOnly)
Copy the code
```
Parameter Description
- Host Stirng or Document The new member to be added to the replica set. Specified as a string or configuration document: 1) as in
  
  If it is a string, specify the host name and an optional port number for the new member. 2) If it is a document, specify the replica set member configuration document found in the Members array. You must specify the host field in the member configuration document. For a description of the configuration fields in the document, see the following document: Configuration Documents for host members
- ArbiterOnly Boolean Optional. This applies only if the value is a string. If true, add
  
  Plus’s host is the arbiter

Rs. The add (" 192.168.83.133:27018)"Copy the code

Ok: 1: The port is successfully added

View replica set status rs.status()

“Name” : “192.168.83.133:27018” is the name of the second node whose role is “stateStr” : “SECONDARY”

6.4.7 Adding a Secondary Quorum Node

Add a quorum node to the replica set
Grammar: rs. AddArb (host)
Ok: 1: The port is successfully added
View the replica set statusrs.status()

6.5 Data Read and Write Operations on replica Sets

Objective: Tests the data read and write status of three nodes with different roles

Use articledb db.comment. Insert ({"articleid":"100000","content": "," userID ":"1001","nickname":"Rose"," createDateTime ":new Date()}) db.ment.find()Copy the code

Log in to secondary node 27018

Unable to read collection data. The current slave node is just a backup, not a slave node, and cannot read data, certainly not write data

Line. By default, the secondary node does not have the read/write permission. You can add the read permission, but you need to set the read permission
Set read operation permission: Set it as a slave node to allow read operations on slave members

grammar
```
Rs. SlaveOk () # or rs. SlaveOk (true)Copy the code
```
This command is a simplified version of db.getmongo ().setSlaveok ()
The read permission is granted, but the insert is not allowed
Read/write separation is now possible, allowing the master to insert data and the never to read data
Remove read permission from slave node: rs.slaveok (false)
arbiterIf the node does not store any service data, you can log in to view it

6.6 Election Rules for the Primary Node

In a replica set, MongoDB automatically elects the primary node and triggers the primary node election
- Primary node failure
- The network of the primary node is unreachable (default heartbeat is 10 seconds)
- Manual intervention (Rs.Stepdown (600))
Once an election is triggered, the primary node is chosen according to certain rules, which determine who wins based on the number of votes cast
- The node with the highest number of votes and the support of a “majority” of members wins
  
  “Majority” is defined as: assuming that the number of voting members in the replication set is N, the majority is N/2 + 1. For example: 3 voting members,
  
  Most of the values are 2. If the number of surviving members in the replication set is less than a majority, the Primary cannot be elected for the entire replication set.
  
  The replicate set will not be able to provide write services and will be read-only
- If the number of votes is equal and both have the support of a “majority” of the members, the new node of the data wins
  
  The old and new data are compared using the operation log Oplog
- The priority parameter matters a lot when it comes to getting votes
  
  Additional votes can be set by setting priority. Priority is the weight. The value ranges from 0 to 1000
  
  The number of votes ranges from 0 to 1000. The larger the priority value is, the more likely it is to have the votes of the majority of members. Specify a higher value to enable a member
  
  More eligible to be a principal member, lower values can make members less eligible.
  
  By default, the priority value is 1
  
  It can be seen that the priority of the master node and the replica node is 1 respectively, that is, by default, they can be considered to have already had one vote. But the election node takes precedence
  
  The priority of the election node must be 0, not another value. They do not have the right to vote, but they do
  
  The right to vote)

6.7 Fault Testing (*)

6.7.1 Testing Duplicate Node Faults

Example Close copy 27018
- The heartbeat between the primary node and the quorum node to 27018 failed, because the primary node is still there, so no vote was triggered
- If so, the master node writes data
```
Db.com ment. Insert ({"_id":"1"," articleID ":"100001","content":" We should not waste the morning on the phone, health is very important, a cup of warm water happiness you, me and him." ," userID ":"1002","nickname":" nickname"," createDateTime ":new Date("2019-08-" 05 t22:08:15. 522 z "), "likenum" : NumberInt (1000), "state" : "1"})Copy the code
```
  The primary node inserts and reads are fine
- If you start the secondary node again, the data written by the primary node is automatically synchronized to the secondary node
  
  Start the 27018 service again
  
  Data on replica nodes is automatically synchronized

6.7.2 Testing faults on the active Node

Close 27017 primary node to trigger voting
- It is found that the heartbeat between the secondary node and the quorum node to 27017 fails. If the heartbeat fails for more than 10 seconds, the heartbeat is automatically initiated because there is no primary node
  
  The vote. And there’s only 27018 replicas, so there’s only one candidate 27018, start voting. 27019 cast one vote to 27018, 27018 has its own vote, so there are two votes, more than the “majority” 27019 is the arbitration node, does not have the right to vote, 27018 does not vote for it, its vote is 0
Results: 27018 became the main node with read and write function
- 27018 If you exit and re-enter, the system automatically switches to the primary node
- Read and write success
- At this point, the primary node 21017 that was down is restarted again. 27017 becomes the secondary node, and 27018 remains the primary node. Log in to 27017 node and discover that it is a slave node. The data is automatically synchronized from 27018 to achieve high availability

6.7.3 The Quorum Node and primary Node are Faulty

Shut down the quorum node 27019 and then shut down the current primary node 27018
After logging in to 27017, it is found that 27017 is still the slave node, and there is no master node in the replica set. As a result, the replica set is read-only.

Unable to write

Why are there no elections? Since 27,017 votes did not have a majority, i.e., no vote greater than or equal to 2, it has only one default vote (priority 1). If you want to trigger an election, you can join any member
- If only 27019 quorum node member is added, the primary node must be 27017, because there is no election, the quorum node does not participate in the election,
  
  But voting
  
  Start quorum node 27019
  
  27017 Upgrading a secondary node to an active node
- If only 27018 nodes are added, an election is initiated. Because 27017 and 27018 are two votes, the new one will be the main day
  
  point
  
  Only 27018 is activated to trigger the election
  
  Newer data is selected as the primary node

6.7.4 The Quorum Node or Secondary Node is Faulty

Close quorum node 27019 and then the current replica node 27018
After 10 seconds, 27017 primary node is automatically degraded to replica node (service degradation)
The replica set cannot write data. It is faulty

6.8 Compass Connects the replica set

6.9 SpringDataMongoDB Connection Replica Set (*)

Replica set syntax
```
mongodb://host1,host2,host3/articledb? Connect =replicaSet&slaveOk=true&replicaSet= name of the replica setCopy the code
```
- SlaveOk =true: Enables the read function on replica nodes to separate read and write data
- Connect =replicaSet: automatically selects the read and write hosts in the replicaSet. If slaveOK is enabled, read and write separation is implemented
Complete connection string reference (understanding)
```
mongodb://[username:password@]host1[:port1][,host2[:port2],...[,hostN[:portN]]] [/[database][?options]]
Copy the code
```
- Mongodb :// This is a fixed format and must be specified
- Username :password@ Optional. If set, the driver will try to log in to the database after connecting to the database server
- Host1 must specify at least one host. Host1 is the only one to be entered in this URI. It specifies the address of the server to connect to. If you want to connect to a replication set, specify multiple host addresses
- PortX Specifies the port number. If this parameter is not specified, the default value is 27017
- /database If username: pass@ is specified, connect to and verify login to the specified database. If this parameter is not specified, the test database is opened by default
- ? Options is the connection option. If you do not use /database, you need to be preceded by a /. All join options are key-value name=value between key-value pairs by & or; (semicolon) separated

Example: Connect three Replicaset servers (ports 27017, 27018, and 27019) directly to the first server, either Replica

Set part is either primary or secondary, write operations are applied to primary and queries are distributed to secondary

server:
  port: 7777


spring:
# data source configuration
  data:
    mongodb:
# host address
# host: 192.168.83.133
The default port is 27017
# port: 27017
# # database
# database: test
    The connection string for the replica set
      uri: Mongo: / / 192.168.83.133:27017192168 83.133:27018192168 83.133:27019 / articledb? connect=replicaSet&slaveOk=true&replicaSet=myrs
Copy the code

Note: The hosts must be all the hosts in the replica set, including the master node, replica node, and quorum node

SpringDataMongoDB automatically implements read/write separation:
- When writing, open only the primary node connection
- The read operation is to open both the master and slave node connections, but use the slave node to fetch data

7. Sharded Cluster (*)

7.1 Sharding Concept

Sharding is a method of distributing data across multiple machines, and MongoDB uses sharding to support deployments with very large data sets and high-throughput operations
In other words: Sharding is the process of breaking up data and distributing it on different machines. This concept is sometimes expressed in the term partitioning. By spreading the data across different machines, more data can be stored and more loads handled without the need for a powerful mainframe computer
Database systems with large data sets or high-throughput applications can challenge the capacity of a single server. For example, a high query rate can exhaust the CPU capacity of the server. A working set size larger than the system’s RAM emphasizes the DISK drive’S I/O capacity
There are two approaches to system growth: vertical scaling and horizontal scaling
- Vertical scaling means increasing the capacity of a single server, such as using more powerful cpus, adding more RAM, or increasing the amount of storage. The limitations of available technologies may limit a single machine to being powerful enough for a given workload. In addition, cloud-based providers have hard caps based on available hardware configurations. As a result, vertical scaling has an actual maximum value
- Scaling out horizontally means dividing up the system data set and loading multiple servers, adding additional servers to increase capacity as needed. While the overall speed or capacity of individual machines may not be high, each machine handling a subset of the entire workload may provide greater efficiency than a single high-speed, high-volume server. Scaling deployment capacity simply requires adding additional servers as needed, which can be less costly overall than high-end hardware for a single machine. The tradeoff is the increased complexity of infrastructure and deployment maintenance
MongoDB supports horizontal scaling through sharding
- Lower server cost for higher performance

7.2 Components in a Sharded Cluster

The MongoDB sharding cluster contains the following components:
- Shard (storage) : Each shard contains a subset of the shard data, and each shard can be deployed as a set of replicas
- Mongos (Routing) : Mongos acts as a query router, providing an interface between the client application and the shard cluster
- Config-servers (” scheduling “configuration) : Configure metadata and configuration Settings for server storage clusters. Starting with MongoDB 3.4, configuration servers must be deployed as replica sets (CSRS).
Diagram of component interaction in a sharded cluster
MongoDB shards data at the collection level and distributes the collection data among the shards in the cluster

7.3 Sharding Cluster Architecture Objectives

Two fragment node replica sets (3+3), one configuration node replica set (3), and two routing nodes (2), altogether 11 service nodes

7.4 Creating a Fragment Node Replica Set

7.4.1 First set of replicas

Prepare a directory for storing data and logs

#-----------myshardrs01mkdir -p /mongodb/sharded_cluster/myshardrs01_27018/log \ & mkdir -p /mongodb/sharded_cluster/myshardrs01_27018/data/db \ & mkdir -p /mongodb/sharded_cluster/myshardrs01_27118/log \ & mkdir -p /mongodb/sharded_cluster/myshardrs01_27118/data/db \ & mkdir -p /mongodb/sharded_cluster/myshardrs01_27218/log \ & mkdir  -p /mongodb/sharded_cluster/myshardrs01_27218/data/dbCopy the code

Create or modify a configuration file

vim /mongodb/sharded_cluster/myshardrs01_27018/mongod.conf
Copy the code

Myshardrs01_27018:

SystemLog: #MongoDB sends all logs to destination: file# The path to the log file to which mongod or Mongos should send all diagnostic logging information
   path: "/mongodb/sharded_cluster/myshardrs01_27018/log/mongod.log"# When the Mongos or Mongod instance is restarted, Mongos or Mongod appends the new entry to the end of the existing log file. logAppend:true
storage:
   The directory in which the mongod instance stores its data. The storage.dbpath setting applies only to Mongod.
   dbPath: "/mongodb/sharded_cluster/myshardrs01_27018/data/db"Journal: # Enable or disable persistent logging to ensure that data files remain valid and recoverable. enabled:trueProcessManagement: # Enable daemon mode to run mongos or Mongod processes in the background. fork:true# specify the file location used to hold the process ID of mongos or Mongod, where Mongos or Mongod will write its PID pidFilePath:"/mongodb/sharded_cluster/myshardrs01_27018/log/mongod.pid"When the replica is initialized, the node name is automatically set to the local domain name instead of IP #bindIpAll:trueBindIp: localhost,192.16883.133.#bindIp #bind port:27018Replication: # Replication set name replSetName: mySharDS01 Sharding: # Sharding role clusterRole: shardSvrCopy the code

Setting up sharding.clusterRole requires the Mongod instance to run the replication. To deploy an instance as a replica set member, use replSetName to set and specify the name of the replica set: ConfigSvr and ShardSvr

The same operation is repeated for 27118 and 27218

vim /mongodb/sharded_cluster/myshardrs01_27118/mongod.conf
Copy the code

vim /mongodb/sharded_cluster/myshardrs01_27218/mongod.conf
Copy the code

Start the first set of replicas: one master, one replica and one arbitrator
- In turn, start
- Initialize the replica set and create the master node, using client commands to connect to either node, but try to connect to the master node here
  
  (1) Execute the initialization replica set commandrs.initiate()
  
  (2) Check the configuration of the primary noders.status()
  
  (3) Add copy nodes and arbitration nodes
View the replica set configurationrs.conf()If the following information is displayed, the configuration is complete

7.4.2 Second set of replicas

Prepare a directory for storing data and logs

#-----------myshardrs02mkdir -p /mongodb/sharded_cluster/myshardrs02_27318/log \ & mkdir -p /mongodb/sharded_cluster/myshardrs02_27318/data/db \ & mkdir -p /mongodb/sharded_cluster/myshardrs02_27418/log \ & mkdir -p /mongodb/sharded_cluster/myshardrs02_27418/data/db \ & mkdir -p /mongodb/sharded_cluster/myshardrs02_27518/log \ & mkdir  -p /mongodb/sharded_cluster/myshardrs02_27518/data/dbCopy the code

Create or modify a configuration file

vim /mongodb/sharded_cluster/myshardrs02_27318/mongod.conf
Copy the code

vim /mongodb/sharded_cluster/myshardrs02_27418/mongod.conf
Copy the code

vim /mongodb/sharded_cluster/myshardrs02_27518/mongod.conf
Copy the code

myshardrs02_27318:

SystemLog: #MongoDB sends all logs to destination: file# The path to the log file to which mongod or Mongos should send all diagnostic logging information
   path: "/mongodb/sharded_cluster/myshardrs02_27318/log/mongod.log"# When the Mongos or Mongod instance is restarted, Mongos or Mongod appends the new entry to the end of the existing log file. logAppend:true
storage:
   The directory in which the mongod instance stores its data. The storage.dbpath setting applies only to Mongod.
   dbPath: "/mongodb/sharded_cluster/myshardrs02_27318/data/db"Journal: # Enable or disable persistent logging to ensure that data files remain valid and recoverable. enabled:trueProcessManagement: # Enable daemon mode to run mongos or Mongod processes in the background. fork:true# specify the file location used to hold the process ID of mongos or Mongod, where Mongos or Mongod will write its PID pidFilePath:"/mongodb/sharded_cluster/myshardrs02_27318/log/mongod.pid"When the replica is initialized, the node name is automatically set to the local domain name instead of IP #bindIpAll:trueBindIp: localhost,192.16883.133.#bindIp #bind port:27318Replication: # Replication set name replSetName: myShards02 Sharding: # Sharding Role clusterRole: shardSvrCopy the code

Repeat the preceding steps for mySHARDRs02_27418 and mySHARDRs02_27518

Start the second set of replicas: one master, one replicas, one arbitrator
(1) Initialize replica set and create master node: use client command to connect any node, but try to connect master node here

Execute the initialize replica set command: rs.initiate()

View replica sets :rs.status()
(2) Master node configuration check: rs.conf()
(3) Add copy nodes and arbitration nodes as follows
View the configuration of replica sets
- rs.conf()
- rs.status()

7.5 Configuring the Creation of node Replica Sets

Prepare a directory for storing data and logs

#-----------configrs 
#Create data node data and log directories 
mkdir -p /mongodb/sharded_cluster/myconfigrs_27019/log \ & 
mkdir -p /mongodb/sharded_cluster/myconfigrs_27019/data/db \ & 
mkdir -p /mongodb/sharded_cluster/myconfigrs_27119/log \ & 
mkdir -p /mongodb/sharded_cluster/myconfigrs_27119/data/db \ & 
mkdir -p /mongodb/sharded_cluster/myconfigrs_27219/log \ & 
mkdir -p /mongodb/sharded_cluster/myconfigrs_27219/data/db
Copy the code

Create or modify a configuration file

vim /mongodb/sharded_cluster/myconfigrs_27019/mongod.conf
Copy the code

vim /mongodb/sharded_cluster/myconfigrs_27119/mongod.conf
Copy the code

vim /mongodb/sharded_cluster/myconfigrs_27219/mongod.conf
Copy the code

myconfifigrs_27019/mongod.conf

SystemLog: #MongoDB sends all logs to destination: file# The path to the log file to which mongod or Mongos should send all diagnostic logging information
   path: "/mongodb/sharded_cluster/myconfigrs_27019/log/mongod.log"# When the Mongos or Mongod instance is restarted, Mongos or Mongod appends the new entry to the end of the existing log file. logAppend:true
storage:
   The directory in which the mongod instance stores its data. The storage.dbpath setting applies only to Mongod.
   dbPath: "/mongodb/sharded_cluster/myconfigrs_27019/data/db"Journal: # Enable or disable persistent logging to ensure that data files remain valid and recoverable. enabled:trueProcessManagement: # Enable daemon mode to run mongos or Mongod processes in the background. fork:true# specify the file location used to hold the process ID of mongos or Mongod, where Mongos or Mongod will write its PID pidFilePath:"/mongodb/sharded_cluster/myconfigrs_27019/log/mongod.pid"When the replica is initialized, the node name is automatically set to the local domain name instead of IP #bindIpAll:trueBindIp: localhost,192.16883.133.#bindIp #bind port:27019Replication: # Name of the replica set replSetName: myConfigRs Sharding: # Sharding Role clusterRole: ConfigSvrCopy the code

Myconfifigrs_27119 /mongod. Conf and myConfiFigrs_27219 / Mongod
Start the three Mongod services in turn
(1) Initialize the replica set and create the master node
- Use client commands to connect to either node, but try to connect to the primary node
- Execute the initialize replica set command:rs.initiate()
- View replica sets (excerpt) :rs.status()

Add two replica nodes

Rs. The add (" 192.168.83.133:27119) rs. Add (" 192.168.83.133:27219) rs. The status ()Copy the code

7.6 Creating and Performing operations on routing Nodes

7.6.1 Creation and connection of the first routing node

Prepare a directory for storing data and logs

#-----------mongos01 
mkdir -p /mongodb/sharded_cluster/mymongos_27017/log
Copy the code

Create or modify the mymongos_27017/mongos.conf configuration file

vi /mongodb/sharded_cluster/mymongos_27017/mongos.conf
Copy the code

SystemLog: #MongoDB sends all logs to destination: file# The path to the log file to which mongod or Mongos should send all diagnostic logging information
   path: "/mongodb/sharded_cluster//mymongos_27017/log/mongod.log"# When the Mongos or Mongod instance is restarted, Mongos or Mongod appends the new entry to the end of the existing log file. logAppend:trueProcessManagement: # Enable daemon mode to run mongos or Mongod processes in the background. fork:true# specify the file location used to hold the process ID of mongos or Mongod, where Mongos or Mongod will write its PID pidFilePath:"/mongodb/sharded_cluster//mymongos_27017/log/mongod.pid"When the replica is initialized, the node name is automatically set to the local domain name instead of IP #bindIpAll:trueBindIp: localhost,192.16883.133.#bindIp #bind port:27017Sharding: # specify configDB: myConfigrs /192.16883.133.:27019.192.16883.133.:27119.192.16883.133.:27219	
Copy the code

Start the Mongos service

./mongos -f /mongodb/sharded_cluster/mymongos_27017/mongos.conf
Copy the code

The client logs in to Mongos and can view the library, but cannot write data

Cause: Through the routing node operation, only the configuration node is connected, but the shard data node is not connected, so the business data cannot be written

7.6.2 Configuring Fragments on routing Nodes

(1) Add sharding using command:
```
sh.addShard("IP:Port")
Copy the code
```
- Add the first set of shard replicas
```
Sh. AddShard (" myshards01/192.168.83.133:27018192168 83.133:27118192168 83.133:27218 ")Copy the code
```
- Viewing fragment status:sh.status()
- Go ahead and add the second set of shard replicas
```
Sh. AddShard (" myshards02/192.168.83.133:27318192168 83.133:27418192168 83.133:27518 ")Copy the code
```
- Warning: If the fragment fails to be added, manually remove the fragment and check the information before adding the fragment again
Remove the shard
```
use admin 
db.runCommand( { removeShard: "myshards02" } )
Copy the code
```
Note: If only the last shard is left, the shard data will be automatically transferred when the shard is removed. A time process is required. After the shard is deleted, the shard data can be deleted again
(2) Enable sharding
- Sh.enablesharding (” library name “), sh.shardCollection(” library name “). A collection of “{” key” : 1})
(3) Collection sharding
- For collection sharding, you must specify the collection and sharding keys using the sh.shardCollection() method
- Grammar:
```
sh.shardCollection(namespace,key,unique)
Copy the code
```
- To fragment a collection, you need to select a Shard Key that must be included in each record, and the Shard Key is established
  
  For a single field or compound field of an index,MongoDB divides the data into different data blocks based on slice keys and distributes the data blocks evenly
  
  To divide data blocks by slice keys,MongoDB uses hash based sharding (random average allocation) or bases
  
  Sharding in range (value size allocation)
  
  Nickname = “nickname” = “nickname
- Fragmentation rules
  - Sharding rule 1: Hash strategy
    
    For hash-based sharding,MongoDB computes the hash value of a field and uses the hash value to create blocks of data. In systems that use hash-based sharding, documents with “close” slice keys are likely not stored in the same data block, so data partitioning
    
    Separation is better
    
    Example: Data is fragmented according to the hash value of nickname as the slice key
```
sh.shardCollection("articledb.comment",{"nickname":"hashed"})
Copy the code
```
    Viewing fragment status:sh.status()
  - Sharding rule 2: Scope policy
    
    For range-based sharding,MongoDB divides the data into different parts based on the range of slice keys. Suppose you have a digit slice key: Imagine a line from minus infinity to infinity, and the value of each slice key draws a point on the line. MongoDB divides this line into shorter, non-overlapping pieces called blocks, each of which contains data within a certain range of slice keys. In systems that use slice keys for scoping, documents with “close” slice keys are likely to be stored in the same data block, and therefore in the same shard.
    
    Example: Shard by age value using the author age field as the shard key
```
sh.shardCollection("articledb.author",{"age":1})
Copy the code
```
    Viewing fragment status:sh.status()
  - Note that:
    
    1) A set can only specify one slice key, otherwise an error is reported.
    
    2) Once a collection is sharded, the sharding key and sharding value cannot be changed. For example, you cannot select different sharding keys for the collection or update the values of the sharding keys
    
    3) Allocate data according to age index
- Performance comparison between range-based sharding and hashing sharding
  - Range-based sharding provides more efficient range queries. Given a range of slice keys, distribution routing makes it easy to determine which data block stores the requested data and forward the request to the corresponding shard. However, scope-based sharding can lead to uneven data across shards, and sometimes the negative effects outweigh the positive effects of query performance. For example, if the field in which the slice key is located grows linearly, all requests for a given period of time will fall into a fixed chunk of data, resulting in distribution in the same shard. In this case, a small number of shards carry most of the data in the cluster, and the system does not scale well.
  - In contrast, sharding based on hash ensures data balance in the cluster at the cost of range query performance. The randomness of the hash values causes the data to be randomly distributed in each data block, and therefore in different slices. But also because of randomness, it is difficult for a range query to determine which shards should be requested, and often all shards need to be requested in order to return the desired result
  - Otherwise, Hash Sharding is recommended
    - Using _id as the slice key is a good choice because it is mandatory, and you can use the hash of the data document _id as the slice key. This scheme ensures that reads and writes are evenly distributed, and it ensures that each document has a different slice key so that the data blocks are fine
    - Still not perfect, as a query against multiple documents would have to hit all shards. That said, it’s a better solution
    - Ideally, shard keys allow documents to be distributed evenly across the cluster

7.6.3 Inserting Data after Fragmentation

(1) Test 1 (hash rule) : After logging in to Mongos, insert 1000 pieces of data into the comment loop

 use articledb
 for(var i=0; i<=1000; i++){db.comment.insert({_id:i+"".nickname:"BoBo"+i})}
 db.comment.count()
Copy the code

Tip: js syntax, because mongo’s shell is a JavaScript shell
Note: Data inserted from the route must contain a slice key, otherwise it cannot be inserted
The test results
- Log in to the master node of the two slices and count the number of documents
- The first shard replica setdb.comment.count()Article 508. Note that switch the database under articledb
- The second shard replica setdb.comment.count()Article 493. Note that switch the database under articledb
conclusion
- It can be seen that 1000 pieces of data are almost evenly distributed on the two shards. Is assigned based on the hash value of the slice key. This allocation is easy to scale horizontally: once the data store needs more space, shards can be added, while improving performance
- Use db.ment.stats () to view the complete state of a single collection. Mongos executes this command to view the state of the data sharding of the collection
- Use sh.status() to view shard information for all collections in the library

(2) Test 2 (scope rule) : After logging in to MONgs, insert 20000 pieces of data into comment loop for test
Note: If you check the status and find no sharding, it may be caused by the following reasons:

1) The system is busy and sharding.

2) The chunk is not filled up. The default chunksize is 64M. After the chunk is filled up, other chunks will be considered
- The data block fills the data, so for testing, you can make it smaller, in this case 1M, as follows
```
use config 
db.settings.save( { _id:"chunksize", value: 1 } )
Copy the code
```
- Test it and change it back
```
db.settings.save( { _id:"chunksize", value: 64 } )
Copy the code
```

// Insert data
use articledb
for(var i=1; i<=20000; i++) {db.author.save({"name":"BoBoBoBoBoBoBoBoBoBoBoBoBoBoBoBoBoBoBoBoBoBoBoBoBoBoBoB oBoBoBoBoBoBoBoBo"+i,"age":NumberInt(i%120)})}
Copy the code

View the data of two fragmented replica sets
- The first shard copy set myShards01,7681 data
- The second shard replica set myShards02, 18574

7.6.4 Adding another Routing Node

Prepare a directory for storing data and logs

#-----------mongos02 
mkdir -p /mongodb/sharded_cluster/mymongos_27117/log
Copy the code

Create or modify a configuration file

vi /mongodb/sharded_cluster/mymongos_27117/mongos.conf
Copy the code

mymongos_27117/mongos.conf

SystemLog: #MongoDB sends all logs to destination: file# The path to the log file to which mongod or Mongos should send all diagnostic logging information
   path: "/mongodb/sharded_cluster//mymongos_27117/log/mongod.log"# When the Mongos or Mongod instance is restarted, Mongos or Mongod appends the new entry to the end of the existing log file. logAppend:trueProcessManagement: # Enable daemon mode to run mongos or Mongod processes in the background. fork:true# specify the file location used to hold the process ID of mongos or Mongod, where Mongos or Mongod will write its PID pidFilePath:"/mongodb/sharded_cluster//mymongos_27117/log/mongod.pid"When the replica is initialized, the node name is automatically set to the local domain name instead of IP #bindIpAll:trueBindIp: localhost,192.16883.133.#bindIp #bind port:27117Sharding: # specify configDB: myConfigrs /192.16883.133.:27019.192.16883.133.:27119.192.16883.133.:27219	
Copy the code

Start the Mongos service./mongos -f /mongodb/sharded_cluster/mymongos_27117/mongos.conf
Use mongo client to log in 27117, and find that the second route does not need to be configured, because the shard configuration is saved to the configuration server

6.7 SpringDataMongoDB Connects the shard cluster

The SpringDataMongoDB client configuration for multiple routes is as follows

server:
  port: 7777


spring:
# data source configuration
  data:
    mongodb:
# host address
# host: 192.168.83.133
The default port is 27017
# port: 27017
# # database
# database: test
    The connection string for the replica set
      # uri: mongo: / / 192.168.83.133:27017192168 83.133:27018192168 83.133:27019 / articledb? connect=replicaSet&slaveOk=true&replicaSet=myrs
    # connect route string
      uri: Mongo: / / 192.168.83.133:27017192168 83.133:27117 / articledb
Copy the code

Logs show that a route is selected to write data

7. Safety certification

7.1 User and Role Rights of the MongoDB Service

By default, the user access permission control is not enabled when the MongoDB instance is started and run, that is to say, the local server of the instance can be connected to the instance for all kinds of operations, and MongoDB does not conduct user authentication on the connected client, which is very dangerous
According to the mongodb website, you can do the following steps to ensure the security of mongodb:

1) Use a new port. The default port 27017 is not secure if it can be connected once the IP is known

2) Set up the network environment of mongodb. It is best to deploy mongodb to the internal server of the company, so that the external network can not access, and the company uses VPN for internal access

3) Enable security authentication. Set the internal authentication mode between servers and the account and password authentication mode for clients to connect to the cluster
To force user access control (user authentication) on, use the option –auth at startup of the MongoDB instance or add the option auth=true to the specified startup profile
Relevant concepts
- 1) Enable access control:
  
  MongoDB uses role-based Access Control (RBAC) to manage users’ Access to instances
  
  By granting users one or more roles to control user access to database resources and database operation permissions. Before assigning users roles, users cannot access instances. Add the option –auth =true when instances are started or specify the option auth=true in the startup configuration file
- 2) Roles:
  
  In MongoDB, users are granted the operation permissions of database resources by roles. The permissions of each role can be explicitly specified, or inherited from other roles, or both.
- 3) Permissions: Permissions consist of specified database resources and actions allowed on specified resources
  - Resources include databases, collections, partial collections, and clusters.
  - Actions Include adding, deleting, modifying, and querying resources (CRUD).
A role can contain one or more existing roles. A newly created role inherits all permissions of the roles. In the same database, a newly created role can inherit the rights of other roles. A role created in the admin database can inherit the rights of roles in other databases
Common built-in roles
- Database user roles: read and readWrite
- All database user roles: readAnyDatabase, readWriteAnyDatabase, userAdminAnyDatabase, and dbAdminAnyDatabase
- Database management roles: dbAdmin, dbOwner, and userAdmin
- Cluster management roles: clusterAdmin, clusterManager, clusterMonitor, and hostManager
- Backup and restore roles: backup and restore
- Super user role: root
- Internal role: System
Common role permission description
- Read: Any data in the specified database can be read
- ReadWrite: You can read and write any data in a specified database, including creating, renaming, and deleting collections
- UserAdmin: you can create and modify users in the specified database
- Root: super permission

7.2 Single-instance Environment

Objective: Enable security authentication for the MongoDB service of a single instance. The single instance refers to the MongoDB instance that has no replica set or sharding enabled

7.2.1 (Optional) Disabling Enabled Services

Added mongod security authentication for single instances, which can be added directly at the time of service construction or on previously built services
There are two ways to stop a service: quick shutdown and standard shutdown
- Quick shutdown method (quick, simple, and data error prone) : Kill the process by running the kill command
```
kill -2 pID
Copy the code
```
- Standard shutdown method (data is not error-prone, but troublesome) : Shut down the service through the shutdownServer command in the Mongo client
```
// If you want to log in to the server remotely, you must log in to the server with authentication first. Mongo --port 27017 use admin // disable db.shutdownServer()Copy the code
```

Add: If data is corrupted, you need to do the following (understand)

(1) Delete lock file

rm -f /mongodb/single/data/db/*.lock
Copy the code

(2) Data repair

/usr/local/mongodb/bin/mongod --repair --dbpath=/mongodb/single/data/db
Copy the code

7.2.2 Adding Users and Rights

Start the Mongod service in single single mode
Client connection 27017
When operating users, try not to enable authorization when starting the Mongod service

Create two administrator users, one is the system super administrator myroot, one is the admin database management user myadmin

// Switch to the admin library
use admin 
// Create system super user myroot, password: 123456, set role: root
db.createUser({user:"myroot".pwd:"123456".roles: ["root"]})
// create account myadmin to manage user permissions
db.createUser({user:"myadmin".pwd:"123456".roles: [{role:"userAdminAnyDatabase".db:"admin"}]})
// View the user that has been created
db.system.users.find()

// Delete the user
db.dropUser("myadmin")
// Change the password
db.changeUserPassword("myroot"."123456")
Copy the code

prompt
- 1) This example creates two users, one for supermanagement and one for managing users. In fact, you only need one user. Do not create supermanaged users if you have high security requirements to prevent supermanaged leaks
- 2) Like other databases (MySQL), the management of permissions is almost the same, and the information of users and permissions is saved in the corresponding tables of the database. Mongodb stores all user information. The user name, password, and database information are stored in the admin database set system.users.
- {role:”userAdminAnyDatabase”, db:””}

Certification test

Db. auth("myroot","12345") // Password error: failed db.auth("myroot","123456")Copy the code

Creating a Common User
- Create a common user. You can add a common user when authentication is not enabled or after authentication is enabled. After authentication is enabled, the user must be enabled
  
  Use the admin user to log in and authenticate before operation. The bottom layer is a collection of user information stored in the admin database
- ```
Db.createuser ({user: createUser, createUser, createUser, createUser, createUser, createUser); Roles: [{role: "readWrite", db: "articledb"}]})Copy the code
```
Note: If authentication is enabled, the user logging in to the client must use the role of admin, such as the role of myadmin with root

User, and then through the myadmin user to create other roles of users

7.2.3 Enabling Authentication and Client Login on the Server

Stop services that have been started
There are two ways to enable permission authentication and start the service: parameter or configuration file
- Parameters of the way
- The configuration file
```
vim /mongodb/single/mongod.conf
Copy the code
```
```
Security: # Enable authorization: enabledCopy the code
```
There are two authentication methods. One is to log in first and authenticate in Mongo shell. One is direct authentication at login
- Connect first and then authenticate
  - ```
  db.auth("muroot","123456")
  Copy the code
```
- Direct authentication at connection time
  - ```
   ./mongo --port 27017 --authenticationDatabase admin -u myroot -p 123456
  Copy the code
```
- Tip:
  
  -u: indicates the user name
  
  P: password
  
  –authenticationDatabase: Specifies the connection library. If the login is to specify a user name and password, you must specify the corresponding database

7.2.4 SpringDataMongoDB Connection authentication

To connect to the MongoDB server using username and password, you must use the format ‘username:password@hostname/dbname’ with ‘username’ as the username and ‘password’ as the password
Target: Connect to the MongoDB service as user bobo using password 123456

7.3 Replica Set Environment

7.3.1 preface

For the built mongodb replica set, enable security authentication and log in using the account and password for security
The replica set environment was built before use
There are two aspects to configuring access control over replica sets
- Internal authentication is used between replica sets and individual node members of the shared cluster, either using key files or X.509 certificates. This document uses a key file. It is recommended that you use a key file in a test environment, but x.509 certificates are recommended in a formal environment. The principle is that each instance in the cluster connects to each other to verify whether the content of the certificate used by each other is the same. Only instances with the same certificate can access each other
- Enable access authorization when connecting to the mongodb cluster using a client. Access outside the cluster. Authorization needs to be enabled when connecting through visual clients or code
In KeyfiFile authentication, each Mongod instance in the replica set uses the contents of the Keyfifile as a shared password, and only mongod or Mongos instances with the correct key file can connect to the replica set. The contents of the key file must be between 6 and 1024 characters, and on Unix/Linux systems the file owner must have at least read permission on the file

7.3.2 (Optional) Disabling the Enabled Replica Set Service

Shut down the standalone Mongod service used in the previous tests

7.3.3 Adding an Administrator Account on the Active Node

Start the replica set service in sequence
You simply add users on the primary node and the replica set synchronizes automatically
Before enabling authentication, create the supermanagement user myroot and password 123456

7.3.4 Creating a Key File for Replica Set Authentication

Step 1: Generate a key file to the current folder
- Key files can be generated using any method. For example, the following uses OpenSSL to generate a password file, and then uses chmod to change the file permissions so that only the file owner has read permissions
- ```
openssl rand -base64 90 -out ./mongo.keyfile
chmod 400 ./mongo.keyfile
ll mongo.keyfile
Copy the code
```
Tip:

All replica set nodes must use the same keyfifile, which is usually generated on one machine and then copied to another machine, and must have read permission. Otherwise, an error will be reported in the future: permissions on /mongodb/replica_sets/myrs_27017/mongo.keyfile are too open

Make sure that the key files are consistent, regardless of location. But for easy lookup, it is recommended that each machine be placed in a single location, in the same directory as the configuration file, which is copied to multiple directories
```
cp mongo.keyfile /mongodb/replica_sets/myrs_27017
cp mongo.keyfile /mongodb/replica_sets/myrs_27018
cp mongo.keyfile /mongodb/replica_sets/myrs_27019
Copy the code
```

7.3.5 Modifying a Configuration File to Specify keyFile

Edit the mongod. Conf file for each service and add relevant content:

/mongodb/replica_sets/myrs_27017/mongod.conf
```
Security: #KeyFile Authentication file KeyFile: /mongodb/replica_sets/myrs_27017/mongo. KeyFileCopy the code
```
- /mongodb/replica_sets/myrs_27018/mongod. Conf /mongodb/replica_sets/myrs_27019/mongod
After modifying the configuration, start the replica set service one by one

7.3.6 SpringDataMongoDB connection replica set

Yml file

server:
  port: 7777


spring:
# data source configuration
  data:
    mongodb:
# host address
# host: 192.168.83.133
The default port is 27017
# port: 27017
# # database
# database: test
      # username
      # username: bobo
      # your password
      # password: 123456
    The connection string for the replica set
      # uri: mongo: / / 192.168.83.133:27017192168 83.133:27018192168 83.133:27019 / articledb? connect=replicaSet&slaveOk=true&replicaSet=myrs
    # connect route string
      # uri: mongo: / / 192.168.83.133:27017192168 83.133:27117 / articledb
      String concatenation is also used when the server is authenticated
      # uri: mongo: / / bobo: 123456 @192.168.83.133:27017 / articledb
      # copy set has authentication in case of string connection
      uri: Mongo: / / myroot: 123456 @192.168.83.133:27017192168 83.133:27018192168 83.133:2 7019/articledb? connect=replicaSet&slaveOk=true&replicaSet=myrs
Copy the code

7.4 Authentication in a Fragmented Cluster environment

Make sure that the key files are consistent, regardless of location. But for easy searching, it is recommended that each machine be placed in a fixed location,

Put them in the same directory as the configuration files. Here, copy the file to multiple directories

echo '/mongodb/sharded_cluster/myshardrs01_27018/mongo.keyfile /mongodb/sharded_cluster/myshardrs01_27118/mongo.keyfile /mongodb/sharded_cluster/myshardrs01_27218/mongo.keyfile /mongodb/sharded_cluster/myshardrs02_27318/mongo.keyfile /mongodb/sharded_cluster/myshardrs02_27418/mongo.keyfile /mongodb/sharded_cluster/myshardrs02_27518/mongo.keyfile /mongodb/sharded_cluster/myconfigrs_27019/mongo.keyfile /mongodb/sharded_cluster/myconfigrs_27119/mongo.keyfile /mongodb/sharded_cluster/myconfigrs_27219/mongo.keyfile /mongodb/sharded_cluster/mymongos_27017/mongo.keyfile /mongodb/sharded_cluster/mymongos_27117/mongo.keyfile' | xargs -n 1 cp -v /root/mongo.keyfile
Copy the code

The shard replica set operates with the replica set
Different: /mongos. Conf Mongos service configuration file to add authentication
```
KeyFile: /mongodb/sharded_cluster/mymongos_27017/mongo.keyfileCopy the code
```
Authorization: Enabled configuration is not required. The reason is that the security authentication of replica set plus fragment needs to be configured in two aspects. Internal authentication is used between each node of replica set and communication between each internal Mongo instance, and only the same keyfifile is used

To visit each other. KeyFile: /mongodb/sharded_cluster/mymongos_27117/mongo.keyfile. However, for all mongods, this is the true shards to save data. Mongos only does routing and does not save data. So all mongods enable authorization: Enabled for data access. In this way, users can access data only if their account and password are correct

SpringDataMongoDB connection authentication

server:
  port: 7777


spring:
# data source configuration
  data:
    mongodb:
# host address
# host: 192.168.83.133
The default port is 27017
# port: 27017
# # database
# database: test
      # username
      # username: bobo
      # your password
      # password: 123456
    The connection string for the replica set
      # uri: mongo: / / 192.168.83.133:27017192168 83.133:27018192168 83.133:27019 / articledb? connect=replicaSet&slaveOk=true&replicaSet=myrs
    # connect route string
      # uri: mongo: / / 192.168.83.133:27017192168 83.133:27117 / articledb
      String concatenation is also used when the server is authenticated
      # uri: mongo: / / bobo: 123456 @192.168.83.133:27017 / articledb
      # copy set has authentication in case of string connection
      # uri: mongo: / / myroot: 123456 @192.168.83.133:27017192168 83.133:27018192168 83.133:2, 7019 / articledb? connect=replicaSet&slaveOk=true&replicaSet=myrs
      # Shard cluster has authentication in case of string connection
      uri: Mongo: / / myroot: 123456 @192.168.83.133:27017192168 83.133:27117 / articledb
Copy the code

MongoDB clustering and security

6. Replica Sets (*)

6.1 introduction

6.2 Three roles in the replica set

6.3 Replica set architecture objectives

6.4 Creating replica Sets

6.4.1 Step 1: Create an active node

6.4.2 Step 2: Create a replica node

6.4.3 Step 3: Create blanking node

6.4.4 Step 4: Initialize the replica set and primary node

6.4.5 Viewing the Replica Set Configuration

6.4.6 Adding a Secondary Replica Node

6.4.7 Adding a Secondary Quorum Node

6.5 Data Read and Write Operations on replica Sets

6.6 Election Rules for the Primary Node

6.7 Fault Testing (*)

6.7.1 Testing Duplicate Node Faults

6.7.2 Testing faults on the active Node

6.7.3 The Quorum Node and primary Node are Faulty

6.7.4 The Quorum Node or Secondary Node is Faulty

6.8 Compass Connects the replica set

6.9 SpringDataMongoDB Connection Replica Set (*)

7. Sharded Cluster (*)

7.1 Sharding Concept

7.2 Components in a Sharded Cluster

7.3 Sharding Cluster Architecture Objectives

7.4 Creating a Fragment Node Replica Set

7.4.1 First set of replicas

7.4.2 Second set of replicas

7.5 Configuring the Creation of node Replica Sets

7.6 Creating and Performing operations on routing Nodes

7.6.1 Creation and connection of the first routing node

7.6.2 Configuring Fragments on routing Nodes

7.6.3 Inserting Data after Fragmentation

7.6.4 Adding another Routing Node

6.7 SpringDataMongoDB Connects the shard cluster

7. Safety certification

7.1 User and Role Rights of the MongoDB Service

7.2 Single-instance Environment

7.2.1 (Optional) Disabling Enabled Services

7.2.2 Adding Users and Rights

7.2.3 Enabling Authentication and Client Login on the Server

7.2.4 SpringDataMongoDB Connection authentication

7.3 Replica Set Environment

7.3.1 preface

7.3.2 (Optional) Disabling the Enabled Replica Set Service

7.3.3 Adding an Administrator Account on the Active Node

7.3.4 Creating a Key File for Replica Set Authentication

7.3.5 Modifying a Configuration File to Specify keyFile

7.3.6 SpringDataMongoDB connection replica set

7.4 Authentication in a Fragmented Cluster environment

Related Posts

Docker rancher structures,

DFS algorithm

Set up Ceph system to provide storage for K8S