Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
I need synchronous replication over network, but with one strict rule - if DRBD says something is written, it should already be written to both nodes. When secondary is down, and DRBD is still writing to the primary - that is not really synchronous replication. That behaviour makes it asynchronous, because actual write to the secondary node is delayed. In general, I want to ensure that when database transaction is commited, the data rests on both nodes. If secondary is unavailable, transaction should be rolled back. Thanks, Yuri. On 19 March 2010 14:15, Digimer <linux at alteeve.com> wrote: > On 10-03-17 06:35 AM, Yuri Ushakov wrote: > >> Hello, >> >> Is it possible to block write to primary node when secondary is not >> available? >> >> That is, suppose PostgreSQL asks the filesystem to write some bytes. I'd >> like drbd to reply with "write OK" *only* if the data is written to both >> nodes. If secondary is unavailable because of network error, reply >> should be "not written". >> >> What I understood from reading the docs is that unavailable secondary is >> considered non-critical, and drbd continues writing to primary. >> >> Tested that as well - drbdadm disconnect resource, and primary can still >> write to mounted device. >> >> Can this behaviour be changed? >> >> Thanks for help, >> Yuri. >> > > That would largely defeat the purpose of DRBD. When the second node > disappears, the remaining node gets a "dirty" inode list in memory. When the > node returns, it knows exactly what needs to be updated and syncs the > missing data. This sync operation brings the other node back to being > identical to the good node. > > What, exactly, are you trying to accomplish? > > -- > Digimer > E-Mail: linux at alteeve.com > AN!Whitepapers: http://alteeve.com > Node Assassin: http://nodeassassin.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20100319/df8be5e4/attachment.htm>