From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 29 20:24:44 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BDEE16A4CE for ; Mon, 29 Nov 2004 20:24:44 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA5FA43D2D for ; Mon, 29 Nov 2004 20:24:43 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 4165 invoked from network); 29 Nov 2004 20:16:15 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Nov 2004 20:16:15 -0000 Message-ID: <41AB8588.6020901@freebsd.org> Date: Mon, 29 Nov 2004 21:24:40 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041122 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Justin Hopper References: <41A467DB.29212.9F2DEC@localhost> <20041124171358.GG545@numachi.com> <1101366517.15634.318.camel@work.gusalmighty.com> <1101751837.3366.79.camel@work.gusalmighty.com> In-Reply-To: <1101751837.3366.79.camel@work.gusalmighty.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: HD Mirroring X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 20:24:44 -0000 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