Probably can't really use drives which are 18GB or smaller, unless you know of some cheap box to put manyb them in. Otherwise it may cost more for the box than the drives are worth in performance. I think we have three 18GB drives from Suda sitting on a shelf somewhere. Abosolute minimum total box capacity for any database work is 250GB but 400GB is better. Ariel is 210GB usable and has at most 40GB free with all but one master/binary log file deleted. Once we can split out search duty it will be possible to use smaller slaves - they can contain only cur and searchindex.
The recently ordered slaves have 438GB in 6 disk RAID 0, one about 73GB 10K SCSI, the other 73GB 10K SATA. Given Bacon's 7200RPM performance in RAID 10 compared to Suda at 10K SCSI it seems likely that the SATA will at least match the SCSI. RAID 0 because we just don't care if we lose all data on a slave now we have a fair number of them. Might buy a cold spare drive for each though...:)
For read only we switch to a different server and run it read only.
It would be possible to start a new log on the temporary master and apply those updates to the real master but those would inevitably cause badly garbled article history (at least, probably more pain than that) as people try to redo their edits based on the outdated information on this slave serving as a temporary master.
For LVM are you thinking of having all writes go to all database servers at the same time, instead of via replication? Sounds as though that's what you have in mind...
On Tue, 26 Oct 2004, user_Jamesday wrote:
For LVM are you thinking of having all writes go to all database servers at the same time, instead of via replication? Sounds as though that's what you have in mind...
Not exactly. There is still one master database. However, it is stored on an LVM (over hardware raid) volume. With some slack space in the volume group, a stable snapshot can be made of the database on disk and then replicate it to a new slave. At the the snapshot is created, begin a new binlog that can be applied once the copy is complete.
Or am I just thinking crazy again?
--Ricky
On Oct 26, 2004, at 2:24 PM, Ricky Beam wrote:
Not exactly. There is still one master database. However, it is stored on an LVM (over hardware raid) volume. With some slack space in the volume group, a stable snapshot can be made of the database on disk and then replicate it to a new slave. At the the snapshot is created, begin a new binlog that can be applied once the copy is complete.
Or am I just thinking crazy again?
The files on disk aren't guaranteed to be in a stable state unless the server is cleanly shut down.
You could perhaps copy the entire snapshot to another machine, let it replay the innoDB transaction logs to recover the innoDB tables, and run a repair on the MyISAM tables, and then copy things from there, but that sounds itchy to me.
-- brion vibber (brion @ pobox.com)
On Tue, 26 Oct 2004 17:24:42 -0400 (EDT), Ricky Beam jfbeam@bluetronic.net wrote:
On Tue, 26 Oct 2004, user_Jamesday wrote:
For LVM are you thinking of having all writes go to all database servers at the same time, instead of via replication? Sounds as though that's what you have in mind...
Not exactly. There is still one master database. However, it is stored on an LVM (over hardware raid) volume. With some slack space in the volume group, a stable snapshot can be made of the database on disk and then replicate it to a new slave. At the the snapshot is created, begin a new binlog that can be applied once the copy is complete.
You would need a true transaction system for this to work right (i.e. the last write has either been completely done or none at all), does MySQL support this? Also, the slave(s) would then lag behind right?
wikitech-l@lists.wikimedia.org