Pavel, in many cases you're right, two-way synchronization is ideal. This is easily done by enabling both publish and subscribe on each table, that will result in complete two-way replication.
However, we think it's important to give users granular control of their replication for cases where one-way replication may be ideal. For example, if the sole purpose of node B was to provide redundancy for node A and you weren’t making any create/update operations on node B that needed to be reflected on node A, the communication can be one way (A -> B).
Another case where this may be valuable is in sensor data collection. You may have many nodes collecting sensor data that only care about that sensor, but the data could be replicated up to a primary reporting node that would have values from all sensors. In this case, one way replication is important and queries on each node would result in different data sets.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Pavel, in many cases you're right, two-way synchronization is ideal. This is easily done by enabling both publish and subscribe on each table, that will result in complete two-way replication.
However, we think it's important to give users granular control of their replication for cases where one-way replication may be ideal. For example, if the sole purpose of node B was to provide redundancy for node A and you weren’t making any create/update operations on node B that needed to be reflected on node A, the communication can be one way (A -> B).
Another case where this may be valuable is in sensor data collection. You may have many nodes collecting sensor data that only care about that sensor, but the data could be replicated up to a primary reporting node that would have values from all sensors. In this case, one way replication is important and queries on each node would result in different data sets.