[ Date Index ][
Thread Index ]
[ <= Previous by date /
thread ]
[ Next by date /
thread => ]
3 in RAID 0 3 in RAID 0
the two volumes are then run in RAID 1 so we get RAID 1E0 IBM but i call it RAID 10 Wickedly fast, hot swapable to any drive and handles pwr outage
We use RH7.3 run Ext 3 and run a Bigish DB app that makes em rattle - Looovellly !
Alex Charrett wrote:
Is a journalled filesystem necessary on a mirror, or indeed as it's a
software mirror will the combination of the two create unnecessary
overhead on the machine?
Mirroring in most Unix systems (you'll have to check Linux) is pretty low overhead (assuming(!!!!) you keep your I/O channels free by using seperate I/O channels to each disk in a pair - thus your system should survive minor issues like IDE bus failure).
It just schedules two writes for each write - fairly painless when done in software, even more painless when done in hardware (although that makes I/O channel redundancy fun!).
File systems integrity is more about power failure or similar than disk failure (heck if you don't mirror and the disk fails, file system type is largely irrelevant).
So chose your file system based on what it is doing, not what the disks are (assuming you don't use stupid disk types for things - hey I see a lot of Oracle redo logs on RAID 5 - I see quite a few systems using RAID-5 for everything - I think some people think it gets better as the number goes up - well they'll be all right at 10 ;-)
Read the Oracle SAME documents if you feel tempted to use RAID 5 anywhere.
SAME - Striping And Mirroring Everywhere.
RAID 5 is for archives ;-) I have some Oracle database files on RAID-5 somewhere, but hey the box would have been SAME'd if I'd done the install.
I've heard Pete mention a few times that ext3 has given him major performance issues when doing database work, but it is of course possible to store the db files on a non journalled slice and the rest on journalled.
I'd guess journalling things like /usr is pretty pointless because it
doesn't change too often but perhaps it is good on /var and /home, but
still not sure how this will impact system performance.
Journalling on /usr, of course, whilst you write to it less often if it goes "tits up" whilst you are writing to it, well it can take a long time to recover compared to just restoring a database.
I have a 20GB Oracle database stashed away on a machine, it takes 3 hours to recover the database from tape, 8 to recover the OS and database, I don't want /usr to bite the dust when I'm patching it!
Any suggestions/experiences?
Journal everything apart from database files that are doing their own journalling!
Journal everything that can be, has been HP's default for years, originally the kernel had to be on an unjournalled system, but hell you don't want to lose stuff when rebuilding a kernel, so they fixed the loader to boot from a journalled file system.
Follow the database provider, and file system provider advice on configuring database files. If possible try and figure out exactly the paths a database write takes though the system in terms of disk writes, blocking and unblocking.
The Veritas file systems support lazy journalling models suitable for database files, I believe Reiser has something similar, and probably ext3, most of these things (i.e. making decisions on when to do what) are fairly easy to implement compared to writing a journaled file system in the first place.
Big issue can be fsck time for non-journalled file systems - spending 10 to 15 minutes runnings fsck on a reboot is not fun, especially if it then says "rerun fsck manually", and you have another 10 to 15 minutes before the users go away.
-- The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe.
-- The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe.