Date: Mon, 29 Nov 2004 21:24:40 +0100 From: Andre Oppermann <andre@freebsd.org> To: Justin Hopper <jhopper@bsdhosting.net> Cc: freebsd-hackers@freebsd.org Subject: Re: HD Mirroring Message-ID: <41AB8588.6020901@freebsd.org> In-Reply-To: <1101751837.3366.79.camel@work.gusalmighty.com> References: <41A467DB.29212.9F2DEC@localhost> <20041124171358.GG545@numachi.com> <Pine.OSX.4.61.0411241629510.787@oof.local> <1101366517.15634.318.camel@work.gusalmighty.com> <1101751837.3366.79.camel@work.gusalmighty.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41AB8588.6020901>