MediaWiki uses auto-incrementing fields for some of its primary keys. This is a no-no when operating in a MySQL replicated environment, due to the likelihood of multiple servers generating the same primary key number (should the servers lose connectivity).
For those of you who do operate in a MySQL replicated environment, how do you deal with this?
-s
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On 6/20/06, Swoop docuswear@yahoo.com wrote:
MediaWiki uses auto-incrementing fields for some of its primary keys. This is a no-no when operating in a MySQL replicated environment, due to the likelihood of multiple servers generating the same primary key number (should the servers lose connectivity).
For those of you who do operate in a MySQL replicated environment, how do you deal with this?
-s
http://dev.mysql.com/doc/refman/5.0/en/replication-auto-increment.html
On 6/20/06, Gregory Szorc gregory.szorc@gmail.com wrote:
On 6/20/06, Swoop docuswear@yahoo.com wrote:
MediaWiki uses auto-incrementing fields for some of its primary keys. This is a no-no when operating in a MySQL replicated environment, due to the likelihood of multiple servers generating the same primary key number (should the servers lose connectivity).
For those of you who do operate in a MySQL replicated environment, how do you deal with this?
http://dev.mysql.com/doc/refman/5.0/en/replication-auto-increment.html
That's only applicable to MySql 5.0+ As I read the docs, autoincrement fields are only an issue if you have multiple replication MASTERS.
So you can have one or more slave servers which replicate a single master, and do things like load balancing queries across all the servers, and taking backups from a suspended slave without stopping or locking the master. Updates and inserts have to go to the single master.
That's only applicable to MySql 5.0+ As I read the docs, autoincrement fields are only an issue if you have multiple replication MASTERS.
even then you don't want to use multiple masters. unless you really really know what you're doing. if you know mediawiki that well, you might probably assist with coding.
So you can have one or more slave servers which replicate a single master, and do things like load balancing queries across all the servers, and taking backups from a suspended slave without stopping or locking the master. Updates and inserts have to go to the single master.
well, you can do backups from innodb without stopping or locking the master. and yes, you can load balance, and the code for that is already inside MediaWiki.
Domas
On 6/20/06, Domas Mituzas midom.lists@gmail.com wrote:
That's only applicable to MySql 5.0+ As I read the docs, autoincrement fields are only an issue if you have multiple replication MASTERS.
even then you don't want to use multiple masters. unless you really really know what you're doing. if you know mediawiki that well, you might probably assist with coding.
So where did I imply that you should use multiple masters? Or even that I knew mediawiki that well? All I did was point out that the OP's concern only came up if there were multiple masters, and then to suggest that single master replication was the way to go if you wanted replication at all.
So you can have one or more slave servers which replicate a single master, and do things like load balancing queries across all the servers, and taking backups from a suspended slave without stopping or locking the master. Updates and inserts have to go to the single master.
well, you can do backups from innodb without stopping or locking the master. and yes, you can load balance, and the code for that is already inside MediaWiki.
Which, if I understand Brion's latest post correctly uses single master replication, as I suggested.
Hi!
So where did I imply that you should use multiple masters? Or even that I knew mediawiki that well? All I did was point out that the
I don't know - I don't know mediawiki that well :)
OP's concern only came up if there were multiple masters, and then to suggest that single master replication was the way to go if you wanted replication at all.
It is easy way to scale and provide failover. Anything else is not that easy.
Which, if I understand Brion's latest post correctly uses single master replication, as I suggested.
We use multiple single-master-replication clusters.
Domas
Swoop wrote:
MediaWiki uses auto-incrementing fields for some of its primary keys. This is a no-no when operating in a MySQL replicated environment, due to the likelihood of multiple servers generating the same primary key number (should the servers lose connectivity).
There's only one master, so only one place generating keys.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Swoop wrote:
MediaWiki uses auto-incrementing fields for some of its primary keys. This is a no-no when operating in a MySQL replicated environment, due to the likelihood of multiple servers generating the same primary key number (should the servers lose connectivity).
There's only one master, so only one place generating keys.
I should point out that MySQL has no support for conflict management in multi-master replication; basically nobody should ever do it unless they know exactly what they're doing.
Stick with single-master replication only. Never, ever write to a slave.
-- brion vibber (brion @ pobox.com)
Hi!
MediaWiki uses auto-incrementing fields for some of its primary keys. This is a no-no when operating in a MySQL replicated environment, due to the likelihood of multiple servers generating the same primary key number (should the servers lose connectivity).
We do not write to replication slaves.
Domas
mediawiki-l@lists.wikimedia.org