New DB_REPLICA constant; DB_SLAVE deprecated

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

New DB_REPLICA constant; DB_SLAVE deprecated

Aaron Schulz
As of 950cf6016c, the mediawiki/core repo was updated to use DB_REPLICA
instead of DB_SLAVE, with the old constant left as an alias. This is part
of a string of commits that cleaned up the mixed use of "replica" and
"slave" by sticking to the former. Extensions have not been mass
converted. Please use the new constant in any new code.

The word "replica" is a bit more indicative of a broader range of DB
setups*, is used by a range of large companies**, and is more neutral in
connotations.

Drupal and Django made similar updates (even replacing the word "master"):
* https://www.drupal.org/node/2275877
* https://github.com/django/django/pull/2692/files &
https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a02352ae1

I don't plan on doing anything to DB_MASTER, since it seems fine by itself,
like "master copy", "master tape" or "master key". This is analogous to a
master RDBMs database. Even multi-master RDBMs systems tend to have a
stronger consistency than classic RDBMs slave servers, and present
themselves as one logical "master" or "authoritative" copy. Even in it's
personified form, a "master" database can readily be thought of as
analogous to "controller",  "governer", "ruler", lead "officer", or such.**

* clusters using two-phase commit, galera using certification-based
replication, multi-master circular replication, ect...
**
https://en.wikipedia.org/wiki/Master/slave_(technology)#Appropriateness_of_usage
***
http://www.merriam-webster.com/dictionary/master?utm_campaign=sd&utm_medium=serp&utm_source=jsonld

--
-Aaron
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New DB_REPLICA constant; DB_SLAVE deprecated

Amir Sarabadani-2
Sorry for late question. I guess we should deprecate wfWaitForSlaves() and
probably some other methods that still use this logic

Best

On Tue, Sep 6, 2016 at 11:22 AM Aaron Schulz <[hidden email]> wrote:

> As of 950cf6016c, the mediawiki/core repo was updated to use DB_REPLICA
> instead of DB_SLAVE, with the old constant left as an alias. This is part
> of a string of commits that cleaned up the mixed use of "replica" and
> "slave" by sticking to the former. Extensions have not been mass
> converted. Please use the new constant in any new code.
>
> The word "replica" is a bit more indicative of a broader range of DB
> setups*, is used by a range of large companies**, and is more neutral in
> connotations.
>
> Drupal and Django made similar updates (even replacing the word "master"):
> * https://www.drupal.org/node/2275877
> * https://github.com/django/django/pull/2692/files &
>
> https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a02352ae1
>
> I don't plan on doing anything to DB_MASTER, since it seems fine by itself,
> like "master copy", "master tape" or "master key". This is analogous to a
> master RDBMs database. Even multi-master RDBMs systems tend to have a
> stronger consistency than classic RDBMs slave servers, and present
> themselves as one logical "master" or "authoritative" copy. Even in it's
> personified form, a "master" database can readily be thought of as
> analogous to "controller",  "governer", "ruler", lead "officer", or such.**
>
> * clusters using two-phase commit, galera using certification-based
> replication, multi-master circular replication, ect...
> **
>
> https://en.wikipedia.org/wiki/Master/slave_(technology)#Appropriateness_of_usage
> ***
>
> http://www.merriam-webster.com/dictionary/master?utm_campaign=sd&utm_medium=serp&utm_source=jsonld
>
> --
> -Aaron
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New DB_REPLICA constant; DB_SLAVE deprecated

Jaime Crespo
> I don't plan on doing anything to DB_MASTER, since it seems fine by
itself,
> like "master copy", "master tape" or "master key"

MySQL has announced they chose to use "source":
https://mysqlhighavailability.com/mysql-terminology-updates/ We can
consider updating too, I think it is a more accurate representation of what
those servers are (sending original data to, rather than controlling the
replicas).

On Sat, Sep 17, 2016 at 10:18 AM Amir Ladsgroup <[hidden email]> wrote:

> Sorry for late question. I guess we should deprecate wfWaitForSlaves() and
> probably some other methods that still use this logic
>
> Best
>
> On Tue, Sep 6, 2016 at 11:22 AM Aaron Schulz <[hidden email]>
> wrote:
>
> > As of 950cf6016c, the mediawiki/core repo was updated to use DB_REPLICA
> > instead of DB_SLAVE, with the old constant left as an alias. This is part
> > of a string of commits that cleaned up the mixed use of "replica" and
> > "slave" by sticking to the former. Extensions have not been mass
> > converted. Please use the new constant in any new code.
> >
> > The word "replica" is a bit more indicative of a broader range of DB
> > setups*, is used by a range of large companies**, and is more neutral in
> > connotations.
> >
> > Drupal and Django made similar updates (even replacing the word
> "master"):
> > * https://www.drupal.org/node/2275877
> > * https://github.com/django/django/pull/2692/files &
> >
> >
> https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a02352ae1
> >
> > I don't plan on doing anything to DB_MASTER, since it seems fine by
> itself,
> > like "master copy", "master tape" or "master key". This is analogous to a
> > master RDBMs database. Even multi-master RDBMs systems tend to have a
> > stronger consistency than classic RDBMs slave servers, and present
> > themselves as one logical "master" or "authoritative" copy. Even in it's
> > personified form, a "master" database can readily be thought of as
> > analogous to "controller",  "governer", "ruler", lead "officer", or
> such.**
> >
> > * clusters using two-phase commit, galera using certification-based
> > replication, multi-master circular replication, ect...
> > **
> >
> >
> https://en.wikipedia.org/wiki/Master/slave_(technology)#Appropriateness_of_usage
> > ***
> >
> >
> http://www.merriam-webster.com/dictionary/master?utm_campaign=sd&utm_medium=serp&utm_source=jsonld
> >
> > --
> > -Aaron
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Jaime Crespo
<http://wikimedia.org>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New DB_REPLICA constant; DB_SLAVE deprecated

Amir Sarabadani-2
I'd be happy to rename it to "source". It would be also great if we clean
up puppet repo from bad terms

If people want to follow the discussion, I'd recommend checking this
ticket: https://phabricator.wikimedia.org/T254646

Best


On Thu, Jul 2, 2020, 11:30 Jaime Crespo <[hidden email]> wrote:

> > I don't plan on doing anything to DB_MASTER, since it seems fine by
> itself,
> > like "master copy", "master tape" or "master key"
>
> MySQL has announced they chose to use "source":
> https://mysqlhighavailability.com/mysql-terminology-updates/ We can
> consider updating too, I think it is a more accurate representation of what
> those servers are (sending original data to, rather than controlling the
> replicas).
>
> On Sat, Sep 17, 2016 at 10:18 AM Amir Ladsgroup <[hidden email]>
> wrote:
>
> > Sorry for late question. I guess we should deprecate wfWaitForSlaves()
> and
> > probably some other methods that still use this logic
> >
> > Best
> >
> > On Tue, Sep 6, 2016 at 11:22 AM Aaron Schulz <[hidden email]>
> > wrote:
> >
> > > As of 950cf6016c, the mediawiki/core repo was updated to use DB_REPLICA
> > > instead of DB_SLAVE, with the old constant left as an alias. This is
> part
> > > of a string of commits that cleaned up the mixed use of "replica" and
> > > "slave" by sticking to the former. Extensions have not been mass
> > > converted. Please use the new constant in any new code.
> > >
> > > The word "replica" is a bit more indicative of a broader range of DB
> > > setups*, is used by a range of large companies**, and is more neutral
> in
> > > connotations.
> > >
> > > Drupal and Django made similar updates (even replacing the word
> > "master"):
> > > * https://www.drupal.org/node/2275877
> > > * https://github.com/django/django/pull/2692/files &
> > >
> > >
> >
> https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a02352ae1
> > >
> > > I don't plan on doing anything to DB_MASTER, since it seems fine by
> > itself,
> > > like "master copy", "master tape" or "master key". This is analogous
> to a
> > > master RDBMs database. Even multi-master RDBMs systems tend to have a
> > > stronger consistency than classic RDBMs slave servers, and present
> > > themselves as one logical "master" or "authoritative" copy. Even in
> it's
> > > personified form, a "master" database can readily be thought of as
> > > analogous to "controller",  "governer", "ruler", lead "officer", or
> > such.**
> > >
> > > * clusters using two-phase commit, galera using certification-based
> > > replication, multi-master circular replication, ect...
> > > **
> > >
> > >
> >
> https://en.wikipedia.org/wiki/Master/slave_(technology)#Appropriateness_of_usage
> > > ***
> > >
> > >
> >
> http://www.merriam-webster.com/dictionary/master?utm_campaign=sd&utm_medium=serp&utm_source=jsonld
> > >
> > > --
> > > -Aaron
> > > _______________________________________________
> > > Wikitech-l mailing list
> > > [hidden email]
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> --
> Jaime Crespo
> <http://wikimedia.org>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l