Note Check the solidDB Release Notes for any limitations that are associated with using a grid in the current release.
In solidDB grid, the replication of application data and the replication of grid metadata are managed separately. All replication is built on top of solidDB C Replicator (CREP), see C Replicator.
Replication of application data
For application data, a grid maintains copies of both partitioned and non-partitioned (shared) tables by means of asynchronous replication.
Replica copies of the same partition form a replication group, and members of the group (replication units) are distributed to different nodes.
Each replication group has a primary replication unit and one or more secondary replication units. Data can be written to only the primary replication unit but data can be read from both the primary and secondary replication units.
For each partition, the replication factor determines the number of replication units that are stored in the grid.
The following table compares the characteristics of the replication group and replication factor for partitioned and non-partitioned tables:
Table type
Replication Group
Replication Factor
Partitioned table
Each partition of the table has a separate replication group. The primary replication unit for each partition can be on any node in the grid, so it is unlikely that all updates to the table can take place on a single grid node.
The replication factor is configurable. For example, a replication factor of three means that every replication group has three replication units, each stored on a separate grid node.
Non-partitioned table
The table has a single replication group, with each replication unit containing the entire contents of the table. As there is only one primary replication unit for the table, all updates to the table take place on a single grid node.
The replication factor is automatically set to the number of active nodes in the grid. If nodes are added or removed from the grid, the replication factor is adjusted accordingly so that every active node in the grid stores a replica copy of the table.
Replication of grid metadata
Grid metadata, which includes configuration, partitioning information, database schema definition, and user privileges, must be present in every grid node.
One of the nodes in the grid is designated as the leader, to which all metadata updates are automatically routed. Since updates are essential for the correct behavior of the grid, they are executed as synchronously-replicated transactions. Any update to the metadata is first prepared in the leader, then replicated to other grid nodes. The update is committed by the leader only when the majority of nodes have received the update, and sent an acknowledgment to the leader. Waiting for a majority of the nodes to respond (before committing the data) ensures that data is not lost in the case of a single node failure.
The synchronous replication implementation is based on a consensus algorithm. For more information about the consensus algorithm, see solidDB consensus algorithm.
The leader also monitors the response latencies of nodes, state of their replication links, number of replication units, and the availability of the primary replication units for all data. The leader passes this information to the Grid Availability Manager (GAM) component, see Grid Availability Manager.