Greetings,
* Ron (ronljohnso...@gmail.com) wrote:
> I've been a DBA for 20+ years, and restored a **lot** of **copies** of
> production databases. PostgreSQL has some seriously different concepts.
> With every other system, it's: restore full backup to new location, restore
> differential backup,
On 9/19/19 9:17 AM, Stephen Frost wrote:
[snip]
Ah, but you are talking about a cluster promotion, though you don't
realize it. Any time there is a "at some point, I was to stop replaying
WAL and start accepting new changes", there's a timeline switch and
notionally a promotion.
The point of t
Greetings,
* Ron (ronljohnso...@gmail.com) wrote:
> On 9/18/19 8:58 PM, David Steele wrote:
> >On 9/18/19 9:40 PM, Ron wrote:
> >>I'm concerned with one pgbackrest process stepping over another one and
> >>the restore (or the "pg_ctl start" recovery phase) accidentally
> >>corrupting the productio
On 9/18/19 10:18 PM, Jerry Sievers wrote:
> David Steele writes:
>
>> This is not an issue unless you seriously game the system. When a
>
> And/or your recovery system is running archive_mode=always :-)
>
> I don't know how popular that setting value is but that plus an
> identical archive_com
David Steele writes:
> On 9/18/19 9:40 PM, Ron wrote:
>
>>
>> I'm concerned with one pgbackrest process stepping over another one and
>> the restore (or the "pg_ctl start" recovery phase) accidentally
>> corrupting the production database by writing WAL files to the original
>> cluster.
>
> This
On 9/18/19 8:58 PM, David Steele wrote:
On 9/18/19 9:40 PM, Ron wrote:
I'm concerned with one pgbackrest process stepping over another one and
the restore (or the "pg_ctl start" recovery phase) accidentally
corrupting the production database by writing WAL files to the original
cluster.
This is
On 9/18/19 9:40 PM, Ron wrote:
>
> I'm concerned with one pgbackrest process stepping over another one and
> the restore (or the "pg_ctl start" recovery phase) accidentally
> corrupting the production database by writing WAL files to the original
> cluster.
This is not an issue unless you serious
On 9/18/19 8:31 PM, David Steele wrote:
On 9/18/19 6:59 PM, Ron wrote:
Scenario: there's data corruption on production server, so we need to do
a PITR restore from "a few days ago" of the cluster holding the prod
databases to a second cluster on that same VM in order to try and find
the missing
On 9/18/19 6:59 PM, Ron wrote:
>
> Scenario: there's data corruption on production server, so we need to do
> a PITR restore from "a few days ago" of the cluster holding the prod
> databases to a second cluster on that same VM in order to try and find
> the missing data and load it back into the p
Ron writes:
> Hi,
>
> (Thanks, Stephen, for helping with my earlier problem.)
>
> Scenario: there's data corruption on production server, so we need to
> do a PITR restore from "a few days ago" of the cluster holding the
> prod databases to a second cluster on that same VM in order to try and
> f
10 matches
Mail list logo
