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
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
