Primary-replica is good to me. So, how about:
MasterSlave -> PrimaryReplicaReplication MasterDataSource -> PrimaryDataSource SlaveDataSource -> ReplicaDataSource ------------------ Sincerely, Liang Zhang (John) Apache ShardingSphere Hongwei Li <[email protected]> 于2020年9月14日周一 下午10:31写道： > FYI: > primary and replica, replica replication are widely used terms in AWS. > > > https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/ > > https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html > > On Mon, Sep 14, 2020 at 1:07 AM Juan Pan <[email protected]> wrote: > > > 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] > > > > > > > > >
