From: | John R Pierce <pierce(at)hogranch(dot)com> |
---|---|
To: | fburgess(at)radiantblue(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Configuring Standby Server in PostgreSQL 9.3.3 |
Date: | 2014-04-02 22:13:53 |
Message-ID: | 533C8BA1.6070104@hogranch.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 4/2/2014 2:58 PM, fburgess(at)radiantblue(dot)com wrote:
> HI John, all of the backups we have taken were from the 24/7 uptime
> operational production servers. The 4-5 days duration is taken from
> these backups. Several months ago we restored one of these backups to
> another higher capacity database server on fiber channel storage in a
> different location, then we upgraded postgis from 1.5.8 to 2.1.1 and
> PostgreSQL from 9.1.6 to 9.3.3, that restore took 9-10 days to finish.
> We have another VM that has been set aside to be stood up asap as our
> standby server to this primary. Currently, this standby VM only has
> Linux 6.4 installed, no PostgreSQL or PostGIS. I was thinking if we
> can perform a VM clone, we wouldn't have to install PostgreSQL,
> Postgis, packages, etc., on the standby server.
>
was that a file backup of the $PGDATA directory, or a database dump ?
you CANT start streaming replication with a database dump, as its not
the same timeline. you have to use a file system level backup.
quite frankly, dealing with a production database this large, I do
believe I am going to recommend you bring an experienced postgresql
consultant on board who's dealt extensively with large scale
replication, someone like 2ndQuadrant, or CommandPrompt, or PGExperts,
etc, and let them advise you.
--
john r pierce 37N 122W
somewhere on the middle of the left coast
From | Date | Subject | |
---|---|---|---|
Next Message | sidicas2 | 2014-04-02 22:40:06 | BUG #9836: SegFault at heaptouple.c:1104 |
Previous Message | fburgess | 2014-04-02 21:58:03 | Re: Configuring Standby Server in PostgreSQL 9.3.3 |