The ORACLE Dataguard architecture synchronizes Redo or archive logs on a primary/secondary basis at the instance level of granularity. In An OceanBase cluster, there is usually no master/slave system for machines. Data synchronization occurs between the master and standby copies of each partition. The master/slave synchronization of different partitions is performed independently. The location of the primary copy of the same partition (data) is not fixed (but controlled by policy) and can only appear on one machine in one Zone, but the primary copy of different partitions can be in different zones or on different machines.
Suppose there are only three machines (nodes) in total in a cluster with three partitions, each with three copies. Obviously there is a copy of each partition on each machine. However, the location of the primary copy of the three partitions is not fixed. They can all be on one machine, much like the traditional Dataguard architecture, with one master and two standby; They can also be on three machines. The primary copy of each partition synchronizes cloG to its standby copy, and there is a data synchronization flow between the three machines. This is different from ORACLE’s Dataguard architecture and MySQL’s master-master two-way synchronization.
The synchronization protocol between the primary and secondary copies is neither asynchronous nor full synchronization, but Paxos. All copies of the partition (including the primary copy itself) are voted upon a SUCCESSFUL CLOG drop, and when a majority of the replicas vote for a successful CLOG drop, the business transaction is returned on the primary copy commit. Such a mechanism ensures that in the future, if any member copy fails, the full CLOG can be retrieved from the majority copy and applied to the new master copy, ensuring that the data is exactly the same as before the failure.