Hi, > it might not go online, due to the error: > new timeline N forked off current database system timeline M before current > recovery point X/X > [...] > In this case, node1 wrote to it's WAL record 0/304DC68, but sent to node2 > only record 0/304DBF0, then node2, being promoted to primary, forked a next > timeline from it, but when node1 was started as a standby, it first > replayed 0/304DC68 from WAL, and then could not switch to the new timeline > starting from the previous position.
Unless I'm missing something, this is just the right behavior of the system. node1 has no way of knowing the history of node1/node2/nodeN promotion. It sees that it has more data and/or inconsistent timeline with another node and refuses to process further until DBA will intervene. What else can node1 do, drop the data? That's not how things are done in Postgres :) What if this is a very important data and node2 was promoted mistakenly, either manually or by a buggy script. It's been a while since I seriously played with replication, but if memory serves, a proper way to switch node1 to a replica mode would be to use pg_rewind on it first. -- Best regards, Aleksander Alekseev