At a very high level, asynchronous and synchronous replication are the same. Writes are made to the local MapR-FS that owns the table, and then writes are pushed to the gateway. The gateway pushes these writes to the MapR-FS servers on the destination cluster. Each step allows writes to replicate out of order.
After reaching the gateway, synchronous and asynchronous behaviors are the same.
Note that synchronous replication is not synchronous as it is generally defined. First, it does not provide for guaranteed ordering of replicated writes. More simply, it does not provide for causality. Causality means that if application A writes something to a table and then application B writes to table (possibly by reading what A wrote), the replicated table should reflect the writes in the same order. More specifically, if one queries the table at the replica, one should not see the write by B before the write by A shows up. The lack of causality means these writes might appear out of order. MapR-DB always converges to a consistent state, but applications that access the replicas must take care.
Synchronous replication behaves more like lower latency asynchronous replication. This behavior is reasonable when scale and performance are paramount. This type of replication makes little difference in practice because HBase writes are not written in a guaranteed order because Puts are buffered in memory on the client and written to servers in parallel.
The only way to achieve synchronous behavior in HBase is for the client to disable the Put buffer (and then pay the significant performance penalty). In practice, Puts are buffered.
Retrieving data ...