General

General settings allow configuration of cluster name, memory quotas, storage modes, and node availability for the cluster; and of advanced settings for the Index and Query Services.

Examples on This Page

Full and Cluster Administrators can configure general settings by means of Couchbase Web Console, the CLI, or the REST API.

Configure General Settings with the UI

The appearance of the General screen is as follows:

The panels and their UI elements are described below.

Cluster Name

The Cluster Name is the name that was given during initial setup. This name can be changed at any time. The interactive field appears as follows:

Memory Quotas

The amount of memory available to each service, on every node. The combination of assigned values is not permitted to exceed the total memory available on the most memory-constrained node.

The panel appears as follows:

The displayed, configurable options are:

Data. The memory allocation for the Data Service, per node. The minimum allocation must be equal to or greater than the sum of all per bucket memory-allocations on the node.
Query. The soft memory limit for every Query node in the cluster. The garbage collector tries to keep below this target. It is not a hard, absolute limit, and memory usage may exceed this value. When set to 0 (the default), there is no soft memory limit.
Index. The buffer cache size for the Index Service. The specified amount of memory is pre-allocated as soon as the Index Service starts up. It is then shared with all indexes created on the node. The total memory-usage of the indexer process will be the buffer cache size plus the size of various internal data structures and queues.
Search. The memory allocation for the Search Service, per node.
Analytics. The memory allocation for the Analytics Service, per node.
Eventing. The memory allocation for the Eventing Service, per node.

Note that the Backup Service does not require memory-allocation.

Current Version

This panel displays the current version of Couchbase Server, and can be used to indicate whether updates are available. It appears as follows:

The Share usage information with Couchbase and get software update notifications checkbox is checked by default: this means that Couchbase Web Console will display adjacent notifications whenever a new version of Couchbase Server is available. If the checkbox is unchecked, notifications are not provided.

Additionally, if the checkbox is checked, Couchbase Web Console communicates with Couchbase Server to ascertain the following information, which is then transmitted to Couchbase:

The server-version of the current installation.
Information about data-size and performance.
The cluster-configuration, including which services are deployed.

Note that data is transmitted to Couchbase from the browser accessing the web console, not from the cluster itself. The update-notification process works anonymously: data cannot be tracked. No identifiable information (such as bucket names, bucket data, design-document names, or hostnames) is transmitted.

Node Availability

The options in the Node Availability panel control if and when Couchbase Server performs an automatic failover on a node. Couchbase Server only performs an auto-failover in clusters containing three or more nodes. For detailed information about automatic failover policy and constraints, see Automatic Failover.

The fields in this section are:

Auto-failover after X seconds for up to Y node: When you enable this setting (which defaults to enabled), Couchbase Server automatically fails over a node after it has been unresponsive for the duration you set in the seconds box. When Couchbase Server auto-fails over a node, it promotes the replica vBuckets on other nodes to active status to maintain data access. The default duration is 120 seconds. You can change it to any value from 5 to 3600.

You also set the maximum number of nodes that Couchbase Server can auto-fail over at a time in the node box. If Couchbase has auto-failed over the maximum number of nodes, it refuses to auto-fail over more nodes until the you either perform a successful rebalance or manually reset the count of failed-over nodes. This maximum number of allowed auto-failovers also applies to the other auto-failover settings in this section.

You can only enable the other settings in this section when you enable Auto-failover after X seconds for up to Y node.
Auto-failover for sustained data disk read/write failures after X seconds ENTERPRISE EDITION: If you enable this setting, Couchbase Server fails over a node that experiences sustained data disk errors for the duration set in the seconds box. The default duration is 120 seconds. You can change the duration to a value from 5 to 3600 seconds. You can only enable this setting if you enable Auto-failover after X seconds for up to Y node. This setting defaults to off.
Auto-failover for data disk read/write non-responsiveness after X seconds ENTERPRISE EDITION: This setting is similar to the previous setting, except the duration in the seconds box sets the amount of time a read or write operation has to finish. This setting defaults to off. When you enable it, if a read or write operation on the data disk takes longer than the values in the seconds box, Couchbase Server performs an auto-failover on the node. It lets you handle cases where a node’s data disk is indefinitely hanging or is so busy it becomes unresponsive without generating errors. The default duration is 120 seconds. You can change the duration to a value from 5 to 3600 seconds.
Preserve durable writes ENTERPRISE EDITION: If you enable this setting, Couchbase Server does not auto-fail over a node if it could result in the loss of durably written data. This setting defaults to off. For more information, see Preserving Durable Writes.

