Greg Smith, 12.07.2010 18:11:
Yes, but if you try you'll discover that actually getting any shared
disk or file system replication solution setup so that you really do
achieve less failover loss than the file shipping approach will be
expensive, complicated, fragile in its own way, and just
We need to upgrade the postgres running on our production system under
Red Hat Enterprise Linux Server release 5.1 from version 8.1.21 to
version 8.3.6.
we could have a stop/maintenance window of 3/4 our the sum of size of
databases is around 1G .
Which is the best practice to execute such
Hello.
I need failover postgresql installation. Two servers work's together. If
one server fail - another server doing queries.
In MySQL i'm use two server (mysql-ndb and two mysql api server (getting
queries) with mysql-proxy. If one server fail mysql-proxy route all
queries to another.
How
http://www.postgresql.org/docs/8.4/static/high-availability.html would
be a good place to start research. And the archives of this thread
would be another - there are recent messages about this sort of thing.
And google postgres high availability or equivalent.
I use slony but there are plenty
On Tue, 2010-07-13 at 13:33 +0400, Vasiliy G Tolstov wrote:
I need failover postgresql installation. Two servers work's together.
If one server fail - another server doing queries.
snip
How can i do this in postgresql?
If you don't {have/want to use} shared storage, you can use WAL
Am Dienstag 13 Juli 2010 11:30:20 schrieb Silvio Brandani:
We need to upgrade the postgres running on our production system under
Red Hat Enterprise Linux Server release 5.1 from version 8.1.21 to
version 8.3.6.
Have a look here:
If I create a parent table that lives in a specific tablespace, when I create
child tables that inherit the parent and then subsequently index and create a
PK on the child, will all of the index objects default to the tablespace that
the parent is built in?
Regards,
Joe Plugge
2010/7/13 Silvio Brandani silvio.brand...@tech.sdb.it:
We need to upgrade the postgres running on our production system under Red
Hat Enterprise Linux Server release 5.1 from version 8.1.21 to version
8.3.6.
we could have a stop/maintenance window of 3/4 our the sum of size of
databases is
Hello,
I am trying to determine what might cause an issue like this. This was a
large (several hundred GB) data warehouse server with PG 8.2.4. I can't
really determine what caused this issue. We ended up restoring the data
from a backup.
Here are some of the errors in the log:
On Tue, Jul 13, 2010 at 10:29:42AM -0700, Deron wrote:
Hello,
I am trying to determine what might cause an issue like this. This was a
large (several hundred GB) data warehouse server with PG 8.2.4. I can't
really determine what caused this issue. We ended up restoring the data
from a
Deron fecas...@gmail.com writes:
I am trying to determine what might cause an issue like this. This was a
large (several hundred GB) data warehouse server with PG 8.2.4. I can't
really determine what caused this issue. We ended up restoring the data
from a backup.
Here are some of the
With a 1GB database you should have no problem to perform upgrade in
three quarters of hour.
You should script database migration process in order to make it faster.
Upgrading binaries is really simple. A yum upgrade should be enough.
However, prior upgrading binaries, you should perform a
12 matches
Mail list logo
