Looks good to me Thanks,
Hongwei Li > On Sep 16, 2020, at 1:43 AM, "[email protected]" <[email protected]> > wrote: > > 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] >>> >>> >>> >>> >>
