MongoDB Beginner Learning (a): MongoDB Installation and management

Used MySQL database, the whole day is to write a large heap of SQL statements, to remember that these SQL keywords are going to take a few days, write the eggs are exploded, when the contact to MongoDB, found not to write SQL, instantly feel tall on, instantly generated the impulse to learn to use it.

1.MongoDB Introduction

MongoDB is a powerful, flexible, and scalable way of storing data. It extends the many useful features of a relational database, such as secondary indexes, scope queries, and sorting. MongoDB is very versatile, such as the built-in support for MapReduce aggregation, and the support for geospatial indexing. There are many and many features ...

For the entry level of the people, these are floating clouds, I now do not realize its capacity, but also do not realize its horizontal expansion, more than the rate of it, these are when we play to a certain state will be concerned about the problem. I simply think its benefits are very easy to use, provide a series of APIs, do not write SQL statements. What is the difference between it and the relational database, what are the advantages or what shortcomings need to be improved is the future.

Installation of 2.MongoDB

MongoDB's official website is downloaded, according to the system Windows or Linux or other download 32-bit or 64-bit, and then unzip the installation. I installed on Linux, just started on their own virtual machine through the root with Yum installed, and later through the SECURECRT connection to the other server on their own users to install learning, so you can play their own mongodb not to hang the server above, But this can not be through yum, source installation seems to have a lot of software dependencies, so on the official web download a Linux version, and then upload to the server via SFTP after decompression directly to use.

Management of 3.MongoDB

After the decompression into the bin directory, there are some executable files, Mongo,mongod,mongodump,mongoexport, and so on, and then say what their role.

1). Start and stop MongoDB

By executing Mongod to start the MongoDB server, Mongod has a lot of configuration startup options that can be viewed through Mongod--help, some of which are the main options:

--dbpath: Specifies the data directory, which is/data/db/by default. Each mongod process requires a separate directory, and a Mongod.lock file is created in the data directory when the Mongod is started, preventing other mongod processes from using the data directory.

--port: Specifies the port on which the server listens, default is 27017.

--fork: Runs MongoDB as a daemon.

--logpath: Specifies the log output path, which is output at the terminal if not specified. Each boot overwrites the original log and uses the--logappend option if you do not want to overwrite it.

--config: Specifies a configuration file that loads various options that are not specified by the command line. We can say the options we need to write in a file, and then use this option to specify that the file does not have to be written every time you start Mongod.

For example, my configuration file mongodb.conf has the following configuration:

port = 9352
#fork = true #for comments
#logpath = mongodb.log
dbpath = data / db
           Execute mongod to start the MongoDB server with the specified configuration file:

[[email protected] bin] $ ./mongod --config mongodb.conf
2014-06-05T17: 11: 13.118 + 0800 [initandlisten] MongoDB starting: pid = 18077 port = 9352 dbpath = data / db 64-bit host = server0.169
2014-06-05T17: 11: 13.119 + 0800 [initandlisten] db version v2.6.1
2014-06-05T17: 11: 13.119 + 0800 [initandlisten] git version: 4b95b086d2374bdcfcdf2249272fb552c9c726e8
2014-06-05T17: 11: 13.119 + 0800 [initandlisten] build info: Linux build14.nj1.10gen.cc 2.6.32-431.3.1.el6.x86_64 # 1 SMP Fri Jan 3 21:39:27 UTC 2014 x86_64 BOOST_LIB_VERSION = 1_49
2014-06-05T17: 11: 13.119 + 0800 [initandlisten] allocator: tcmalloc
2014-06-05T17: 11: 13.119 + 0800 [initandlisten] options: {config: "mongodb.conf", net: {port: 9352}, storage: {dbPath: "data / db"}}
2014-06-05T17: 11: 13.246 + 0800 [initandlisten] journal dir = data / db / journal
2014-06-05T17: 11: 13.246 + 0800 [initandlisten] recover: no journal files present, no recovery needed
2014-06-05T17: 11: 15.333 + 0800 [initandlisten] preallocateIsFaster = true 20.74
2014-06-05T17: 11: 17.692 + 0800 [initandlisten] preallocateIsFaster = true 13.72
2014-06-05T17: 11: 20.858 + 0800 [initandlisten] preallocateIsFaster = true 23.86
2014-06-05T17: 11: 20.858 + 0800 [initandlisten] preallocateIsFaster check took 7.612 secs
2014-06-05T17: 11: 20.858 + 0800 [initandlisten] preallocating a journal file data / db / journal / prealloc.0
2014-06-05T17: 11: 23.121 + 0800 [initandlisten] File Preallocator Progress: 492830720/1073741824 45%
2014-06-05T17: 11: 26.424 + 0800 [initandlisten] File Preallocator Progress: 681574400/1073741824 63%
2014-06-05T17: 11: 29.004 + 0800 [initandlisten] File Preallocator Progress: 964689920/1073741824 89%
2014-06-05T17: 11: 34.558 + 0800 [initandlisten] preallocating a journal file data / db / journal / prealloc.1
2014-06-05T17: 11: 37.089 + 0800 [initandlisten] File Preallocator Progress: 524288000/1073741824 48%
2014-06-05T17: 11: 40.090 + 0800 [initandlisten] File Preallocator Progress: 807403520/1073741824 75%
2014-06-05T17: 11: 43.063 + 0800 [initandlisten] File Preallocator Progress: 1017118720/1073741824 94%
2014-06-05T17: 11: 48.020 + 0800 [initandlisten] preallocating a journal file data / db / journal / prealloc.2
2014-06-05T17: 11: 51.040 + 0800 [initandlisten] File Preallocator Progress: 576716800/1073741824 53%
2014-06-05T17: 11: 54.039 + 0800 [initandlisten] File Preallocator Progress: 807403520/1073741824 75%
2014-06-05T17: 11: 57.026 + 0800 [initandlisten] File Preallocator Progress: 1069547520/1073741824 99%
2014-06-05T17: 12: 01.985 + 0800 [FileAllocator] allocating new datafile data / db / local.ns, filling with zeroes ...
2014-06-05T17: 12: 01.985 + 0800 [FileAllocator] creating directory data / db / _tmp
2014-06-05T17: 12: 02.285 + 0800 [FileAllocator] done allocating datafile data / db / local.ns, size: 16MB, took 0.167 secs
2014-06-05T17: 12: 02.315 + 0800 [FileAllocator] allocating new datafile data / db / local.0, filling with zeroes ...
2014-06-05T17: 12: 02.413 + 0800 [FileAllocator] done allocating datafile data / db / local.0, size: 64MB, took 0.097 secs
2014-06-05T17: 12: 02.434 + 0800 [initandlisten] build index on: local.startup_log properties: {v: 1, key: {_id: 1}, name: "_id_", ns: "local.startup_log"}
2014-06-05T17: 12: 02.434 + 0800 [initandlisten] added index to empty collection
2014-06-05T17: 12: 02.456 + 0800 [initandlisten] command local. $ Cmd command: create {create: "startup_log", size: 10485760, capped: true} ntoreturn: 1 keyUpdates: 0 numYields: 0 reslen: 37 494ms
2014-06-05T17: 12: 02.457 + 0800 [initandlisten] waiting for connections on port 9352
           Start the MongoDB server successfully, listen on port 9352, and wait for the client to connect. If log files are specified, these logs are output to the specified log file. If set to a daemon process, a child process will be created, and the parent process will exit when the MongoDB server is started.

           It is important for MongoDB to stop securely, because some data may still be cached and not written to disk. A secure stop is to first write data to disk and then end the MongoDB process. You can use ctrl + c to stop the MongoDB server directly, or you can use the client. Mongo is a javascript shell, and it will automatically connect to the MongoDB server when it is started. Can operate the database. Let's take a look at mongo stopping the MongoDB server:

[[email protected] bin] $ ./mongo --port 9352
MongoDB shell version: 2.6.1
connecting to: 127.0.0.1:9352/test
> show dbs
admin (empty)
local 0.078GB
test (empty)
> use admin
switched to db admin
> db.shutdownServer ()
2014-06-05T17: 21: 59.263 + 0800 DBClientCursor :: init call () failed
server should be down ...
2014-06-05T17: 21: 59.265 + 0800 trying reconnect to 127.0.0.1:9352 (127.0.0.1) failed
2014-06-05T17: 21: 59.266 + 0800 warning: Failed to connect to 127.0.0.1:9352, reason: errno: 111 Connection refused
2014-06-05T17: 21: 59.266 + 0800 reconnect 127.0.0.1:9352 (127.0.0.1) failed failed couldn't connect to server 127.0.0.1:9352 (127.0.0.1), connection attempt failed
exit
bye
           As can be seen from the above, we are connected to the local 9352 port test database. Admin is a root database. This database is used to manage the entire MongoDB. Not anyone can stop the MongoDB server, so we must use admin to execute shutdownServer () Come to stop.

        2). Safety and certification

           The above uses the mongo client to connect to the MongoDB server without any security authentication, which means that anyone can connect to it. Of course, you can run it in a trusted environment to ensure that only trusted machines can access it, and you can Authentication for a single connection. each Each MongoDB database can have many users. If security checking is enabled, only database authenticated users can perform related operations. The admin user can read and write to any database. Users in other databases can only perform operations with related permissions.

           Before enabling security checks, create a few users:

> use admin
switched to db admin
> db.addUser ("tp", "12345")
WARNING: The 'addUser' shell helper is DEPRECATED. Please use 'createUser' instead
Successfully added user: {"user": "tp", "roles": ["root"]}
> use test
switched to db test
> db.addUser ("test1", "12345", true)
WARNING: The 'addUser' shell helper is DEPRECATED. Please use 'createUser' instead
Successfully added user: {"user": "test1", "roles": ["read"]}
> db.addUser ("test2", "12345")
WARNING: The 'addUser' shell helper is DEPRECATED. Please use 'createUser' instead
Successfully added user: {"user": "test2", "roles": ["dbOwner"]}
> use admin
switched to db admin
> show collections
system.indexes
system.users
system.version
> db.system.users.find ()
{"_id": "admin.tp", "user": "tp", "db": "admin", "credentials": {"MONGODB-CR": "e4aafd1c8d19d9e490192fe5bf43ffe0"}, "roles": [{" role ":" root "," db ":" admin "}]}
{"_id": "test.test1", "user": "test1", "db": "test", "credentials": {"MONGODB-CR": "2da1438b5a04dd46cfdf97c40a3c6d71"}, "roles": [{" role ":" read "," db ":" test "}]}
{"_id": "test.test2", "user": "test2", "db": "test", "credentials": {"MONGODB-CR": "4accbd2cb1dce25ed8b3b162103b0b87"}, "roles": [{" role ":" dbOwner "," db ":" test "}]}
           A user tp is added in admin, and two users test1 and test2 are added to the test database. AddUser () takes three parameters, the first is the username, the second is the password, and the third is read-only. Set true to read-only. From the user collection system.users, it can be seen that tp is a super user in the admin database, has root permissions, test1 has only read permissions, and test2 is a dbOwner, which can be read or written. addUser can also modify user passwords and read-only status. Now restart the MongoDB server, add the --auth command option to enable the security check, and then connect through mongo:

> show dbs
2014-06-05T17: 59: 57.519 + 0800 listDatabases failed: {
        "ok": 0,
        "errmsg": "not authorized on admin to execute command {listDatabases: 1.0}",
        "code": 13
} at src / mongo / shell / mongo.js: 47
> use test
switched to db test
> db.auth ("test1", "12345")
1
> show collections
people
system.indexes
> db.people.find ()
{"_id": ObjectId ("53903f7af73bb0df22f8e4a6"), "name": "Mary", "age": 10}
> db.people.insert ({"name": "join", "age": 20})
WriteResult ({
        "writeError": {
                "code": 13,
                "errmsg": "not authorized on test to execute command {insert: \" people \ ", documents: [{_id: ObjectId ('53903fd6959e902814f56d8c'), name: \" join \ ", age: 20.0}], ordered: true} "
        }
})
> db.auth ("test2", "12345")
1
> db.people.find ()
{"_id": ObjectId ("53903f7af73bb0df22f8e4a6"), "name": "Mary", "age": 10}
> db.people.insert ({"name": "join", "age": 20})
WriteResult ({"nInserted": 1})
> use admin
switched to db admin
> db.auth ("tp", "12345")
1
> show dbs
admin 0.078GB
local 0.078GB
test 0.078GB
           No user authentication is performed after connecting to the MongoDB server, so nothing can be done. After using the test database and user authentication, you can view the collection in the test library. Because test1 can only read but not write, find can succeed and insert fail. Test2 can both read and write. After using the admin database for user authentication, you can view a list of all databases. In fact, such authentication is not very useful, it is just one way, the most secure way is to restrict access.

        3) .Data backup

           ①. Data file backup

              The simplest backup is the backup of the data files, which is directly assigned the data / db directory, because we have specified that the data directory is data / db, then most of MongoDB's data is here, but there is a problem with the latest data It is still in the cache, it is not necessary to synchronize to disk, you can stop shutdownServer () before backing up. But this will affect the normal work of MongoDB.

           ②.mongodump and mongorestore

              There are two executable files in bin: mongodump and mongorestore. This is a backup of a MongoDB database. It can be backed up when MongoDB is running, such as backing up the test database, and then dumping the backed up database file into another MongoDB. Server. This backup method does not back up the latest data, but only the data that has been written to MongoDB. There may be data that is not written in the cache, so this part of the data cannot be backed up. mongodump and mongorestore can also query all options with --help.

