By default, different Persistence Service instances do not synchronize with each other. For example, in a scenario with two Persistence Service instances, the first persistence service could receive a DDS sample ‘S1’ from the original DataWriter that is not received by the second persistence service. If the disk where the first persistence service stores its DDS samples fails, ‘S1’ will be lost.
To enable synchronization between Persistence Servic instances, use the tag <synchronization> under <persistence_service>. When it comes to synchronization, there are two different kinds of information that can be synchronized independently:
|
Tags within |
Description |
Number of Tags Allowed |
|
<synchronize_data> |
Enables synchronization of DDS data samples in redundant Persistence Service instances. When set to 1, DDS samples lost on the way to one service instance can be repaired by another without impacting the original publisher of that message. To synchronize the instances, the tag <synchronize_data> must be set to 1 in every instance involved in the synchronization. Note: This DDS sample synchronization mechanism is not equivalent to database replication. The extent to which database instances have identical contents depends on the destination ordering and other QoS settings for the Persistence Service instances. Default: 0 |
0 or 1 |
|
<synchronize_ |
Enables synchronization of Durable Subscriptions in redundant Persistence Service instances. When set to 1, the different Persistence Service instances will synchronize their Durable Subscription information. This information includes the set of Durable Subscriptions as well as information about the Durable Subscription’s state, such as the DDS samples that have already been received by the Durable Subscriptions. Default: 0 |
0 or 1 |
|
<durable_ |
The period (in milliseconds) at which the information about Durable Subscriptions is synchronized. Default: 5000 milliseconds |
0 or 1 |
© 2016 RTI