0

I recently did a move of a VM and didn't pay close enough attention.

The VM container the postgres master. Some time passed between the backup and the move and now I'm getting stuff like this:

ERROR:  requested starting point 14C/93000000 is ahead of the WAL flush position of this server 14C/524BE2E0

The problem is going to be the fact that the slave received more WAL archives in between the time of the backup and the move.

The problem is: how do I fix it?

I've already done a new basebackup, cleaned wal archives with archivecleaner, but restarted the slave just keeps it coming back.

Sounds like slave WAL is ahead of master.

What's the solution here? I can't find it on google. Is there a way to reset this wal flush position? To tell the server to start anew?

EDIT: I ended up fixing it by deleting the slave and redeploying it, having it take the new basebackup as starting point.

  • I suggest posting this question on Postgresql General email list, postgresql.org/community to see if you can get help. To have the slave ahead of the master means the slave rolled its transactions log or master sent wal then it was rolled back some how.... I suspect this may require completely redoing the slave.. – zsheep Feb 7 at 14:18
  • How did you do the "move"? It sounds like you restored an old backup, and called that the moved data. Which means you lost a lot of transaction which happened between the backup and when the old master was finally shutdown. If that is the case, you really have a mess. The replica contains data that was lost on the master, while the new master may also contain transaction done after the move. There is no clean way to merge these together. The easiest solution is declare one or the other to be correct, and sacrifice the transactions only in the other one. – jjanes Feb 7 at 14:23
  • @jjanes , if you are correct that he did a dump and restore, OH BOY he has a mess. it can be merged back together, by using FDW or other tool to compare to the two databases to match everything back-up. But the first step would be declare the new master shut down the replication, then start identifying the missing data.. – zsheep Feb 7 at 17:10
  • @jjanes yeah that's what happened. Lucky it wasn't critical, not a very much used system. I ended up deleting the slave and redeploying a new one. But yeah obviously this brings dangers along with it. – KdgDev Feb 8 at 19:20
  • 1
    You could answer your own question to help those may have the same problem in the future? – Vérace Feb 9 at 21:09
1

I ended up deleting the slave and redeploying a new one with the "new" basebackup.

Obviously this is not ideal, but it works. It's a last resort solution. It's literally setting up that part of the environment fresh.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.