All,
  MySql 4.1 has been the production release since 4.1.7 and are
currently at the 4.1.9 release.  You could look into the seperate
MySql Cluster product, but it is around $5k per cpu last time I
checked.

--Nick


On Wed, 2 Feb 2005 13:28:22 -0700 (MST), Technical Director
<[EMAIL PROTECTED]> wrote:
> 
> Drumslayer,
> 
> >  The only problem with this is that 4.1 is stil
> > considered Beta ("not yet ready for production"). I
> > see little chance in convincing managment to utilize
> > something beta for something so important.  :(
> 
> Forgive me for being possibly naive but from what I understand 4.1.X moved
> off of beta into Generally Available with a "This is the current generally
> available (GA) release of the MySQL database server. It is recommended for
> most users." [ http://dev.mysql.com/downloads/mysql/4.1.html ] Not
> necessarily saying it's bomb proof but I don't know if they classify it
> as beta anymore.
> 
> As well if it means anything to you we would never have moved our
> 'crticial' services to 4.1.X from 4.0.XX if we didn't believe it was
> ready. Our wait time was seemingly forever but appears to have paid off
> with the stability and strength of the system.
> 
> My 2 cents.
> 
> Rob.
> 
> On Wed, 2 Feb 2005, Drumslayer wrote:
> 
> >
> > --- Technical Director <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > Drumslayer,
> > >
> > > I am part of a team running MySQL 4.1.X on 5
> > > machines in a replication
> > > setup. Our first way to help manage load is the use
> > > of useful rules in
> > > our connection classes to direct "W"rites to our big
> > > server with fast I/O
> > > and memory and directing "R"reads to our slower I/O
> > > less RAM slaves only.
> >
> >
> >  I so far have only seen an alternative from a company
> > called Emic. But it only runs any OS but freeBSD
> > sadly. (it modifies the kernel so compat won't do it)
> >
> >  Have you heard of any hardware solutions or FreeBSD
> > friendly free or commercial products? I know basic
> > clustering and such is supposed to be OK but
> > everything that seems OS agnostic says it's Beta.
> >
> >  We may wind up doing it this way but right now its a
> > toss up of a Beta Solution or move to linux with Emic.
> > Which I'm not fond of becouse its so convoluted and
> > Well Not BSD :)
> >
> >  Thanks
> >
> >  M.
> >
> >
> > > This one step in itself has done a LOT for keeping
> > > uptimes high and
> > > queries fast.
> > >
> > > A positive advantage is that the 5 machines allows
> > > us the opportunity to
> > > change the configuration if say one fails we can
> > > promote another slave to
> > > take that position or in the case of the "W"rite
> > > server we can promote a
> > > slave to a "W"rite server until the original "W"rite
> > > server can be recovered.
> > >
> > > As well whether you use C/C++, Java, PHP or some
> > > other scripting language
> > > to access your database it shouldn't be too hard to
> > > write some sort of
> > > algorithm in your connection to spread the
> > > connections across your host
> > > base.
> > >
> > > When it comes to management I won't lie, 4.0.XX's
> > > handling of Replication
> > > was tough. Since though we've made the move to 4.1.X
> > > our problems have
> > > become less and less.
> > >
> > > A final advantage to having seperate machines in a
> > > replication setup is
> > > the ability to upgrade a segment or machine to a
> > > newer MySQL version to
> > > see how it will operate on your hardware/OS and with
> > > your programs. We did
> > > this with our move from 4.0.XX to 4.1.X by taking 2
> > > slaves out of the main
> > > loop, promoting one to the new 4.1.X master and the
> > > other slave to a new
> > > 4.1.X slave. After testing in pre-production we
> > > proceeded with the
> > > deployment on our other 3 boxes.
> > >
> > > INFO: Our 5 machine replication setup consists of:
> > >
> > > 1) 1 - 4 x P4 Xeon Compaq Server ("W"rite DB Server)
> > > 2) 4 - 1 x P3 Compaq Servers ("R"ead DB Server)
> > >
> > > NOTE: On a smaller scale on my home network I do the
> > > same on three
> > > machines all sub-server class. I still have great
> > > reliability and "robust"
> > > performance from such a simple design.
> > >
> > > I hope this information is helpful, I know it works
> > > well for us.
> > >
> > > Rob.
> > >
> > > On Tue, 1 Feb 2005, Drumslayer wrote:
> > >
> > > > Hi
> > > >  I have been running a fairly heavy duty server
> > > for
> > > > MySQL on FreeBSD but its starting to peak. I would
> > > > like to know what others have done as far as using
> > > a
> > > > load balancing solution for MySQL or their success
> > > > with replication.
> > > >  Also has anyone done a 64 bit build of MySQL on
> > > > FreeBSD successfully?
> > > >
> > > >  Thanks!
> > > >
> > > >   M.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > __________________________________
> > > > Do you Yahoo!?
> > > > The all-new My Yahoo! - What will yours do?
> > > > http://my.yahoo.com
> > > > _______________________________________________
> > > > freebsd-questions@freebsd.org mailing list
> > > >
> > >
> > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > > > To unsubscribe, send any mail to
> > > "[EMAIL PROTECTED]"
> > > >
> > > _______________________________________________
> > > freebsd-questions@freebsd.org mailing list
> > >
> > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > > To unsubscribe, send any mail to
> > > "[EMAIL PROTECTED]"
> > >
> >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail - You care about security. So do we.
> > http://promotions.yahoo.com/new_mail
> >
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to