Article For
4.2 5.0 5.2

Hub/Sink Replication: Overview


Hub/Sink replication is used to maintain a live replica of a database or a chosen part of it, through a secure connection between ongoing Hub and Sink replication tasks.


What is Hub/Sink Replication for?

  • Flexible Connectivity
    The connection between Hub and Sink doesn't have to be continuous and can be initiated by the Sink at will.
    This can be very helpful when the Sink instance tends to go offline, e.g. -

    • Using a cellular network that may not always have connectivity
    • Using a laptop in a location with no WiFi
    • Onboard ships that sail offshore and offline
    • in a security installation that limits its communication time with the outside world
    • In a remote settlement that surfaces online every now and then

    in the ship's case, for example, the Sink can initiate a connection with an onshore Hub to replicate data, whenever it returns online.

  • Many to One
    The Hub can serve many Sinks using the same port, simplify security protocols and save server resources.

    This can be useful whenever multiple devices (e.g. an array of computers onboard a fleet of trucks) collect their records locally and replicate them periodically to a central database.

Filtered Replication

Filtered Replication allows you to choose the documents that would be replicated. Replicating only a selected part of your database can be useful in numerous cases, e.g. -

  • To keep documents confidentiality
    When an organization whose main database serves multiple departments, facilities or branches use Filtered Replication to keep documents confidentiality.
    The central database of a health-care network, for example, can protect patients privacy by updating each clinic's database instance only with records of patients treated by this clinic.

  • As an additional security measure
    A central database that an array of traffic enforcement cameras replicate speed tickets to, for example, can use Filtered Replication to restrict each camera's replication to just tickets generated by this camera.
    This will prevent a potential hacker from replicating a stolen camera's speed tickets as if they were collected by another camera (e.g. to overrun a ticket collected by any chosen camera, with a blank one).

  • Both the Hub and the Sink can filter data
    Only documents matching the filters defined by both, will be replicated.
  • Documents are selected by path
    Paths can include wildcards (companies/*) and exact document IDs (companies/88-A).
  • Read and Write filtering
    You can further increase filtering resolution, by defining separate lists of allowed paths for incoming and outgoing documents.

Accesses and Certificates

The connection between Hub and Sink tasks is validated using public-key cryptography.

  • Creating Accesses
    When you create or edit a Hub task, you can add it Accesses.
    Each Access can be used by a Sink task to connect the Hub.
    You are required to issue a certificate for each Access, that would identify Sinks that connect the Hub via this Access.

  • Issuing Certificates

    • You can issue a certificate from a few sources:
      • Create a new certificate in the Hub task creation page.
      • Import and reuse the certificate that is already used by the server to validate client access.
      • Provide a certificate from any other source.
  • Export from Hub, Import by Sink
    After using the Hub task creation page to issue the certificate, you need to export the certificate to a file.
    When you create a Sink task, you are given the option to load the file and provide the Sink with the certificate it would access the hub with.

What does the replication include?

Documents are replicated along with all their properties, including Time Series, counters, attachments and revisions.

Failover

Read about replication tasks Failover Here.

Backward-Compatibility

Read about Hub/Sink Replication backward compatibility with Pull Replication Here.