MIME-Version: 1.0
Received: by 10.100.248.16 with SMTP id v16mr45899anh.0.1244583705020; Tue, 09 
	Jun 2009 14:41:45 -0700 (PDT)
Date: Tue, 9 Jun 2009 14:41:44 -0700 (PDT)
In-Reply-To: <4cfa0b030905292053r7044f554odc83b3d48e653129@mail.gmail.com>
X-IP: 70.164.46.211
References: <4cfa0b030905292053r7044f554odc83b3d48e653129@mail.gmail.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us) 
	AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Safari/530.17,gzip(gfe),gzip(gfe)
Message-ID: <e86b9c9a-ab28-4926-9a7c-70ae3235feb7@v4g2000vba.googlegroups.com>
Subject: Re: An idea for a tool to verify the safeness of upgrading
From: rwa <waread...@gmail.com>
To: Maatkit Help <maatkit-discuss@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On May 29, 11:53=A0pm, Baron Schwartz <ba...@xaprb.com> wrote:

> I've just had the 4th or 5th customer case in the last week where an
> upgrade really needed to be tested to verify plan stability, etc. =A0I
> would welcome your input on creating a new tool for this purpose.

We were one of those cases, and we'd be happy to sponsor this.  I do
think our particular problem might be a little different than most,
and any suggestions for testing in our case would be particularly
interesting.

Rather than have a single application that uses MySQL we have dozens
of financial analysts doing ad hoc analysis against a shared data
set.  What they choose to do (and hence the queries) changes
dramatically from week to week, an a small subset of that coalesces
into ongoing, regularly run scripts.  So even the scheduled queries
can change fairly significantly.  The largest issue is that many of
these analyses involve intermediary tables that are dropped after the
work is done.

We log the vast majority of our queries (including selects), but many
of these cannot be run or explained any longer due to the absence of
these intermediary tables.  So just having the queries and a tool to
review them gets us only so far.  Other than building a slave,
converting all the tables to the next version, running the replication
stream (though in that case we miss selects) we don't have much to
help us.  Even with this when we hit an issue we have to fall back to
a pre-upgraded version of the slave, allow it to catch up while we
remove the offending queries from our usage then try again.

As I said we'll get some use out of anything, so we'd be willing to
sponsor what you have now, but if we can come up with something that
addresses the above it's even more interesting.

Thanks,