OpenStack Trove MongoDB Configuration Items

The default log message verbosity level for the systemlog.verbosity component. The level of detail determines the amount of information and debug messages that the MongoDB outputs. The verbosity level can be between 0 and 5:0 is the default log verbosity level for MongoDB to include informational messages. 1 to 5 adds a verbosity level to include debug messages. To use a different level of detail for a named component, use the component's verbosity settings. For example, use systemLog.component.accessControl.verbosity to set verbosity levels specifically for access components. For specific component verbosity settings, see systemlog.component. <name>. verbosity settings. For a variety of ways to set the verbosity level of the log, see Configuring log verbosity levels. SystemLog.component.accessControl.verbosity the log message verbosity level of the component associated with the access control. See Access Components. The verbosity level can be between 0 and 5:0 is the default log verbosity level for MongoDB to include informational messages. 1 to 5 adds a verbosity level to include debug messages. SystemLog.component.command.verbosity the verbosity level of the log message for the component associated with the command. See command component. The verbosity level can be between 0 and 5:0 is the default log verbosity level for MongoDB to include informational messages. 1 to 5 adds a verbosity level to include debug messages. SystemLog.component.control.verbosity the level of verbosity of the log message for the component associated with the control operation. See Control components. The verbosity level can be between 0 and 5:0 is the default log verbosity level for MongoDB to include informational messages. 1 to 5 adds a verbosity level to include debug messages. SystemLog.component.geo.verbosity the log message verbosity level of the component associated with the geospatial resolution operation. See Geo components. The verbosity level can be between 0 and 5:0 is the default log verbosity level for MongoDB to include informational messages. 1 to 5 adds a verbosity level to include debug messages. SystemLog.component.index.verbosity the log message verbosity level of the component associated with the index operation. See index component. The verbosity level can be between 0 and 5:0 is the default log verbosity level for MongoDB to include informational messages. 1 to 5 adds a verbosity level to include debug messages. SystemLog.component.networK.verbosity the log message verbosity level of the components associated with the network operation. See network components. The verbosity level can be between 0 and 5:0 is the default log verbosity level for MongoDB to include informational messages. 1 to 5 adds a verbosity level to include debug messages. SystemLog.component.query.verbosity the level of verbosity of the log message for the component associated with the query operation. View the query component. The verbosity level can be between 0 and 5:0 is the default log verbosity level for MongoDB to include informational messages. 1 to 5 adds a verbosity level to include debug messages. SystemLog.component.replication.verbosity the verbosity level of log messages for the components associated with the replication. See REPL components. The verbosity level can be between 0 and 5:0 is the default log verbosity level for MongoDB to include informational messages. 1 to 5 adds a verbosity level to include debug messages. SystemLog.component.sharding.verbosity the verbosity level of the log message for the component associated with the Shard. See Sharding components. The verbosity level can be between 0 and 5:0 is the default log verbosity level for MongoDB to include informational messages. 1 to 5 adds a verbosity level to include debug messages. SystemLog.component.storage.verbosity the level of verbosity of log messages for storage-related components. See Storage components. The verbosity level can be between 0 and 5:0 is the default log verbosity level for MongoDB to include informational messages. 1 to 5 adds a verbosity level to include debug messages. SystemLog.component.storage.journal.verbosity the level of verbosity of log messages for log-related components. See Journal components. The verbosity level can be between 0 and 5:0 is the default log verbosity level for MongoDB to include informational messages. 1 to 5 adds a verbosity level to include debug messages. SystemLog.component.write.verbosity the level of verbosity of the log message for the component associated with the write operation. See the Write component. The verbosity level can be between 0 and 5:0 is the default log verbosity level for MongoDB to include informational messages. 1 to 5 adds a verbosity level to include debug messages. Systemlog.quiet runs MONGOs or mongod in a quiet mode, trying to limit the amount of output. Systemlog.traceallexceptions Print details for debugging. For supportOther log records related to troubleshooting. When Systemlog.logappend is true, when the MONGOs or Mongod instance restarts, MONGOs or Mongod appends the new entry to the end of the existing log file. Without this option, Mongod will back up the existing log and create a new file. The behavior of the systemlog.logrotatelogrotate command. Specify to rename or reopen: Rename Rename the log file. Reopen closes and re-opens the log file according to the typical Linux/unix log rotation behavior. When using the Linux/unix logrotate utility, please reopen it to avoid log loss. Systemlog.timestampformat the time format of the timestamp in the log message. Specify one of the following values: The value description CTime displays a timestamp of Wed Dec 31 18:17:54.811. ISO8601-UTC displays the timestamp of Coordinated Universal Time (UTC) in ISO-8601 format. For example, at the beginning of the era of New York: 1970-01-01t00:00:00.000ziso8601-local Displays the local timestamp in ISO-8601 format. For example, New York begins at the time: the maximum number of concurrent connections that 1969-12-31t19:00:00.000-0500net.maxincomingconnectionsmongos or Mongod will accept. This setting does not work if the maximum connection tracking threshold is higher than the operating system configuration. Do not assign a value that is too low for this option, or you will encounter an error during normal application operations. This is especially useful for a mongos if you have a client that creates multiple connections and allows them to time out instead of shutting them down. This setting prevents MONGOs from causing connection spikes on individual fragments. Spikes like this can disrupt the operation and memory allocation of the Shard cluster. Net.wireobjectcheck If True, the Mongod or MONGOs instance validates all requests when it receives the client to prevent the client from inserting an incorrect or invalid Bson into the MongoDB database. For objects with high-level subdocument nesting, Net.wireobjectcheck has little impact on performance. Net.ipv6 enables or disables IPV6 support and allows MONGOs or mongod to connect to a MongoDB instance using a IPV6 network. Before MongoDB 3.0, you must specify Net.ipv6 to use IPV6. net.http.enabled enable or disable the HTTP interface. Enabling an interface can increase network exposure. KeepThe HTTP interface disables production deployment. If you enable this interface, only trusted clients should be allowed to access this port. See firewall. Note MongoDB Enterprise does not support Kerberos authentication, and the HTTP status interface in any version of MongoDB does not support Kerberos. Net.http.JSONPEnabled enables or disables JSONP access through the HTTP interface. Enabling an interface can increase network exposure. net.http.RESTInterfaceEnabled enable or disable the simple rest API. Even if you disable the HTTP interface option, enabling the Rest API enables the HTTP interface, which can increase network exposure. Security.authorization enables or disables role-based access control (RBAC) to manage each user's access to database resources and operations. Set this option to one of the following: Value description enabled users can only Access database resources and operations that have been granted permissions. Disabled can access any database and perform any operation. For more information, see Role-based access control. Security.sasl.hostName the fully qualified server domain name used to configure SASL and Kerberos authentication. The SASL host name only covers the host name of the host with SASL and Kerberos configuration. For MONGO Shell and other MongoDB tools to connect to the new hostname, see gssapihostname options in MONGO shell and other tools. Security.sasl.serviceName the registered name of the service using SASL. This option allows you to override the default Kerberos service name component for the Kerberos principal name based on the instance. If not specified, the default value is MongoDB. The path to the SECURITY.SASL.SASLAUTHDSOCKETPATHSASLAUTHD UNIX domain socket file. Security.javascriptenabled enables or disables server-side JavaScript execution. When disabled, you cannot use server-side operations that perform JavaScript code, such as the Where query operator, The MapReduce command and the Db.collection.mapReduce () method, the group command, and the Db.collection.group () method. The OPERATIONPROFILING.SLOWOPTHRESHOLDMS database parser considers the query to be slow in milliseconds in the threshold value. MongoDB logs all the slow queries to the dayLog, even if the database analyzer is turned off. When the parser is open, it writes to the System.profile collection. For more information about the database Analyzer, see the Profile command. Operationprofiling.mode the level of database analysis, which inserts information about operational performance into the System.profile collection. Specify one of the following levels: level set off no files. The SLOWOP only includes slow operation. All includes all operations. Database analysis can affect database performance. This option is enabled only after careful consideration. STORAGE.INDEXBUILDRETRY Specifies whether Mongod rebuilds the incomplete index on the next boot. This applies to situations in which Mongod restarts after a shutdown or stop in the middle of an index build. In this case, Mongod always removes any incomplete indexes, and then, by default, attempts to rebuild them. To prevent Mongod from rebuilding the index, set this option to false. storage.journal.enabled enable or disable the durability journal to ensure that the data files remain valid and recoverable. This option is only applicable when the--dbpath option is specified. Mongod logging is enabled by default and is 64-bit in version 2.0. Storage.directoryperdb when True, MongoDB uses a separate directory to store data for each database. The directory is located in the Storage.dbpath directory, and each subdirectory name corresponds to the database name. Change in version 3.0: To change the STORAGE.DIRECTORYPERDB option for an existing deployment, you must restart the Mongod instance with the new Storage.directoryperdb value and the new data directory (Storage.dbpath value), and then repopulate the data. For stand-alone instances, you can use Mongodump on an existing instance, stop the instance, restart the new Storage.directoryperdb value and the new data directory, and populate the new data directory with Mongorestore. For replica sets, you can use the new Storage.directoryperdb value and the new data catalog to restart by stopping the secondary member to scroll through the update, and populate the new data directory with the initial synchronization. To update all members, start with the secondary member first. Then lower the main features and update the demoted members. Storage.syncperiodsecsmongodb The amount of time that can pass before the data is flushed to the data file by the Fsync operation. Warning if Storage.syncperiodsecs is set to 0, MongoDB will not sync the memory-mapped files to disk. The Mongod process writes data to the log quickly and lazily writes data files to the data. Storage.syncperiodsecs has no effect on log files or log records. The Serverstatus command reports the state of the background flush thread through the backgroundflushing field. The storage engine for the Storage.enginemongod database. Valid options include MMAPV1 and Wiredtiger. If you try to start Mongod with Storage.dbpath, which contains data files that are generated by the storage engine other than the storage engine specified by Storage.engine, Mongod will refuse to start. Storage.mmapv1.nsSize He is the default size for namespace files, which are files that end in. NS. Each collection and index is evaluated as a single namespace. Use this setting to control the size of the newly created namespace file. This option has no effect on existing files. The maximum size of a namespace file is 2047 megabytes. The default value of 16 megabytes provides approximately 24,000 namespaces. Storage.mmapv1.quota.enforced enables or disables the maximum limit for the number of digital data files that can be owned by each database. When run with the storage.mmapv1.quota.enforced option, MongoDB has a maximum of 8 data files per database. Adjust quotas using Storage.quota.maxFilesPerDB. Storage.mmapv1.quota.maxFilesPerDB the limit on the number of data files per database. The Storage.mmapv1.quota.maxFilesPerDB option requires that you set Storage.mmapv1.smallFiles to True when MongoDB uses a smaller default file size. The Storage.mmapv1.smallFiles option reduces the initial size of the data file and limits the maximum size to MB. Storage.mmapv1.smallFiles also reduces the size of each log file from 1000 gigabytes to 128 megabytes. If you have a large number of databases, and each database holds a small amount of data, use Storage.mmapv1.smallFiles. The storage.mmapv1.smallFiles option causes the Mongod instance to create a large number of files, which can affect the performance of a larger database. Storage.mmapv1.journal.debugFlags provides testing capabilities. does not apply toIn general, and will affect the integrity of the data file in the event of an abnormal shutdown of the system. The maximum time (in milliseconds) that the Storage.mmapv1.journal.commitIntervalMsmongod process allows between log operations. The value can be within the range of 2 to 300 milliseconds. A lower value can increase the performance of the disk. If a single block device (such as a physical volume, RAID device, or LVM volume) contains both log and data files, the default log commit interval is 100 milliseconds. If the log is on a block device that differs from the data file, the default log commit interval is 30 milliseconds. To force Mongod to commit logs more frequently, you can specify J:true. When a write operation with J:true is suspended, Mongod will reduce the commitintervalms to One-third of the set value. Storage.wiredTiger.engineConfig.cacheSizeGBWiredTiger the maximum size of the cache that will be used for all data. Ensure that the Storage.wiredTiger.engineConfig.cacheSizeGB is sufficient to accommodate the entire working set of the Mongod instance. Note Storage.wiredTiger.engineConfig.cacheSizeGB only limits the size of the Wiredtiger cache, not the total amount of memory used by Mongod. The Wiredtiger cache is just one component of the RAM used by MongoDB. MongoDB also automatically uses all available memory on the machine through the file system cache (the data in the file system cache is compressed). Additionally, the operating system uses any available RAM to buffer the file system block. In order to accommodate additional consumers of RAM, you may have to reduce the Wiredtiger cache size. Avoid increasing the Wiredtiger cache size above its default value. The default Wiredtiger cache size value assumes that each node has a Mongod instance. If a single node contains multiple instances, you should reduce the settings to accommodate other Mongod instances. If you run Mongod in a container that does not have access to all of the RAM that is available on the system, such as Lxc,cgroups,docker, You must set Storage.wiredTiger.engineConfig.cacheSizeGB to a value that is less than the value of the RAM available in the container. The exact number depends on the other processes running in the container. Storage.wiredTiger.engineConfig.statisticsLogDelaySecsstorage.wiredTiger.engineConfig.journalCompressorCompression type used to compress the Wiredtiger log data. Available compressors are: Nonesnappyzlibstorage.wiredTiger.collectionConfig.blockCompressor The default compression type used to compress collected data. You can override this on a per-collection basis when you create a collection. The available compressors are: Nonesnappyzlibstorage.wiredTiger.collectionConfig.blockCompressor will affect all collections created. If you change the value of storage.wiredTiger.collectionConfig.blockCompressor in an existing MONGODB deployment, all new collections will use the specified compressor. The existing collection will continue to use the compressor specified at the time of creation, or the default compressor at the time. Storage.wiredTiger.indexConfig.prefixCompression enables or disables prefix compression for index data. Specify true for Storage.wiredTiger.indexConfig.prefixCompression to enable prefix compression for index data, or to suppress the prefix of index data to false. The Storage.wiredTiger.indexConfig.prefixCompression setting affects all created indexes. If you change the value of storage.wiredTiger.indexConfig.prefixCompression on an existing MONGODB deployment, all new indexes will use prefix compression. The existing index is not affected. REPLICATION.OPLOGSIZEMB the maximum size, in megabytes, of the copy operation log (that is, oplog). The Mongod process creates a oplog based on the maximum amount of free space. For 64-bit systems, Oplog is typically 5% of the free disk space. Once Mongod creates Oplog for the first time, changing the REPLICATION.OPLOGSIZEMB option will not affect the oplog size. For more information, see Oplog Size. The Replication.secondaryIndexPrefetchreplication.secondaryIndexPrefetch is only available for MMAPV1 storage engines. The secondary member of the replica set is loaded into the in-memory index before the operation is applied from the Oplog. By default, the binaries load all the indexes associated with the operation into memory before the action is applied from the Oplog. Set this setting to the followingOne: Value description None binary does not load the index into memory. All secondary loads all indexes associated with the operation. _id_only secondary does not have an extra index loaded outside of memory to the _ID index that already exists. The role of Sharding.clusterrolemongod instances in a shard cluster. Set this setting to one of the following: Value Description Configsvr starts this instance as a configuration server. By default, the instance is started from Port 27019. Shardsvr this instance to start as a fragment. By default, the instance is started from Port 27018. Auditlog.format The format of the output file that is used for auditing if the destination is a file. The Auditlog.format option can have one of the following values: The value description JSON outputs the JSON-formatted audit event to the file specified in-auditpath. BSON outputs the audit event to the file specified in-auditpath in the BSON binary format. Printing an audit event to a file in JSON format degrades server performance rather than printing to a file in Bson format. Note The Auditlog.filter filter restricts the types of operations logged by the audit system. This option takes the form of a string representation of the query document as follows: {<field1>:<expression1>, ...} <field> can be any field in an audit message, including the fields returned in the Param document. <expression> is a query condition expression. To specify an audit filter, enclose the filter document in single quotation marks to pass it as a string. To specify an audit filter in the configuration file, you must use the YAML format of the configuration file. Note Snmp.subagent When Snmp.subagent is true, SNMP runs as a child agent. For more information, see Using SNMP to monitor MongoDB on Linux. Snmp.master when Snmp.master is true, SNMP runs as the primary server. For more information, see Using SNMP to monitor MongoDB on Linux. Replication.localpingthresholdmsmongos the ping time, in milliseconds, that determines which secondary replica set members pass read operations from the client. The default value of 15 corresponds to the default value in all client drivers. When MONGOs receives a request that allows the secondary member to be read, MONGOs will: Find the member of the group with the lowest ping time. Constructs aCopies the list of collection members, which is within the 15-millisecond ping time of the nearest appropriate member in the collection. If you specify a value for the REPLICATION.LOCALPINGTHRESHOLDMS option, MONGOs constructs a list of replica members within the allowed delay range for that value. Select a randomly read member from this list. The ping time for members that are used to compare through the REPLICATION.LOCALPINGTHRESHOLDMS setting is the moving average of the most recent pings computed per 10 seconds. Therefore, some queries may reach a member that is above the threshold until MONGOs recalculates the average value. For more information, see the Member selection section of the Read preference document. Sharding.autosplit enables or disables blocks for the automatic splitting of the fragment collection. If the sharding.autosplit on all MONGOs instances is false, then MongoDB does not create a new block when the data in the collection grows. Because any one of the MONGOs in the cluster can create a split to completely disable the split in the cluster, you must set Sharding.autosplit to False on all MONGOs. Warning Sharding.chunksize the size (in megabytes) of each block in the Shard cluster. In most deployments, the size of the MB is ideal: a larger block size may result in uneven distribution of data; Smaller block sizes can cause blocks between nodes to run inefficiently. Sharding.chunksize affects the block size only when the cluster is first initialized. Setparameter to set the MongoDB parameters or parameters described in the MongoDB server parameters to set parameters in the Yaml configuration file, use the following format: Setparameter: <parameter1>:<value1    > <parameter2>:<value2> For example, to specify Enablelocalhostauthbypass:setparameter in the configuration file: Enablelocalhostauthbypass:false

　　

More Openstack/trove articles: http://www.cnblogs.com/S-tec-songjian/

This article belongs to the Blog Park user S-tec original works, protected by the state copyright law, without permission, any unit and individual should not do for profit use, if only do personal study, exchange and other non-profit use, should specify the author's name, work name, the original address, and shall not infringe the author's other rights to enjoy the law.

OpenStack Trove MongoDB Configuration Items