[[email protected] bin] $ ./mongodump --port 9352 -d test -o test_data
connected to: 127.0.0.1
2014-06-05T19: 00: 03.381 + 0800 DATABASE: test to test_data / test
2014-06-05T19: 00: 03.411 + 0800 test.system.indexes to test_data / test / system.indexes.bson
2014-06-05T19: 00: 03.426 + 0800 1 documents
2014-06-05T19: 00: 03.426 + 0800 test.test to test_data / test / test.bson
2014-06-05T19: 00: 03.463 + 0800 1 documents
2014-06-05T19: 00: 03.464 + 0800 Metadata for test.test to test_data / test / test.metadata.json
              -d is the specified database, -o is the output backup file, and the test database is backed up as a test_data file.

[[email protected] bin] $ ./mongorestore --port 9352 -d temple --drop test_data / test /
connected to: 127.0.0.1:9352
2014-06-05T19: 05: 53.454 + 0800 test_data / test / people.bson
2014-06-05T19: 05: 53.454 + 0800 going into namespace [temple.people]
2014-06-05T19: 05: 53.454 + 0800 dropping
2 objects found
2014-06-05T19: 05: 53.454 + 0800 Creating index: {key: {_id: 1}, name: "_id_", ns: "temple.people"}
[[email protected] bin] $ ./mongo --port 9352
MongoDB shell version: 2.6.1
connecting to: 127.0.0.1:9352/test
> show dbs
admin 0.078GB
local 0.078GB
temple 0.078GB
test 0.078GB
              Here, the test database backed up above is now re-imported into the temple database. --Drop means that if there is a temple database, all the collections in it will be deleted. If you do not specify, the collections in the original temple will be merged.

           ③.mongoexport and mongoimport

              As mentioned above, mongodump and mongorestore are backing up a certain database. Then mongoexport and mongoimport are backing up a table in a database. You can also view all the options with --help. Of course, mongoexport can also be backed up without statistics, but It is not necessarily the latest data.

[[email protected] bin] $ ./mongoexport --port 9352 -d test -c people -o prson
connected to: 127.0.0.1:9352
exported 2 records
[[email protected] bin] $ cat prson
{"_id": {"$ oid": "53903f7af73bb0df22f8e4a6"}, "name": "Mary", "age": 10}
{"_id": {"$ oid": "53903ff6959e902814f56d8d"}, "name": "join", "age": 20}
[[email protected] bin] $ ./mongoimport --port 9352 -d temple -c user prson
connected to: 127.0.0.1:9352
2014-06-05T19: 14: 00.555 + 0800 imported 2 objects
[[email protected] bin] $ ./mongo --port 9352
MongoDB shell version: 2.6.1
connecting to: 127.0.0.1:9352/test
> use temple
switched to db temple
> show collections
system.indexes
user
> db.user.find ()
{"_id": ObjectId ("53903f7af73bb0df22f8e4a6"), "name": "Mary", "age": 10}
{"_id": ObjectId ("53903ff6959e902814f56d8d"), "name": "join", "age": 20}
              -c represents the collection collection. The people collection in the test library is backed up as a prson file, and then imported into the user collection in the temple library.

        ④.fsync and lock

              Both mongodump and mongoexport pairs can be backed up without stopping the MongoDB server, but they lose the ability to obtain real-time data, and the fsync command can also back up real-time data without stopping MongoDB. Its implementation is actually locked to prevent the The database write operation, then the buffer data is written to disk, and then unlocked after backup. During this period, any write operation to the database will block until the lock is released.

> db.runCommand ({"fsync": 1, "lock": 1})
{
        "info": "now locked against writes, use db.fsyncUnlock () to unlock",
        "seeAlso": "http://dochub.mongodb.org/core/fsynccommand",
        "ok": 1
}
>
Make a backup in between, blocking any insert operation
>
db.fsyncUnlock ()
{"ok": 1, "info": "unlock completed"}
              I think in fact, real-time is relative. If the database is locked from writing, the latest data is still not backed up.