WO2021147926A1

WO2021147926A1 - Methods and systems for hybrid edge replication

Info

Publication number: WO2021147926A1
Application number: PCT/CN2021/072947
Authority: WO
Inventors: Rohit Prabhakar SARDESAI; Sanil Kumar DIVAKARAN NAIR; Guruprasad I NAIK
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2020-01-20
Filing date: 2021-01-20
Publication date: 2021-07-29
Also published as: CN113138879A

Abstract

Methods and systems for hybrid edge replication are disclosed. The present invention finds its application in edge cloud scenarios. For any edge cloud deployment, data processing at the edge is a critical feature. For this processing, the data needs to be shared across and also to be replicated with other edge nodes or central cloud. Thus, the present invention plays a critical role in all the edge use-cases since it involves data handling from the devices or from cloud. It also helps to handle offline and failure scenarios in edge cloud. Through selective replication, it ensures better resources utilization and ensures the availability of edge cloud services.

Description

METHODS AND SYSTEMS FOR HYBRID EDGE REPLICATION

TECHNICAL FIELD

The present subject matter described herein, in general, relates to replicating databases and more particularly, it relates to methods and systems for hybrid edge replication.

BACKGROUND

Replication involves storing copies of data at multiple storage devices. There is a single logical copy of the data and, an update to one replica will be reflected at all other replicas of said data. This technique offers the following advantages listed hereinbelow:

a) Enhanced performance: replication makes it possible to accept and handle more requests since workload is distributed among a plurality of processes.

b) Reduced latency: with replication latency is reduced since data is replicated closer to the user.

c) Reduced failures: replication allows services to overcome individual server failures since there are other servers available to provide the same service.

d) Fault tolerance: replication also ensures correct data is provided to the client.

This technology finds its application in user devices that continuously sync data across all user devices and social media platforms. In particular, they allow users to continuously sync data across a plurality of devices by doing away with the need to explicitly save, reload, and exchange shared data. This is not merely limited to mobile applications or social media platforms or distributed versions of desktop applications. In the distributed systems, replication is primarily employed to provide fault tolerance. The entity being replicated is a process. There are two types replication strategies used in distributed systems, namely, active and passive replication.

Figure 1 illustrates a typical edge cloud topology where each edge node needs to communicate vertically (north-south) and horizontally (east-west) . Data sharing is needed across edge nodes and edge node to cloud. Data replication for high availability (HA) is needed at cloud and at edge cloud. Selective data communication is needed across edges and edge to cloud based on the data processing and compute location.

In passive replication, a primary server processes client requests and updates the state on a plurality of backup servers and sends back a response to the client. If the primary server fails, one of the backup servers assumes its position. They can be used for non-deterministic processes as well. Figure 2 illustrates the block diagram for passive replication view. This may be referred to as a primary-secondary replication model where the initial write happens to the primary always and then replicates to the secondary nodes. The disadvantage of passive replication is that in case of failure, the response is delayed. In particular, the problems associated with edge cloud scenarios are as follows:

a) Cannot have a primary server at all edge. Since there is a single primary it can be either at one edge or in cloud. However, to have writes at all edges we need multiple primary at edges;

b) Data writes at edges still happen to primary server in cloud. Since there is a single primary server which is ideally located in the cloud all writes at edges will happen to primary server in the cloud which would then get replicated to secondary node at the edge;

c) All data gets replicated at all edges, since there is a single primary server ideally located in the cloud and the secondary at the edges there is replication of all data from the primary in cloud to secondary at the edges; and

d) Edge offline scenario fails. When there is no connection between the cloud and edge, the secondary at edge will be on its own. Since there is a minimum quorum for the secondary nodes to select the primary a single secondary at the edge will not continue to work. This fails the basic requirements of Edge Computing (offline mode)

Hence, selective sharing, replication and offline scenarios cannot be handled by passive replication. In passive replication, replication occurs in one direction: from the master to the replica.

In active replication, each client request is processed by all the servers. It requires that the process hosted by the servers is deterministic, i.e., given the same initial state and a request sequence, all processes will produce the same response sequence and end up in the same final state. Figure 3 illustrates the block diagram for active replication view. This may be referred to as a multiple-master model where all act as masters. The disadvantage of active replication is that most real world servers are non-deterministic. In particular, the problems associated with edge cloud scenarios are as follows:

a) With a master node at edge, all data gets replicated across all edges;

b) With large number of edges, the sync between replicas will be a problem; and

c) Edge offline scenario is hard to handle.

