TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

pg_rewind in PostgreSQL 9.5

243 点作者 willlll大约 10 年前

11 条评论

moe大约 10 年前
This looks like a great tool, but it&#x27;s also a sour reminder that replication still feels a lot like open heart surgery on postgresql.<p>Why can&#x27;t we just type &quot;enslave 10.0.0.2&quot; into psql and have the computer do the hard work? The machinery is &quot;almost there&quot; 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?
评论 #9254536 未加载
评论 #9254491 未加载
评论 #9253853 未加载
评论 #9254088 未加载
rdtsc大约 10 年前
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:&#x2F;&#x2F;www.actordb.com&#x2F;</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?
评论 #9254462 未加载
nierman大约 10 年前
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.)
andyidsinga大约 10 年前
have to say - &quot;pg_rewind&quot; is nice and meta here on HN.<p>need to convince a postgres contributor to add easter egg &quot;pg_essay&quot;.
snuxoll大约 10 年前
It&#x27;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&#x27;ll probably just keep using corosync and pacemaker with a shared fiber channel volume for clustering. Sure, it&#x27;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.
keypusher大约 10 年前
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&#x27;s WAL logs, but not each other&#x27;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.
hobs大约 10 年前
Nice, definitely something that is a pain for mirroring in SQL Server, though if you have a good runbook its just time consuming and boring.
评论 #9253529 未加载
corford大约 10 年前
I don&#x27;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&#x27;t require taking the current master offline when you promote a slave?
mappu大约 10 年前
Can anyone comment on how this compares to postgres-BDR?<p>I&#x27;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.
iradik大约 10 年前
how does mysql failover compare in this regard?
评论 #9253877 未加载
评论 #9253842 未加载
bradhe大约 10 年前
every step forward in modern relational DBs for reliability is a step backwards for operations and the simplicity of the model. If you&#x27;re steeped in the ecosystem and know how things &quot;used to be&quot; you don&#x27;t see how insane things actually are. Forrest, trees, etc.
评论 #9254843 未加载