On Feb 3, 2009, at 7:31 PM, Phoenix Kiula wrote:
Thanks, Gregory and Simon, for the very useful posts.
I have increased the vacuum_cost_limit to 2000 for now, just to see if
that has an impact. Hopefully positive.
Next on my list is to be able to easily upgrade to 8.3, but Slony
seemed like a daunting task the last time I tried. I am on 8.2.9, on
Linux CentOS. Is there a quick and reliable guide to upgrading,
without causing a downtime in a high production environment?
I don't know whether this exists, but it could be quite useful to have
a connection pooler that would send it's queries to both a master and
slave database at once and only returns the results of the master. The
slave could then for example be the new version of PG. That receives
the same queries, so it's data should be up to date with the master
(if no errors occur) and it can be monitored for any problems in the
meanwhile without influencing the workings of the master DB. When
everything is as it should be simply tell the pool to switch to the
new DB, possibly removing the old master (although keeping it around
and after a while upgrade it in preparation of the next major upgrade
would probably be smart).
There are a few gotchas there of course:
- How would you create the clone in the first place? The master is
being updated while the clone is being created, so all queries that
happen during that time need to be performed on the slave yet,
somehow...
- What to do if the slave fails queries that the master eats just
fine? The data shouldn't get out of sync. For example due to the
recent stricter type-casting changes.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,498a9c2b747032137693194!
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
