On Mon, Oct 18, 2010 at 4:31 AM, Fujii Masao masao.fu...@gmail.com wrote:
But, even though we will have done that, it should be noted that WAL in
A might be ahead of that in B. For example, A might crash right after
writing WAL to the disk and before sending it to B. So when we restart
the old
On Thu, Oct 14, 2010 at 8:23 AM, fazool mein fazoolm...@gmail.com wrote:
The concept of time line makes sense to me in the case of asynchronous
replication. But in case of synchronous replication, I am not so sure.
When a standby connects to the primary, it checks if both have the same time
Fujii Masao masao.fu...@gmail.com writes:
But, even though we will have done that, it should be noted that WAL in
A might be ahead of that in B. For example, A might crash right after
writing WAL to the disk and before sending it to B. So when we restart
the old master A as the standby after
I believe we should come up with a universal solution that will solve
potential future problems as well (for example, if in sync replication, we
decide to send writes to standbys in parallel to writing on local disk).
The ideal thing would be to have an id that is incremented on every failure,
On Wed, Oct 13, 2010 at 04:23:57PM -0700, fazool mein wrote:
Hello guys,
The concept of time line makes sense to me in the case of asynchronous
replication. But in case of synchronous replication, I am not so sure.
When a standby connects to the primary, it checks if both have the same
Hello guys,
The concept of time line makes sense to me in the case of asynchronous
replication. But in case of synchronous replication, I am not so sure.
When a standby connects to the primary, it checks if both have the same time
line. If not, it doesn't start.
Now, consider the following
