From owner-freebsd-questions@FreeBSD.ORG Mon May 11 19:34:22 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB22F106566B for ; Mon, 11 May 2009 19:34:22 +0000 (UTC) (envelope-from wmoran@potentialtech.com) Received: from mail.potentialtech.com (internet.potentialtech.com [66.167.251.6]) by mx1.freebsd.org (Postfix) with ESMTP id A9B3F8FC08 for ; Mon, 11 May 2009 19:34:22 +0000 (UTC) (envelope-from wmoran@potentialtech.com) Received: from vanquish.ws.pitbpa0.priv.collaborativefusion.com (pr40.pitbpa0.pub.collaborativefusion.com [206.210.89.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.potentialtech.com (Postfix) with ESMTPSA id 4B8DBEBC0A; Mon, 11 May 2009 15:34:21 -0400 (EDT) Date: Mon, 11 May 2009 15:34:20 -0400 From: Bill Moran To: Martin Turgeon Message-Id: <20090511153420.439eed75.wmoran@potentialtech.com> In-Reply-To: <4A087A57.1050202@optiksecurite.com> References: <4A01DBCE.9070304@optiksecurite.com> <20090506150933.d0ef0178.wmoran@potentialtech.com> <4A087A57.1050202@optiksecurite.com> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.14.7; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-questions@freebsd.org" Subject: Re: Advices for a jailed MySQL server X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 19:34:23 -0000 In response to Martin Turgeon : > Bill Moran a =E9crit : > > In response to Martin Turgeon : > >=20 > >> Hi everyone, > >> > >> I'm starting to build a new dedicated MySQL server. I will be using=20 > >> FreeBSD 7.2-REL. My plan is to jail the latest version of MySQL 5.0 an= d=20 > >> to put the MySQL data outside the jail. My objective is to be able to= =20 > >> update MySQL without down time. My objective would be to create anothe= r=20 > >> up to date MySQL jail and when I'm ready to make the switch, just poin= t=20 > >> the new jail to the data outside the jail using something like a nullf= s=20 > >> mount. > >> > >> Is someone using something like this? > >> > >> Did someone have any advice about how to update a MySQL server without= =20 > >> down time? > >> > >> Did someone have any advice on how to tune a dedicated MySQL server=20 > >> running FreeBSD 7.2 (Dual core Xeon, 4G RAM, mirror RAID on a PERC5=20 > >> controler 2x146G 15K)? > >> > >> Thanks everyone for sharing your precious knowledge :) > >=20 > > I expect that what you're trying to do will work, however it's > > horrifically error-prone during the upgrade procedure (what if you > > forget to stop the first MySQL before you start the new one!) > >=20 > > If you need to do anything zero-downtime, then you probably want > > to run multiple MySQL instances and use database replication to > > keep the data in sync. That way you just switch which DB is > > master, then upgrade the slave ... rinse/repeat. > >=20 >=20 > Hi and thanks for your reply. Sorry for the late response... >=20 > I thought about the risk of the procedure and that's why I asked here=20 > hoping that someone had a better idea! >=20 > Do you mean to have another jail with an up to date slave MySQL, get it=20 > in sync with the master and then switch the config file of the slave to=20 > make it a master, restart the new MySQL, change the config so that the=20 > apps are connecting to the new DB? Yeah. That's what we do here (although we're using PostgreSQL/Slony). It works on a number of levels. In our case, each database is on a separate physical server, so we can move the master database to a different server, then do a complete OS/software upgrade with no downtime to the application (ok, there _is_ some downtime, it takes about 60 seconds to move everything around, but that amount of downtime is hardly even noticeable to a client, and our front-end code is designed to wait it out and continuously reconnect, so if the user is just patient, the site eventually comes up) I'm not nearly as familiar with MySQL's replication solution as I am with PostgreSQL's, but Slony allows us to have multiple versions of PostgreSQL running, so we can do our upgrading a little at a time as the situation allows. --=20 Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/