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
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 |