Merge branch 'release/3.3' into prerelease/3.3

Author: simon-dew

modules/ROOT/pages/database-management.adoc

@@ -1,6 +1,5 @@
 = Database Management
 :page-edition: {release}
-:page-status: {prerelease}
 :page-toclevels: 2@
 :page-pagination: next
 :page-role:

modules/ROOT/pages/get-started-install.adoc

@@ -20,8 +20,10 @@ include::partial$_set_page_context.adoc[]
 
 :downloads--url: https://www.couchbase.com/downloads/?family=sync-gateway[downloads page]
 :sg_download_link: pass:q,a[{url-package-downloads}/{version-maintenance}/]
+:sg_package_name_arm: couchbase-sync-gateway-community_{version-maintenance}_arm64
 :sg_package_name: couchbase-sync-gateway-community_{version-maintenance}_x86_64
 :sg_package_name_ee: couchbase-sync-gateway-enterprise_{version-maintenance}_x86_64
+:sg_package_name_ee_arm: couchbase-sync-gateway-enterprise_{version-maintenance}_arm64
 :sg_accel_package_name: couchbase-sync-gateway-enterprise_{version-maintenance}_x86_64
 
 :install-location-linux: /opt/couchbase-sync-gateway/
@@ -457,7 +459,7 @@ Download the required edition of Sync Gateway from the {downloads--url}.
 --
 [{snippet-header}]
 ----
-sudo unzip -d /opt {sg_package_name_ee}.zip
+sudo unzip -d /opt {sg_package_name_ee_arm}.zip
 ----
 --
 
@@ -634,4 +636,4 @@ include::partial$block-related-content-deploy.adoc[]
 :is-intro!:
 :is-prepare!:
 :is-install!:
-:is-verify!:
+:is-verify!:

modules/ROOT/pages/server-compatibility-buckets.adoc

@@ -52,7 +52,11 @@ For more information, see xref:server:learn:data/expiration.adoc[].
 Sync Gateway does not support Bucket-level TTL, make sure your buckets have their `maxTTL` setting set to `0`.
 If the bucket setting has a non-zero `maxTTL` value set, Sync Gateway returns an error prompting you to set the value to `0` in the Couchbase Server Admin UI.
 
-NOTE: You can still set Document expiration settings and Collection maxTTL.
+Similarly, do not set Collection-level TTL (`maxTTL` on collections) as this can interfere with Sync Gateway's internal documents, including those with `_sync` prefixes and other system documents that are essential for proper operation. 
+If these system documents expire due to collection-level TTL, Sync Gateway may malfunction or fail to operate properly. 
+You can use per-collection sync functions to set expiry on all documents within a collection when you need TTL-like behavior at the collection level, while preserving Sync Gateway's system documents.
+
+NOTE: You can still set Document expiration settings on individual documents.
 
 // BEGIN -- Page Footer
 include::partial$block-related-content-sync.adoc[]

modules/ROOT/pages/sync-inter-syncgateway-overview.adoc

@@ -58,14 +58,15 @@ A typical architecture for this use cases is shown in <<icr-cloud-to-edge>>
 image::icr-cloud-to-edge200712.svg[,600]
 
 === Active-to-active Mobile Synchronization
-Here edge clusters containing active Sync{nbsp}Gateway nodes are replicated between geographically separate cloud-based Sync Gateway deployments.
-An ideal use-case for inter-Sync{nbsp}Gateway replication, which was designed to keep clusters in different data centers in sync.
 
-The Couchbase Server Cross Data Center Replication API (xref:server:manage:manage-xdcr/xdcr-management-overview.adoc[XDCR]) is similarly used to replicate between Couchbase Server clusters.
-*However, the inter-Sync{nbsp}Gateway replication feature is specifically designed for Sync Gateway deployments and it must be used for replication between mobile clusters.* {fnxdcr}
+Inter-Sync Gateway replication replicates edge clusters containing Sync{nbsp}Gateway nodes between geographically separate cloud-based Sync Gateway deployments.
+This provides an ideal use-case for inter-Sync{nbsp}Gateway replication, which was designed to keep clusters in different data centers in sync.
 
+Couchbase Server uses the Cross Data Center Replication API (xref:server:manage:manage-xdcr/xdcr-management-overview.adoc[XDCR]) similarly to replicate between Couchbase Server clusters.
+*However, inter-Sync{nbsp}Gateway replication feature is specifically designed for Sync Gateway deployments and must be used for replication between mobile clusters.* {fnxdcr}
 
-A typical architecture for this use case is shown in <<icr-active-mobile>>
+
+<<icr-active-mobile>> shows a typical architecture for this use case.
 
 [[icr-active-mobile]]
 .Active-to-active mobile synchronization
@@ -148,6 +149,29 @@ NOTE: Push replications to pre-2.8 targets do not use Delta Sync
 _Related configuration elements_:  {configuration-schema-database--xref}  |  {configuration-schema-database--xref--db-replications}  |
 {configuration-schema-database--xref--delta-sync}  |  {configuration-schema-database--xref--db-rep-delta}
 
+=== Collections Support
+
+Inter-Sync Gateway replication supports named collections, including:
+
+* Enabling or disabling collections replication.
+* Limit replication to specific collections.
+* Map local collections to differently named remote collections.
+
+For detailed configuration of collections parameters (`collections_enabled`, `collections_local`, `collections_remote`), see xref:configuration-schema-isgr.adoc#replication[Run Inter-Sync Gateway Replication Configuration Schema].
+
+==== Collection Mapping
+
+Collection mapping allows you to replicate local collections to differently named collections on the remote target. You configure this using two parallel arrays:
+
+* `collections_local` - specifies the collections to replicate from the source.
+* `collections_remote` - specifies the corresponding target collection names on the remote.
+
+The mapping works positionally, where the first collection in `collections_local` maps to the first collection in `collections_remote`, the second to the second, and so on.
+
+NOTE: You must verify all specified collections exist in both source and target Sync Gateway database configurations before starting replication. 
+Sync Gateway does not automatically create missing collections or sync new collections after replication begins.
+
+This collection mapping capability adapts the mapping concept from XDCR for Sync Gateway deployments. For information about xref:server:learn:clusters-and-availability/xdcr-with-scopes-and-collections.adoc#implicit-mapping[Implicit Mapping] and xref:server:learn:clusters-and-availability/xdcr-with-scopes-and-collections.adoc#explicit-mapping[Explicit Mapping] in the XDCR documentation.
 
 === Directionality
 

modules/ROOT/pages/sync-with-couchbase-server.adoc

@@ -8,7 +8,6 @@ ifdef::prerelease[:page-status: {prerelease}]
 :description: Use Sync Gateway to sync Couchbase Server changes securely from cloud to edge
 :keywords: sync gateway, replication, sync, synchronization, edge, cloud
 :pageOriginRel: "sg=1.5, Cbs=5.0)_"
-:imagesdir: ../assets/images
 
 include::partial$_set_page_context.adoc[]
 
@@ -21,7 +20,7 @@ include::partial$block-standard-footnotes.adoc[tags=sgw1x5;cbs5x0]
 :fn-sgw: footnote:fn-sgw[Prior to Release 2.5, Server 5.0 all writes had to go through Sync Gateway, or had to use bucket shadowing to ensure that the security and replication metadata needed by mobile applications was preserved.]
 // :fn-sgw-ref: footnote:fn-sgw[]
 
-:enable-sba-config-item: {configuration-schema-database--pfx}#enable_shared_bucket_access[$dbname.enable_shared_bucket_access]
+:enable-sba-config-item: {configuration-schema-database--pfx--db}-enable_shared_bucket_access[$dbname.enable_shared_bucket_access]
 :xattr--page: xref:server:learn:data/extended-attributes-fundamentals.adoc[Extended Attributes (XATTR)]
 
 include::partial$block-caveats.adoc[tags="cbs6.0ke-xattrs"]
@@ -30,16 +29,16 @@ include::partial$block-caveats.adoc[tags="cbs6.0ke-xattrs"]
 == Introduction
 
 
-{sgw-t} will automatically sync database changes if {configuration-schema-database--xref--import-docs} and {configuration-schema-database--xref--enable-shared-bucket-access} are set 'true'.
+{sgw-te} will automatically sync database changes if {configuration-schema-database--xref--import-docs} and {configuration-schema-database--xref--enable-shared-bucket-access} are set 'true'.
 
-enable_shared_bucket_access::
-This setting ensures that both {sgw-t} and {cbs-t} can read and write to the same bucket simultaneously and that {sgw-t} can access {cbs} document XATTRS +
-See: <<sgw-paths>> and {configuration-schema-database--xref--enable-shared-bucket-access}.
+* Enable_Shared_Bucket_Access
 +
-Setting this property to `true` will be required in a future release, and `false` will not be supported.
+This setting ensures that both {sgw} and {cbs-te} can read and write to the same bucket simultaneously and that {sgw} can access {cbs} document XATTRS +
+See: <<sgw-paths>> and {configuration-schema-database--xref--enable-shared-bucket-access}.
 
-import_docs::
-Setting this property true ensures that the {sgw-t} node performs import processing, obtaining the mobile metadata it requires to replicate changes -- see: <<import-process>>.
+* Import Docs
++
+Setting this property true ensures that the {sgw} node performs import processing, obtaining the mobile metadata it requires to replicate changes -- see: <<import-process>>.
 
 You can configure both these properties using the Admin Rest API {configuration-schema-database--xref} endpoint.
 
@@ -54,7 +53,7 @@ image::shared-bucket-access.png[]
 
 Mobile applications require additional metadata in order to manage security and replication.
 
-{sgw-t} stores this information using {cbs} XATTRs (see {cbs} documentation on {server-data-xattr-fundamentals--xref}).
+{sgw} stores this information using {cbs} XATTRs (see {cbs} documentation on {server-data-xattr-fundamentals--xref}).
 
 
 === Extended Attributes (XATTRs)
@@ -72,24 +71,24 @@ Extended attributes:
 * Can be accessed via {cbs} SDKs using the sub-document API, via command-line tools, and via views.
 
 * Are accessible from {sqlpp} in {cbs} using the `().xattrs` property. +
-For example, `SELECT meta().xattrs._sync from travel-sample where Meta().id = "user::demo";`.
+For example, `SELECT meta().xattrs._sync from travel-sample where Meta().id = "user::demo"`;.
 
 
-Both {sgw-t} and {cbs} use a System extended attribute, with the following characteristics to support mobile convergence (shared bucket access):
+Both {sgw} and {cbs} use a System extended attribute, with the following characteristics to support mobile convergence (shared bucket access):
 
 * Shares lifetime with the document metadata - when a document is deleted, system xattrs are preserved with the tombstone.
 * Allocated 1MB of storage, independent of the 20MB available for the document
 
-WARNING: The sync metadata is maintained internally by {sgw-t} and its structure can change at any time.
+WARNING: The sync metadata is maintained internally by {sgw} and its structure can change at any time.
 It should not be used to drive business logic of applications.
 The direct use of the {sqlpp} query is unsupported and must not be used in production environments.
-The `_raw` endpoint (/db/_raw/{docid}) on {sgw-t}'s Admin REST API returns both the document and its associated mobile metadata.
+The `_raw` endpoint (/db/_raw/{docid}) on {sgw}'s Admin REST API returns both the document and its associated mobile metadata.
 
 === Documents
 
-With bucket-sharing enabled, {cbs} documents can be inserted directly (using {sqlpp} or SDKs) or by using {sgw-t}'s {rest-api--xref}.
+With bucket-sharing enabled, {cbs} documents can be inserted directly (using _{sqlpp}_ or _SDKs_) or by using {sgw}'s {rest-api--xref}.
 
-{sgw-t} {fn-sgw1x5} creates the metadata it needs by abstracting it from the SDK or {sqlpp} applications reading and writing data directly to {cbs} buckets.
+{sgw} {fn-sgw1x5} creates the metadata it needs by abstracting it from the SDK or {sqlpp} applications reading and writing data directly to {cbs} buckets.
 It uses {cbs} XATTRs {fn-cbs5x0} to store that metadata into an external document fragment -- see {xref-svr-pg-xattrs}.
 
 // The REST API will also include the following behavioral changes:
