| 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: | Whole Thread | Raw Message | 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 |