On Sat, Jul 31, 2010 at 5:59 PM, Gordan Bobic <email@example.com> wrote:
> Edward Capriolo wrote:
>> On Fri, Jul 30, 2010 at 5:19 AM, Jeff Jansen <firstname.lastname@example.org>
>>> Eugen Leitl <email@example.com> wrote on 2010-Jul-28:
>>>> Please do; I would be also quite interested as well.
>>> OK, my first pass at "HA Vserver with DRBD and Heartbeat" docs are up at:
>>> Comments are enabled, so you can comment on the page if you've got
>>> corrections, clarifications, etc.
>>> Jeff Jansen
>>>> It does not scale as well as some other solutions, but it may have other
>>>> advantages that you want (maybe better locking, maybe >>better fail over
>> A little off topic, but it is important distinction between scaling
>> and fail over. You really have to think hard on what your looking for.
>> DRBD gives you disk replication Active/Passive and Active/Active 2
>> nodes. Active Passive does not scale and active/active "scales" to two
>> nodes which really is not scaling, in best case if you scaled a web
>> server now you can handle twice the traffic, what happens when you get
>> three or ten times the traffic? That solution no longer holds up.
> I could be wrong, but I seem to remember that DRBD supports up to 3 nodes.
I mispoke. My point was it is not scalable beyond a certain number.
This does not even take into account performance.
>> At this point you have to look into file systems that allow multiple
>> read/writes NFS or OCFS2. NFS does have locking but
>> it seems to be the general case that no one was any luck with it in
>> high contention situations.
> _ALL_ file systems that support concurrent access have performance problems
> in high contention situations.
There is a difference between performance problems and failing to work
correctly. If the locks really do not work they are not really locks.
>> OCFS2 is multi-attach file systems and it supports much stronger
>> locking semantics. Great! now that we have good locks and multi-mount
>> the question becomes what software is designed to work with this type
>> of file system? Can we have 10 nodes running mysql and
>> managing/working with the same MYD tables? It may work in theory but
>> practically I do not know of anyone doing it?
> You can do this with GFS/GFS2 or OCFS2. You have to set MySQL's locking to
> external. But the performance suffers as in any high-contention case.
> Performance of such a solution is in most cases going to be worse than a
> single node with a non-concurrent-access file system.
> That seems to be a weird isolated incident. There are plenty of accounts of
> it working fine. Possibly a bug in the particular version of MySQL that the
> poster was using.
Ok. Point was it does not work well and performs worse then single
instance. That is performance scaling, but people usually mean to
scale the performance UP with more nodes, not down. Does anyone want a
more complex worse performing system?
>> The only software I know of that works well and scales on OCFS2 is
>> oracle, (probably because oracle corporation made both)
> Indeed, OCFS was initially designed for backing Oracle databases.
>> Most prominent scaling solutions cassandra, hbase, mongo, redis, hdfs.
>> Do NOT work with multi-attached file systems.
> That's due to performance reasons. For scaling you need performance to scale
> with the number of nodes you have. No shared-everything system will provide
> such performance due to the locking overheads. Most shared-everything
> solutions scale inversely.
Received on Sun Aug 1 00:39:21 2010