@@ -100,7 +99,7 @@ It uses {cbs} XATTRs {fn-cbs5x0} to store that metadata into an external documen
 === Blobs and Attachments
 
 .Couchbase Server SDK/{sqlpp}
-Use {sgw-t}'s REST API's {xref-sgw-ep-public-api-attachment} endpoints to
+Use {sgw}'s REST API's {xref-sgw-ep-public-api-attachment} endpoints to
 manage attachments and blob data; you cannot use {cbs} SDKs to do this
 directly.
 
@@ -115,7 +114,7 @@ Couchbase Lite apps seamlessly handle blobs and attachments, see the appropriate
 include::partial$blocklinks-cbl.adoc[]
 
 .Using a WebApp
-Attachments can be accessed through {sgw-t}'s REST API using the xref:rest_api_public.adoc#tag/Document-Attachment/operation/get_keyspace-docid-attach[+/{keyspace}/{docid}/{attach}+] endpoint.
+Attachments can be accessed through {sgw}'s REST API using the xref:rest_api_public.adoc#tag/Document-Attachment/operation/get_keyspace-docid-attach[+/{keyspace}/{docid}/{attach}+] endpoint.
 
 === Tombstone Revisions
 
@@ -130,21 +129,23 @@ As stated, mobile metadata is not kept in the document, but in a system extended
 The {sqlpp} query language {fnref-cbs5x0} supports the ability to query these extended attributes (XATTRS) and hence the document's sync metadata -- see: <<simple-query>>.
 
 [#simple-query]
-.Querying XATTRS-bsed sync metadata
+.Querying XATTRS-based sync metadata
 ====
-[source,sqlpp]
+[source,sql]
 ----
 SELECT meta().xattrs._sync FROM scope.collection WHERE meta().id = "mydocId"
 ----
 ====
 
-WARNING: The sync metadata is maintained internally by {sgw-t} and its structure can change at any time.
-It should not be used to drive business logic of applications. The direct use of the {sqlpp} query is *unsupported* and must not be used in production environments.
+WARNING: {sgw} maintains the sync metadata internally, and its structure can change at any time. 
+Applications must not use it for business logic. 
+The direct use of the {sqlpp} query or modifying the internal sync metadata contents to drive the business logic is unsupported and must not be used in production environments. 
+The sync metadata includes the `_sync` extended attribute (XATTR) in use case documents and all `_sync:` prefixed documents in Sync Gateway connected Buckets.
 
 === Enable Shared Bucket Access
 
 Shared bucket access is an opt-in feature.
-You can enable it without bringing down the entire {sgw-t} cluster  -- see <<enable-sba>>.
+You can enable it without bringing down the entire {sgw} cluster  -- see <<enable-sba>>.
 
 [#enable-sba]
 .Enable Bucket-Sharing
@@ -161,7 +162,7 @@ You can enable it without bringing down the entire {sgw-t} cluster  -- see <<ena
     }
 }
 ----
-<.> The `import_docs` property is used to specify that a {sgw-t} node participates (exclusively) in {import-process--xref}. The mechanism by which {sgw-t} incorporates changes to data buckets it shares with {cbs} -- see: <<import-process>>.
+<.> The `import_docs` property is used to specify that a {sgw} node participates (exclusively) in {import-process--xref}. The mechanism by which {sgw} incorporates changes to data buckets it shares with {cbs} -- see: <<import-process>>.
 
 ====
 
@@ -171,37 +172,30 @@ You can enable it without bringing down the entire {sgw-t} cluster  -- see <<ena
 
 
 The *import process* is a key part of mobile convergence.
-It is the means by which {sgw-t} becomes aware of non-{sgw-t} data changes and obtains the mobile metadata it requires to replicate changes.
+It is the means by which {sgw} becomes aware of non-{sgw} data changes and obtains the mobile metadata it requires to replicate changes.
 
 image::shared-bucket-access.png[]
 
-Any non-{sgw-t} change is eligible for import.
+Any non-{sgw} change is eligible for import.
 The document is first run through the Sync Function to compute read security and routing, with the following differences:
 
-* The import is processed with an admin user context in the Sync Function, similar to writes made through the {sgw-t} Admin API.
+* The import is processed with an admin user context in the Sync Function, similar to writes made through the {sgw} Admin API.
 This means that `requireAccess`, `requireUser` and `requireRole` calls in the Sync Function are treated as no-ops.
 * During import, `oldDoc` is `nil` when the Sync Function is executed.
 
-You can specify a filter function using the {configuration-schema-database--pfx}#import_filter[import_filter] property, which will only import specific documents.
+You can specify a filter function using the {configuration-schema-database--pfx--db}_import_filter[import_filter] property, which will only import specific documents.
 
 TIP: Use the {bootstrap-schema--xref--logging-console-log-keys} log key to troubleshoot import processing issues in the logs.
 
 === Configuration
 
 Note that `import_docs` only takes effect if the `enabled_shared_bucket_access` is set to `true`.
 
-****
-[.edition]#{enterprise}#
-
+{enterprise}::
 The `import_docs` parameter defaults to `true`, implying that, by default, all nodes in a cluster participate in import processing.
 To exclude a node, set `"import_docs": false`.
-
-'''
-
-[.edition]#{community}#
-
-The `import_docs` parameter defaults to `false` and must be explicitly set to `true`.
-****
+{community}::
+The `import_docs` parameter defaults to false and must be explicitly set to `true`.
 
 The following table describes the key behavior differences between Community Edition and Enterprise Edition when `import_docs` is enabled, disabled or not set at all.
 
@@ -241,7 +235,7 @@ The following table describes the key behavior differences between Community Edi
 |===
 
 === High Availability
-In _Enterprise Edition_, import processing work is sharded across all {sgw-t} nodes with import enabled.
+In _Enterprise Edition_, import processing work is sharded across all {sgw} nodes with import enabled.
 This implies that if one of the nodes fail, the failed shard is automatically picked up by the remaining nodes in the cluster.
 This way, you get High Availability of import processing.
 
@@ -254,7 +248,7 @@ As described in the table above, if `import_docs` is set to `false`, the node wi
 This configuration is specifically recommended for workload isolation: to isolate import nodes from the client-facing nodes.
 Workload isolation may be preferable in deployments with high write throughput.
 
-The following diagram shows an example architecture of two {sgw-t} nodes handling the incoming client connections (`import_docs: false`) and two nodes sharing the import processing (`import_docs: true`).
+The following diagram shows an example architecture of two {sgw} nodes handling the incoming client connections (`import_docs: false`) and two nodes sharing the import processing (`import_docs: true`).
 
 image:workload-isolation.png[]
 
@@ -270,16 +264,16 @@ image:workload-isolation.png[]
 .Next Steps
 ****
 
-* Check out our getting started tutorial for more on how to setup, configure and run {sgw-t} replications - xref:tutorials:userprofile-sync:userprofile_sync.adoc[Sync tutorial]
+* Check out our getting started tutorial for more on how to setup, configure and run {sgw} replications - xref:tutorials:userprofile-sync:userprofile_sync.adoc[Sync tutorial]
 
 * Further reading:
 ** {cbs} documentation on {server-data-xattr-fundamentals--xref}
 
 ** Configuration file references:
 
 *** {enable-sba-config-item} to enable convergence for a given database.
-*** {configuration-schema-database--pfx}#import_docs[$dbname.import_docs] to give a particular {sgw-t} node the role of importing the documents.
-*** {configuration-schema-database--pfx}#import_filter[$dbname.import_filter] to select which document(s) to make aware to mobile clients.
+*** {configuration-schema-database--pfx--db}-import_docs[$dbname.import_docs] to give a particular {sgw} node the role of importing the documents.
+*** {configuration-schema-database--pfx--db}-import_filter[$dbname.import_filter] to select which document(s) to make aware to mobile clients.
 
 ****
 

preview/HEAD.yml

@@ -0,0 +1,3 @@
+sources:
+  docs-server:
+    branches: release/7.6