Re: Streaming Rep - 2-phase backups and reducing time to full replication

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Subject: Re: Streaming Rep - 2-phase backups and reducing time to full replication
Date: 2009-12-28 10:55:50
Message-ID: 1261997750.18116.3674.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2009-12-25 at 14:33 +0900, Fujii Masao wrote:
> On Thu, Dec 24, 2009 at 6:03 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > I see it would work like this: Add a new option to recovery.conf,
> > perhaps two_phase_backup = on. Startup creates a file called
> > backup_in_progress then waits. When second phase of backup is complete
> > (7b), delete the file and then Startup process will continue. Very few
> > lines of code to make this work.
>
> Where do you think the WAL files shipped before doing (7b) are stored?
> If it's pg_xlog, the disk full failure would occur in the standby. If
> it's an archive, restore_command would have to be supplied the same as
> my idea.

Yes, agreed.

I am still concerned about the interactions at the start of replication.
It isn't clear how these things work exactly and as a result, I feel we
may be missing some better ideas.

Two points concern me
* When would sync rep be able to start?
* How do we avoid sending WAL twice?

--
Simon Riggs www.2ndQuadrant.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Urbański 2009-12-28 12:13:18 Re: join ordering via Simulated Annealing
Previous Message Boszormenyi Zoltan 2009-12-28 10:20:57 Re: [PATCH] Provide rowcount for utility SELECTs