Hello, Am Montag 17 August 2009 21:44:28 schrieb Carl Fürstenberg:
Perhaps there would be an idea to initiate an other dev to be able to do such work.
it is not this easy as you think. For taking a dump, a db-slave of the wm- cluster has to taken away from the cluster. That means that the cluster miss one server and the other servers has to do more work. The new commons(=S4)- cluster have fewer server then the other cluster so taken one away is even more critical. So such a old could be only taken in low-traffic-times.
Sincerly, DaB.
DaB. wrote:
Hello, Am Montag 17 August 2009 21:44:28 schrieb Carl Fürstenberg:
Perhaps there would be an idea to initiate an other dev to be able to do such work.
it is not this easy as you think. For taking a dump, a db-slave of the wm- cluster has to taken away from the cluster. That means that the cluster miss one server and the other servers has to do more work. The new commons(=S4)- cluster have fewer server then the other cluster so taken one away is even more critical. So such a old could be only taken in low-traffic-times.
Sincerly, DaB.
How was commons splitted? Wouldn't that have required making a dump of the db to reimport it at the new cluster? If so... run to get a copy !
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Platonides:
Wouldn't that have required making a dump of the db to reimport it at the new cluster?
no. s4 was created by taking existing s2 slaves and removing all databases which were not commons. then commonswiki was dropped on the remaining s2 servers.
- river.
River Tarnell wrote:
Platonides:
Wouldn't that have required making a dump of the db to reimport it at the new cluster?
no. s4 was created by taking existing s2 slaves and removing all databases which were not commons. then commonswiki was dropped on the remaining s2 servers.
- river.
:( They should have kept a s2 slave so toolserver could get a dump from it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Platonides:
They should have kept a s2 slave so toolserver could get a dump from it.
why? we already have a dump from an s4 slave.
- river.
River Tarnell wrote:
Platonides:
They should have kept a s2 slave so toolserver could get a dump from it.
why? we already have a dump from an s4 slave.
- river.
Reading DaB message, I thought the problem was taking a dump, since it was harder to take a s4 slave out of rotation. If the dump is there, then the only remaining task is reimporting it [before binlogs are deleted], which shouldn't be much an issue.
Hello, Am Dienstag 18 August 2009 00:37:40 schrieb Platonides:
Reading DaB message, I thought the problem was taking a dump
I tought so, yes.
BTW: If the wm-server-admins hadn't drop commons from s2, we wouldn't need a dump ;)
Sincerly, DaB.
DaB. wrote:
BTW: If the wm-server-admins hadn't drop commons from s2, we wouldn't need a dump ;)
Sure. What about restricting drops so they aren't replicated? That would make toolserver resistant against some datalosses at tampa (including careless sysadmins ;) ). However, a subsequent create database + tables would fail and their inserts would be a mess with the previous rows...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Platonides:
If the dump is there, then the only remaining task is reimporting it [before binlogs are deleted], which shouldn't be much an issue.
actually, while importing the dump we found a regression (bug) in the newer version of MySQL that we run on some servers, which caused the import to fail with a confusing error message. i spent several hours last night trying to identify the issue without success; this morning i discussed it with domas and we've now restarted the import using a workaround that should allow it to succeed.
when you use MySQL, nothing is ever simple.
- river.
toolserver-l@lists.wikimedia.org