Re: Configurations for performance

> I assume that you're only running MySQL on one machine
at a time, and
> using drbd to keep a hot copy of the block device? Or
are you running the
> commercial MySQL cluster product?
>   
The current setup is to use drbd to keep a hot copy of the
block device. 
I don't have enough RAM to hold the database in memory (the
MySQL 
cluster requires it all to be in RAM - no good for large
db's)
> This sounds well within the capabilities of your
hardware. I certainly
> don't expect DBMail to fall over and die. But, please
do let us know if
> you have to do any interesting tuning. A brief
whitepaper would be grand!
>   
Once I get it all up and running and in production I'll
definitely write 
to the list with how I set it up (I have to do this for our
internal 
documentation anyway)
> If you're going all out, a battery backed user
accessible cache like a
> MicroMemory -- www.umem.com -- or the Gigabyte I-RAM
--
> http://www.gigabyte.com.tw/Products/Storage/Default.aspx
 -- (much
> cheaper!) will allow you to place the filesystem's
journal on that device.
> This is a little different than battery backed RAID
controllers, because
> now the filesystem itself is in control.
>   
That's a great looking device. I'll have to see if our 1U
servers can 
fit it 
>> If I had postgres running on one server and mysql
on the other, this 
>> would be a perfect solution IMO. Just deciding on
whether the added 
>> complexity of running two db's is worth it.
>>     
>
> How would you sync the data between the two databases?
Surely not on the
> block device anymore...
>   
When I first installed my test systems I had MySQL in
master-master 
replication which worked great, but my bubble was burst with
the IMAP ID 
not being guaranteed to be incrementing for each message. I
found that 
the traffic on the network using the built-in replication
was about 20% 
of the traffic on the network using drbd (plus writes should
be faster)

The reason to try drbd is that it looked fairly easy to fail
over and 
back, but now that I think of it a split-brain situation is
going to 
cause data loss no matter which way it's resolved. I'll have
to do some 
research on failing over MySQL and Postgres master-slave
configurations.

Regards,
Josh.
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

On Thu, Mar 29, 2007, Josh <joshtestmail.worldhosting.org> said:

> 
>> I assume that you're only running MySQL on one
machine at a time, and
>> using drbd to keep a hot copy of the block device?
Or are you running the
>> commercial MySQL cluster product?
>>   
> The current setup is to use drbd to keep a hot copy of
the block device. 
> I don't have enough RAM to hold the database in memory
(the MySQL 
> cluster requires it all to be in RAM - no good for
large db's)

Ok, so when the other side disappears, you turn off the
drbd, then start
MySQL and recover no differently than any other typical
crash. Neat idea!

Might I suggest just using MySQL's master-slave replication?
It does the
same thing but without the inherent risks of bringing up an
imperfect
block replica.

[snip]
> The reason to try drbd is that it looked fairly easy to
fail over and 
> back, but now that I think of it a split-brain
situation is going to 
> cause data loss no matter which way it's resolved. I'll
have to do some 
> research on failing over MySQL and Postgres
master-slave configurations.

STOMITH :-P

I just realized that DBMail can fix the IMAP UID problem
after a split
brain situation by reassigning id's and incrementing
UIDVALIDITY. This
would be way out in the future, though. So far we're trying
very hard not
to have to be hands-on about the underlying database
replication. It will
take lots and lots of code and tons of failure scenario test
cases, so we
won't start down that path until we're ready to commit to
it. This is one
of those things where half-assed code is far, far worse than
no code at
all.

Aaron
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

> When I first installed my test systems I had MySQL in
master-master
> replication which worked great, but my bubble was burst
with the IMAP
> ID not being guaranteed to be incrementing for each
message. I found
> that the traffic on the network using the built-in
replication was
> about 20% of the traffic on the network using drbd
(plus writes should
> be faster)
>
I'd run multi-master and then use a perdition setup on each
machine such
that users only access one machine for their email. As all
reads/writes
for one user happen on one machine you should avoid that
problem.
If you have a failure then all users get pointed to the one
machine and
everything keeps going.

You should get more performance and the same redundancy.

If you have 3 machines then you can have your data backed up
twice, and
all the performance of 3 frontends and use mysql's own
handling of
recovering from network breaks. If you got fancier you might
be able to
setup some kind of system where each user was on 2 machines
(but not 3)
for an added performance boost at the cost of some
redundancy.

hmm you would need to split your users into 3 parts and have
6
databases/frontends but it should work
machines = A,B,C
users into groups of a,b,c

machine A has a + b, B has b + c , C has c + a.

set each user group up on one database install and then
replicate that
db to one other machine.
use heartbeat or something to script what happens when a
node goes offline.

it'd be more work but should give you the best use of your
hardware.

If your feeling keen do all your setup inside Xen then you
can migrate a
node transparently.
> The reason to try drbd is that it looked fairly easy to
fail over and
> back, but now that I think of it a split-brain
situation is going to
> cause data loss no matter which way it's resolved. I'll
have to do
> some research on failing over MySQL and Postgres
master-slave
> configurations.
>
> Regards,
> Josh.
> _______________________________________________
> DBmail mailing list
> DBmaildbmail.org
> htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail