Thread: error message in PITR restore:
Hi folks,
I’m in the process of implementing PITR backups and restores and learning as I practice. I restored
Using tar –xzf (backup-name) followed by restarting postgres and having the server replay the logs.
I used a recovery_target_time of 1 day prior to current_date Postgres seems to come up OK but
I get the following message over and over again in the serverlog:
ERROR: xlog flush request F/83462374 is not satisfied --- flushed only to F/82FFF0AC
CONTEXT: writing block 1242336 of relation 1663/16388/17696
The logs that came into play in the replay are (in shorthand)
80, 81, 82. The log that was copied back into xlog was 83 prior to the restore.
The relation in the error message points back to a table that was indeed being updated
While the backup was being done.
When I attempt to do another backup I get an error that the checkpoint request failed.
Is there any way replay the restore to get out of this pickle, or do I start from scratch?
Fortunately this is a development server so I have the luxury of recopying production.
Mark Steben
Senior Database Administrator
@utoRevenue™
A Dominion Enterprises Company
480 Pleasant Street
Suite B200
Lee, MA 01238
413-243-4800 Home Office
413-243-4809 Corporate Fax
msteben@autorevenue.com
Visit our new website at
www.autorevenue.com
IMPORTANT: The information contained in this e-mail message is confidential and is intended only for the named addressee(s). If the reader of this e-mail message is not the intended recipient (or the individual responsible for the delivery of this e-mail message to the intended recipient), please be advised that any re-use, dissemination, distribution or copying of this e-mail message is prohibited. If you have received this e-mail message in error, please reply to the sender that you have received this e-mail message in error and then delete it. Thank you.
On Fri, 2008-05-16 at 11:35 -0400, Mark Steben wrote: > I’m in the process of implementing PITR backups and restores and > learning as I practice. I restored > > Using tar –xzf (backup-name) followed by restarting postgres and > having the server replay the logs. > > I used a recovery_target_time of 1 day prior to current_date > Postgres seems to come up OK but > Did you use pg_start_backup()? That sequence of events can occur if the backup_label file is missing, since that won't constrain the stop point from being earlier than it should be. Is there a backup_label file as part of the tar? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
Mark Steben Senior Database Administrator @utoRevenueT A Dominion Enterprises Company 480 Pleasant Street Suite B200 Lee, MA 01238 413-243-4800 Home Office 413-243-4809 Corporate Fax msteben@autorevenue.com Visit our new website at www.autorevenue.com IMPORTANT: The information contained in this e-mail message is confidential and is intended only for the named addressee(s). If the reader of this e-mail message is not the intended recipient (or the individual responsible for the delivery of this e-mail message to the intended recipient), please be advised that any re-use, dissemination, distribution or copying of this e-mail message is prohibited. If you have received this e-mail message in error, please reply to the sender that you have received this e-mail message in error and then delete it. Thank you. -----Original Message----- From: Simon Riggs [mailto:simon@2ndquadrant.com] Sent: Friday, May 16, 2008 12:30 PM To: Mark Steben Cc: pgsql-admin@postgresql.org Subject: Re: [ADMIN] error message in PITR restore: On Fri, 2008-05-16 at 11:35 -0400, Mark Steben wrote: > I'm in the process of implementing PITR backups and restores and > learning as I practice. I restored > > Using tar -xzf (backup-name) followed by restarting postgres and > having the server replay the logs. > > I used a recovery_target_time of 1 day prior to current_date > Postgres seems to come up OK but > Did you use pg_start_backup()? That sequence of events can occur if the backup_label file is missing, since that won't constrain the stop point from being earlier than it should be. Is there a backup_label file as part of the tar? [Mark Steben] -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support [Mark Steben] You may have hit on the issue. I started a tar, then realized that I did not do a 'start backup' so I cancelled the tar then issued the 'start_backup' and 'restarted' the tar. Now when I issue another start-backup I get the 'checkpoint request failed' error. There is a 'backup_label_old' file as part of the data cluster but not A backup_label. Simon, I think you uncovered the problem but I don't see anyway around it Short of reloading the db from a pg_dump backup. Any suggestions would Be appreciated. Thanks, Mark
On Fri, 2008-05-16 at 13:21 -0400, Mark Steben wrote: > Simon, I think you uncovered the problem but I don't see anyway around > it Short of reloading the db from a pg_dump backup. Any suggestions > would Be appreciated. Thanks, Re-run the backup? Sounds safest. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
I would like to use password authentication for most users, but LDAP authentication for the remaining ones users, There will be no overlap of login names. I do not really want to create an entry in the pg_hba.conf file for each login. What I would like is something like host all all 142.104.0.0/24 MD5 host all all 142.104.0.0/24 ldap... in hopes that if the account can be authenticated by MD5 local postgresql accounts, then it is, otherwise it will be authenticated by ldap. Is this type of setup possible? Evan Rempel.
Well, the list became very quiet on this question. Can anyone chime in with suggestions to have some accounts authenticated by ldap and the remainder by MD5 Evan. Evan Rempel wrote: > I would like to use password authentication for most users, but LDAP authentication for the remaining ones users, > There will be no overlap of login names. > > I do not really want to create an entry in the pg_hba.conf file for each login. What I would like is > something like > > > host all all 142.104.0.0/24 MD5 > host all all 142.104.0.0/24 ldap... > > in hopes that if the account can be authenticated by MD5 local postgresql accounts, then it is, > otherwise it will be authenticated by ldap. > > Is this type of setup possible? -- Evan Rempel
Evan Rempel wrote: > Well, the list became very quiet on this question. Can anyone chime in with > suggestions to have some accounts authenticated by ldap and the remainder by MD5 Create a group/role and list that in pg_hba.conf for each authentication method. --------------------------------------------------------------------------- > > Evan. > > Evan Rempel wrote: > > I would like to use password authentication for most users, but LDAP authentication for the remaining ones users, > > There will be no overlap of login names. > > > > I do not really want to create an entry in the pg_hba.conf file for each login. What I would like is > > something like > > > > > > host all all 142.104.0.0/24 MD5 > > host all all 142.104.0.0/24 ldap... > > > > in hopes that if the account can be authenticated by MD5 local postgresql accounts, then it is, > > otherwise it will be authenticated by ldap. > > > > Is this type of setup possible? > > -- > Evan Rempel > > -- > Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +