You Jay Shaughnessy, I like the way you think.
That sounds like minimal downtime (the usual) which is not related to the size of database
but with a *temporary* delay in historic measurements.
This is why I had asked whether it would be possible to keep both metric storage options,
basically to make the transition in the background. This sounds much less complicated.
-alan
----- Original Message -----
From: "Jay Shaughnessy" <jshaughn(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Monday, January 14, 2013 1:33:49 PM
Subject: Re: Metrics Migration Tool - Cassandra
Stefan, has any thought been given to (optionally) migrating the bulk of
the data *after* the upgrade? I'm not sure if this make sense,
really. But the idea being that the customer upgrades RHQ and starts
running with the new backend. At this point no data is being written to
the legacy tables so they are quiet. All new metric data will move to
the new Cassandra backend. Then, with RHQ running we migrate the legacy
data into the new backend. So, for some period we lack historical data,
but it would hopefully not be a very large delay. It's possible maybe
that until the migration is complete we suspend aggregation. Just a
thought.
On 1/14/2013 12:00 PM, Elias Ross wrote:
Just my 2 cents:
I would like to continue running RHQ with minimal downtime (less than
30 minutes if possible). The main issue with downtime is loss of
systems monitoring capability. Historical data is definitely nice to
have, but system monitoring trumps this. I would sooner drop the
metrics data than have to face an unpredictable migration process.
I would prefer if migration could happen concurrent to running of RHQ.
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel