Deploying Couchbase Eventing

In order to process events on Couchbase NoSQL database Gluesync needs that the eventing service is deployed inside the cluster and available. Eventing service is needed to run Gluesync Eventing functions. Those functions will generate events based on changes that happen on Couchbase documents in a particular bucket. Gluesync then will process those events and replicate data into the destination database.

How to size your cluster deployment

To properly define the sizing and number of nodes needed to provide that functionality our professional services can be involved opening a ticket to the support team.

Automatic Eventing functions deploying for Couchbase self-hosted

If you’re considering running Gluesync in a Capella cluster (Couchbase DBaaS) please see next chapter.

Gluesync automatically deploys the following Eventing functions inside your Couchbase Cluster deployment at its first initialisation. Each function has a prefix gluesync_ word to be easily recognised inside your Eventing deployment. As per you can have multiple Gluesync instances running into your Couchbase Server cluster.

When deploying Gluesync targeting a bucket shared with a Couchbase Sync Gateway you will need an additional configuration before starting the connector. Please refer to this page to learn more.

Deploying eventing functions in Couchbase Capella DBaaS

Couchbase Capella is the Database-as-a-Service (DBaaS) provided by Couchbase, a fully-managed Couchbase Cluster instance capaple also of running Couchbase Mobile through Couchbase App Services.

Currently, Capella DBaaS, does not support direct access to the same Eventing APIs that are instead exposed in a self-hosted Couchbase cluster. We’re working closely with the vendor in order to get this feature available as soon as possible for our customers, for that reason until its availability you should deploy GS eventing functions manually into your Capella cluster.

Our professional services are aviable to support you in that task and provide you the packege containing the Javascript-based functions that are briefly described below.

Eventing function `gluesync_${configuration.sourceName}_generate_document_event`

Generates an event from a JSON document change notification and writes it inside the helper bucket. This function uses the Gluesync’s config JSON document mentioned below to retrieve the list of docTypes to monitor.

Eventing function `gluesync_${configuration.sourceName}_save_event_to_target`

Takes the saved event and writes it into the source bucket where it will be consumed by Gluesync.

Understanding Gluesync’s config JSON (Document types list)

Gluesync will store a specific JSON document into your “Data bucket” in order to let you catch events coming from the specified JSON document type’s key; it can be easily recognised thanks to its type property __gluesync_config_doc.

Config JSON document has basically this simple structure:

{
  "sourceEntities": ["orders","DocumentType2","DocumentType3","DocumentType4"],
  "type": "__gluesync_config_doc"
}

Leaving the mentioned document empty will let the eventing function generate an event for every document type that gets changed inside your “Data bucket”.

do not manually edit this document, it is automatically managed by the Gluesync connector.

Understanding Gluesync’s migration flag

Gluesync will store a specific JSON document into your “Data bucket” in order keep trace of the first migration before enable tracking of changes. This is usefull to know if migration already happened in case of restart or retry. The id of the document is __gluesync_migration_doc.

JSON document has basically this simple structure:

{
  "migratedEntities": ["orders","DocumentType2","DocumentType3","DocumentType4"]
}

Understanding Gluesync’s events counter

Gluesync will store a specific JSON document into your “Data bucket” in order keep a counter to processed events. This is usefull to have a checkpoint in case of restart or retrye. The id of the document is __gluesync_events_counter.