Hence, selective sharing or replication is not handled. Also, the dynamic partition or selective attribute is missing. In active (also referred to as cross`-center data replication (XDCR) ) replication, client applications perform read/write operations on any of the participating clusters and changes in one database are then copied and applied to all the other databases.

Distributed in-memory key value stores like memcached, aerospike, voltdb, support passive replication and active replication (also called cross-center data replication i.e. XDCR) for high availability and disaster recovery.

In edge computing environments, using an in-memory store for storing metadata about edge nodes, devices and edge groups’ speeds up local client writes. The replication requirements are slightly different from the ones provided by the available in-memory key-value stores. Since connectivity to cloud is not always guaranteed, it is essential that clients can write to the secondary edge replicas. Secondary edge replicas can replicate this data to cloud whenever cloud connectivity is available. Passive replication won’t be able to fit this requirement.

This can be still achieved with XDCR. However, in addition edge nodes could optionally publish some common metadata to all other edge nodes in the same edge group. This capability isn’t provided by default in any of the key-value stores or kv stores.

In XDCR, what data to replicate between nodes in the cluster is controlled by partitioning the data, thereby allowing partitioning data per edge node. However, there is no mechanism to handle selectively replicating data amongst a group of edge nodes. Therefore, in such cases, additional logic on top of the database layer is written to selectively replicate data, effectively not using the replication logic provided by the key-value stores themselves which would be error prone, more complex and difficult to maintain.

For some existing technology, reference is made to US 9239767 B2 which discloses selective replication of databases operating in a cluster. Replication tasks are triggered by primary servers, which build federated tables in primary db (database) for doing updates to secondary db. Loose coupling is thus achieved and helps async replication. The drawbacks associated with this technology being they employ primary-copy mechanism. Federated tables are built for doing updates to secondary db servers and cannot work for an edge computing environment where the edge replicas are kind of secondary db servers which can directly be written to by clients.

Reference is also made to US 8315977 B2 which discloses data synchronization between a data center environment and a cloud computing environment. A database manager component running on the data center detects changes in data records and transfers them to the cloud. The cloud replicator running in the cloud listens for database record updates and applies the changes to the cloud database. It allows automatic synchronization of data between data center and cloud. The cloud replicator has logic to detect db update changes, convert data to cloud db specific format and store. The drawbacks associated with this technology being that custom db manager and replicator modules need to be developed to perform the synchronization.

Reference is also made to US 7177886 B2 which discloses an apparatus and a method for coordinating logical data replication with highly available data replication. In particular, asynchronous data replication between primary and backup database servers. It avoids data inconsistencies among remote servers in the event of a failure of the central database primary server and provides asynchronous replication functionality that is robust with respect to primary database failure. It also provides for fail-safe recovery via a high availability replication system, while retaining the broad functionality of data distribution by asynchronous replication. The drawback associated with this technology being that it only supports primary-copy mechanism and backup servers cannot accept write requests.

The problems associated with the state of art technologies being that the distributed in-memory stores operate in passive mode, i.e., writes happen only via the master node, mode or active mode where all nodes can take read/write requests and synchronize. In edge computing, edge nodes need to accept local writes and replicate the data to the cloud and hence passive replication cannot cater to this requirement. Active replication requires quorum for read/writes to be processed which can’t be guaranteed in offline scenarios, so active replication also can’t satisfy edge requirements. Moreover, for security reasons, some of the data of an edge node should not be made available to other edge nodes connected to the cloud, i.e., selective sharing across edge nodes. Furthermore, the existing inbuilt replication mechanisms in KV-stores do not provide customization and therefore, need additional work at the platform layer to handle selective data replication.

Accordingly, there is a need for selective replication of edge data to cloud/edge groups, selective sharing of one edge data across edge nodes and support for offline scenarios of edge for data replication and sharing. In particular, there is a need for hybrid edge replication in key value stores for edge computing scenarios.

The above-described need for hybrid edge replication for edge computing scenarios is merely intended to provide an overview of some of the shortcomings of conventional systems /mechanism /techniques, and is not intended to be exhaustive. Other problems/shortcomings with conventional systems/mechanism/techniques and corresponding benefits of the various non-limiting embodiments described herein may become further apparent upon review of the following description.

SUMMARY

This summary is provided to introduce concepts related to methods and systems for hybrid edge replication, and the same are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.

An objective of the present invention is to provide a mechanism to handle selective replication, selective sharing between edge nodes in edge groups an also between and edge nodes and cloud.

Another objective of the present invention is to support offline scenarios of edge for data replication and sharing.

Yet another objective of the present invention is to provide hybrid edge replication protocol (HERP) in key value stores for edge computing scenarios.

In particular, the present invention allows edge clients to write to edge nodes which will replicate corresponding data in the cloud, i.e., primary/designated master and south to north. The cloud clients would be able to write to primary/master which replicates to corresponding edge nodes by providing new ids (north to south) . The edge nodes will be able to replicate data between them belonging to same group, i.e., south bound replicas. It supports dynamic selective data replication and dynamic selective data sharing is supported.

According to first aspect of the invention, there is provided a method for selective replication of data to a plurality of data nodes. The method comprising the steps of: sending, by a user device, a write request to write data at a first data node; wherein the write request comprises data and metadata, said metadata comprising a publication bit and an endpoint bit; determining, by the first data node, whether the data is to be replicated: to at least one data node, or to a set of data nodes associated with a group, or to all the data nodes associated with one or more groups; or to one or more data nodes and a group; wherein each data node comprises a group membership table; and replicating, by the first data node, the data to one or more data nodes.

In a first possible implementation of the method according to the first aspect, the data node is an edge node; and wherein a group comprises a plurality of data nodes.

In a second possible implementation of the method according to the first aspect, further comprises the step of: writing, by the user device, data to the first data node.

In a third possible implementation of the method according to the first aspect, further comprises the steps of: storing, by the first data node, an operation log op_num to record the data written by the user device in the first data node; and incrementing, by the first data node, a commit number commit_num by one count in the first data node.

In a fourth possible implementation of the method according to the first aspect, each data node comprises an Op_log comprising an edge-view number to determine whether the data node is situated at the edge of the network.

In a fifth possible implementation of the method according to the first aspect, the first data node replicates and shares the data when the publication bit is y; wherein the first data node does not replicate and share the data when the publication bit is s; wherein the first data node replicates the data when the publication bit is r; and wherein the first data node shares the data when the publication bit is s.

In a sixth possible implementation of the method according to the first aspect, the endpoint bit comprises at least one nodeID, or at least one groupID’s, or a combination of nodeID’s and groupID’s.

In a seventh possible implementation of the method according to the first aspect, the group membership table comprises at least one groupID of a group; and at least one nodeID of a data node associated with the group.

In an eighth possible implementation of the method according to the first aspect, the first data node replicates and shares the data to at least one data node when the publication bit is y and the endpoint bit comprises the nodeID associated with the data node.

In a ninth possible implementation of the method according to the first aspect, the first data node replicates and shares the data to a set of data nodes associated with a group when the publication bit is y and the endpoint bit comprises the groupID and nodeID’s of the set of data nodes associated with the group.

In a tenth possible implementation of the method according to the first aspect, the first data node replicates and shares the data to all the data nodes associated with one or more groups, when the publication bit is y and the endpoint bit comprises the groupID associated with the group.

In an eleventh possible implementation of the method according to the first aspect, the first data node replicates and shares the data to one or more data nodes and a group when the publication bit is y and the endpoint bit comprises one or more nodeID’s associated with the data nodes and the groupID associated with the group.

In a twelfth possible implementation of the method according to the first aspect, further comprises the steps of: registering, by the user device, a new groupID associated with a new group to the first data node; and registering, by the user device, one or more nodeID’s associated with one or more data nodes to the new group.

In a thirteenth possible implementation of the method according to the first aspect, further comprises the steps of: deregistering, by the user device, a groupID associated with a group from the first data node; and deregistering, by the user device, one or more nodeID’s associated with one or more data nodes associated with a group.

According to second aspect of the invention, there is provided a method for selective replication of data from a cloud network to a plurality of data nodes. The method comprising the steps of: sending, by a user device, a write request to write data at a primary node of the cloud network; wherein the write request comprises data and metadata, said metadata comprising a publication bit and an endpoint bit; and determining, by the primary node, whether the data is to be replicated: to at least one data node, or to a set of data nodes associated with a group, or to all the data nodes associated with one or more groups; or to one or more data nodes and a group; wherein each data node comprises a group membership table and the primary node comprises a client table; and replicating, by the primary node, the data to one or more data nodes.

In a first possible implementation of the method according to the second aspect, the cloud network comprises at least one primary node and one or more cloud nodes; wherein the data node is an edge node; and wherein a group comprises a plurality of data nodes.

In a second possible implementation of the method according to the second aspect, further comprises the step of: writing, by the user device, data to the primary node.

In a third possible implementation of the method according to the second aspect, further comprises the step of: determining, by the primary node, the data nodes associated with a group by looking up the group membership table, when the nodeID is not indicated in the endpoint bit.

In a fourth possible implementation of the method according to the second aspect, further comprises the steps of: storing, by the primary node, an operation log op_num to record the data written by the primary node in a data node; and incrementing, by the primary node, a commit number commit_num by one count in the data node.

In a fifth possible implementation of the method according to the second aspect, each data node comprises an Op_log comprising an edge-view number to determine whether the data node is situated at the edge of the network.

In a sixth possible implementation of the method according to the second aspect, the primary node replicates and shares the data when the publication bit is y; wherein the primary node does not replicate and share the data when the publication bit is s; wherein the primary node replicates the data when the publication bit is r; and wherein the primary node shares the data when the publication bit is s.

In a seventh possible implementation of the method according to the second aspect, the endpoint bit comprises at least one nodeID, or at least one groupID’s, or a combination of nodeID’s and groupID’s.

In an eighth possible implementation of the method according to the second aspect, the group membership table comprises at least one groupID of a group; and at least one nodeID of a data node associated with the group.

In a ninth possible implementation of the method according to the second aspect, the primary node replicates and shares the data to at least one data node when the publication bit is y and the endpoint bit comprises the nodeID associated with the data node.

In a tenth possible implementation of the method according to the second aspect, the primary node replicates and shares the data to a set of data nodes associated with a group when the publication bit is y and the endpoint bit comprises the groupID and nodeID’s of the set of data nodes associated with the group.

In an eleventh possible implementation of the method according to the second aspect, the primary node replicates and shares the data to all the data nodes associated with one or more groups, when the publication bit is y and the endpoint bit comprises the groupID associated with the group.

In a twelfth possible implementation of the method according to the second aspect, the primary node replicates and shares the data to one or more data nodes and a group when the publication bit is y and the endpoint bit comprises one or more nodeID’s associated with the data nodes and the groupID associated with the group.

In a thirteenth possible implementation of the method according to the second aspect, further comprises the steps of: registering, by the user device, a new groupID associated with a new group to the data node; and registering, by the user device, one or more nodeID’s associated with one or more data nodes to the new group.

In a fourteenth possible implementation of the method according to the second aspect, further comprises the steps of: deregistering, by the user device, a groupID associated with a group from the data node; and deregistering, by the user device, one or more nodeID’s associated with one or more data nodes associated with a group.

According to third aspect of the invention, there is provided a system for selective replication of data to a plurality of data nodes. The system comprising a user device sending a write request to write data at a first data node, wherein the write request comprises data and metadata, said metadata comprising a publication bit and an endpoint bit; the first data node determining whether the data is to be replicated: to at least one data node, or to a set of data nodes associated with a group, or to all the data nodes associated with one or more groups; or to one or more data nodes and a group, wherein each data node comprises a group membership table; and replicating the data to one or more data nodes.

In a first possible implementation of the system according to the third aspect, the data node is an edge node; and wherein a group comprises a plurality of data nodes.

In a second possible implementation of the system according to the third aspect, the user device writes data to the first data node.

In a third possible implementation of the system according to the third aspect, the first data node stores an operation log op_num to record the data written by the user device in the first data node; and increments a commit number commit_num by one count in the first data node.

In a fourth possible implementation of the system according to the third aspect, each data node comprises an Op_log comprising an edge-view number to determine whether the data node is situated at the edge of the network.

In a fifth possible implementation of the system according to the third aspect, the first data node replicates and shares the data when the publication bit is y; wherein the first data node does not replicate and share the data when the publication bit is s; wherein the first data node replicates the data when the publication bit is r; and wherein the first data node shares the data when the publication bit is s.

In a sixth possible implementation of the system according to the third aspect, the endpoint bit comprises at least one nodeID, or at least one groupID’s, or a combination of nodeID’s and groupID’s.

In a seventh possible implementation of the system according to the third aspect, the group membership table comprises at least one groupID of a group; and at least one nodeID of a data node associated with the group.

In an eighth possible implementation of the system according to the third aspect, the first data node replicates and shares the data to at least one data node when the publication bit is y and the endpoint bit comprises the nodeID associated with the data node.

In a ninth possible implementation of the system according to the third aspect, the first data node replicates and shares the data to a set of data nodes associated with a group when the publication bit is y and the endpoint bit comprises the groupID and nodeID’s of the set of data nodes associated with the group.

In a tenth possible implementation of the system according to the third aspect, the first data node replicates and shares the data to all the data nodes associated with one or more groups, when the publication bit is y and the endpoint bit comprises the groupID associated with the group.

In an eleventh possible implementation of the system according to the third aspect, the first data node replicates and shares the data to one or more data nodes and a group when the publication bit is y and the endpoint bit comprises one or more nodeID’s associated with the data nodes and the groupID associated with the group.

In a twelfth possible implementation of the system according to the third aspect, the user device registers a new groupID associated with a new group to the first data node; and registers one or more nodeID’s associated with one or more data nodes to the new group.

In a thirteenth possible implementation of the system according to the third aspect, the user device deregisters a groupID associated with a group from the first data node; and deregisters, one or more nodeID’s associated with one or more data nodes associated with a group.

According to fourth aspect of the invention, there is provided a system for selective replication of data from a cloud network to a plurality of data nodes. The system comprising: a user device sending a write request to write data at a primary node of the cloud network, wherein the write request comprises data and metadata, said metadata comprising a publication bit and an endpoint bit; and the primary node determining whether the data is to be replicated: to at least one data node, or to a set of data nodes associated with a group, or to all the data nodes associated with one or more groups; or to one or more data nodes and a group, wherein each data node comprises a group membership table and the primary node comprises a client table; and the primary node replicating the data to one or more data nodes.

In a first possible implementation of the system according to the fourth aspect, the cloud network comprises at least one primary node and one or more cloud nodes; wherein the data node is an edge node; and wherein a group comprises a plurality of data nodes.

In a second possible implementation of the system according to the fourth aspect, the user device writes data to the primary node.

In a third possible implementation of the system according to the fourth aspect, the primary node determines the data nodes associated with a group by looking up the group membership table, when the a nodeID is not indicated in the endpoint bit.

In a fourth possible implementation of the system according to the fourth aspect, the primary node stores an operation log op_num to record the data written by the primary node in a data node; and increments a commit number commit_num by one count in the data node.

In a fifth possible implementation of the system according to the fourth aspect, each data node comprises an Op_log comprising an edge-view number to determine whether the data node is situated at the edge of the network.

In a sixth possible implementation of the system according to the fourth aspect, the primary node replicates and shares the data when the publication bit is y; wherein the primary node does not replicate and share the data when the publication bit is s; wherein the primary node replicates the data when the publication bit is r; and wherein the primary node shares the data when the publication bit is s.

In a seventh possible implementation of the system according to the fourth aspect, the endpoint bit comprises at least one nodeID, or at least one groupID’s, or a combination of nodeID’s and groupID’s.

In an eighth possible implementation of the system according to the fourth aspect, the group membership table comprises at least one groupID of a group; and at least one nodeID of a data node associated with the group.

In a ninth possible implementation of the system according to the fourth aspect, the primary node replicates and shares the data to at least one data node when the publication bit is y and the endpoint bit comprises the nodeID associated with the data node.

In a tenth possible implementation of the system according to the fourth aspect, the primary node replicates and shares the data to a set of data nodes associated with a group when the publication bit is y and the endpoint bit comprises the groupID and nodeID’s of the set of data nodes associated with the group.

In an eleventh possible implementation of the system according to the fourth aspect, the primary node replicates and shares the data to all the data nodes associated with one or more groups, when the publication bit is y and the endpoint bit comprises the groupID associated with the group.

In a twelfth possible implementation of the system according to the fourth aspect, the primary node replicates and shares the data to one or more data nodes and a group when the publication bit is y and the endpoint bit comprises one or more nodeID’s associated with the data nodes and the groupID associated with the group.

In a thirteenth possible implementation of the system according to the fourth aspect, the user device registers a new groupID associated with a new group to the data node; and registers one or more nodeID’s associated with one or more data nodes to the new group.

In a fourteenth possible implementation of the system according to the fourth aspect, the user device deregisters a groupID associated with a group from the data node; and deregisters one or more nodeID’s associated with one or more data nodes associated with a group.

Other aspects, advantages, and salient features of the invention will become apparent to those skilled in the art from the following detailed description, which, taken in conjunction with the annexed drawings, discloses exemplary embodiments of the invention.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

The detailed description is described with reference to the accompanying figures. In the figures, the digit (s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to refer like features and components.

Figure 1 illustrates a block diagram of a typical edge cloud topology, as prior art of the present invention.

Figure 2 illustrates a block diagram of a passive replication view, as prior art of the present invention.

Figure 3 illustrates a block diagram of an active replication view, as prior art of the present invention.

Figure 4 illustrates a block diagram of HERP in passive replication model, in accordance with an embodiment of the present invention.

Figure 5 illustrates a block diagram of HERP in active replication model, in accordance with another embodiment of the present invention.

Figure 6 illustrates a block diagram group based edge replication in HERP, in accordance with another embodiment of the present invention.

Figure 7 illustrates a block diagram of offline replication, in accordance with the present invention.

Figure 8 illustrates a block diagram of indirect replication for shared group data, in accordance with the present invention.

Figure 9 illustrates a block diagram of primary or master failure case, in accordance with the present invention.

Figure 10 illustrates a block diagram of edge node failure scenario, in accordance with the present invention.

Figure 11 illustrates a block diagram of HERP view in edge cloud topology, in accordance with the present invention.

Figure 12 illustrates a block diagram of HERP positioning in edge platform architecture, in accordance with the present invention.

Figure 13 illustrates a block diagram of the HERP membership table, in accordance with the present invention.

Figure 14 illustrates a block diagram of the HERP new metadata, in accordance with the present invention.

Figure 15 illustrates a block diagram of data write to edge and replicated to cloud, in accordance with the present invention.

Figure 16 illustrates a block diagram of data write to edge and replication to cloud with publication to edge, in accordance with the present invention.

Figure 17 illustrates a block diagram of data write without publication, in accordance with the present invention.

Figure 18 illustrates a block diagram of data not published across groups, in accordance with the present invention.

Figure 19 illustrates a block diagram of data write at cloud, in accordance with the present invention.

Figure 20 illustrates a block diagram of data written to cloud and replicated to group, in accordance with the present invention.

Figure 21 illustrates a block diagram of data replication across the edges in the group, in accordance with the present invention.

Figure 22 illustrates a block diagram of replication to specific edge, in accordance with the present invention.

Figure 23 illustrates a block diagram of a failure case where cloud is offline, in accordance with the present invention.

Figure 24 illustrates a block diagram of a failure case where cloud is offline and some peers are down (1) , in accordance with the present invention.

Figure 25 illustrates a block diagram of failure case where cloud offline and some peers are down (2) , in accordance with the present invention.

Figure 26 illustrates a block diagram of a failure case where cloud secondary replicas are down, in accordance with the present invention.

Figure 27 illustrates a block diagram of a failure case where edge nodes are getting rebooted, in accordance with the present invention.

Figure 28 illustrates a block diagram of a failure case where edge node failed, in accordance with the present invention.

Figure 29 illustrates a block diagram of data consistency handling -timestamp ordering (1) , in accordance with the present invention.

Figure 30 illustrates a block diagram of data consistency handling -timestamp ordering (2) , in accordance with the present invention.

Figure 31 illustrates a block diagram of data consistency handling -timestamp ordering (3) , in accordance with the present invention.

Figure 32 illustrates a block diagram of data consistency handling -timestamp ordering (4) , in accordance with the present invention.

Figure 33 illustrates a block diagram of ownership based conflict resolution-sample, in accordance with the present invention.

Figure 34 illustrates a block diagram of the Owner Only Publish (OOPub) method, in accordance with the present invention.

Figure 35 illustrates flow-chart for a method for selective replication of data across a plurality of data nodes, in accordance with the present invention.

Figure 36 illustrates flow-chart for method for selective replication of data to a cloud network, in accordance with the present invention.

Figure 37 illustrates flow-chart for a method for selective replication of data to a plurality of data nodes, in accordance with a first embodiment of the present invention.

Figure 38 illustrates flow-chart for a method for selective replication of data from a cloud network to a plurality of data nodes, in accordance with a second embodiment of the present invention.

Figure 39 illustrates block diagram for a system for selective replication of data to a plurality of data nodes, in accordance with a third embodiment of the present invention.

Figure 40 illustrates block diagram for a system for selective replication of data from a cloud network to a plurality of data nodes, in accordance with a fourth embodiment of the present invention.

It is to be understood that the attached drawings are for purposes of illustrating the concepts of the invention and may not be to scale.

DETAILED DESCRIPTION OF THE PRESENT INVENTION

The following clearly describes the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are merely a part rather than all of the embodiments of the present invention. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

The present invention can be implemented in numerous ways, as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or electronic communication links. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.

A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, and components, modules, units and/or circuits have not been described in detail so as not to obscure the invention.

Although embodiments of the invention are not limited in this regard, discussions utilizing terms such as, for example, “processing, ” “computing, ” “calculating, ” “determining, ” “establishing” , “analyzing” , “checking” , or the like, may refer to operation (s) and/or process (es) of a computer, a computing platform, a computing system, or other electronic computing device, that manipulates and/or transforms data represented as physical (e.g., electronic) quantities within the computer's registers and/or memories into other data similarly represented as physical quantities within the computer's registers and/or memories or other information non-transitory storage medium that may store instructions to perform operations and/or processes.

Although embodiments of the invention are not limited in this regard, the terms “plurality” and “a plurality” as used herein may include, for example, “multiple” or “two or more” . The terms “plurality” or “a plurality” may be used throughout the specification to describe two or more components, devices, elements, units, parameters, or the like. Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments or elements thereof can occur or be performed simultaneously, at the same point in time, or concurrently.

In the present invention, “edge cloud topology” refers to the way the various edge nodes are deployed.

In the present invention, “edge nodes” refers to a node connected at the edge cloud. This edge node may be connected with various passive devices (sensors/actuators) or another edge node.

In the present invention, “edge clients” refers to any application or service requests or writes data to the nodes. Same for cloud and edge.

In the present invention, “edge replicas” refers to replicated data at the edge as per the configurations explained in the invention. Replication is a standard process and no difference.

In the present invention, “passive replication” refers to replication that occurs in one direction, i.e., from the master to the replica.

In the present invention, “active/XDCR replication” refers to replication where client applications perform read/write operations on any of the participating clusters and changes in one database are copied and applied to all the other databases.

In the present invention, “kv stores” refers to key-value store which is a key building block for many systems like databases and large websites.

In the present invention, “metadata” refers to metadata information for the actual data.

Methods and systems for hybrid edge replication are disclosed. While aspects are described for hybrid edge replication protocol (HERP) in key value (kv) stores for edge computing scenarios, the present invention may be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary systems, devices/nodes/apparatus, and methods.

Henceforth, embodiments of the present disclosure are explained with the help of exemplary diagrams and one or more examples. However, such exemplary diagrams and examples are provided for the illustration purpose for better understanding of the present disclosure and should not be construed as limitation on scope of the present disclosure.

The present invention provides methods and systems for hybrid edge replication.

The problems associated with the prior art is that the distributed in-memory stores operate in passive mode, i.e., writes happen only via the master node, or active mode where all nodes can take read/write requests and synchronize. In edge computing, edge nodes need to accept local writes and replicate the data to the cloud and hence passive replication cannot cater to this requirement. Active replication requires quorum for read/writes to be processed which can’t be guaranteed in offline scenarios, so active replication also can’t satisfy edge requirements.

Moreover, for security reasons, some of the data of an edge node should not be made available to other edge nodes connected to the cloud, i.e., selective sharing across edge nodes. Furthermore, the existing inbuilt replication mechanisms in kv -stores do not provide customization and therefore, need additional work at the platform layer to handle selective data replication. Accordingly, there is a need for selective replication of edge data to cloud/edge groups, selective sharing of one edge data across edge nodes and support for offline scenarios of edge for data replication and sharing.

Thus, the present invention discloses methods and systems for hybrid edge replication in kv-stores for edge computing scenarios. The present invention specifically allows edge clients to write to edge nodes which will replicate corresponding data in the cloud, i.e., primary/designated master and south to north. The cloud clients would be able to write to primary/master which replicates to corresponding edge nodes by providing new ids (north to south) . The edge nodes will be able to replicate data between them belonging to same group, i.e., south bound replicas. It supports dynamic selective data replication and dynamic selective data sharing is supported. The hybrid edge replication protocol has a corresponding interface in cloud.

Significantly, edge computing is capable of handling huge data and maximum processing at the edge. Therefore, the data handling needs to be highly configurable for replication and sharing. The present invention provides a highly configurable and scalable data handling for edge computing scenarios. Since selective data filtering across edge to cloud and edge to edge is essential for efficient and smart edge compute solution. However, the existing implementations are on custom built modules. The present invention provides an inbuilt KV store protocol to handle selective data sharing and replication.

The present invention supports complete south (edge) bound recovery and HA, i.e., Offline, Shutdown/Reboot cases handled. It also provides selective sharing of data across edges or edge to cloud to achieve specific use-cases or tasks as needed. The edge nodes can easily share public /private data amongst each other in a group or with the cloud thus providing flexibility and increased security. The master independent model helps for easily scalable and extensible data handling, including replicas, sharing etc. It facilitates with data consistency handling and is compatible with any standard data conflict resolution methods such as time stamp ordering or ownership based. The configurable and dynamic selective data replication and sharing helps for various different edge scenarios to be handled effectively without any additional development.

In the present invention, each edge group talks to one primary replica in the cloud. This keeps the replication simple and scalable. If the primary replica goes down, the edge group simply switches to the newly elected leader. The solution is easily scalable if more edge nodes are added to a group or more groups are added to the cluster. The present invention has excellent fault tolerant features for recovery and HA. Device migration from edge to edge or group to group can be achieved very easily. It is highly supportive of data analytics at edge. The present invention can be implemented for specific KV stores and other databases as well.

The present invention is also capable of supporting Intelligent Edge Fabric (IEF) to handle edge cloud scenarios and competitive features using HERP:

a) Dynamic Selective Data Replication and Sharing;

b) HA, Recovery and Scalability (offline and online scenarios) ;

c) Device Migration (Huge demand in future) ; and

d) Dynamically configurable data management and analytics.

Figure 4 illustrates a block diagram of HERP in passive replication model. Notably, in the following figures C stands for Client; E stands for Edge; P stands for Primary and S stands for Secondary. The primary and secondary replicas will reside in the cloud. The edge nodes will support the new edge replicas with HERP with the corresponding interface in primary replica in cloud. Edge clients can write to edge replica which will replicate the corresponding data to the primary replica in cloud which will further replicate it to the secondary replicas in the cloud. Cloud clients can write to the primary replica in the cloud which will replicate to corresponding edge nodes based on the edge ID apart from replicating to the secondary replicas in cloud. Further, edge replicas belonging to the same group can replicate data between themselves as elaborated in [00105] below. Multiple concurrent writes at the primary and edges will be resolved on basis of timestamp/ownership as explained in [00133-00141] . Hence selective data replication and selective data sharing is achieved with HERP in passive replication model.

Figure 5 illustrates a block diagram of HERP in active replication model. The master replicas will reside in the cloud. The edge nodes will support the new edge replicas with HERP with the corresponding interface in master replicas in the cloud. Edge clients can write to edge replica which will replicate the corresponding data to the corresponding master replica in cloud which will further replicate it to the other master replicas in cloud. Cloud clients can write to a master replica in the cloud which will replicate to corresponding edge nodes based on the edge ID apart from replicating to the master replicas in cloud. Further, edge replicas belonging to the same group can replicate data between themselves as elaborated in [00105] below. Multiple concurrent writes at the primary and edges will be resolved on basis of timestamp/ownership as explained in [00133-00141] . Hence selective data replication and selective data sharing is achieved with HERP in active replication model.

Figure 6 illustrates a block diagram of group based edge replication in HERP. Edges can be grouped for selective replication of data between edge replicas which avoids dependency on the cloud during offline scenarios. Edge clients can write to edge replica which will replicate the data to the corresponding edge replicas in the group. Replication to cloud will happen when the cloud is online or through indirect replication as elaborated in [00107] .

Figure 7 illustrates a block diagram of offline replication. Notably, CC stands for Cloud Client, EC stands for Edge Client, E stands for Edge and P/M stands for Primary/Master. The edge node can be offline with the cloud and/or with other edges of a group. Edge data not corresponding to any group will be replicated to cloud directly when the cloud is online. Edge data corresponding to a group can be replicated to other edges in the group that are offline either directly (when the other edge in available online) or indirectly as elaborated in [00107] .

Figure 8 illustrates a block diagram of indirect replication for shared group data. Some or all of the edges in a group can be offline with the cloud. Also some or all of the edge nodes corresponding to a group may be offline with the edge. Edge data corresponding to a group can be replicated to another offline edge in the group indirectly through the cloud when the edge is online with the cloud or through another edge in the group that is online with the offline edge.

Figure 9 illustrates a block diagram of primary or master failure case. In the passive replication scenario, all Primary/Slave nodes contain the edge and group information. When a primary node is down the new primary indicates the same to edge nodes and data replication happens with the new primary. In the active replication scenario the edge nodes contain information of all master nodes. When the current master is down the edge nodes select the new master. Hence, data replication is handled between the cloud and edge even on failure of a PM node in cloud.

Figure 10 illustrates a block diagram of edge node failure scenario. Notably, CC stands for Cloud Client, EC stands for Edge Client, E stands for Edge and P/M stands for Primary/Master. On edge node failure the corresponding edge data is replicated in the P/M in cloud and the other edges corresponding to its groups. When the edge node recovers from failure the edge data is replicated from the P/M and the other edge nodes corresponding to its groups. Hence data replication is handled between the cloud and edge even on failure of edge node.

The replication mechanism in the cloud can still continue performing replication using the replication protocol of their choice. The HERP protocol will not alter this replication behaviour in the cloud. This ensures that the HERP protocol is loosely coupled and focuses on edge-side replication only. Figure 11 illustrates a block diagram of HERP view in edge cloud topology. HERP allows multi cluster, multi group deployment scenarios to be supported seamlessly, it ensures that the default cloud replication model remains unaffected, and it can be plugged into existing replication protocol in Kv stores as extensions thereby providing easy integration. With HERP, edge to edge, edge to cloud replica and data sharing are achieved with dynamic selective support.

Figure 12 illustrates a block diagram of HERP positioning in edge platform architecture. In this architecture each edge and cloud cluster node has HERP supported kvstore. The data replication and sharing will follow the HERP protocol in addition to the existing replication support from the underlying kvstore.

Figure 13 illustrates a block diagram of the HERP membership table. The primary replica registers edge nodes belonging to a group in the “edge-group-membership” table.

Figure 14 illustrates the dataset operation flow. Client writes to edge node e1. pub= “y” indicates the write needs to be replicated across all edges in the group. The group membership metadata is replicated to the edges belonging to the group only. Additionally, endpoints can be specified while publishing the data for selective sharing/replication.

Fig 15 illustrates the dataset operation flow. Edge node e1 records the write operation in the operation log, and updates the commit number by 1. It thus guarantees the client that the write performed is now persistent and accepted.

Figure 16 illustrates a block diagram of data write to edge and replication to cloud with publication to edge. The primary replica responds with the reply message to e1. As the request included publishing the data to all edge numbers, e1 looks up the edge group membership table and sends a Publish message to all the edge nodes in the group.

Figure 17 illustrates a block diagram of data write without publication. If the request did not include publishing to all group members, e1 doesn’t publish the message.

Figure 18 illustrates a block diagram of data not published across groups. Since e1 and e2 are in different groups, e1 doesn’t publish the message to e2.

Figure 19 illustrates a block diagram of data write at cloud. Client writes to primary replica and specifies the details of the group and edge node to which the data needs to be replicated or shared with.

Figure 20 illustrates a block diagram of data written to cloud and replicated to group. If the edge id isn’t provided in the request, primary looks up the edge group membership table to find out the edge nodes belonging to the group, records the edge id’s in the client table, updates the operation log, sends prepare messages to its followers, and finally executes the write request after incrementing the commit number.

Figure 21 illustrates a block diagram of data replication across the edges in the group. If original request contains pub= “y” , the primary publishes the write request to all edge nodes belonging to the group (after lookup from edge-group-membership table) , passing the original client-id it received in the request.

Figure 22 illustrates a block diagram of replication to specific edge. Client writes to primary replica in the cloud, specifies which group and edge node to replicate the data, but doesn’t want it to be published to other edge nodes in the group. The data is replicated to the specified edge node in the group. It is however not shared with other edge nodes in the same group.

Failures can happen while processing read/write requests at the edge. One such failure scenarios could be that there could be intermittent /no cloud connectivity. The present invention explains how failures are handled hereinbelow:

Cloud Offline: edge operation unaffected; sync to edge peer happens; Sync to cloud happens when the cloud is online for selective intended data. Figure 23 illustrates a block diagram of a failure case where cloud is offline.

Cloud Offline and some peers down

Cloud Offline and some peers down: edge operation unaffected; sync to edge peers available;

Sync to cloud and other peers happen when they are online.

Figure 24 illustrates a block diagram of a failure case where cloud is offline and some peers are down (1) . Client writes to edge node e1. e1 sends a write request to the primary replica in the cloud and peers in the group. e1 publishes write requests to other edge nodes in the group which are available. Whenever cloud connectivity is back, e1 sends the publish message to the cloud. Whenever other offline peers become online, the data is shared across them. Data will be published to cloud and other peers when it is online only if the data is intended for them. Transaction view and commit number will be used.

Figure 25 illustrates a block diagram of failure case where cloud offline and some peers are down (2) . Client writes data to the cloud. Cloud sends the request to the edge nodes but since the nodes are offline, the publish operation happens when the nodes come back online. The publish operation happens to the specific edges for specific data as per selective sharing.

Figure 26 illustrates a block diagram of a failure case where cloud secondary replicas are down. Client writes data to the cloud. Cloud sends the request, but the edge nodes can’t be reached. Write at the cloud works fine. When the nodes come back online. The publish operation happens to the specific edges for specific data as per selective sharing.

Figure 27 illustrates a block diagram of a failure case where edge nodes are getting rebooted. Replicated data is available in the cloud and with peers in the group. The edge node which got rebooted sends a group broadcast for recovery. Peers in the group respond with the data. The edge node can recover the data which was shared amongst all group members and can start functioning from where it stopped last.

Figure 28 illustrates a block diagram of a failure case where edge node failed.

Recovery possibilities offered by the present invention are as indicated hereinbelow:

a) If the system supports new edge node comes up with e1 credentials, it can recover the data from e2 and cloud and work as normal. (sequence same as reboot scenario)

b) If e1 has a standby system, it can simply take over and recover the data from e2 and cloud.

c) If 1 and 2 are not possible, then, from the cloud it can implement recovery methods to fetch any edge node failed through the replicated group data replicated through HERP. This secure credential and establishing the recovery is not in our scope. However, the e1 data replica will be available for recovery.

HERP: New APIs (Draft)

//Edge Replica Group management

RegisterGroup (groupId string) error

DeregisterGroup (groupId string) error

groupId: The name of the group to be registered/deregistered

//Edge Node Management

AddNodeToGroup (groupId string, nodeId string) error

RemoveNodeFromGroup (groupId string, nodeId string) error

groupId: The name of the group (add to OR remove from)

nodeId: The id of the edge node or the cloud cluster node

//Broadcast message to group /edges

Publish (groupId string, endpoints [] string, msg string, pubOpts [] string) error

groupId: The name of the group to which the publish to be done

endpoints: The specific end points to which the data to be published

msg: payload

pubOpts: Publish options which can contain pub flag options, the timestamp info /ownership info etc. based on the deployment models

pub flag options:

y = sharing and replication

n = no sharing &no replication

r = replication only

s = sharing only

Reject (rejectMsg string, endpoint string)

rejectMsg: Reject reason

endpoint: endpoint name

//Write data to a group /edges

Write (groupId string, endpoints [] string, msg string) error

groupId: The name of the group to which the publish to be done

endpoints: The specific end points to which the data to be published

msg: payload

//Recovery Management

Recover (groupId string, nonce int, recovOpts [] string) error, recoverResponse

groupId: The name of the group (add to OR remove from)

nonce: unique identifier to identify the recovery request order (avoid duplicate message)

recovOpts: Recovery options which can contain endpoint id

recoverResponse: recover response which contains the oplog, commit-num..

NOTE: All the dynamic options can be made as static configurations. If no dynamic metadata is given, the system will follow the static configuration.

Data Consistency Handling in HERP. The present invention provides consistency, availability and partitioning. In particular, it provides availability and dynamic real-time partitioning which eventually results in consistency. The eventual consistency is achieved based on the existing methodologies and the present invention does not affect the same. This involves two key approaches, i.e., a) Time Stamp Ordering and b) Ownership. The approach can be decided based on the edge cloud deployment and user requirements. HERP additionally provides certain methods to facilitate the standard methods to work better in Edge Scenarios [like OOPub (Owner Only Publish) ] .

Approach 1 –Use Timestamp Ordering (1) .

Figure 29 illustrates a block diagram of data consistency handling -timestamp ordering (1) . Each data transaction is given a unique timestamp by a network timestamp server. To resolve conflicts, the transaction with the latest timestamp is executed by the network timestamp server. Edge nodes e1 and e2 update the same property “a” . They get timestamps t2 and t3 from the network timestamp server. Assume t1 < t2 < t3. Thus t3 is the latest transaction. The client-table at the corresponding edge node additionally maintains write timestamp (w_ts) and read timestamp (r_ts) for each key-value pair.

Figure 30 illustrates a block diagram of data consistency handling -timestamp ordering (2) . Both edge nodes e1 and e2 publish write requests to each other with their timestamps.

Figure 31 illustrates a block diagram of data consistency handling -timestamp ordering (3) . Since t2 < t3, edge node e2 retains the write value and e1 receives a reject response from e2. E1 rollbacks its write operation and decrements its op-num and commit-num.

Figure 32 illustrates a block diagram of data consistency handling -timestamp ordering (4) . The PUBLISH request from e2 needs to be processed by e1. Since t1 < t3, e1 accepts the PUBLISH request from e2 and updates “a “with the new value.

Approach 2 –Ownership Based Conflict Resolution. This is a standard method used in most of the standard replication systems. It is common in systems where the deployments are with multiple masters or write nodes.

a) Single ownership or shared ownership based systems are available. Basically the conflict will be resolved based on the ownership of each data.

b) Dynamic Ownership is also used in certain shared ownership systems so as to manage the update workflow based on the deployment scenario

Figure 33 illustrates a block diagram of ownership based conflict resolution-sample. A multitude of ownership based data conflict management methods are available and any one of those can be applied to the present invention. Since there is no dependency, ownership can be configured based on the deployment. In Edge Scenario, the source of the data can be set as owner, dynamic ownership techniques can be used as needed, and token based or similar techniques can be applied to handle the ownership. Notably, Owner Only Publish (OOPub) algorithm can be added to HERP, which can be configured as needed.

Facilitation of ownership data conflict resolution -Owner Only Publish (OOPub) method. Ibn this scenario, only the owner can update the data while others can only read the data. This approach can be used for edge to cloud OR edge to edge scenarios. Usually the device data is owned by the device in the corresponding edge nodes. The configurable metadata can be owned by the user roles (cloud or the interface to user for modifications)

Figure 34 illustrates a block diagram of the Owner Only Publish (OOPub) method. Figure 35 illustrates flow-chart for a method for selective replication of data across a plurality of data nodes, in accordance with the present invention. Figure 36 illustrates flow-chart for method for selective replication of data to a cloud network, in accordance with the present invention.

Figure 37 illustrates flow-chart for a method for selective replication of data to a plurality of data nodes (12 ₁, 12 ₂, 12 ₃, .... 12 _n) , as a first embodiment of the present invention. This method comprising the steps of:

sending (S101) , by a user device (10) , a write request to write data at a first data node (11) ; wherein the write request comprises data and metadata, said metadata comprising a publication bit and an endpoint bit;

determining (S102) , by the first data node (11) , whether the data is to be replicated: to at least one data node (12 ₁) , or to a set of data nodes (12 ₁, 12 ₃, 12 ₄) associated with a group (G ₁) , or to all the data nodes associated with one or more groups (G ₁, G ₂…G _n) ; or to one or more data nodes (12 ₁, 12 ₄) and a group (G ₂) ;

wherein each data node (11, 12 ₁, 12 ₂, …. 12 _n) comprises a group membership table; and

replicating (S103) , by the first data node (11) , the data to one or more data nodes (12 ₁, 12 ₂, 12 ₃, .... 12 _n) .

In the method illustrated in Figure 37, the data node (12 ₁, 12 ₂, 12 ₃, .... 12 _n) is an edge node. A group comprises a plurality of data nodes (12 ₁, 12 ₂, 12 ₃, .... 12 _n) .

The method illustrated in Figure 37 further comprises the step of: writing, by the user device (10) , data to the first data node (11) . This method also comprises the steps of: storing, by the first data node (11) , an operation log op_num to record the data written by the user device (10) in the first data node (11) ; and incrementing, by the first data node (11) , a commit number commit_num by one count in the first data node (11) . This method further comprises the steps of: registering, by the user device (10) , a new groupID associated with a new group to the first data node (11) ; and registering, by the user device (10) , one or more nodeID’s associated with one or more data nodes to the new group. This method also comprises the steps of: deregistering, by the user device (10) , a groupID associated with a group from the first data node (11) ; and deregistering, by the user device (10) , one or more nodeID’s associated with one or more data nodes associated with a group.

Notably, the first data node (11) replicates and shares the data when the publication bit is y. The first data node (11) does not replicate and share the data when the publication bit is s. The first data node (11) replicates the data when the publication bit is r. The first data node (11) shares the data when the publication bit is s. Further, each data node comprises an Op_log comprising an edge-view number to determine whether the data node (12 ₁, 12 ₂, 12 ₃, .... 12 _n) is situated at the edge of the network. The endpoint bit comprises at least one nodeID, or at least one groupID’s, or a combination of nodeID’s and groupID’s. The group membership table comprises at least one groupID of a group (G ₁, G ₂…G _n) ; and at least one nodeID of a data node (12 ₁, 12 ₂, 12 ₃, .... 12 _n) associated with the group.

Significantly, in the method illustrated in Figure 37 the first data node (11) :

replicates and shares the data to at least one data node (12 ₁) when the publication bit is y and the endpoint bit comprises the nodeID associated with the data node (12 ₁) ;

replicates and shares the data to a set of data nodes (12 ₁, 12 ₃, 12 ₄) associated with a group (G ₁) when the publication bit is y and the endpoint bit comprises the groupID and nodeID’s of the set of data nodes (12 ₁, 12 ₃, 12 ₄) associated with the group (G ₁) ;

replicates and shares the data to all the data nodes associated with one or more groups (G ₁, G ₂…G _n) , when the publication bit is y and the endpoint bit comprises the groupID associated with the group; and

replicates and shares the data to one or more data nodes (12 ₁, 12 ₄) and a group (G ₂) when the publication bit is y and the endpoint bit comprises one or more nodeID’s associated with the data nodes (12 ₁, 12 ₄) and the groupID associated with the group (G ₂) .

Figure 38 illustrates flow-chart for a method for selective replication of data from a cloud network to a plurality of data nodes (11, 12 ₁, 12 ₂, …. 12 _n) , as a second embodiment of the present invention. This method comprising the steps of:

sending (S201) , by a user device (20) , a write request to write data at a primary node (21) of the cloud network, wherein the write request comprises data and metadata, said metadata comprising a publication bit and an endpoint bit; and

determining (S202) , by the primary node (21) , whether the data is to be replicated: to at least one data node (12 ₁) , or to a set of data nodes (12 ₁, 12 ₃, 12 ₄) associated with a group (G ₁) , or to all the data nodes associated with one or more groups (G ₁, G ₂…G _n) ; or to one or more data nodes (12 ₁, 12 ₄) and a group (G ₂) , wherein each data node (11, 12 ₁, 12 ₂, …. 12 _n) comprises a group membership table and the primary node (21) comprises a client table; and

replicating (S203) , by the primary node (21) , the data to one or more data nodes (12 ₁, 12 ₂, 12 ₃, .... 12 _n) .

The cloud network comprises at least one primary node (21) and one or more cloud nodes; where the data node (12 ₁, 12 ₂, 12 ₃, .... 12 _n) is an edge node and a group comprises a plurality of data nodes. Further, each data node comprises an Op_log comprising an edge-view number to determine whether the data node is situated at the edge of the network.

This method as illustrated in Figure 38 further comprises the step of: writing, by the user device (20) , data to the primary node (21) . This method also comprises the step of determining, by the primary node (21) , the data nodes associated with a group by looking up the group membership table, when the nodeID is not indicated in the endpoint bit. The method further comprises the steps of: storing, by the primary node (21) , an operation log op_num to record the data written by the primary node (21) in a data node; and incrementing, by the primary node (21) , a commit number commit_num by one count in the data node.

This method as illustrated in Figure 38 further comprises the step of: registering, by the user device (20) , a new groupID associated with a new group to the data node; and registering, by the user device (20) , one or more nodeID’s associated with one or more data nodes to the new group. This method also comprises the steps of: deregistering, by the user device (20) , a groupID associated with a group from the data node; and deregistering, by the user device (20) , one or more nodeID’s associated with one or more data nodes associated with a group.

Significantly, the primary node (21) replicates and shares the data when the publication bit is y. The primary node (21) does not replicate and share the data when the publication bit is s. The primary node (21) replicates the data when the publication bit is r. The primary node (21) shares the data when the publication bit is s. Further, the endpoint bit comprises at least one nodeID, or at least one groupID’s, or a combination of nodeID’s and groupID’s. The group membership table comprises at least one groupID of a group (G ₁, G ₂…G _n) ; and at least one nodeID of a data node (12 ₁, 12 ₂, 12 ₃, .... 12 _n) associated with the group.

Notably, in the method illustrated in Figure 37 the primary node (21) :

Figure 39 illustrates a block diagram of a system for selective replication of data to a plurality of data nodes (12 ₁, 12 ₂, 12 ₃, .... 12 _n) as a third embodiment of the present invention. This system comprises a user device (10) , a first data node (11) and a plurality of data nodes (12 ₁, 12 ₂, 12 ₃, .... 12 _n) . This system is adapted to perform the method illustrated in Figures 35 and 37.

Figure 40 illustrates a block diagram of a system for selective replication of data from a cloud network to a plurality of data nodes (12 ₁, 12 ₂, 12 ₃, .... 12 _n) as a fourth embodiment of the present invention. This system comprises a user device (20) , a primary node (21) and a data node (12 ₁, 12 ₂, 12 ₃, .... 12 _n) . This system is adapted to perform the method illustrated in Figures 36 and 38.

Reference is made to Table 1 where HERP of the present invention is compared with ViewStamped Replication (VR) protocol while in Table 2 the present invention is compared with Open Source Redis Replication Protocol. HERP differentiates from both protocols such that it allows secondary writes at edge nodes, can work in offline scenarios since no master leader election is involved and it supports group based selective sharing which is not available in the other two protocols.

Table 1 tabulates HERP vs. ViewStamped Replication (VR) protocol

Table 2 tabulates HERP vs. Open Source Redis Replication Protocol

Implementation with different kv-stores /db

a) It is easy to integrate with etcd (raft) or such kv stores;

b) It is easy to integrate with standard replication protocols (Experimented with view stamped replication protocol for the illustration with Diamond) ; and

c) It is based on the architecture, feasible to integrate with standard databases replication methods (however, can have possible innovations for the same if needed) .

Example: Modifications Required in Redis

a) Enterprise Redis implements active replication using CRDT’s and vector clocks.

b) The syncers which do CRDT peer replication will need modification to achieving selective replication with publish APIs

Performance Impact of HERP

a) Very minimum metadata and hence minimum conditional verifications during any transactions. Can be implemented without any performance impact in the system (as it is very much aligned to standard metadata for kvstores) .

b) As the metadata holds minimum states, can be implemented in optimized way to handle performance and foot print requirements for HERP.

c) The publish () will be a replacement for the write () and hence, there is no additional messaging across the nodes.

d) Even when the system is scaled (more devices/more edge nodes) , the search requirements are very minimum across the nodes as we have owner only publish kind of features. Even if all the edges (Not owner only publish) , publish the data, it will be limited to the edge nodes. Also this can be based on the hierarchical deployment of the edge cloud.

e) Worst case performance: Publishing requests to edges in the group will be affected if concurrent updates are made to the same data in even one of the other edges in the group. Reject messages need to be processed by the source edge node and rollbacks need to be performed at all other edges in the group which didn’t report the conflict. This is only in case there is no OOPub and concurrent updates happen at all the edges in the group. This can be less likely.

The present invention finds its application in edge cloud scenarios. For any edge cloud deployment, data processing at the edge is a critical feature. For this processing, the data needs to be shared across and also to be replicated with other edge nodes or central cloud. Thus, the present invention plays a critical role in all the edge use-cases since it involves data handling from the devices or from cloud. It also helps to handle offline and failure scenarios in edge cloud. Through selective replication, it ensures better resources utilization and ensures the availability of edge cloud services.

Some of the non-limiting advantages and future implementations of the present invention are indicated hereinbelow:

It provides a highly configurable and scalable data handling for edge computing scenarios.

It provides selective data filtering across edge to cloud and edge to edge is essential for efficient and smart edge compute solution.

It provides complete south (edge) bound recovery and HA (Offline, Shutdown/Reboot cases handled) .

It provides selective sharing of data across edges or edge to cloud to achieve specific use-cases or tasks as needed.

It provides flexibility and increased security since edge nodes can easily share public /private data amongst each other in a group or with the cloud.

Its master independent model provides for easily scalable and extensible data handling (including replicas, sharing etc. ) .

It facilitates with data consistency handling and is compatible with any standard data conflict resolution methods (like time stamp ordering or ownership based) .

The configurable and dynamic selective data replication and sharing allows for various different edge scenarios to be handled effectively without any additional development.

It is simple and scalable and when the primary replica goes down, the edge group simply switches to the newly elected leader.

It provides excellent fault tolerant features for recovery and HA.

The protocol works seamlessly even if the edge cluster grows or shrinks dynamically.

It provides for easy device migration from edge to edge or group to group.

It is highly supportive of data analytics at edge.

It provides for dynamic selective data replication and sharing.

It provides for HA, Recovery and Scalability in both offline and online scenarios.

It provides for dynamically configurable data management and analytics.

It finds future application in specific KV stores and other databases.

A person skilled in the art may understand that any known or new algorithms be used for the implementation of the present invention. However, it is to be noted that, the present invention provides methods and systems for hybrid edge replication to achieve the above mentioned benefits and technical advancement irrespective of using any known or new algorithms.

A person of ordinary skill in the art may be aware that in combination with the examples described in the embodiments disclosed in this specification, units and algorithm steps may be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether the functions are performed by hardware or software depends on the particular applications and design constraint conditions of the technical solution. A person skilled in the art may use different methods to implement the described functions for each particular application, but it should not be considered that the implementation goes beyond the scope of the present invention.

It may be clearly understood by a person skilled in the art that for the purpose of convenient and brief description, for a detailed working process of the foregoing system, apparatus, and unit, reference may be made to a corresponding process in the foregoing method embodiments, and details are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus, method or system may be implemented in other manners. For example, the described apparatus embodiment is merely exemplary. For example, the unit division is merely logical function division and may be other division in actual implementation. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented through some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.

When the functions are implemented in a form of a software functional unit and sold or used as an independent product, the functions may be stored in a computer-readable storage medium. Based on such an understanding, the technical solutions of the present invention essentially, or the part contributing to the prior art, or a part of the technical solutions may be implemented in a form of a software product. The computer software product is stored in a storage medium, and includes several instructions for instructing a computer node (which may be a personal computer, a server, or a network node) to perform all or a part of the steps of the methods described in the embodiment of the present invention. The foregoing storage medium includes: any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory (Read-Only Memory, ROM) , a random access memory (Random Access Memory, RAM) , a magnetic disk, or an optical disc.

Devices that are in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. In addition, devices that are in communication with each other may communicate directly or indirectly through one or more intermediaries.

When a single device or article is described herein, it will be readily apparent that more than one device/article (whether or not they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether or not they cooperate) , it will be readily apparent that a single device/article may be used in place of the more than one device or article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the invention need not include the device itself.

Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the disclosure of the embodiments of the invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

With respect to the use of substantially any plural and/or singular terms herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. The various singular/plural permutations may be expressly set forth herein for sake of clarity.

Although implementations for methods and systems for hybrid edge replication has been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of implementations of hybrid edge replication protocol in kv-stores for edge computing scenarios.

Claims

A method for selective replication of data to a plurality of data nodes (12 ₁, 12 ₂, 12 ₃, .... 12 _n) , said method comprising:

sending (S101) , by a user device (10) , a write request to write data at a first data node (11) ;

wherein the write request comprises data and metadata, said metadata comprising a publication bit and an endpoint bit;

determining (S102) , by the first data node (11) , whether the data is to be replicated: to at least one data node (12 ₁) , or to a set of data nodes (12 ₁, 12 ₃, 12 ₄) associated with a group (G ₁) , or to all the data nodes associated with one or more groups (G ₁, G ₂...G _n) ; or to one or more data nodes (12 ₁, 12 ₄) and a group (G ₂) ;

wherein each data node (11, 12 ₁, 12 ₂, .... 12 _n) comprises a group membership table; and

replicating (S103) , by the first data node (11) , the data to one or more data nodes (12 ₁, 12 ₂, 12 ₃, .... 12 _n) .
The method as claimed in claim 1, wherein the data node (12 ₁, 12 ₂, 12 ₃, .... 12 _n) is an edge node; and wherein a group comprises a plurality of data nodes.
The method as claimed in claim 1, further comprising the step of:

writing, by the user device (10) , data to the first data node (11) .
The method as claimed in claim 1, further comprising the steps of:

storing, by the first data node (11) , an operation log op_num to record the data written by the user device (10) in the first data node (11) ; and

incrementing, by the first data node (11) , a commit number commit_num by one count in the first data node (11) .
The method as claimed in claim 1, wherein each data node comprises an Op_log comprising an edge-view number to determine whether the data node (12 ₁, 12 ₂, 12 ₃, .... 12 _n) is situated at the edge of the network.
The method as claimed in claim 1,

wherein the first data node (11) replicates and shares the data when the publication bit is y;

wherein the first data node (11) does not replicate and share the data when the publication bit is s;

wherein the first data node (11) replicates the data when the publication bit is r; and

wherein the first data node (11) shares the data when the publication bit is s.
The method as claimed in claim 1, wherein the endpoint bit comprises at least one nodeID, or at least one groupID’s, or a combination of nodeID’s and groupID’s.
The method as claimed in claim 1, wherein the group membership table comprises at least one groupID of a group (G ₁, G ₂...G _n) ; and at least one nodeID of a data node (12 ₁, 12 ₂, 12 ₃, .... 12 _n) associated with the group.
The method as claimed in any one of the previous claims, wherein the first data node (11) replicates and shares the data to at least one data node (12 ₁) when the publication bit is y and the endpoint bit comprises the nodeID associated with the data node (12 ₁) .
The method as claimed in any one of the previous claims, wherein the first data node (11) replicates and shares the data to a set of data nodes (12 ₁, 12 ₃, 12 ₄) associated with a group (G ₁) when the publication bit is y and the endpoint bit comprises the groupID and nodeID’s of the set of data nodes (12 ₁, 12 ₃, 12 ₄) associated with the group (G ₁) .
The method as claimed in any one of the previous claims, wherein the first data node (11) replicates and shares the data to all the data nodes associated with one or more groups (G ₁, G ₂...G _n) , when the publication bit is y and the endpoint bit comprises the groupID associated with the group.
The method as claimed in any one of the previous claims, wherein the first data node (11) replicates and shares the data to one or more data nodes (12 ₁, 12 ₄) and a group (G ₂) when the publication bit is y and the endpoint bit comprises one or more nodeID’s associated with the data nodes (12 ₁, 12 ₄) and the groupID associated with the group (G ₂) .
The method as claimed in claim 1, further comprising the steps of:

registering, by the user device (10) , a new groupID associated with a new group to the first data node (11) ; and

registering, by the user device (10) , one or more nodeID’s associated with one or more data nodes to the new group.
The method as claimed in claim 1, further comprising the steps of:

deregistering, by the user device (10) , a groupID associated with a group from the first data node (11) ; and

deregistering, by the user device (10) , one or more nodeID’s associated with one or more data nodes associated with a group.
A method for selective replication of data from a cloud network to a plurality of data nodes, said method comprising:

sending (S201) , by a user device (20) , a write request to write data at a primary node (21) of the cloud network;

wherein the write request comprises data and metadata, said metadata comprising a publication bit and an endpoint bit; and

determining (S202) , by the primary node (21) , whether the data is to be replicated: to at least one data node (12 ₁) , or to a set of data nodes (12 ₁, 12 ₃, 12 ₄) associated with a group (G ₁) , or to all the data nodes associated with one or more groups (G ₁, G ₂...G _n) ; or to one or more data nodes (12 ₁, 12 ₄) and a group (G ₂) ;

wherein each data node (11, 12 ₁, 12 ₂, .... 12 _n) comprises a group membership table and the primary node (21) comprises a client table; and

replicating (S203) , by the primary node (21) , the data to one or more data nodes (12 ₁, 12 ₂, 12 ₃, .... 12 _n) .
The method as claimed in claim 15, wherein the cloud network comprises at least one primary node (21) and one or more cloud nodes; wherein the data node (12 ₁, 12 ₂, 12 ₃, .... 12 _n) is an edge node; and wherein a group comprises a plurality of data nodes.
The method as claimed in claim 15, further comprising the step of: writing, by the user device (20) , data to the primary node (21) .
The method as claimed in claim 15, further comprising the step of: determining, by the primary node (21) , the data nodes associated with a group by looking up the group membership table, when the a nodeID is not indicated in the endpoint bit.
The method as claimed in claim 18, further comprising the steps of:

storing, by the primary node (21) , an operation log op_num to record the data written by the primary node (21) in a data node; and

incrementing, by the primary node (21) , a commit number commit_num by one count in the data node.
The method as claimed in claim 15, wherein each data node comprises an Op_log comprising an edge-view number to determine whether the data node is situated at the edge of the network.
The method as claimed in claim 15,

wherein the primary node (21) replicates and shares the data when the publication bit is y;

wherein the primary node (21) does not replicate and share the data when the publication bit is s;

wherein the primary node (21) replicates the data when the publication bit is r; and

wherein the primary node (21) shares the data when the publication bit is s.
The method as claimed in claim 15, wherein the endpoint bit comprises at least one nodeID, or at least one groupID’s, or a combination of nodeID’s and groupID’s.
The method as claimed in claim 15, wherein the group membership table comprises at least one groupID of a group (G ₁, G ₂...G _n) ; and at least one nodeID of a data node (12 ₁, 12 ₂, 12 ₃, .... 12 _n) associated with the group.
The method as claimed in any one of the previous claims, wherein the primary node (21) replicates and shares the data to at least one data node (12 ₁) when the publication bit is y and the endpoint bit comprises the nodeID associated with the data node (12 ₁) .
The method as claimed in any one of the previous claims, wherein the primary node (21) replicates and shares the data to a set of data nodes (12 ₁, 12 ₃, 12 ₄) associated with a group (G ₁) when the publication bit is y and the endpoint bit comprises the groupID and nodeID’s of the set of data nodes (12 ₁, 12 ₃, 12 ₄) associated with the group (G ₁)
The method as claimed in any one of the previous claims, wherein the primary node (21) replicates and shares the data to all the data nodes associated with one or more groups (G ₁, G ₂...G _n) , when the publication bit is y and the endpoint bit comprises the groupID associated with the group.
The method as claimed in any one of the previous claims, wherein the primary node (21) replicates and shares the data to one or more data nodes (12 ₁, 12 ₄) and a group (G ₂) when the publication bit is y and the endpoint bit comprises one or more nodeID’s associated with the data nodes (12 ₁, 12 ₄) and the groupID associated with the group (G ₂) .
The method as claimed in claim 15, further comprising the steps of:

registering, by the user device (20) , a new groupID associated with a new group to the data node; and

registering, by the user device (20) , one or more nodeID’s associated with one or more data nodes to the new group.
The method as claimed in claim 15, further comprising the steps of:

deregistering, by the user device (20) , a groupID associated with a group from the data node; and

deregistering, by the user device (20) , one or more nodeID’s associated with one or more data nodes associated with a group.
A system for selective replication of data to a plurality of data nodes (12 ₁, 12 ₂, 12 ₃, .... 12 _n) , said system comprising:

a user device (10) sending (S101) a write request to write data at a first data node (11) , wherein the write request comprises data and metadata, said metadata comprising a publication bit and an endpoint bit;

the first data node (11) determining (S102) whether the data is to be replicated: to at least one data node (12 ₁) , or to a set of data nodes (12 ₁, 12 ₃, 12 ₄) associated with a group (G ₁) , or to all the data nodes associated with one or more groups (G ₁, G ₂...G _n) ; or to one or more data nodes (12 ₁, 12 ₄) and a group (G ₂) , wherein each data node (11, 12 ₁, 12 ₂, .... 12 _n) comprises a group membership table; and replicating (S103) the data to one or more data nodes (12 ₁, 12 ₂, 12 ₃, .... 12 _n) .
The system as claimed in claim 30, wherein the data node (12 ₁, 12 ₂, 12 ₃, .... 12 _n) is an edge node; and wherein a group comprises a plurality of data nodes.
The system as claimed in claim 30, wherein the user device (10) writes data to the first data node (11) .
The system as claimed in claim 30, wherein the first data node (11) stores an operation log op_num to record the data written by the user device (10) in the first data node (11) ; and increments a commit number commit_num by one count in the first data node (11) .
The system as claimed in claim 30, wherein each data node comprises an Op_log comprising an edge-view number to determine whether the data node (12 ₁, 12 ₂, 12 ₃, .... 12 _n) is situated at the edge of the network.
The system as claimed in claim 30,

wherein the first data node (11) replicates and shares the data when the publication bit is y;

wherein the first data node (11) does not replicate and share the data when the publication bit is s;

wherein the first data node (11) replicates the data when the publication bit is r; and

wherein the first data node (11) shares the data when the publication bit is s.
The system as claimed in claim 30, wherein the endpoint bit comprises at least one nodeID, or at least one groupID’s, or a combination of nodeID’s and groupID’s.
The system as claimed in claim 30, wherein the group membership table comprises at least one groupID of a group (G ₁, G ₂...G _n) ; and at least one nodeID of a data node (12 ₁, 12 ₂, 12 ₃, .... 12 _n) associated with the group.
The system as claimed in any one of the previous claims, wherein the first data node (11) replicates and shares the data to at least one data node (12 ₁) when the publication bit is y and the endpoint bit comprises the nodeID associated with the data node (12 ₁) .
The system as claimed in any one of the previous claims, wherein the first data node (11) replicates and shares the data to a set of data nodes (12 ₁, 12 ₃, 12 ₄) associated with a group (G ₁) when the publication bit is y and the endpoint bit comprises the groupID and nodeID’s of the set of data nodes (12 ₁, 12 ₃, 12 ₄) associated with the group (G ₁) .
The system as claimed in any one of the previous claims, wherein the first data node (11) replicates and shares the data to all the data nodes associated with one or more groups (G ₁, G ₂...G _n) , when the publication bit is y and the endpoint bit comprises the groupID associated with the group.
The system as claimed in any one of the previous claims, wherein the first data node (11) replicates and shares the data to one or more data nodes (12 ₁, 12 ₄) and a group (G ₂) when the publication bit is y and the endpoint bit comprises one or more nodeID’s associated with the data nodes (12 ₁, 12 ₄) and the groupID associated with the group (G ₂) .
The system as claimed in claim 30, wherein the user device (10) registers a new groupID associated with a new group to the first data node (11) ; and registers one or more nodeID’s associated with one or more data nodes to the new group.
The system as claimed in claim 30, wherein the user device (10) deregisters a groupID associated with a group from the first data node (11) ; and deregisters, one or more nodeID’s associated with one or more data nodes associated with a group.
A system for selective replication of data from a cloud network to a plurality of data nodes, said system comprising:

a user device (20) sending (S201) a write request to write data at a primary node (21) of the cloud network, wherein the write request comprises data and metadata, said metadata comprising a publication bit and an endpoint bit; and

the primary node (21) determining (S202) whether the data is to be replicated: to at least one data node (12 ₁) , or to a set of data nodes (12 ₁, 12 ₃, 12 ₄) associated with a group (G ₁) , or to all the data nodes associated with one or more groups (G ₁, G ₂...G _n) ; or to one or more data nodes (12 ₁, 12 ₄) and a group (G ₂) , wherein each data node (11, 12 ₁, 12 ₂, .... 12 _n) comprises a group membership table and the primary node (21) comprises a client table; and

the primary node (21) replicating (S203) the data to one or more data nodes (12 ₁, 12 ₂, 12 ₃, .... 12 _n) .
The system as claimed in claim 44, wherein the cloud network comprises at least one primary node (21) and one or more cloud nodes; wherein the data node (12 ₁, 12 ₂, 12 ₃, .... 12 _n) is an edge node; and wherein a group comprises a plurality of data nodes.
The system as claimed in claim 44, wherein the user device (20) writes data to the primary node (21) .
The system as claimed in claim 44, wherein the primary node (21) determines the data nodes associated with a group by looking up the group membership table, when the a nodeID is not indicated in the endpoint bit.
The system as claimed in claim 47, wherein the primary node (21) stores an operation log op_num to record the data written by the primary node (21) in a data node; and increments a commit number commit_num by one count in the data node.
The system as claimed in claim 44, wherein each data node comprises an Op_log comprising an edge-view number to determine whether the data node is situated at the edge of the network.
The system as claimed in claim 44,

wherein the primary node (21) replicates and shares the data when the publication bit is y;

wherein the primary node (21) does not replicate and share the data when the publication bit is s;

wherein the primary node (21) replicates the data when the publication bit is r; and

wherein the primary node (21) shares the data when the publication bit is s.
The system as claimed in claim 44, wherein the endpoint bit comprises at least one nodeID, or at least one groupID’s, or a combination of nodeID’s and groupID’s.
The system as claimed in claim 44, wherein the group membership table comprises at least one groupID of a group (G ₁, G ₂...G _n) ; and at least one nodeID of a data node (12 ₁, 12 ₂, 12 ₃, .... 12 _n) associated with the group.
The system as claimed in any one of the previous claims, wherein the primary node (21) replicates and shares the data to at least one data node (12 ₁) when the publication bit is y and the endpoint bit comprises the nodeID associated with the data node (12 ₁) .
The system as claimed in any one of the previous claims, wherein the primary node (21) replicates and shares the data to a set of data nodes (12 ₁, 12 ₃, 12 ₄) associated with a group (G ₁) when the publication bit is y and the endpoint bit comprises the groupID and nodeID’s of the set of data nodes (12 ₁, 12 ₃, 12 ₄) associated with the group (G ₁)
The system as claimed in any one of the previous claims, wherein the primary node (21) replicates and shares the data to all the data nodes associated with one or more groups (G ₁, G ₂...G _n) , when the publication bit is y and the endpoint bit comprises the groupID associated with the group.
The system as claimed in any one of the previous claims, wherein the primary node (21) replicates and shares the data to one or more data nodes (12 ₁, 12 ₄) and a group (G ₂) when the publication bit is y and the endpoint bit comprises one or more nodeID’s associated with the data nodes (12 ₁, 12 ₄) and the groupID associated with the group (G ₂) .
The system as claimed in claim 44, wherein the user device (20) registers a new groupID associated with a new group to the data node; and registers one or more nodeID’s associated with one or more data nodes to the new group.
The system as claimed in claim 44, wherein the user device (20) deregisters a groupID associated with a group from the data node; and deregisters one or more nodeID’s associated with one or more data nodes associated with a group.