The Node Availability section also contains a For Ephemeral Buckets subsection that you can expand. The settings in this subsection are:

Enable auto-reprovisioning for up to X node: This setting helps avoid data loss in cases where a node fails and restarts before Couchbase Server can begin an auto-failover for it. This setting defaults to enabled. When it’s enabled, Couchbase Server automatically promotes the replicas of the active ephemeral vBuckets on the failed node. By making these replicas active, Couchbase Server prevents the loss of data caused by the restarted node losing the data in its ephemeral buckets.

The node box sets the maximum number of nodes Couchbase Server can auto-reprovision at a time. This value defaults to 1, meaning only a single node’s ephemeral buckets are auto-reprovisioned at a time. After the failed node rejoins the cluster, you must perform a rebalance before another node can be auto-reprovisioned. Only set this limit greater than 1 if the remaining nodes have enough capacity to handle the increased workload of multiple ephemeral buckets.
Allow auto-failover for ephemeral buckets with no replicas ENTERPRISE EDITION: When enabled, this setting allows Couchbase Server to auto-failover a node that contains an ephemeral bucket with no replicas. When Couchbase Server fails over a node with an ephemeral bucket with no replicas, it creates empty vBuckets on the remaining nodes to replace the missing vBuckets on the failed node. When the failed node rejoins the cluster, Couchbase Server moves the replacement vBuckets back to it.

This setting is off by default. When it’s off, Couchbase Server does not auto-failover a node that contains vBuckets for an unreplicated ephemeral bucket. In this case, you must manually fail over any node that contains an unreplicated ephemeral bucket’s vBuckets.

See Auto-Failover and Ephemeral Buckets for more information about auto-failover and ephemeral buckets.

Auto-Failover and Durability

Couchbase Server provides durability, which ensures the greatest likelihood of data-writes surviving unexpected anomalies, such as node-outages. The auto-failover maximum should be established to support guarantees of durability. See Durability, for information.

Rebalance Settings

Rebalance redistributes data, indexes, event processing, and query processing among available nodes. For an overview, see Rebalance. Fully open, the panel appears as follows:

The Retry rebalance option allows rebalance to be retried, in cases where it has failed. Check the checkbox, to enable. The specifiable, maximum number of retries must be in the range of 1 to 3, inclusive. The specifiable, maximum number of seconds must be in the range of 5 to 3600, inclusive.

Note that this option should not be enabled if the cluster is managed by Couchbase Autonomous Operator, or if custom scripts are already being used to trigger rebalance. Note also that no administrative tasks should be attempted when rebalance-retries are pending. However, pending rebalance-retries can be cancelled: see Automated Rebalance-Failure Handling, for information.

The Max moves per node during rebalance option establishes the maximum number of concurrent vBucket moves permitted on every individual node. The minimum value for the parameter is 1, the maximum 64, the default 4. For information, see Limiting Concurrent vBucket Moves.

Data Settings

The fields that appear when you expand the Advanced Data Settings section let you control filesystem use limits and I/O thread allocation.

Prevent writes to buckets when storage becomes <number>% full controls whether Couchbase Server prevents the Data Service from writing to filesystem containing the data path after it fills past the percetage you set. Enabling this option can help prevent the data path from becoming full. This limit does not affect any other service. If other services write to the same filesystem, the filesystem can still become full. This option is off by default. When selected, Couchbase Server prevents writes to buckets when the filesystem fills to the percent you set in the % full field. The default value for this field is 85%.

See Filesystem Free Space and Usage Limits for more information.

The Reader Thread Settings and Writer Thread Settings options let you control the number of threads the Data Service uses on each node to read and write data. Allocating more threads can improve performance. In particular, adding more writer threads can improve durable write performance. See Durability for more information. However, setting the number of threads too high can reduce performance if the node is not capable of handling the additional threads.

Both Reader Thread Settings and Writer Thread Settings offer the same options:

Default

Couchbase Server sets the number of threads to a balanced value suitable for most workloads.

Disk i/o optimized

Couchbase Server sets the number of threads equal to the number of CPU cores on the node. For buckets using the Magma storage engine, consider using this setting for the following conditions:

For Writes

When reducing the latency of durable writes is more important to you than write throughput.
For write-intensive workloads where you want greater throughput and you find the SSD is not saturated using the default setting.

For Reads

When you have low memory data residency, use this option for better throughput and latency.
When your data is on a high-latency virtualized storage device such as EBS volumes on the cloud. In this case, a larger I/O queue depth helps saturate the disk IOPS/bandwidth.

For more details, see Magma.

Fixed value

When you select this option, a field appears in which you can select the number of threads to use.

As a guideline, set the number of reader and writer threads equal to the queue depth of your IO subsystem (for example, readers = queue_depth and writers = queue_depth). For best performance, benchmark different settings and choose the one that meets your throughput and latency requirements.

See Threading for more information about reader and writer threads.

Query Settings

Left-clicking on Advanced Query Settings displays interactive fields with which you can configure the Query Service. The top section of the panel appears as follows:

Under CURL() Function Access, specify either Unrestricted or Restricted, to determine which URLs the CURL() function can access.

If you specify Unrestricted (the default), the CURL() function can access all URLs.
If you specify Restricted, the UI expands, to display configurable fields into which you can enter the allowed and disallowed URLs.

When a query has an extremely large corresponding index scan, the indexer buffers the results into a temporary directory. Since this method may cause high I/O and works differently on Windows, you can configure backfill settings for the SQL++ engine and its embedded GSI client.

The Query Temp Disk Path field enables you to specify the path to which the indexer writes temporary backfill files, to store any transient data during query processing. The specified path must already exist. Only absolute paths are allowed. The default path is var/lib/couchbase/tmp within the Couchbase Server installation directory.

The Quota field enables you to specify the maximum size of temporary backfill files, in megabytes. Setting the size to 0 disables backfill. Setting the size to -1 means the size is unlimited. The maximum size is limited only by the available disk space.

While queries support unlimited backfill when the quota is -1, GSIs do not perform backfill if the quota is 0 or less. To enable backfill for GSIs, configure the quota to a sufficiently large positive value, such as 102400 or higher. You can set this value higher than the available disk space to effectively allow unlimited backfill. However, the actual usage remains within the limits of the available disk space.

Additional Query settings are provided in the lower section of the panel:

The bottom half of the Query Settings panel

Pipeline Batch: The number of items that can be batched for fetches from the Data Service.
Pipeline Cap: The maximum number of items that can be buffered in a fetch.
Scan Cap: The maximum buffered channel size between the indexer client and the Query Service, for index scans.
Timeout: The maximum time to spend on a request before timing out.
Prepared Limit: The maximum number of prepared statements to be held in the cache.
Completed Limit: The number of requests to be logged in the completed requests catalog.
Completed Threshold: The completed-query duration (in milliseconds) beyond which the query is logged in the completed requests catalog.
Log Level: The log level used in the logger.
Max Parallelism: The maximum number of index partitions for parallel aggregation-computing.
N1QL Feature Controller: Enables or disables features in the Query engine.

Do not change the N1QL Feature Controller setting without guidance from technical support.
Transaction Timeout: The number of milliseconds to elapse before a transaction times out.
Memory Quota: The amount of memory, in megabytes, allocated to the processing of a query.
Use Cost-Based Optimizer: when checked (as it is by default), specifies that the cost-based optimizer is used for queries: when the checkbox is unchecked, the optimizer is not used.
Use Replica: specifies whether a query can fetch data from a replica vBucket if active vBuckets are inaccessible. The possible values are:
- Unset — read from replica is enabled or disabled at request level.
- On — read from replica is enabled for all queries, but can be disabled at request level.
- Off — read from replica is disabled for all queries and cannot be overridden at request level.
Do not enable read from replica when you require consistent results. Only SELECT queries that are not within a transaction can read from replica.

Note that KV range scans cannot currently be started on a replica vBucket. If a query uses sequential scan and a data node becomes unavailable, the query might return an error, even if read from replica is enabled for the request.

For additional details on all the Query settings in the lower section of the panel, refer to Configure Queries.

Index Storage Mode

This panel provides radio buttons that set the storage mode for indexes and some additional index settings:

The index storage mode options are Memory Optimized Index Storage, and Standard Index Storage.

The settings under Advanced Settings for indexes are:

Indexer Threads: Sets the number of threads the Index Service uses. You can increase the number of threads dedicated to the Index Service on multi-core machines. The default value of 0 has the Index Service use one thread per core on the node.
Num Replica: Sets the default number of index replicas the Index Service creates for new indexes. Defaults to 0 (no replicas). See Index Replication.
Indexer Rebalance Settings: When cleared, Optimize Index Placement On Rebalance has Couchbase Server only redistribute indexes during a rebalance when the nodes containing them are leaving the cluster. When selected, Couchbase Server redistribute indexes among the Index Service nodes during a rebalance to optimize performance. See Index Redistribution.
Indexer Log Level: Sets the logging level. The options are: Silent, Fatal, Error, Warn, Info, Verbose, Timing, Debug, and Trace. The default is Info.
Bloom Filter: The default cleared setting for Enable Bloom Filter turns off Bloom filters for memory management. When selected, Enable Bloom Filter enables Bloom filters. See Per Page Bloom Filters.

7.2.1+ From release 7.2.1 onward, Bloom filters for plasma back indexes will be enabled by default. During an upgrade, mixed mode clusters with nodes that support bloom filters will enable it for back indexes, even if they was disabled in the past. Users must explicitly disable it again after a cluster setup, or a new node is added.
Once bloom filters are disabled in mixed mode, adding a new 7.2.1+ node will not re-enable them.

File Transfer Based Rebalance: Controls whether Couchbase Server rebuilds indexes or copies them between nodes. The default cleared setting has an Index Server node rebuild any newly assigned index during a rebalance. You cannot enable file-based rebalance when you have enabled Memory Optimized Index Storage. When you select this option, Couchbase Server copies the index files from one Index Server node to another during a rebalance instead of rebuilding them. See Index Rebalance Methods.

You can disable this feature from the UI or via REST API. To learn about disabling this feature via REST API, see Curl Command to Disable the File Transfer Based Rebalance. This feature is disabled by default.

Disabling this feature slows down the Rebalance operation.

XDCR Maximum Processes

The maximum number of threads used per node, to support XDCR. A greater number of threads increases parallelism, and may thereby produce enhanced XDCR performance. The default number of threads is 4.

The panel appears as follows:

Analytics Replicas

The number of replicas for analytics data. The absolute maximum number of replicas is 3. Each replica resides on an Analytics Node: a given Analytics Node can host either one replica, or the active data on which replicas are based. Thus, if a cluster contains three Analytics Nodes, the practical maximum number of replicas is 2; one node hosting the active data, and each of the other two nodes hosting a single replica.

The panel appears as follows:

Note that if you change this setting, you must run a rebalance for the changes to take effect.

Saving Settings

To save settings, left-click on the Save button, at the lower left.

Alternatively, cancel recently entered values, and thereby reset to previous values; by left-clicking on Cancel/Reset.

Configure General Settings with the CLI

To configure name and memory, index storage, and auto-failover via CLI, use the appropriate CLI command; as described below. Note that no CLI support is provided for configuring query settings. As an alternative, see Configure General Settings with the REST API, below. Additionally, for information on URL access lists via the SQL++ CURL() function, see CURL Function.

Name and Memory Settings via CLI

