Hi Liang,
I also looked through many docs of other databases, like MySQL, MariaDB, PostgreSQL, and MongoDB. For me, I can accept your proposal. In short, no matter `PrimarySecondaryReplication` or `PrimaryReplicaReplication`, IMO. We need to focus on `replication` which means a synchronization process among primary nodes and secondary nodes (Replica nodes). The links below will help me explain more. [1] https://medium.com/@Jelastic/mongodb-replica-set-with-master-slave-replication-and-automated-failover-be3cb374452 [2] https://www.datadriveninvestor.com/2020/05/28/the-master-slave-database-concept-for-beginners/ [3] https://www.postgresql.org/docs/9.2/warm-standby.html [4] https://mariadb.com/resources/blog/database-master-slave-replication-in-the-cloud/ Best, Trista Juan Pan (Trista) Senior DBA & PMC of Apache ShardingSphere E-mail: [email protected] On 09/14/2020 12:34，[email protected]<[email protected]> wrote： I investigate related materials again, maybe read-write-spilt is not a good name. There are two features in Apache ShardingSphere now, master-slave and replica. Master-slave: Write to master data source and replication data to slave data sources async, and then read from slave data sources. Benefit: performance. Replica: Still in dev mode, we plan to use Raft algorithm to keep the multiple replicas with consensus. Benefit: consensus. The tow features can not use together, users can choose one of them in the same time only. I prefer to rename master-slave module to primary-secondary-replication, and rename replica module to consensus-replication. The new names can describe the feature more accurate and can let user to know they are mutually exclusive. Primary-standby-replication is another choice, but I am afraid the meaning of `standby` is waiting here and do nothing if normal, but the secondary data source still need to process the query requests. So, how about to rename the concept to: MasterSlave -> PrimarySecondaryReplication MasterDataSource -> PrimaryDataSource SlaveDataSource -> SecondaryDataSource Please advice me. ------------------ Sincerely, Liang Zhang (John) Apache ShardingSphere Hongwei Li <[email protected]> 于2020年9月14日周一 下午12:02写道： I don't have any idea about how the module 'shardingsphere-master-slave' vs 'shardingsphere-read-write-split', was named. If there was no specific reason, it is like a historical debt, but does not matter so much, as it has been there for a long time, everyone knows the function of the module. In the meantime, 'read-write-split' is more obvious from the processing/action perspective of the module. 'Master/Slave' is also fine from the processing object(datasource) perspective. For simple processing and not considering much, the replacement of 'master/slave' to 'primary/replica' including the combinations is much straightforward. It is kind of 'leave it as is' processing. For moving one step further, renaming the module to 'read-write-split' is a way to go. The questions are: shall we replace 'MasterSlave' as 'ReadWriteSplit' at all places? Do we need to consider if the replacement is meaningful at any place, such as the below names: MasterSlaveDataSourceRuleConfiguration MasterSlaveLoadBalanceAlgorithm On Sat, Sep 12, 2020 at 11:29 PM [email protected] < [email protected]> wrote: I like MasterDataSource -> PrimaryDataSource SlaveDataSource -> ReplicaDataSource But I am not sure about MasterSlave -> PrimaryReplica Because ShardingSphere's feature is route the update SQL to PrimaryDataSource and route the query SQL to ReplicaDataSource. The name ReadWriteSplit may describe the feature more clear. Any suggestions? ------------------ Sincerely, Liang Zhang (John) Apache ShardingSphere Juan Pan <[email protected]> 于2020年9月13日周日 上午10:07写道： Hi Craig, Thanks for your suggestion. :-) For me, both `primary` and `source` are ok. usually using terms like "primary", "secondary", "source", and "replica" Considering the expression above is mentioned in [1]. There are good reasons for MySQL to use "source" instead of "primary" because in their model there may be many "source" databases. Actually, ShardingSphere could also have many "source" databases (Depending on the user's configuration). MasterSlave -> ReadWriteSplit IMO, this renaming does not sound wonderful. I prefer MasterSlave -> PrimaryReplica or MasterSlave -> SourceReplica Moreover, I'd like to listen to others' opinions. [1] https://mysqlhighavailability.com/mysql-terminology-updates/ Best, Trista Juan Pan (Trista) Senior DBA & PMC of Apache ShardingSphere E-mail: [email protected] On 09/12/2020 22:26，Craig Russell<[email protected]> wrote： Hi, This will be a significant change so I think it would be good to resolve all of the naming before any PR is proposed. The first place to start might be the documentation to see all of the name changes in one place. There are good reasons for MySQL to use "source" instead of "primary" because in their model there may be many "source" databases. Personally I don't think "source" is particularly obvious to users, but they did not ask me. ;-) For ShardingSphere, "primary" and "replica" seem to be better choices. It will be easy for us to tell users that ShardingSphere's "replica" corresponds to MySQL's "source". So the concepts to be changed might be: MasterSlave -> PrimaryReplica MasterDataSource -> PrimaryDataSource SlaveDataSource -> ReplicaDataSource And again, it might be easier to review the name changes in the context of documentation changes. HTH, Craig On Sep 6, 2020, at 2:42 AM, [email protected] wrote: Hi All, I want to discuss to rename MasterSlave module to ReadWriteSplit module. MySQL[1] has already change the master and slave to source and replica. Some concepts I plan to change: MasterSlave -> ReadWriteSplit MasterDataSource -> SourceDataSource SlaveDataSource -> ReplicaDataSource Please advice me. [1] https://mysqlhighavailability.com/mysql-terminology-updates/ ------------------ Sincerely, Liang Zhang (John) Apache ShardingSphere Craig L Russell [email protected]
