HD Mirroring

[Andre Oppermann]

Justin Hopper wrote:
> On Wed, 2004-11-24 at 23:08, Justin Hopper wrote:
> 
>>On Wed, 2004-11-24 at 13:31, Charles Sprickman wrote:
>>
>>>On Wed, 24 Nov 2004, Brian Reichert wrote:
>>>
>>>
>>>>And, although I've not tested it, recent versions of MySQL can
>>>>outright support a cluster:
>>>>
>>>> http://dev.mysql.com/doc/mysql/en/NDBCluster.html
>>>
>>>I'm just curious if there's any other solution that will work on FreeBSD. 
>>>I have about 5 mysql servers (4 slaves, 1 master) and one application in 
>>>particular is not smart enough to try other servers if the configured 
>>>server does not answer.  Is there any type of local proxy that can 
>>>intelligently route requests to the "best" server?
>>>
>>
>>I too was curious about the MySQL Clustering support and its status on
>>FreeBSD, since it wasn't as a supported OS.  Over the last couple of
>>hours I was able to set up a cluster consisting of a management process
>>and data node running in one jail, and a MySQL server and another data
>>node running in a different jail.  Once everything was up and running,
>>the cluster seemed to be working excellent, data was synchronizing
>>flawlessly throughout the cluster.  Nuking either of the data node
>>processes did not affect access to the data in the cluster, so failover
>>seemed to be working as well.
>>
>>The only problem that I ran into, and it may be user error on my part,
>>is that when the cluster is shut down (or all data node processes are
>>killed), the data contained in the node is lost when the cluster is
>>brought back online.  Perhaps there is some recovery step that is
>>required before the cluster can be used again.
>>
>>If someone else has already tested MySQL's clustering ability with
>>FreeBSD, then please let us know the results so that I don't recreate
>>the wheel here.  If not, I'll continue seeing how far I can get with it,
>>as I would definitely like to implement this functionality on several of
>>the more critical databases that I manage.
> 
> 
> I'm sure it's taboo to respond to one's own message, but thought I would
> follow up with some information on the problems I was running into with
> MySQL Cluster.
> 
> The first problem, where it appeared that the data in the cluster was
> lost when the cluster was shut down, turned out to be there are some
> problems with the MySQL servers, which act as API clients to the
> cluster, reliably connecting into the cluster.  Several times I could
> not get a MySQL server to connect to the cluster, but found no rhyme or
> reason for it so far.  The cluster seems to be retaining data just fine
> upon shutdown, when the MySQL servers can actually connect to it to
> query data that is...

If you have many TCP connections to one target it may happen that you
get the same source port on the originator again within the TIME_WAIT
timeout.  And if the ISN wrapped in the meantime the new connection
will 'hang'.

> The second problem I encountered was while trying to load a table that
> was 163MB in size that contained around 1 million rows.  The NDB cluster
> would continually report that the table was "full" when trying to import
> the data.  After checking around on mailing lists, I found out that the
> NDB clustering engine will require around table_size*2*10% RAM to load a
> table.  NDB keeps all of the data in main memory, and has a fair amount
> of overhead per row.
> 
> Perhaps somebody else can do a more thorough test of MySQL clustering on
> FreeBSD to make sure that it is in fact fully stable.  It seems like a
> remarkable system, assuming you have the gigs of RAM it takes to run it
> with a table of any substantial size...

But that is an application problem, not FreeBSD's fault.

-- 
Andre