Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
actually you should not worry about synchronizing between your node1 and node2. Well I know you also known about this but just to make sure that we are on the same page. Because during your node2 in an offline/shutdown mode, the node1 of course will taking care of your synchronization of the data. As soon as node2 back online, node2 will sync it from the node1, therefore you will get the same database again as what you expected this DRBD is here in the first place. You should combine it with the heartbeat to make it even more usable in terms of downtime and taking over for this kind of situation. On Sat, Mar 20, 2010 at 12:38 AM, Digimer <linux at alteeve.com> wrote: > On 10-03-19 11:24 AM, Yuri Ushakov wrote: > >> 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. >> > > Hmm, it seems like it's a bit outside of the original goal of DRBD, but it > might be doable via the 'on-io-error' or 'fencing' options. Take a look at > this: http://www.drbd.org/users-guide/re-drbdconf.html > > > -- > Digimer > E-Mail: linux at alteeve.com > AN!Whitepapers: http://alteeve.com > Node Assassin: http://nodeassassin.org > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20100322/60515bde/attachment.htm>