FAQs
Does the MongoDB instance function differently from the open-source MongoDB?
The MongoDB instance is completely consistent with the native MongoDB.
How secure is MongoDB?
Access Security
MongoDB instances only support intranet login via cloud hosts and are isolated by account, so only cloud hosts of with same account can log in to the MongoDB instance.
MongoDB instances are mandatory for authentication and can only be accessed with authentication.
Data Security
All MongoDB instance data files are stored on the RSSD cloud disk for data protection.
MongoDB instances provide automatic backup functionality that automatically backs up data at scheduled times. At the same time, manual backup is also provided so that users can actively back up data at specific times.
MongoDB cluster data is stored in three replicas for protection.
How to backup and recover?
MongoDB instances support manual backup, allowing users to save important data backups at certain critical points in time. The current number of manual backups allowed is 3; if this limit is exceeded, the earliest manual backup will be automatically deleted. When creating a manual backup, users only need to input the backup name, and the backup process will begin immediately in the background.
Backups can be downloaded to the local machine or to a cloud host.
If you need to restore a MongoDB instance, it is recommended that users first download the backup files to their local system. After professional review, the files can then be imported into the MongoDB instance to mitigate data risks.
How to use authentication?
From the perspective of data security and maintainability, MongoDB instances enforce authentication.. All instances use keyfile authentication, which is equivalent to auth=true. The administrator account and password for MongoDB instances are the admin username and password provided during application.
MongoDB instances uniformly use the keyfile
ymSs/7YgMlxlMMTR9K3B6eKyopWD98MX1KIuySyI8Kk1Coqw1sYZp2Nh4nN5yrul+0J21pIpNOzXU3Mbbl2zihF/qMEkofAWJPeORzZd2VR0c2rwHG4xxuxNRFOK3BSTTSIyAgMfnBVTPwC671E18SJi3r/RohfGxy8NveipsZCqTTRDVcGXKqFf4i3vBRLXil+it1oxPb63ayjYJ7Uz1piVQQRtHlD+KzUEaTzhl/CW9Da8xhq1Lm2bxNUWov/ltDfJSyke+a+a1OlbpGTYwD5WeYINbGYYbJMpC1P6ELCQ2kD1c/Dyae7WNLcDO3ICJSOvGigKIGo3om5M8CeiUJ/xHA67RkJak2idSlXOopIEdjjAxtFRPWaF8jEoMgtOSty2OQMBpBYDYcwgRRFL8+fQQvHd1c6sQoXUoN1JbBqhtNxpvlm05keinIP9Al+EeIA1itZjUBcjC5zZgAAPHbXe803TosCupq/jS2W6K8MBEOUg+42u4r8g4Sp2LKdbqqdza1PlBHFQmExSz2pAN61DwZPKjMlBArlCpa5Kk/44DzOc9Lc3bW51AdieG5xFad6d9qS0LLFFeG4tB5HcbUCCKWkVdUM5ocCb0TTRfJ2KNTRaJUTfKq4WLCe1zrIeHCvQIbKVJLgyo/3HHgse331daqVRm+rAAPWwgXVKbo/+XfYkS28ftDMOA6spIN1Vsba+UGdLjGFiq40xLSCA5z0RvB88oYouuyw16VAQuv1JzUk4tzZ9f5Snr1MlyI5rrjO6DZeDT3WYOK9TGRDshWHuVjDCtvDTYPjACy0Jy4Uhikze+pz9gAUbmJNUeU14CZb5EA1/mkICjpbIJigG1lduERa1g5OFv3cS4UIyh8V/zE11rjVdLva0Fq58w713kO6t40xG2QWbpTX/D5VWVH7j0Uq4QX3xSUPvCzIrcGXV0whPRM93BGCgEZVIkdOfDv2+VGDMDmL3mWyJ8/ysjaN1VOnf
How to access MongoDB instances?
After applying for a MongoDB instance, an IP and Port will be obtained.
Command-line operation
Log in to the cloud host and enter the following in the command line:
mongo --host $ip --port $port --authenticationDatabase $db --username $admin --password $admin_passwd
For example:
mongo --host 10.4.12.80 --port 27017 --authenticationDatabase admin --username root --password root
Or:
mongo $ip:$port/$db -u $admin -p $admin_passwd
For example:
mongo 10.4.12.80:27017/admin -u root -p root
API operation
Users can use the open-source MongoDB API library to connect to MongoDB. For security reasons, MongoDB can only be accessed on the intranet.
How to access business MongoDB?
Due to MongoDB’s security mechanism, users cannot connect to the business db directly at startup, or they will always be prompted with no privileges. This requires the following steps:
-
Log in to the admin library.
-
Switch to the business db, such as game.
-
Use createUser.
-
Use the mongo client to connect to the business library, such as:
mongo 10.4.12.80:27017/game -u root -p root
MongoDB 2.6 has made many improvements to the security mechanism, the specific methods can be seen, pay attention to the concept of roles:
http://docs.mongodb.org/master/reference/method/db.createUser/
How does MongoDB manage memory?
MongoDB uses mmap to manage memory, resulting in memory usage often reaching 100%. Sometimes, after a backup operation (either automatic or manual), memory usage will immediately rise to 100% as well. This generally isn’t a cause for concern. After memory usage increases, it typically will not be released proactively.
If the working load is normal and the memory usage is bottlenecked, it’s recommended to upgrade the memory online.
How does MongoDB manage disk?
MongoDB uses a pre-allocation mechanism to allocate large files for data storage, and operations such as drop, remove and compact do not free up disk space, but they can reuse pre-allocated space. If the disk usage rate is too high, then you need to be aware of whether it reaches 100%. If the disk space usage rate is close to 100%, it’s recommended that you the following methods to overcome it:
- Upgrade disk;
- Create a secondary node and use replication to sync data from the primary node to the secondary, as the secondary typically requires less storage space. Then, perform a primary-secondary switch;
- Repair the db by executing db.repairDatabase, this will block the read and write services of the whole instance, it’s not recommended to use.
How to manage and view slow queries?
Run db.setProfilingLevel() in the business library to start and stop the slow search. Refer to the method:
http://docs.mongodb.org/manual/reference/method/db.setProfilingLevel/
Run db.getProfilingStatus() to view the status of slow query settings.
Run db.system.profile.find() to view the collected slow query, this helps query optimization work.
How to find MongoDB’s statistical information?
Statistics can be seen on the MongoDB management page, including CPU usage, memory usage, connection count, various QPS indicators, etc.
How to use mongostat monitoring?
mongostat is a monitoring tool provided by the official, the usage method is:
mongostat -h $ip --port $port --authenticationDatabase admin -u $admin -p $admin_password --discover
As in:
mongostat -h 10.4.4.50 --port 27017 --authenticationDatabase admin -u root -p root --discover
How to view the attribute information and synchronization status of the replica set?
The client mongo connects to a primary node and executes the rs.status() command to view the properties of the replica set, where the set field is the id of the replica set.
Run the rs.printReplicationInfo() command to view the usage of oplog.
The client mongo connects to a secondary node, executes the rs.printSlaveReplicationInfo() command to view the synchronization status with the primary node, and can see whether it lags behind the primary.
Accessing UDB-MONGO from the Internet using HAproxy
Just as using MySQL-Proxy allows UDB-MYSQL to be accessed from the Internet, HAproxy can be used to access UDB-MONGO from the Internet.
Specific process is:
Install HAproxy
# yum install -y haproxy
Modify the configuration file according to the following content. The default configuration file path: /etc/haproxy/haproxy.cfg
global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon
stats socket /var/lib/haproxy/statsdefaults
defaults
log global
option dontlognull
option http-server-close
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
maxconn 3000
listen mongod
bind uhost-ip:27017
mode tcp
balance roundrobin
server mongo1 mongodb-ip:27017
listen mongo-web
bind uhost-ip:28017
mode http
balance roundrobin
server mongo1 mongodb-ip:28017
The uhost-ip in the configuration is the internal network IP of the cloud host, and the mongodb-ip is the internal network IP of UDB-MONGO.
Restart the service
# service haproxy restart
# chkconfig haproxy on
Open the corresponding port in the firewall
”In this configuration, since external clients need to access the UHost machine where haproxy is located through ports 27017 and 28017 (refer to the two bind statements in the configuration), please edit the firewall settings for this UHost machine to allow access on ports 27017 and 28017.
Connect to MongoDB via the public network
# mongo uhost-eip:27017/admin -u root -p
Web control panel of MongoDB accessible via public network: http:%%//%%uhost-eip:28017
How to resolve the error when using wget to download the Log of the cloud database on the cloud host?
When downloading log backups of cloud data-cloud databases on cloud hosts, double quotes should be added before and after the URL.
Example: The download address is: http://udbbackup.ufile.ucloud.cn/udb-3u022a/
wget -O ppp.tgz "http://udbbackup.ufile.ucloud.cn/udb-3u022a/"
-O Set local name
How to modify the size of the local library?
Once the DB is successfully applied for, oplogSize size modification is no longer supported, and only changes are supported before the DB application.
If it is a common sharding server, the default size of our UDB local library is 5G. If you need to set it to a specified size, you can create a custom configuration file before creating MongoDB, and set the size by modifying oplogSize, and then create the DB using this custom configuration file.
If the write operations are frequent, it’s recommended to adjust the size of oplogSize appropriately according to the applied disk capacity.
If it is a config server, the system will automatically generate a local database of around several tens of MB. Setting the local database size during the DB setup phase will have no effect.
How to query the server version and other installation information of MongoDB instance?
Log into Mongo shell and run the following command to view:
udb-test:PRIMARY> db.serverBuildInfo()
{
"version" : "2.4.9",
"gitVersion" : "52fe0d21959e32a5bdbecdc62057db386e4e029c",
"sysInfo" : "Linux ip-10-2-29-40 2.6.21.7-2.ec2.v1.2.fc8xen #1 SMP Fri Nov 20 17:48:28 EST 2009 x86_64 BOOST_LIB_VERSION=1_49",
"loaderFlags" : "-fPIC -pthread -rdynamic",
"compilerFlags" : "-Wnon-virtual-dtor -Woverloaded-virtual -fPIC -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -Werror -pipe -fno-builtin-memcmp -O3",
"allocator" : "tcmalloc",
"versionArray" : [2, 4, 9, 0],
"javascriptEngine" : "V8",
"bits" : 64,
"debug" : false,
"maxBsonObjectSize" : 16777216,
"ok" : 1
}
How to connect to MongoDB Cloud database?
Connect to a replica set
If MongoDB is used in a replica set mode, then when connecting to MongoDB, a correct connection URI needs to be set, so that subsequent primary node downtime can be successfully migrated, the application layer doesn’t need to change connection settings, and automatically has high availability. All kinds of language drivers support URI connection. The general connection URI string format of the replica set is as follows, including the account, password, and IP and port of each node of the replica set.
URI: mongodb://user:password@ip1:port1,ip2:port2,…
Suppose the URI content is as follows:
mongodb://uclouder:edFO09SkdU@10.9.57.241:27017,10.9.40.112:27017,10.9.35.45:27017/test
Then the correct connection method is:
client=MongoClient('mongodb://uclouder:edFO09SkdU@10.9.57.241:27017,10.9.40.112:27017,10.9.35.45:27017/test')
MongoDB only supports write operations on the primary node, but the read operations can have a few options, customers can choose the appropriate reading strategy according to their own business needs:
primary: Default setting, all read operations are on the primary node
primaryPreferred: Prefer to read the primary node, if primary is not available then read the secondary node
secondary: All read operations read the secondary node
secondaryPreferred: Prefer to read secondary, if secondary is unavailable then read primary
nearest: Read the node with the lowest network latency
As an example, if read-write separation is needed, i.e., prefer to read secondary nodes, and the connection timeout is 500ms, then the URI configuration is as follows:
mongodb://uclouder:edFO09SkdU@10.9.57.241:27017,10.9.40.112:27017,10.9.35.45:27017/test?connectTimeoutMS=500&readPreference=secondaryPreferred
Connect to a shard cluster
The method of connecting to a sharded cluster is identical to connecting to a regular MongoDB instance. However, when multiple mongos instances are present, even if the IP addresses of all mongos instances are fully listed in the URI, it does not automatically ensure high availability and load balancing for mongos. This can typically be achieved by setting up a proxy like HaProxy or LVS.Assuming there are three mongos nodes with IP addresses IP1, IP2, and IP3, and the proxy IP for HaProxy is IP4, using a simple round-robin strategy, an example connection URI would be as follows:
mongodb://uclouder:edFO09SkdU@IP4:27017/test?connectTimeoutMS=500&readPreference=secondaryPreferred
How to estimate the time used by MongoDB to recover from backup to new instances?
When restoring MongoDB to a new instance from a backup, the recovery time depends on the backup data volume and the target cluster specifications. Smaller backup data volumes and higher target cluster specifications generally lead to faster recovery completion. For logical backups, the typical data recovery speed is approximately 10-20 GB per hour.
Case one: The replica set, with 42G of data in size and 11G in size of backup file, with the target cluster computing specification of 4C8G, disk capacity of 100G, takes 3 hours and 48 minutes to complete recovery.
Case two: The replica set, with 49G of data in size and 13G in size of backup file, with the target cluster computing specification of 8C16G, disk capacity of 240G, takes 2 hours and 27 minutes to complete recovery.
The time of rollback to new instances function is similar to this function.