From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Jinhua Luo <luajit(dot)io(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: issue about the streaming replication |
Date: | 2017-03-12 11:20:39 |
Message-ID: | CAB7nPqSWc=tM2kniOAXfcGzPdDLTfaaX77FRBReQtr86LXtRUw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Mar 12, 2017 at 5:24 PM, Jinhua Luo <luajit(dot)io(at)gmail(dot)com> wrote:
> I think this diverge scenario is common, because it's likely the
> master would crash due to some hardware issue (e.g. power off) which
> would cause some committed transaction has not yet synced to slave,
> while the slave would be promoted to new master and accepts new
> transactions, then how to recover the old master? Moreover, how to
> recover the data on old master which is missing on new master?
pg_rewind (https://www.postgresql.org/docs/9.6/static/app-pgrewind.html)
has been designed with exactly this scenario in mind, aka recycling a
past master as a slave to a promoted node. Have you looked at it? What
you are trying to do is much likely going to create corruptions on
your systems, so I am not surprised that you see inconsistency
failures, what you are seeing is pretty much the tip of hte iceberg.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Jinhua Luo | 2017-03-12 13:19:12 | Re: issue about the streaming replication |
Previous Message | Jinhua Luo | 2017-03-12 08:24:24 | issue about the streaming replication |