diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 8133ad9abe..3c6c752ec1 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -285,7 +285,6 @@ include::cli:partial$cbcli/nav.adoc[] *** xref:cli:cbstats/cbstats-durability-monitor.adoc[durability-monitor] *** xref:cli:cbstats/cbstats-failovers.adoc[failovers] *** xref:cli:cbstats/cbstats-hash.adoc[hash] - *** xref:cli:cbstats/cbstats-items.adoc[items] *** xref:cli:cbstats/cbstats-key.adoc[key] *** xref:cli:cbstats/cbstats-kvstore.adoc[kvstore] *** xref:cli:cbstats/cbstats-kvtimings.adoc[kvtimings] @@ -298,7 +297,6 @@ include::cli:partial$cbcli/nav.adoc[] *** xref:cli:cbstats/cbstats-scheduler.adoc[scheduler] *** xref:cli:cbstats/cbstats-scopes.adoc[scopes] *** xref:cli:cbstats/cbstats-scopes-details.adoc[scopes-details] - *** xref:cli:cbstats/cbstats-slabs.adoc[slabs] *** xref:cli:cbstats/cbstats-tap-vbtakeover.adoc[tap-vbtakeover] *** xref:cli:cbstats/cbstats-tasks.adoc[tasks] *** xref:cli:cbstats/cbstats-timing.adoc[timings] diff --git a/modules/audit-event-reference/pages/audit-event-reference.adoc b/modules/audit-event-reference/pages/audit-event-reference.adoc index 80ce562b38..ce8e447a3a 100644 --- a/modules/audit-event-reference/pages/audit-event-reference.adoc +++ b/modules/audit-event-reference/pages/audit-event-reference.adoc @@ -117,7 +117,6 @@ The following events are generated by the Data Service, in response to attempts | Event Group | Event Name | ID | Description | Filter? | Event Type | Data Service | opened DCP connection | 20480 | opened DCP connection | N | Admin | Data Service | authentication failed | 20481 | authentication failed | N | Admin -| Data Service | external memcached bucket flush | 20482 | External user flushed the content of a memcached bucket | N | Admin | Data Service | invalid packet | 20483 | Rejected an invalid packet | N | Admin | Data Service | command access failure | 20484 | Rejected access to a command | N | Admin | Data Service | authentication succeeded | 20485 | Authentication to the cluster succeeded | N | Admin diff --git a/modules/cli/pages/cbstats/cbstats-items.adoc b/modules/cli/pages/cbstats/cbstats-items.adoc deleted file mode 100644 index cac5f06344..0000000000 --- a/modules/cli/pages/cbstats/cbstats-items.adoc +++ /dev/null @@ -1,45 +0,0 @@ -= items -:description: Gives statistics about items stored in the bucket. -:page-topic-type: reference - -[abstract] -{description} - -== Syntax - -Request syntax: - ----- -cbstats host:11210 [common options] items ----- - -== Description - -For [.api]`memcached` buckets only. -This command gives statistics about items stored in the specified bucket, or the default bucket if none is specified. - -== Options - -There are no options for this command. -For common [.cmd]`cbstats` options, see xref:cbstats-intro.adoc[[.cmd]`cbstats`]. - -== Example - -*Request* - ----- -cbstats localhost:11210 -u Administrator -p password -b orders items ----- - -*Response* - ----- - items:2:age: 21766 - items:2:evicted: 0 - items:2:evicted_nonzero: 0 - items:2:evicted_time: 0 - items:2:number: 5 - items:2:outofmemory: 0 - items:2:reclaimed: 0 - items:2:tailrepairs: 0 ----- diff --git a/modules/cli/pages/cbstats/cbstats-slabs.adoc b/modules/cli/pages/cbstats/cbstats-slabs.adoc deleted file mode 100644 index 7013991578..0000000000 --- a/modules/cli/pages/cbstats/cbstats-slabs.adoc +++ /dev/null @@ -1,47 +0,0 @@ -= slabs -:description: Gives statistics on current memory allocation. -:page-topic-type: reference - -[abstract] -{description} - -== Syntax - -Request syntax: - ----- -cbstats host:11210 [common options] slabs ----- - -== Description - -For [.api]`memcached` buckets only. -This command gives statistics on current memory allocation (slab allocator). - -== Options - -There are no options for this command. -For common [.cmd]`cbstats` options, see xref:cbstats-intro.adoc[[.cmd]`cbstats`]. - -== Example - -*Request* - ----- -cbstats localhost:11210 -u Administrator -p password -b orders slabs ----- - -*Response* - ----- - 2:chunk_size: 144 - 2:chunks_per_page: 7281 - 2:free_chunks: 0 - 2:free_chunks_end: 7276 - 2:mem_requested: 661 - 2:total_chunks: 7281 - 2:total_pages: 1 - 2:used_chunks: 5 - active_slabs: 1 - total_malloced: 1048464 ----- diff --git a/modules/introduction/partials/new-features-80.adoc b/modules/introduction/partials/new-features-80.adoc index e609f68246..862dc329db 100644 --- a/modules/introduction/partials/new-features-80.adoc +++ b/modules/introduction/partials/new-features-80.adoc @@ -62,6 +62,13 @@ curl --get -u \ [#section-new-feature-data-service] === Data Service +https://jira.issues.couchbase.com/browse/MB-38452[MB-38452] Memcached buckets have been removed:: +Couchbase Server 8.0 has removed support for Memcached buckets. +They were deprecated in version 6.5.1. +Before upgrading to Couchbase Server 8.0, you must remove any Memcached buckets from your cluster. +You can replace them with ephemeral buckets which are similar to Memcached buckets but support features such as rebalance, backup, query, and eventing. +See the https://docs-archive.couchbase.com/server/6.6/learn/buckets-memory-and-storage/buckets.html#bucket-capabilities[Bucket Capabilities in the Version 6.6 documentation] for a summary of the differences between Memcached and ephemeral buckets. +If you do not remove your Memcached buckets, the upgrade process reports an error message telling you to remove the Memcached buckets before proceeding. https://jira.issues.couchbase.com/browse/MB-9418[MB-9418]:: The previous warmup behavior was to load values and not complete warmup until the Bucket reaches one of: diff --git a/modules/learn/pages/buckets-memory-and-storage/buckets.adoc b/modules/learn/pages/buckets-memory-and-storage/buckets.adoc index b4023071bd..18ace1ea6a 100644 --- a/modules/learn/pages/buckets-memory-and-storage/buckets.adoc +++ b/modules/learn/pages/buckets-memory-and-storage/buckets.adoc @@ -1,63 +1,53 @@ = Buckets -:description: pass:q[A _bucket_ is the fundamental space for storing data in Couchbase Server.] +:description: pass:q[A bucket is the fundamental space for storing data in Couchbase Server.] :page-aliases: understanding-couchbase:buckets-memory-and-storage/buckets,architecture:core-data-access-buckets [abstract] {description} Each bucket contains a hierarchy of scopes and collections to group keys and values logically. +See xref:data/scopes-and-collections.adoc[Scopes and Collections] for more information about scopes and collections. == Bucket Types [#couchbase-bucket-types] -A maximum of 30 buckets can be created in a cluster. -Each bucket must be specified as one of the following three _types_. +You can create up to 30 buckets in a cluster. +Couchbase Server supports two types of buckets: -* *Couchbase buckets*: These store data persistently, as well as in memory. -They allow data to be automatically replicated for high availability, using the Database Change Protocol (DCP); and dynamically scaled across multiple clusters, by means of Cross Datacenter Replication (XDCR). +* Couchbase buckets store data both in memory and on disk. +They support automatic data replication for high availability using the Database Change Protocol (DCP). +You can also scale data across multiple clusters with Cross Datacenter Replication (XDCR). + -If a Couchbase bucket's RAM-quota is exceeded, items are _ejected_. -This means that data, which is resident both in memory and on disk, is removed from memory, but not from disk. -Therefore, if removed data is subsequently needed, it is reloaded into memory from disk. -For a Couchbase bucket, ejection can be either of the following, based on configuration performed at the time of bucket-creation: +If a Couchbase bucket exceeds its RAM quota, the system ejects items. +Ejection removes data from memory but keeps it on disk. +If you need the removed data later, Couchbase Server reloads it from disk. +You can configure ejection at bucket creation as either of the following: - ** _Value-only_: Only key-values are removed. -Generally, this favors performance at the expense of memory. + ** Value-only: The system removes only key-values. +This option generally improves performance but uses more memory. - ** _Full_: All data — including keys, key-values, and metadata — is removed. -Generally, this favors memory at the expense of performance. + ** Full: The system removes all data, including keys, key-values, and metadata. +This option generally saves memory but may reduce performance. -* *Ephemeral buckets*: These are an alternative to Couchbase buckets, to be used whenever persistence is not required: for example, when repeated disk-access involves too much overhead. -This allows highly consistent in-memory performance, without disk-based fluctuations. -It also allows faster node rebalances and restarts. +* Ephemeral buckets are an alternative to Couchbase buckets when you do not need data persistence. +Use them when disk access causes too much overhead. +Ephemeral buckets deliver consistent in-memory performance without disk-based fluctuations. +They also allow nodes to rebalance and restart faster. + -If an Ephemeral bucket's RAM-quota is exceeded, one of the following occurs, based on configuration performed at the time of bucket-creation: +An Ephemeral bucket handles running out of RAM quota in one of two ways, depending on how you set their ejection policy: - ** Resident data-items remain in RAM. -No additional data can be added; and attempts to add data therefore fail. + ** If you choose not to have data ejected, Couchbase Server does not remove data from the bucket when it fills. +Instead, it returns an error when you try to load additional data into the bucket. +To be able to load more data into the bucket, you must either increase the bucket's RAM quota or remove some data from the bucket. - ** Resident data-items are _ejected_ from RAM, to make way for new data. -For an Ephemeral bucket, this means that data, which is resident in memory (but, due to this type of bucket, can never be on disk), is removed from memory. -Therefore, if removed data is subsequently needed, it cannot be re-acquired from Couchbase Server. -+ -For an Ephemeral bucket, ejection removes all of an item's data: however, a _tombstone_ (a record of the ejected item, which includes keys and metadata) is retained until the next scheduled purge of metadata for the current node. -See xref:buckets-memory-and-storage/storage.adoc[Storage] for more information. - -* *Memcached buckets*: These are now _deprecated_. -Memcached buckets are designed to be used alongside other database platforms, such as ones employing relational database technology. -By caching frequently-used data, Memcached buckets reduce the number of queries a database-server must perform. -Each Memcached bucket provides a directly addressable, distributed, in-memory key-value cache. -+ -Memcached buckets are _not persistent on disk_: they only exist in RAM. -If a Memcached bucket's RAM-quota is exceeded, items are _ejected_. -For a Memcached bucket, this means that data, which is resident in memory (but, due to this type of bucket, can never be on disk), is removed from memory. -Therefore, if removed data is subsequently needed, it cannot be re-acquired from Couchbase Server. -Ejection removes all of an item's data. - -All bucket types are fully compatible with the Memcached open source distributed key-value cache. + ** If you enable data ejection, Couchbase Server removes older data from the bucket to make room for new data. +When Couchbase Server ejects data from an Ephemeral bucket, you cannot recover it. +It removes all of the item's data. +However, it keeps a tombstone (a record of the ejected item, including keys and metadata) until the next scheduled metadata purge for the current node. +See xref:buckets-memory-and-storage/storage.adoc[Storage] for more details. == Bucket Capabilities -The Couchbase and Ephemeral bucket-types each support a slightly different set of capabilities; as shown by the following table. +The Couchbase and Ephemeral buckets support a different set of capabilities as the following table shows: |=== | Capability | Couchbase buckets | Ephemeral buckets @@ -179,64 +169,70 @@ For version 7.0.2 and after, Yes. [#replication-dcp-and-xdcr] == Couchbase vs Ephemeral Buckets -Couchbase and Ephemeral buckets both provide a highly available, dynamically reconfigurable, distributed data-store; which survives node failures, and allows cluster-reconfiguration to occur while service-requests continue to be handled. -The following table provides further information on the principal capabilities shared by both bucket-types. +Couchbase and Ephemeral buckets both provide a highly available, dynamically reconfigurable, distributed data store. +They survive node failures and allow cluster reconfiguration while the system continues to handle service requests. +The following table provides information about the main capabilities shared by both bucket types. [cols="3,5,5"] |=== | Capability | Couchbase Buckets | Ephemeral Buckets | Persistence -| Couchbase buckets are persisted asynchronously, from memory to disk. -This provides protection from server-restarts. -You can set persistence-properties at the bucket level. -| Ephemeral buckets are not persisted to disk: they are retained in RAM only. +| Couchbase buckets persist data asynchronously from memory to disk. +This persistence protects data from server restarts. +You can set persistence properties at the bucket level. +| Ephemeral buckets do not persist data to disk. +They retain data in RAM only. | Replication (DCP and XDCR) -| Couchbase buckets can be replicated across a configurable number of servers. -If the host machine fails, a replica server is promoted to be the host server, providing high availability cluster operations via failover. +| Couchbase buckets replicate data across a configurable number of servers. +If the host node fails, a replica server becomes the host server. +This provides high availability cluster operations through failover. You can configure replication at the bucket level. -Additionally, _Cross Datacenter Replication_ (XDCR) allows replication of Couchbase bucket-data between clusters. -| Ephemeral buckets can be replicated across a configurable number of servers, exactly as can Couchbase buckets; but without being persisted to disk. -Likewise, XDCR allows replication of Ephemeral bucket-data between clusters and without persistence: note however, that if an Ephemeral bucket configured to eject data when its RAM-quota is exceeded is used as a source for XDCR, not all data written to the bucket is guaranteed to be replicated by XDCR. +Cross datacenter replication (XDCR) enables replication of Couchbase bucket data between clusters. +| Ephemeral buckets replicate data across a configurable number of servers, just like Couchbase buckets, but without persisting data to disk. +XDCR can also replicate Ephemeral bucket data between clusters without persistence. +If your source for an XDCR replication is an Ephemeral bucket that ejects data when it exceeds its RAM quota, XDCR does not guarantee replication of all data written to the bucket. | Rebalance -| By means of rebalancing, the load constituted by Couchbase buckets is distributed evenly across nodes within the cluster. -Buckets and nodes can be dynamically added and removed. -| Rebalancing redistributes Ephemeral buckets, exactly as it does Couchbase buckets; but without the data being persisted to disk. +| Rebalancing distributes the load of Couchbase buckets evenly across nodes in the cluster. +You can add or remove buckets and nodes dynamically. +| Rebalancing redistributes Ephemeral buckets in the same way as Couchbase buckets, but without persisting data to disk. | Auto-failover and auto-reprovision -| By default, Auto-failover starts when a node has been inaccessible for 120 seconds. -Auto-failover can happen only up to a specified maximum number of times, prior to manual reset. -When a failed node becomes accessible again, delta-node recovery is used: re-using data on disk, and resynchronizing it. +| By default, auto-failover starts when a node is inaccessible for 120 seconds. +Auto-failover can occur up to a specified maximum number of times before you must reset it manually. +When a failed node becomes accessible again, delta-node recovery uses data on disk and resynchronizes it. | Auto-reprovision starts as soon as a node is inaccessible. -Auto-reprovision can happen multiple times, for multiple nodes. -When a failed node becomes accessible again, no delta-node recovery is required, since no data resides on disk. +Auto-reprovision can occur multiple times for multiple nodes. +When a failed node becomes accessible again, the system does not require delta-node recovery because no data resides on disk. |=== == Bucket Security -Buckets are protected by the Couchbase _Role-Based Access Control_ (RBAC) system. -See -xref:learn:security/authorization-overview.adoc[Authorization] and -xref:learn:security/authentication.adoc[Authentication] for details. +The Couchbase Role-Based Access Control (RBAC) system protects buckets. +See xref:learn:security/authorization-overview.adoc[Authorization] and xref:learn:security/authentication.adoc[Authentication] for details. -From release 7.6, Couchbase Server no longer supports {sqlpp} operations on buckets without password specification -- for instance, legacy buckets which have been upgraded to use RBAC. -Users must authenticate to connect to the Query service and execute a {sqlpp} statement, and must be authorized to access all required buckets and collections. +Starting with version 7.6, Couchbase Server does not support {sqlpp} operations on buckets without a password. +This restriction includes legacy buckets upgraded to use RBAC. +Users must authenticate to connect to the Query Service and execute a {sqlpp} statement. +They must also have a role that grants them access to the buckets and collections they need to access. +See xref:learn:security/authorization-overview.adoc[] for more information about authorization. == Bucket Storage + Couchbase supports two different backends for the underlying storage of bucket data: -include::manage:partial$backend-description-section.adoc[] -See xref:learn:buckets-memory-and-storage/storage-engines.adoc[] for more information. -Note that the bucket storage backends apply only to Couchbase buckets: they do _not_ apply to Ephemeral buckets. +* Couchstore: the traditional storage engine better suited to lower volumes of data. +* Magma: the latest high performance storage engine for much higher data volumes. + +See xref:learn:buckets-memory-and-storage/storage-engines.adoc[] for more Information about storage engines. + +The bucket storage backends apply only to Couchbase buckets. +Ephemeral buckets do not use these backends. == Using Buckets in Administration and Development -For information on how to create, access, and manage buckets, see -xref:manage:manage-buckets/bucket-management-overview.adoc[Manage Buckets]. +See xref:manage:manage-buckets/bucket-management-overview.adoc[Manage Buckets] for information about creating, accessing, and managing buckets. -== Scopes and Collections -Within each bucket, data is organized in a logical hierarchy of _scopes_ and _collections_. -For more information, refer to xref:data/scopes-and-collections.adoc[Scopes and Collections]. diff --git a/modules/learn/pages/buckets-memory-and-storage/compression.adoc b/modules/learn/pages/buckets-memory-and-storage/compression.adoc index 985a024bf5..e871fe5974 100644 --- a/modules/learn/pages/buckets-memory-and-storage/compression.adoc +++ b/modules/learn/pages/buckets-memory-and-storage/compression.adoc @@ -40,7 +40,6 @@ On receipt of a compressed item, Couchbase Server decompresses the item when sto Couchbase Server sends the item in uncompressed form. This mode is assigned by default to buckets _upgraded_ from a previous version of Couchbase Server. The mode is recommended for use where clients cannot benefit from compression, and where neither memory-resources nor network-bandwidth will be negatively impacted by the size and quantity of items to be handled. -Note also that this is the only mode under which Memcached buckets operate. * *Passive*: On receipt of a compressed item, Couchbase Server stores it in compressed form both in memory and on disk. Couchbase Server sends the item back to the client in compressed form if this is requested by the client; otherwise, it sends the item back in uncompressed form. On receipt of an uncompressed item, Couchbase Server stores it in memory in uncompressed form, and stores it on disk in compressed form. diff --git a/modules/learn/pages/data/expiration.adoc b/modules/learn/pages/data/expiration.adoc index 0a7b5d41d9..08c4f0b5bc 100644 --- a/modules/learn/pages/data/expiration.adoc +++ b/modules/learn/pages/data/expiration.adoc @@ -15,9 +15,7 @@ For example, you often want documents that contain user session data to expire s Or you may use documents to store cached data. You can have these documents automatically expire so your application knows to refresh the data from its source. -Couchbase Server Enterprise Edition lets you have documents expire after a period of time, called the document's Time To Live (TTL). -This feature only works in Couchbase and Ephemeral buckets. -It does not work in Memcached buckets. +Couchbase Server Enterprise Edition lets you have documents expire after a period of time, called the document's Time To Live (TTL). You can set an expiration value on an individual document either when you create it or when you mutate it. Set the expiration to the number of seconds the document should exist before Couchbase Server automatically removes it. diff --git a/modules/learn/pages/glossary.adoc b/modules/learn/pages/glossary.adoc index e854c14993..ea248de16a 100644 --- a/modules/learn/pages/glossary.adoc +++ b/modules/learn/pages/glossary.adoc @@ -12,10 +12,9 @@ Use the links to locate the full descriptions of each. Each instance runs on its own physical or virtual machine. * xref:clusters-and-availability/clusters-and-availability.adoc[Cluster]: One or more instances of Couchbase Server, each running on an independent node; but cooperating with any and all others, so as to form a unified system; whereby resources are shared, and a single interface provided for data-access and management. * xref:buckets-memory-and-storage/buckets.adoc[Bucket]: A logical, user-named entity that groups items; allowing them to be accessed, indexed, replicated, and access-controlled. -There are three types: +There are two types: ** *Couchbase*: Retains data both in memory and on disk. ** *Ephemeral*: Retains data in memory only. - ** *Memcached*: Deprecated in 7.0, this has been intended for use in the context of other database platforms, such as ones employing relational database technology, in order to provide a managed memory-cache for frequently-used data. * xref:data/scopes-and-collections.adoc[Collection]: A data container, defined on Couchbase Server, within a bucket whose type is either _Couchbase_ or _Ephemeral_. * xref:data/scopes-and-collections.adoc[Scope]: A mechanism for the grouping of multiple collections. * xref:data/durability.adoc[Durability]: The atomic commitment of a single-document data-write, which ensures the write's greatest likelihood of surviving an unexpected anomaly, such as a node-outage, prior to the write's propagation throughout the entire cluster. diff --git a/modules/manage/assets/images/manage-buckets/addDataBucketDialogExpandedForMemcached.png b/modules/manage/assets/images/manage-buckets/addDataBucketDialogExpandedForMemcached.png deleted file mode 100644 index d6a97609bb..0000000000 Binary files a/modules/manage/assets/images/manage-buckets/addDataBucketDialogExpandedForMemcached.png and /dev/null differ diff --git a/modules/manage/pages/manage-buckets/create-bucket.adoc b/modules/manage/pages/manage-buckets/create-bucket.adoc index 7290327995..75078b6f70 100644 --- a/modules/manage/pages/manage-buckets/create-bucket.adoc +++ b/modules/manage/pages/manage-buckets/create-bucket.adoc @@ -42,7 +42,6 @@ A bucket name can be up to 100 characters in length and contain: . Choose a *Bucket Type* for the bucket: + * *Couchbase* -* *Memcached* * *Ephemeral* + @@ -88,7 +87,6 @@ For information about how to import documents into a bucket, see xref:manage:imp The available advanced settings for your bucket change based on your selected *Bucket Type*: * <> -* <> * <> [#couchbase-bucket-settings] @@ -175,20 +173,6 @@ For more information about flushing, see xref:manage-buckets/flush-bucket.adoc[F [#add-data-bucket-dialog-expanded] image::manage-buckets/addBucketWithMagmaOption.png[,400,align=center, alt="An image that displays the Add Data Bucket dialog, with a Couchbase Bucket Type and CouchStore Storage Backend selected. The Advanced bucket settings are expanded and to show the default selections for a Couchbase and Couchstore bucket."] -[#memcached-bucket-settings] -==== Memcached Bucket Settings - -CAUTION: Memcached buckets are deprecated. Use a *Couchbase* or *Ephemeral* bucket, instead. - -To configure advanced settings for a Memcached bucket: - -. To enable flushing for the bucket, under *Flush*, select the *Enable* checkbox. -+ -For more information about flushing, see xref:manage-buckets/flush-bucket.adoc[Flush a Bucket]. - -[#add-data-bucket-dialog-expanded-for-memcached] -image::manage-buckets/addDataBucketDialogExpandedForMemcached.png[,350,align=center, alt="An image that displays the Add Data Bucket dialog. The Memcached Bucket Type and CouchStore Storage Backend are selected. The bucket Name has been set to mySecondTestBucket."] - [#ephemeral-bucket-settings] ==== Ephemeral Bucket Settings diff --git a/modules/manage/partials/backend-description-section.adoc b/modules/manage/partials/backend-description-section.adoc deleted file mode 100644 index 8c49d21535..0000000000 --- a/modules/manage/partials/backend-description-section.adoc +++ /dev/null @@ -1,4 +0,0 @@ -[horizontal] -*Couchstore*:: the traditional storage engine better suited to lower volumes of data. -*Magma*:: the latest high performance storage engine for much higher data volumes. - diff --git a/modules/rest-api/pages/rest-bucket-create.adoc b/modules/rest-api/pages/rest-bucket-create.adoc index fbc196b313..d403c44a79 100644 --- a/modules/rest-api/pages/rest-bucket-create.adoc +++ b/modules/rest-api/pages/rest-bucket-create.adoc @@ -19,8 +19,7 @@ POST /pools/default/buckets/ == Description These respectively create a new bucket and edit an existing bucket. -The bucket can be of any type: Couchbase, Ephemeral, or Memcached. -(Note, however that Memcached buckets are now _deprecated_.) +The bucket can be of either type: Couchbase or Ephemeral. On creation, a bucket must be assigned a name that is unique among buckets defined on the cluster: this name cannot subsequently be changed. Names cannot be longer than 100 bytes (which is to say, characters). @@ -43,7 +42,7 @@ Note that floats and integers referred to in the following syntax-display are _n curl -X POST -u : http://:/pools/default/buckets -d name= - -d bucketType=[ couchbase | ephemeral | memcached ] + -d bucketType=[ couchbase | ephemeral ] -d ramQuota= -d storageBackend=[ couchstore | magma ] -d evictionPolicy=[ @@ -177,7 +176,7 @@ The value of the `ramQuota` parameter (described below), is hereby increased to === bucketType Specifies the _type_ of the bucket. -This can be `couchbase` (which is the default), `ephemeral`, or `memcached`. +This can be `couchbase` (which is the default) or `ephemeral`. For a detailed explanation of bucket types, see xref:learn:buckets-memory-and-storage/buckets.adoc[Buckets]. If an invalid bucket type is specified, the error-notification `{"bucketType":"invalid bucket type"}` is returned. @@ -279,7 +278,6 @@ The _ejection policy_ to be assigned to and used by the bucket. Policy-assignment depends on bucket type. For a _Couchbase_ bucket, the policy can be `valueOnly` (which is the default) or `fullEviction`. For an _Ephemeral_ bucket, the policy can be `noEviction` (which is the default) or `nruEviction`. -No policy can be assigned to a _Memcached_ bucket. This value _can_ be modified, following bucket-creation. If such modification occurs, the bucket is restarted with the new setting: this may cause inaccessibility of data, during the bucket's warm-up period. @@ -325,7 +323,6 @@ A _durability level_ to be assigned to the bucket, as the minimum level at which Level-assignment depends on bucket type. For a _Couchbase_ bucket, the level can be `none`, `majority`, `majorityAndPersistActive`, or `persistToMajority`. For an _Ephemeral_ bucket, the level can be `none` or `majority`. -No level can be assigned to a _Memcached_ bucket. This parameter _can_ be modified, following bucket-creation. diff --git a/preview/DOC-12483_remove_memcached_buckets.yml b/preview/DOC-12483_remove_memcached_buckets.yml new file mode 100644 index 0000000000..58eddfd02b --- /dev/null +++ b/preview/DOC-12483_remove_memcached_buckets.yml @@ -0,0 +1,25 @@ +sources: + docs-devex: + branches: DOC-12483_remove_memcached_buckets + docs-analytics: + branches: release/8.0 + couchbase-cli: + # url: ../../docs-includes/couchbase-cli + url: https://github.com/couchbaselabs/couchbase-cli-doc + # branches: HEAD + branches: master + startPaths: docs/ + backup: + # url: ../../docs-includes/backup + url: https://github.com/couchbaselabs/backup-docs.git + #branches: HEAD + branches: master + startPaths: docs/ + #analytics: + # url: ../../docs-includes/docs-analytics + # branches: HEAD + cb-swagger: + rl: https://github.com/couchbaselabs/cb-swagger + branches: release/8.0 + start_path: docs +