Date: Mon, 11 May 2009 15:34:20 -0400 From: Bill Moran <wmoran@potentialtech.com> To: Martin Turgeon <freebsd@optiksecurite.com> Cc: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: Advices for a jailed MySQL server 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>
next in thread | previous in thread | raw e-mail | index | archive | help
In response to Martin Turgeon <freebsd@optiksecurite.com>: > Bill Moran a =E9crit : > > In response to Martin Turgeon <freebsd@optiksecurite.com>: > >=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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090511153420.439eed75.wmoran>