Name and memory settings are established with the setting-cluster command.

/opt/couchbase/bin/couchbase-cli setting-cluster \
--cluster 10.143.192.101:8091 \
--username Administrator \
--password password \
--cluster-ramsize 256 \
--cluster-name 10.143.192.101 \
--cluster-index-ramsize 256 \
--cluster-fts-ramsize 512 \
--cluster-eventing-ramsize 256 \
--cluster-analytics-ramsize 1024

This establishes the cluster-name as 10.143.192.101, the memory allocation for Data and Index Services each as 256 megabytes, and the memory allocation for each other service as zero.

If successful, the call produces the following output:

SUCCESS: Cluster settings modified

Note that settings for an individual server may be retrieved with the server-info command, the output for which can be filtered, as appropriate, by grep:

/opt/couchbase/bin/couchbase-cli server-info \
-c 10.143.192.101 -u Administrator -p password | grep fts

This returns the setting for ftsMemoryQuota:

"ftsMemoryQuota": 512,

Index Storage Settings via CLI

Index storage can be configured with the setting-index command.

/opt/couchbase/bin/couchbase-cli setting-index \
-c 10.143.192.101:8091 \
-u Administrator \
-p password \
--index-log-level info \
--index-stable-snapshot-interval 40000 \
--index-memory-snapshot-interval 150 \
--index-storage-setting default \
--index-threads 8 \
--index-max-rollback-points 10

This establishes the logging level as info, the stable snapshot interval at 40 seconds, the memory snapshot at 150 milliseconds, and the storage setting as default (which means standard, rather than memory optimized). The number of threads to be used is established as 8, and the maximum number of rollback points to 10. For information on the significance of these values see setting-index.

If successful, the call produces the following output:

SUCCESS: Indexer settings modified

Software-Update Settings via CLI

You can enable and disable software update notifications in Couchbase Server Enterprise Edition using the setting-notification command.

/opt/couchbase/bin/couchbase-cli setting-notification \
-c 10.143.192.101 -u Administrator -p password \
--enable-notifications 1

Setting value of 1 for --enable-notifications enables update-notifications. A value of 0 disables notifications. If successful, the command produces the following output:

SUCCESS: Notification settings updated

You cannot disable software update notifications in Couchbase Server Community Edition.

Auto-Failover Settings via CLI

Auto-failover can be configured with the setting-autofailover command.

/opt/couchbase/bin/couchbase-cli setting-autofailover \
-c 10.143.192.101:8091 \
-u Administrator \
-p password \
--enable-auto-failover 1 \
--auto-failover-timeout 120 \
--max-failovers 2

This enables auto-failover, with a timeout of 120 seconds, and an event-maximum of 2.

If successful, the command returns the following output:

SUCCESS: Auto-failover settings modified

For a detailed description of auto-failover settings, policy, and constraints, see Automatic Failover.

Query Settings via CLI

You can set all of the cluster-level query settings, except for the CURL access control settings, using the setting-query command.

To get the current cluster-level query settings, use the --get option:

/opt/couchbase/bin/couchbase-cli setting-query \
-c 10.143.192.101:8091 \
-u Administrator \
-p password \
--get

To set cluster-level query settings, for example the log level and the maximum parallelism, use the --set option:

/opt/couchbase/bin/couchbase-cli setting-query \
-c 10.143.192.101:8091 \
-u Administrator \
-p password \
--set \
--log-level debug \
--max-parallelism 4

For additional details on the cluster-level query settings, refer to Settings and Parameters.

Rebalance Settings via CLI

To obtain the cluster’s current rebalance settings by means of the CLI, use the setting-rebalance command, with the --get option:

/opt/couchbase/bin/couchbase-cli setting-rebalance \
-c 10.143.192.101 \
-u Administrator \
-p password \
--get

If successful, the command returns the current rebalance settings:

Automatic rebalance retry disabled
Retry wait time: 300
Maximum number of retries: 2

To modify the current rebalance settings, use the --set option; and specify appropriate values for the --max-attempts and --wait-for flags:

/opt/couchbase/bin/couchbase-cli setting-rebalance \
-c 10.143.192.101 \
-u Administrator \
-p password \
--set \
--max-attempts 3 \
--wait-for 200

If successful, the command displays the following success message:

SUCCESS: Automatic rebalance retry settings updated

For more information, see the reference page Configure Rebalance Retries.

XDCR Process Setting via CLI

To configure the number of XDCR processes for the node, use the setting-xdcr command, with the --max-processes option:

/opt/couchbase/bin/couchbase-cli setting-xdcr \
-c 10.143.192.101 \
-u Administrator \
-p password \
--max-processes 5

If successful, the command returns the following message:

SUCCESS: Global XDCR settings updated

Analytics Settings via CLI

To obtain the current Analytics replica settings by means of the CLI, use the setting-analytics command, with the --get option:

/opt/couchbase/bin/couchbase-cli setting-analytics \
-c localhost \
-u Administrator \
-p password \
--get

If successful, the command returns the current replica settings:

numReplicas: 0

To establish the number of replicas for Analytics Service data, use the setting-analytics command, with the --set and --replicas options:

/opt/couchbase/bin/couchbase-cli setting-analytics \
-c localhost \
-u Administrator \
-p password \
--set \
--replicas 3

If successful, the command returns the following message:

SUCCESS: Analytics settings updated

Configure General Settings with the REST API

Multiple REST API methods are provided to support configuration of general settings. These are described below.

Name and Memory Settings via REST

To establish name and memory settings, use the /pools/default method.

curl -v -X POST -u Administrator:password \
http://10.143.192.101:8091/pools/default \
-d clusterName=10.143.192.101 \
-d memoryQuota=256 \
-d indexMemoryQuota=256 \
-d ftsMemoryQuota=256 \
-d cbasMemoryQuota=1024 \
-d eventingMemoryQuota=512

This establishes the cluster’s IP address as its name, and assigns memory-quotas to the Data, Index, Search, Analytics, and Eventing Services.

Note that when used with GET, /pools/default returns configuration-settings. The output can be filtered, by means of a tool such as jq:

curl -s -u Administrator:password \
http://10.143.192.101:8091/pools/default | jq '.ftsMemoryQuota'

If successful, this returns the value of the key ftsMemoryQuota:

Update Notification and Statistics Settings via REST

In Couchbase Server Enterprise Edition, you can use the /setting/stats endpoint to turn off notifications about new server versions and reporting of cluster statistics back to Couchbase:

curl -v -X POST -u Administrator:password \
http://10.143.192.101:8091/settings/stats \
-d sendStats=false

You cannot change this setting in Couchbase Server Community Edition. The sendStats setting is always true in this edition.

See the update-notifications option in the cluster-init command line interface reference for details of what sendStats shares.

Node Availability Settings via REST

To establish node availability settings, use the /settings/autoFailover method.

curl -v -X POST -u Administrator:password \
http://10.143.192.101:8091/settings/autoFailover \
-d enabled=true \
-d timeout=120 \
-d failoverOnDataDiskIssues[enabled]=false \
-d failoverOnDataDiskIssues[timePeriod]=120 \
-d maxCount=2 \
-d failoverPreserveDurabilityMajority=true

This enables auto-failover, with a timeout of 120 seconds, and a maximum failover-count of 2. Auto-failover is enabled in the event of suboptimal disk responsiveness, with a time-period of 120 seconds specified. Auto-failover is prohibited in cases where this might result in the loss of durably written data.

For more information on these options, see the descriptions provided above, for the UI.

Additionally, the /settings/autoReprovision method can be used; to specify that if a node containing active Ephemeral buckets becomes unavailable, its replicas on the specified number of other nodes are promoted to active status as appropriate, to avoid data-loss.

curl -v -X POST -u Administrator:password \
http://10.143.192.101:8091/settings/autoReprovision \
-d enabled=true \
-d maxNodes=1

This enables auto-reprovisioning, specifying 1 as the maximum number of nodes.

Index Settings via REST

