This looks like a great tool, but it's also a sour reminder that replication still feels a lot like open heart surgery on postgresql.<p>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?
ActorDB 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.<p>I am not affiliated with the project, but just saw it the other day and thought it was a pretty cool pattern:<p><a href="http://www.actordb.com/" rel="nofollow">http://www.actordb.com/</a><p>Here is the excerpt from their description page:<p>---<p>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.<p>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).<p>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.<p>---<p>Would this work for PG replication as well I wonder?
If you are performing a planned failover then the old master can be turned into a slave without extra tools or steps. Simply shut down the master first. As part of this process it waits until the slave has the necessary wal.<p>pg_rewind will be great for remastering under other scenarios (unexpected failovers, etc.)
It's nice to see a lot of work being put into mirroring replication in the PostgreSQL 9.0 line, but until better admin tools are there I'll probably just keep using corosync and pacemaker with a shared fiber channel volume for clustering. Sure, it's cold standby, but it only takes a couple seconds for a standby node to come up and I just have to keep my WAL backups like normal for recovery.
One 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.
I don't get it. Why is it a problem taking a pg_basebackup of the new master to re-seed the old master (which is now a slave) and then promoting it to master again?<p>Or does pg_rewind offer a way to do this that doesn't require taking the current master offline when you promote a slave?
Can anyone comment on how this compares to postgres-BDR?<p>I'm in the market for an asynchronous multi-master RDBMS to cope with a dozen masters and huge (~800ms) latencies - i think my best bets are either BDR or maybe the Cassandra storage engine for MariaDB.
every step forward in modern relational DBs for reliability is a step backwards for operations and the simplicity of the model. If you're steeped in the ecosystem and know how things "used to be" you don't see how insane things actually are. Forrest, trees, etc.