DOC-12483 remove memcached buckets

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]

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

modules/introduction/partials/new-features-80.adoc

@@ -62,6 +62,13 @@ curl --get -u <username:password> \
 [#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:

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].

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.

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.