To establish index settings, use the /settings/indexes method.

curl -v -X POST http://127.0.0.1:8091/settings/indexes \
-u Administrator:password \
-d indexerThreads=4 \
-d logLevel=verbose \
-d maxRollbackPoints=2 \
-d storageMode=plasma \
-d redistributeIndexes=false \
-d numReplica=0 \
-d enablePageBloomFilter=false

This establishes the storage mode for indexes as plasma. It also establishes a verbose logging level, and a total of 4 index threads. For detailed information on these and other settings, see the REST reference page for the method, at Set GSI Settings.

If successful, the call returns a JSON object, which provides values for all current index settings:

{
  "redistributeIndexes": false,
  "numReplica": 0,
  "enablePageBloomFilter": false,
  "enableShardAffinity": false,
  "indexerThreads": 4,
  "memorySnapshotInterval": 200,
  "stableSnapshotInterval": 5000,
  "maxRollbackPoints": 2,
  "logLevel": "verbose",
  "storageMode": "plasma"
}

Data Settings via REST

To set the number of reader and writer threads for Couchbase Server, use the POST /pools/default/settings/memcached/global HTTP method and endpoint, as follows:

curl -v -X POST -u Administrator:password \
http://10.143.192.101:8091/pools/default/settings/memcached/global \
-d num_reader_threads=12 \
-d num_writer_threads=8

This sets the number of reader threads to 12, and the number of writer threads to 8. If successful, the call returns an object whose values confirm the settings that have been made:

{"num_reader_threads":12,"num_writer_threads":8}

See Threading for an overview of reader and writer threads. Also see the REST API reference page, Setting Thread Allocations.

Query Settings via REST

To set the directory for temporary backfill data, and establish its size-limit, use the /settings/querySettings method.

curl -v -X POST -u Administrator:password \
http://localhost:8091/settings/querySettings \
-d 'queryTmpSpaceDir=/tmp' \
-d 'queryTmpSpaceSize=2048'

This specifies that the directory for temporary backfill data should be /tmp; and that the maximum size should be 2048 megabytes.

If successful, this call returns a JSON document featuring all the current query-related settings, including access-control:

{
  "queryTmpSpaceDir": "/tmp",
  "queryTmpSpaceSize": 2048,
// ...
  "queryCurlWhitelist": {
    "all_access": false
  }
}

The document’s values indicate that the specified values for directory and size have been established; and that the current setting for access-control restricts access to all, with no exceptions.

To specify particular URLs as allowed and disallowed, use the /settings/querySettings/curlWhitelist method:

curl -v -X POST -u Administrator:password \
http://localhost:8091/settings/querySettings/curlWhitelist \
-d '{"all_access": false,
     "allowed_urls": ["https://company1.com"],
     "disallowed_urls": ["https://company2.com"]}'

A JSON document is specified as the payload for the method. The document’s values indicate that https://company1.com is allowed, and https://company2.com is disallowed.

If successful, the call returns a JSON document that confirms the modified settings:

{
  "all_access": false,
  "allowed_urls": [
    "https://company1.com"
  ],
  "disallowed_urls": [
    "https://company2.com"
  ]
}

For additional information, refer to Query Settings REST API.

Rebalance Settings via REST

By means of the REST API, both rebalance retries and maximum concurrent moves per node can be configured.

Rebalance Retries via REST

To obtain the cluster’s current settings for rebalance retries by means of the REST API, use the GET /settings/retryRebalance HTTP method and URI, as follows:

curl -X GET -u Administrator:password \
http://10.143.192.101:8091/settings/retryRebalance

If successful, the command returns the following object:

{"enabled":true,"afterTimePeriod":200,"maxAttempts":3}

This output shows that rebalance retry is enabled, with 200 seconds required to elapse before a retry is attempted, and a maximum of 3 retries possible.

To change the rebalance settings, use the POST method with the same URI, specifying appropriate values:

curl -X POST -u Administrator:password \
http://10.143.192.101:8091/settings/retryRebalance \
-d enabled=false \
-d afterTimePeriod=100 \
-d maxAttempts=2

If successful, the command returns the following object:

{"enabled":false,"afterTimePeriod":100,"maxAttempts":2}

This verifies that rebalance retry has been disabled, the required period between retries changed to 100 seconds, and the maximum number of retries changed to 2.

For more information on getting and setting the rebalance retry status, see Configure Rebalance Retries, Get Rebalance-Retry Status, and Cancel Rebalance Retries.

Maximum Concurrent vBucket Moves via REST

To inspect the current maximum number of concurrent vBucket moves permitted for every node, use the GET /settings/rebalance HTTP method and URI, with the rebalanceMovesPerNode parameter, as follows:

curl -v -X GET http://10.143.201.101:8091/settings/rebalance \
-u Administrator:password

This returns an object, confirming the current setting as being 4 (which is the default value):

{"rebalanceMovesPerNode":4}

To set a new value for the parameter use the POST method with the same URI, and with the rebalanceMovesPerNode parameter. Note that the minimum value is 1, and the maximum 64.

curl -v -X POST http://10.143.201.101:8091/settings/rebalance \
-u Administrator:password \
-d rebalanceMovesPerNode=10

If successful, the call returns an object confirming the new setting:

{"rebalanceMovesPerNode":10}

For more information, see the REST reference page Limiting Concurrent vBucket Moves.

XDCR Process Setting via REST

To determine how many XDCR processes are configured per node, use the GET /settings/replications HTTP method and URI, as follows. Note that this example pipes the output to the jq program, to facilitate readability.

curl -X GET -u Administrator:password \
http://10.143.192.101:8091/settings/replications | jq '.'

If successful, the command returns the following object:

{
  "checkpointInterval": 600,
  "compressionType": "Auto",
  "desiredLatency": 50,
  "docBatchSizeKb": 2048,
  "failureRestartInterval": 10,
  "filterBypassExpiry": false,
  "filterDeletion": false,
  "filterExpiration": false,
  "goGC": 100,
  "goMaxProcs": 4,
  "logLevel": "Info",
  "networkUsageLimit": 0,
  "optimisticReplicationThreshold": 256,
  "priority": "High",
  "sourceNozzlePerNode": 2,
  "statsInterval": 1000,
  "targetNozzlePerNode": 2,
  "workerBatchSize": 500
}

The configured number of threads is the value to goMaxProcs; which is currently 4. To change this value, use the POST method with the same URI, specifying the required number of processes as the value to the --goMaxProcs option:

curl -X POST -u Administrator:password \
http://10.143.192.101:8091/settings/replications \
-d goMaxProcs=5 | jq '.'

If successful, this returns the following object:

{
  "checkpointInterval": 600,
  "compressionType": "Auto",
  "desiredLatency": 50,
  "docBatchSizeKb": 2048,
  "failureRestartInterval": 10,
  "filterBypassExpiry": false,
  "filterDeletion": false,
  "filterExpiration": false,
  "goGC": 100,
  "goMaxProcs": 5,
  "logLevel": "Info",
  "networkUsageLimit": 0,
  "optimisticReplicationThreshold": 256,
  "priority": "High",
  "sourceNozzlePerNode": 2,
  "statsInterval": 1000,
  "targetNozzlePerNode": 2,
  "workerBatchSize": 500
}

This output indicates that the value of goMaxProcs has been appropriately incremented.

For more information, see the reference page Managing Advanced XDCR Settings.

Analytics Settings via REST

To establish the number of replicas for Analytics Service data, use the /settings/analytics endpoint. The GET method can be used to retrieve the current setting:

curl -X GET -u Administrator:password \
http://localhost:8091/settings/analytics

If successful, the call returns an object such as the following:

{"numReplicas":1}

This indicates that the number of replicas currently configured for the Analytics Service is 1. To change this number to 2, enter the following:

curl -X POST -u Administrator:password \
http://localhost:8091/settings/analytics \
-d numReplicas=2

If successful, the call returns an object confirming the newly established number of replicas:

{"numReplicas":2}