pg_rewind in PostgreSQL 9.5
hlinnaka.iki.fi
pg_rewind in PostgreSQL 9.5
1–10 of 63 posts
Re: pg_rewind in PostgreSQL 9.5
#2Nice, definitely something that is a pain for mirroring in SQL Server, though if you have a good runbook its just time consuming and boring.
Re: pg_rewind in PostgreSQL 9.5
#3Nice, definitely something that is a pain for mirroring in SQL Server, though if you have a good runbook its just time consuming and boring.
? MSSQL mirroring failover is very easy and painless( arguably one of best compared to other rdbms), just make sure not to do automatic failover as that can cause false failover with spotty network between nodes and witness.
Re: pg_rewind in PostgreSQL 9.5
#4Nice, definitely something that is a pain for mirroring in SQL Server, though if you have a good runbook its just time consuming and boring.
? MSSQL mirroring failover is very easy and painless( arguably one of best compared to other rdbms), just make sure not to do automatic failover as that can cause false failover with spotty network between nodes and witness.
Sorry about that, I was referencing failing back over to the primary after failing over to the secondary.
Specifically from the post:
- Cool. And how do I fail back to the old master?
- Umm, well, you have to take a new base backup from the new master, and re-build the node from scratch..
Re: pg_rewind in PostgreSQL 9.5
#5Earlier quoted context omitted.
? MSSQL mirroring failover is very easy and painless( arguably one of best compared to other rdbms), just make sure not to do automatic failover as that can cause false failover with spotty network between nodes and witness.
Sorry about that, I was referencing failing back over to the primary after failing over to the secondary. Specifically from the post: - Cool. And how do I fail back to the old master? - Umm, well, you have to take a new base backup from the new master, and re-build the node from scratch..
The post is about Postgres, you were referring to MSSQL mirroring, which can fail back from primary to secondary and back to primary almost seamlessly, depending on type of failure and log catchup.
Postgres has been a pain as described in the article.......
Re: pg_rewind in PostgreSQL 9.5
#6how does mysql failover compare in this regard?
Re: pg_rewind in PostgreSQL 9.5
#7One pain point we have run into is the inability to fail over to a previous master that only has access to other WAL logs. That is, we have nodes that can see each other's WAL logs, but not each other's full database. Last master can come back alone, a previous slave can come back alone, but a node that went down as master and came back after having missed transactions apparently cannot.
Re: pg_rewind in PostgreSQL 9.5
#8ActorDB is an interesting project that operates on distributed SQLite database. It tries to provide clustering between instances and it does it by continuously replicating the WAL between nodes.
I am not affiliated with the project, but just saw it the other day and thought it was a pretty cool pattern:
Here is the excerpt from their description page:
---
Actors are replicated using the Raft distributed consensus protocol. The way we have integrated Raft with the database engine is by replicating the WAL (write-ahead log). Every write to the database is an append to WAL. For every append we send that data to the entire cluster to be replicated. Pages are simply inserted to WAL on all nodes. This means the master executes the SQL, but the slaves just append to WAL.
If a server is very stale or is added new, ActorDB will first send the base actor file to the new server, then it will send the WAL pages (if there are any).
We use a combined WAL file for all actors. This means even with potentially thousands of actors doing writes at the same time, the server will not be appending to thousands of files at once. All writes are appends to the same file and that performs very well.
---
Would this work for PG replication as well I wonder?
Re: pg_rewind in PostgreSQL 9.5
#9This looks like a great tool, but it's also a sour reminder that replication still feels a lot like open heart surgery on postgresql.
Why can't we just type "enslave 10.0.0.2" into psql and have the computer do the hard work? The machinery is "almost there" for a half a decade now. Who do we have to bribe (wink wink, nudge) to bring the UX into a state where crutches like pg_rewind are not needed?
Re: pg_rewind in PostgreSQL 9.5
#10how does mysql failover compare in this regard?
This looks similar* to replication w/GTIDs + transactional replication (both MySQL 5.6 features).
* MySQL replication works a little different by using binary logs.